ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

external imu published by robot_pose_ekf for gmapping

asked 2014-03-05 14:34:01 -0500

chao gravatar image

updated 2014-03-05 14:40:07 -0500

Hi,

I am usng hydro with ubuntu 12.04.

I tried to install a microstrain imu 3DM-GX3-25 and publish the data using robot_pose_ekf and finally use the tf publish for gmapping. I uploaded the bagfile in dropbox. As you can see from the bagfile, the turtlebot location tends to vibrate/fluctuate in the map, i guess this is the reason why gmapping is not using robot_pose_ekf. Can anyone suggests me how I can improve this?

I am thinking to replace the imu data from mobile base with the imu data from microstrain imu. I suppose that this answer answers my question for roomba, how can i do it for kobuki base?

Thank you

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2014-03-05 15:25:23 -0500

tfoote gravatar image

robot_pose_ekf can work just fine with gmapping. Watching your bag playback it just looks like gmapping is having trouble converging. If you watch in the /odom frame everything looks pretty solid. With 10 seconds of decay on the laser scans they seem to blur ~ 10cm which is good.

You're driving through a very repetitive environment it's not too surprising that gmapping is updating it's estimates frequently while you're still exploring. You may also want to close some smaller loops and incrementally build up your map to help gmapping build up confidence incrementally. And tuning gmapping's parameters to make sure to match your robot is important.

edit flag offensive delete link more

Comments

noted, thanks alot. am i right to say that the odometry is provided by the imu data from the built in gyro and the twist from the wheel? so if the `/odom` itself is not accuate, the `robot_pose_ekf` will not be accurate not matter how good is the imu? in gmapping, i suppose that the best case is when `/odom` is close to the `/map`. however, often i could see that the `/odom` is moving away from `/map` as the time goes.

chao gravatar image chao  ( 2014-03-05 19:34:31 -0500 )edit

i have tried to use only laser scan with high decay and got the screenshots @ https://www.dropbox.com/sh/vu5deh28hdd9jpl/GaKpi233HS. there is original odom, one with both use_imu_heading and publish tf set true and one with use_imu_heading set true while publish tf set false. but all three seems about the same i think.

chao gravatar image chao  ( 2014-03-05 20:47:25 -0500 )edit

Odometry is expected to drift over time. You're going around a grid almost 10m on a side 4 times and your total drift is on the order of 3-4 meters. That's pretty good. That drift is what the localization should be compensating for.

tfoote gravatar image tfoote  ( 2014-03-05 21:10:12 -0500 )edit

noted, thanks alot :)

chao gravatar image chao  ( 2014-03-05 21:58:34 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2014-03-05 14:34:01 -0500

Seen: 1,040 times

Last updated: Mar 05 '14