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

gmapping seems to ignore odometry data [closed]

asked 2012-06-06 10:53:55 -0500

jgdo gravatar image

updated 2015-06-25 12:15:51 -0500

allenh1 gravatar image


I'm new to ROS and just managed to get the Kinect fake lasescan and a driver node for my robot hardware working. Now I tried the slam_gmapping to create a map of my room, but the map creation quality is far away from the maps you can see on youtube, e.g.

It seems to me like gmapping ignores the published odometry data and frames because the estimated position jumps the whole time. Even if the robot rotates on the same spot it happens that the estimated position jumps for around 30-40cm. The curious thing is that my odometry is quite good and the laser scans would fit absolutely perfectly to the available map without any jumping.

Is there a possibility to say gmapping that it should stick to the odometry and make only small corrections?

Thanks and regards - jgdo -


thanks four Your reply! I'm not using the turtlebot but a self made robot with kinect and a notebook, and I so don't have any calibration software for that. What does the turtlebot calibration do? At my robot i adjusted the odometery by manually driving and rotating and they seem to work good since i can drive around and when i come back to the original place, the computed coordinates are near to zero.

here is a bagfile containing scan, tf, odometry and the map.

As you can see at the beginning gmapping tries to match the new scans to the existing part of the map instead of extending it, which causes the estimated position to jump. To get a good map its is necessary to drive backwards to a corner so the kinect can see two opposite walls at same time.

I hope this data is enough for you, if not i can make a longer example, but the behavior is the same.

Thanks again and regards - jgdo -

edit retag flag offensive reopen merge delete

Closed for the following reason the question is answered, right answer was accepted by allenh1
close date 2015-06-25 12:31:08.056466


would you mind posting a bag file of your data?

allenh1 gravatar image allenh1  ( 2012-06-06 11:20:14 -0500 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2012-06-06 11:25:12 -0500

allenh1 gravatar image

updated 2012-06-08 06:34:05 -0500

From my experience with the turtlebot gmapping, the odometry needs to be calibrated (I'm sure you've already done that in the tutorial, but I have trouble here). I suggest manually editing the turtlebot.launch file to change the gyro parameter to about 2.38 [that's what works best for me]. Then, run the calibration file. If you can post a bag file,I can try to play with your data.

Hope this helps! -Hunter A.

With your bag, this is the map I made. It seems to me that your linear translation odometry is flawed (unless this is the environment).

image description image description

I'm going to look at your bag file further. In the mean time, here is the turtlebot calibration information. I know it's not a turtlebot, but you might be able to use this file in the mean time.

Ok. Found the issue. If you are using a gyro sensor, then that's what is messing up your map. The EKF uses the gyro and the odometry to get pose. When one of them is bad, the whole thing is bad. Consider adjusting your gyro sensor, or just completely removing it from the robot_pose_ekf configuration. If you're not using a gyro, just let me know.

Edit the file in /etc/ros/electric/turtlebot.launch:

$ sudo nano /etc/ros/electric/turtlebot.launch

The parameters that currently exist (most likely 1.0 for both) you need to multiply with the output numbers. Then, save the file (control + o) and restart turtlebot services.

$ sudo service turtlebot stop 
$ sudo service turtlebot start

(If you have not configured it to startup automatically, then just reboot your system).

edit flag offensive delete link more


I have tried the calibration and it said "Multiply the 'turtlebot_node/odom_angular_scale_correction' parameter with 1.007505". What do I have to do with this value now?

My robot does't have a gyro yet, so it can't mess up anything (or can it?)

jgdo gravatar image jgdo  ( 2012-06-08 06:26:47 -0500 )edit

How exactly did you get that map, especially the right one? As you can see in the bag file, I got pretty worse results..

jgdo gravatar image jgdo  ( 2012-06-08 06:33:07 -0500 )edit

I used gmapping. Because I have a fast computer, I changed the parameters for mapping: rosrun gmapping slam_gmapping _particles:=300 _linearUpdate:=0.01 _angularUpdate:=0.001

allenh1 gravatar image allenh1  ( 2012-06-08 06:57:47 -0500 )edit

If you want me to map the whole thing, I can definitely do that for you. Just increase the size of your bag file. Do a couple loops.

allenh1 gravatar image allenh1  ( 2012-06-08 07:01:25 -0500 )edit

Ok it has to do something with the number of particles you use. If I set it to 300 I get a god map, at 100 a bad one (loop closing doesn't work then). But I wonder how fast your computer is, I have a i3 2100 with 3.1 GHz and I had to slow down the whole playback to r = 0.05 to get good results.

jgdo gravatar image jgdo  ( 2012-06-08 11:04:03 -0500 )edit

Btw. I have a selfmade motor controller connected to the notebook and not a roomba, so I don't use the turtlebot driver at all but a custom driver node. Is it right that you just have to multiply delta(angle) by odom_angular_scale_correction when doing the odometry calculation?

jgdo gravatar image jgdo  ( 2012-06-08 11:13:24 -0500 )edit

That's a little out of my knowledge area... I'll investigate the answer to that. I am running a Core i7 with 3.1 Ghz.

allenh1 gravatar image allenh1  ( 2012-06-09 15:41:20 -0500 )edit

Ok. I have confirmation with respect to the scale_correction parameters. You multiply by the deltas before update. That's it! All you need to do!

allenh1 gravatar image allenh1  ( 2012-06-11 04:54:20 -0500 )edit

answered 2012-06-08 05:11:35 -0500

dornhege gravatar image

The odom from the bag looks reasonably accurate to me.

Driving backwards might be a problem. If that is not in the motion model that gmapping has, there is no chance to estimate that correctly. Did you see any error outputs when running gmapping?

edit flag offensive delete link more


No I just get the standard messages like "Registering Scans:Done"

jgdo gravatar image jgdo  ( 2012-06-08 06:51:07 -0500 )edit

Question Tools



Asked: 2012-06-06 10:53:55 -0500

Seen: 2,032 times

Last updated: Jun 25 '15