external imu published by robot_pose_ekf for gmapping

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

chao
153 ●22 ●26 ●35

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

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

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

tfoote

58457 ●128 ●550 ●526 http://www.ros.org/

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

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 ( 2014-03-05 19:34:31 -0600 )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 ( 2014-03-05 20:47:25 -0600 )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 ( 2014-03-05 21:10:12 -0600 )edit

noted, thanks alot :)

chao ( 2014-03-05 21:58:34 -0600 )edit

add a comment

external imu published by robot_pose_ekf for gmapping

1 Answer

Comments

Question Tools

Stats

Related questions

external imu published by robot_pose_ekf for gmapping edit

1 Answer

Comments

Question Tools

Stats

Related questions

external imu published by robot_pose_ekf for gmapping