gmapping seems to ignore odometry data

Question

Hi,

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. http://www.youtube.com/watch?feature=player_embedded&v=yQfvObAAxZA#!

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 -

---

Update:

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 -

---

Originally posted by jgdo on ROS Answers with karma: 56 on 2012-06-06

Post score: 1

---

Original comments

Comment by allenh1 on 2012-06-06:
would you mind posting a bag file of your data?

Answer 1

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).

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).

---

Originally posted by allenh1 with karma: 3055 on 2012-06-06

This answer was ACCEPTED on the original site

Post score: 2

---

Original comments

Comment by jgdo on 2012-06-08:
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?)

Comment by jgdo on 2012-06-08:
How exactly did you get that map, especially the right one? As you can see in the bag file, I got pretty worse results..

Comment by allenh1 on 2012-06-08:
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

Comment by allenh1 on 2012-06-08:
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.

Comment by jgdo on 2012-06-08:
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.

Comment by jgdo on 2012-06-08:
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?

Comment by allenh1 on 2012-06-09:
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.

Comment by allenh1 on 2012-06-11:
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!