ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A
Ask Your Question

Gmapping inconsistent between identical runs

asked 2014-05-01 03:56:05 -0500

BlitherPants gravatar image


I've been trying to get a decent map of an office building using gmapping on my Turtlebot 2(Kinect), ROS Hydro, Ubuntu 12.04

After posting this a few weeks ago, I had come to the conclusion that my gmapping runs were failing because my i3 laptop CPU wasn't fast enough; while running gmapping with a bagfile, I would see one of the cores jump to 100% usage and sit there for a few seconds. While doing this, I would suppose gmapping was missing vital updates. I somewhat confirmed this by slowing down my bagfiles, and this produced overall better, but still not entirely consistent, maps.

I have now obtained an i7 laptop (Dell Latitude E6410 -- 2.67 GHz x 4) to test with, and I figured this should be fast enough, but I am still not getting consistent results between playing the same bagfile back with the same arguments to gmapping.

For instance, compare these two images: image description image description

When creating the bagfile, I used keyboard teleop at the default speed, which is very slow. These two images are generated from the same bagfile, using the same gmapping parameters, and played back ten times slower.

If driving the robot at a slow speed, playing the bagfile back at a tenth of that, and running gmapping on an i7 processor does not produce identical results between identical runs, what does?

What worries and confuses me is that modern computers don't get all that much faster than the one I have. Yet people on here seem to be getting reasonable and consistent results. Am I missing something basic that everyone else understands? Do I need to use a separate lightning-fast desktop computer to run solely gmapping and publish the map and transforms back to the laptop? Is there a bug in gmapping that makes it produce different output between identical runs if the map is big?

My gmapping parameters, by the way, are the turtlebot demo defaults, with slightly reduced particles and increased map update interval:

  <arg name="scan_topic" default="scan" />

  <node pkg="gmapping" type="slam_gmapping" name="slam_gmapping" output="screen">
    <param name="base_frame" value="base_footprint"/>
    <param name="odom_frame" value="odom"/>
    <param name="map_update_interval" value="100"/>
    <param name="maxUrange" value="6.0"/>
    <param name="maxRange" value="8.0"/>
    <param name="sigma" value="0.05"/>
    <param name="kernelSize" value="1"/>
    <param name="lstep" value="0.05"/>
    <param name="astep" value="0.05"/>
    <param name="iterations" value="5"/>
    <param name="lsigma" value="0.075"/>
    <param name="ogain" value="3.0"/>
    <param name="lskip" value="0"/>
    <param name="srr" value="0.01"/>
    <param name="srt" value="0.02"/>
    <param name="str" value="0.01"/>
    <param name="stt" value="0.02"/>
    <param name="linearUpdate" value="0.5"/>
    <param name="angularUpdate" value="0.436"/>
    <param name="temporalUpdate" value="-1.0"/>
    <param name="resampleThreshold" value="0.5"/>
    <param name="particles" value="50"/>
    <param name="xmin" value="-50.0"/>
    <param name="ymin" value="-50.0"/>
    <param name="xmax" value="50.0"/>
    <param name="ymax" value="50 ...
edit retag flag offensive close merge delete


The fact that you are seeing inconsistent results is probably because the algorithm is at its limits--not necessarily computation performance-wise, but maybe regarding the capabilities of the parameter setup, sensors, and algorithm.

dornhege gravatar image dornhege  ( 2014-05-01 09:31:09 -0500 )edit

Multiple runs mean you'll have different random seeds and messages might get lost. Missing a single laser scan at a critical point can be bad.

dornhege gravatar image dornhege  ( 2014-05-01 09:31:42 -0500 )edit

Thanks... any guesses as to what would cause a missed scan? I could raise the linear/angular update and decrease the particle count more, but won't that ruin my chances of getting a decent map? The gmapping authors mapped out pretty large areas, but I guess it could be better equipment, maybe?

BlitherPants gravatar image BlitherPants  ( 2014-05-01 10:06:24 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2014-05-01 10:59:54 -0500

tfoote gravatar image

Gmapping like most robotics is probabilistic and optimization based. As @dornhege states if you are near the edge of convergence for your parameters even with the same inputs the stochastic behavior can give quite different outputs.

More info on gmapping can be found at:

edit flag offensive delete link more


Some of the links on the OpenSLAM site are either circular or broken, so I haven't gotten much use from it in the past. Another problem: the authors' results are with much more expensive hardware. I suppose by "edge of convergence" you mean things like updates are too frequent and too many particles

BlitherPants gravatar image BlitherPants  ( 2014-05-01 11:41:55 -0500 )edit

[cont] but I've tried it with several permutations and can't get consistently acceptable results. Which is why I ask if anyone could share params they've successfully used for a Kinect setup. Would it help the problem of missed scans if I got funding for an expensive laser? Thanks for the response..

BlitherPants gravatar image BlitherPants  ( 2014-05-01 11:44:36 -0500 )edit

The Kinect is very hard to do SLAM with as it has a very limited field of view and range. Both of which make slam much easier. So yes a proper laser range finder will make your life much easier. In addition most algorithms including gmapping were designed based on laser range finders and their properties.

tfoote gravatar image tfoote  ( 2014-05-01 12:37:29 -0500 )edit

This is also why you see a lot larger areas mapped. I'd claim all gmapping examples use laser scanner with at least 180 deg FOV.

dornhege gravatar image dornhege  ( 2014-05-01 23:27:47 -0500 )edit

Regarding parameter tuning: You'd have to find out what causes the mapping errors and then see if that can be fixed with parameters in a stable manner. Basically that means play the log to the critical point and review the data. Does the odometry jump badly? Have the scans consistent overlap?

dornhege gravatar image dornhege  ( 2014-05-01 23:30:21 -0500 )edit

Another point is: What do you want to achieve? Do you need to build one good map for localization or do you need SLAM during navigation? The latter is harder as it need to be always stable and not only succeed once.

dornhege gravatar image dornhege  ( 2014-05-01 23:30:56 -0500 )edit

By "critical point", do you mean the point at which the scan matching fails? My original goal has always been SLAM during navigation, but since I've been having so much trouble with that, I've at least been trying to make a good map with teleop first and navigate through that output.

BlitherPants gravatar image BlitherPants  ( 2014-05-02 03:20:36 -0500 )edit

I hope to get a better scanner, though cost is an issue. It looks like a Hokuyo would be my next cheapest option (and much better FOV), but it also is still considered short range and even mentioned on the gmapping site as such. Would I be wasting my time? Thank you both for the input, by the way...

BlitherPants gravatar image BlitherPants  ( 2014-05-02 03:25:42 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2014-05-01 03:56:05 -0500

Seen: 1,338 times

Last updated: May 01 '14