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

Gmapping failure culprit -- parameters, odometry, sensors?

asked 2014-03-31 05:03:06 -0500

BlitherPants gravatar image

updated 2016-10-24 09:09:58 -0500

ngrennan gravatar image


I am running ROS Hydro on a Turtlebot 2 (Kobuki + Kinect)

I have been trying to use teleop + gmapping to get a decent map of my cubicled office building, but after slowly perimeter-driving and looping back through several hallways, inevitably, the map will eventually do something absurd like this: image description

I started with the first two hallways on the right, constantly weaving in and out of cubicles and repeating areas. The picture of those hallways really isn't bad, but when I started exploring the third vertical hallway after 30+ minutes, gmapping suddenly decided to create that horizonal hallway beginning to form on the bottom-left, which is extremely off. Anything after that point in time got progressively worse.

This happens fairly frequently when things seem to be going otherwise well.

The following are my gmapping parameters:

  <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="2.0"/>
    <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.2"/>
    <param name="angularUpdate" value="0.1"/>
    <param name="temporalUpdate" value="-1.0"/>
    <param name="resampleThreshold" value="0.5"/>
    <param name="particles" value="100"/>

    <param name="xmin" value="-30.0"/>
    <param name="ymin" value="-30.0"/>
    <param name="xmax" value="30.0"/>
    <param name="ymax" value="30.0"/>

    <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)"/>

I have changed very little from the default turtlebot configuration, besides lowering the linear/angular update, slightly increasing the number of particles, and decreasing the map update interval.

Since I know that a failure in scan matching causes gmapping to rely on odometry, I wonder if my odometry is decent enough. I ran the test suggested in the navigation tuning guide ( ):

  • I booted up minimal.launch, keyboard_teleop.launch , gmapping_demo.launch, and view_navigation_app.launch
  • In rviz, I set the global frame to odom, turned off all costmaps, and put the decay time on /scan to 600s.

I did all the following tests at the lowest teleop speed.

This is the result of performing three rotations in my standard-sized cubicle: image description

Entrance to cubicle, staring at wall ~5ft away: image description

Drove straight towards wall: image description

Circled ... (more)

edit retag flag offensive close merge delete



Looking at the images you posted, it seems like the odometry isn't very good, so maybe using higher values of parameters srr, str and in particular of srt and stt could help... Can you try? Moreover the kinect sensor has a small fov and obviously a laser scan with larger fov would perform much better.

Tirjen gravatar image Tirjen  ( 2014-04-01 03:05:59 -0500 )edit

Is there any good way to figure out exactly how much str, etc should be changed? The method I'm using (accumulating laser scans with odom as the fixed frame) won't visibly reflect those changes...

BlitherPants gravatar image BlitherPants  ( 2014-04-01 04:30:44 -0500 )edit

Just try to move around the robot and see map result... i would rise srt and stt to something like 0.5 and the other two to 0.2... Otherwise, did you try to use those parameters?

Tirjen gravatar image Tirjen  ( 2014-04-01 21:06:13 -0500 )edit

The link is broken, but if you see the default turtlebot gmapping file I posted above, srr = 0.01, srt = 0.02, str = 0.01, stt = 0.02. I will try your suggestions.

BlitherPants gravatar image BlitherPants  ( 2014-04-02 03:45:18 -0500 )edit

My question was about seeing it line up to know I have them at good values, since those params affect gmapping and not my method of raw laserscans and odometry. Maybe launching gmapping with a particle count of 1 would show how good the alignment is?

BlitherPants gravatar image BlitherPants  ( 2014-04-02 03:46:26 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2014-04-14 04:40:02 -0500

BlitherPants gravatar image

updated 2014-04-14 04:54:28 -0500

I believe the answer to my question may be "None of the Above"!

I have written a script to replay a bag file to gmapping with several permutations of the error values, and what I've found is that I can't get consistent results with any set of parameters -- not even between identical arguments to gmapping.

What does matter is the speed at which I play back the bag file. I have found that slowing the sensor data down to 1/5 of the speed or so, has a chance of giving me a decent result for even a large-scale test. I managed to get this result in that way:

image description

I had noticed during the testing of gmapping that the load on one of my four 1.4GHz cores would frequently spike and remain at 100% for a while. The other cores were not overloaded, but I now wonder if gmapping actually has the capability to properly distribute the load or not. See this question for a similar problem:

Either way, I do believe I will need a better laptop in the future if I want even a chance of getting gmapping to work online.

edit flag offensive delete link more


AFAIK gmapping is single threaded, so the 100% CPU is gmapping being at the limits, probably missing updates. Lowering angular/linear_update and increasing particles might have made things worse.

dornhege gravatar image dornhege  ( 2014-04-14 04:50:28 -0500 )edit

That's what I figured, thanks. Do you know what the minimum CPU requirements are for gmapping, by any chance?

BlitherPants gravatar image BlitherPants  ( 2014-04-14 09:10:09 -0500 )edit

It is nice information to know. Thanks for sharing :)

jihoonl gravatar image jihoonl  ( 2014-04-14 22:22:48 -0500 )edit

It's probably hard to state CPU requirements as those depend on the parameters set (e.g. update freq, particles) and those in turn depend on how hard the combination of environment + sensors is.

dornhege gravatar image dornhege  ( 2014-04-15 04:23:30 -0500 )edit

True...I think I should have rephrased the question to ask if you or anyone else had a CPU that worked well in general for them.

BlitherPants gravatar image BlitherPants  ( 2014-04-15 04:44:59 -0500 )edit

The best way to figure this out might be how you did it. Play the log file as slow as possible to ensure that no data is skipped, so that you see the algorithm performance and not the CPU performance. Then adjust the parameters to a minimal working set for the environment/sensors.

dornhege gravatar image dornhege  ( 2014-04-15 05:35:34 -0500 )edit

The CPU that you'd need then must be fast enough to stay below 100% load.

dornhege gravatar image dornhege  ( 2014-04-15 05:35:58 -0500 )edit

Thanks. I am in the process of getting a better laptop, so I guess I'll see how that works.

BlitherPants gravatar image BlitherPants  ( 2014-04-15 05:55:56 -0500 )edit

Question Tools

1 follower


Asked: 2014-03-31 05:03:06 -0500

Seen: 2,066 times

Last updated: Apr 14 '14