Rosanswers logo


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.0"/>
  make the starting size small for the benefit of the Android client's memory...
    <param name="xmin" value="-1.0"/>
    <param name="ymin" value="-1.0"/>
    <param name="xmax" value="1.0"/>
    <param name="ymax" value="1.0"/>

    <param name="delta" value="0.05"/>
    <param name="llsamplerange" value="0.01"/>
    <param name="llsamplestep" value="0.01"/>
    <param name="lasamplerange" value="0.005"/>
    <param name="lasamplestep" value="0.005"/>
    <remap from="scan" to="$(arg scan_topic)"/>

If anyone would like to share with me their working test setup, ie, type of computer(s) used and relevant parameters, I would greatly appreciate it. I know it won't be exactly ideal for my situation but I would like to at least see something that works.

Thanks in advance.

Originally posted by BlitherPants on ROS Answers with karma: 504 on 2014-05-01

Post score: 1

Original comments

Comment by dornhege on 2014-05-01:
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.

Comment by dornhege on 2014-05-01:
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.

Comment by BlitherPants on 2014-05-01:
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?


1 Answer 1


Rosanswers logo

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: http://openslam.org/gmapping.html

Originally posted by tfoote with karma: 58457 on 2014-05-01

This answer was ACCEPTED on the original site

Post score: 0

Original comments

Comment by BlitherPants on 2014-05-01:
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

Comment by BlitherPants on 2014-05-01:
[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..

Comment by tfoote on 2014-05-01:
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.

Comment by dornhege on 2014-05-01:
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.

Comment by dornhege on 2014-05-01:
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?

Comment by dornhege on 2014-05-01:
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.

Comment by BlitherPants on 2014-05-02:
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.

Comment by BlitherPants on 2014-05-02:
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...

Comment by dornhege on 2014-05-02:
We have equipped all our Turtlebots with Hokuyos. Depending on your environment the 5m max range might be sufficient. 240 degrees FOV vs. about 60 from Kinect does make a difference.

Comment by dornhege on 2014-05-02:
You can still try to get gmapping running or just try another SLAM algorithm. Hector_slam should also work out of the box. Just run it once and see how that behaves.

Comment by dornhege on 2014-05-02:
And yes - the critical point is where the maps gets the "bend".

Comment by BlitherPants on 2014-05-05:
I will try it, thanks. @dornhege, may I ask the size and style of your testing environment, please?

Comment by dornhege on 2014-05-05:
We've run in similar environments as yours. Office space, or a grid-arena of about 10x10m. This kind of structure is actually quite nice for SLAM. If your Kinect always sees at least one corner it should work.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.