Gmapping inconsistent between identical runs
Hello,
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:
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:
<launch>
<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 ...
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.
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.
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?