Rosanswers logo

Hey everyone

I am working with the ROS Navigation stack using a simulated environment in Stage. Initially I would have created a topic criticizing the precision of the AMCL localization stack, but after deeper research I found the error to occur from the map I have created with the GMapping.
The following image shows the comparison between the ideal image (blue) and the resulting map from GMapping (red). Interesting enough the data fed into the GMapping process are all ideal, no error in either the odometry or the laser scans.
Besides setting the number of particles to 150 I use the standard settings when executing the GMapping process. Actually I have tried to reduce the update frequency in the translation and angular rotation, but it did not change alot.

Comparision http://s8.postimage.org/eeg3w3qtx/autolab_compare.png

I have also tried to visualize quite primitively how I have traveled through the area. The black dot is the start and the numbers shows the order in which the different areas have been explored.

Comparision http://s11.postimage.org/t5eihk9zn/autolab_compare_path.png

Does anyone have any idea to how to improve the result of the GMapping process? So far it does not seem that impressive.

Sebastian Aslund

P.s my laser scanner is modeled to a SICK LMS200 with a range at 8m.
P.p.s Maybe it was an idea to show the results between a higher update frequency. The red figure shows the map with the standard update intervals. In the blue map the linear update is set to 0.2 and the angular update is set to 0.1.

Comparision http://s7.postimage.org/lyx68iaaz/map_cpm10vs02.png

Originally posted by Aslund on ROS Answers with karma: 289 on 2012-07-18

Post score: 4

Original comments

Comment by joq on 2012-07-18:
Does it help to add more particles?

Comment by allenh1 on 2012-07-18:
Depends. At 100 particles, I get improved results; however, at 150 I loose those results. I usually use this to start gmapping: rosrun gmapping _particles:=100 _linearUpdate:=0.1 _angularUpdate:=0.1.

Comment by Aslund on 2012-07-18:
I have already increased the number of particles from 30 (the default value) to 150. But I can try raising it to 500 or so and see what happens.

Comment by allenh1 on 2012-07-18:
You might want to create an entropy publisher to set it to 0. This can also help.

Comment by Aslund on 2012-07-18:
What do you exactly mean by "create an entropy publisher to set it to 0"?

Comment by allenh1 on 2012-07-18:
Entropy is a new topic in slam. It is a float64. The higher the entropy, the worse the odometry. If your odometry is perfect, then 0 will notify gmapping of this.

Comment by tsdk00 on 2019-04-12:
@allenh1 While doing Hector_mapping, the odometry data gets totally ignored. So, how were you able to achieve the map with hector mapping using odometry?


3 Answers 3


Rosanswers logo

I mapped with hector slam. Using odometry with it, I was able to create this map:

image description

This is pretty close to the original. I don't have the ground truth image, so I cannot make any comparison locally, but, trusting my eyes, it seems to be a pretty good one. Playing with parameters in a launch file, you can probably improve it. Here is the launch file I used to create the above:

<?xml version="1.0"?>


  <node pkg="hector_mapping" type="hector_mapping" name="hector_mapping" output="screen">
    <!-- Topic names -->
    <param name="scan_topic" value="base_scan" />    
    <!-- Frame names -->
    <param name="base_frame" value="base_laser_link" />
    <param name="odom_frame" value="odom"/>
    <param name="output_timing" value="false"/>
    <!-- Tf use -->
    <param name="use_tf_scan_transformation" value="true"/>
    <param name="use_tf_pose_start_estimate" value="false"/>
    <param name="pub_map_odom_transform" value="true"/>
    <param name="advertise_map_service" value="true"/>
    <!-- Map size / start point -->
    <param name="map_resolution" value="0.050"/>
    <param name="map_size" value="2048"/>
    <param name="map_start_x" value="0.5"/>
    <param name="map_start_y" value="0.5" />
    <param name="map_multi_res_levels" value="2" />
    <!-- Map update parameters -->
    <param name="update_factor_free" value="0.4"/>
    <param name="update_factor_occupied" value="0.9" />    
    <param name="map_update_distance_thresh" value="0.4"/>
    <param name="map_update_angle_thresh" value="0.06" />
    <!-- Debug parameters -->
      <param name="pub_drawings" value="true"/>
      <param name="pub_debug_output" value="true"/>

  <node pkg="hector_trajectory_server" type="hector_trajectory_server" name="hector_trajectory_server" output="screen">
    <param name="target_frame_name" type="string" value="/map" />
    <param name="source_frame_name" type="string" value="/base_link" />
    <param name="trajectory_update_rate" type="double" value="4" />
    <param name="trajectory_publish_rate" type="double" value="0.25" />

  <node pkg="hector_geotiff" type="geotiff_node" name="hector_geotiff_node" output="screen" launch-prefix="nice -n 15">
    <remap from="map" to="/dynamic_map" />
    <param name="map_file_path" type="string" value="$(find hector_geotiff)/maps" />
    <param name="map_file_base_name" type="string" value="hector_slam_map" />
    <param name="geotiff_save_period" type="double" value="10" />
    <param name="draw_background_checkerboard" type="bool" value="true" />
    <param name="draw_free_space_grid" type="bool" value="true" />


To run the bag in simtime, use this command:

rosbag play <bagfile>.bag --clock

Originally posted by allenh1 with karma: 3055 on 2012-07-18

This answer was NOT ACCEPTED on the original site

Post score: 1

Original comments

Comment by metal on 2012-07-18:
Hi there, I am working on a similar work. I am using LMS200 for my robot. I would like to know ,how did u implement the navigation stack in ros. Here is my email id: [email protected]. This would make it easier for us to communicate. Thanks.

Comment by Aslund on 2012-07-18:
If you are asking how to install the Hector-slam stack, then the process is quite simple. For fuerte you can download the stack here: http://tu-darmstadt-ros-pkg.googlecode.com/svn/branches/fuerte/. For other you can use: http://tu-darmstadt-ros-pkg.googlecode.com/svn/trunk/hector_slam/.

Comment by Aslund on 2012-07-18:
The rest is decribed here: http://www.ros.org/wiki/hector_slam. Ps. if you are talking concretely about the foundamental navigation part, then this tutorial makes it all a walk in the park: http://www.ros.org/wiki/navigation


Rosanswers logo

-- Second update to the responces --

Since it seemed that there were a consensus that higher particle count is not the way to go, then I went back to the beginning. I tried off with a particle count at 30, the default value. Instead the updates were lowered to 0.01. This results in the command _particles:=30 _linearUpdate:=0.1 _angularUpdate:=0.1 and the returned map is displayed below.

Comparision http://s11.postimage.org/lk32yireb/autolab_compare_path_30_01_01_no_Error.png

I began to wonder. Now all my tests have been based on the ideal values, so I tried the same parameters on the noisy data. This gives the following map:

Comparision http://s16.postimage.org/h4hhuxy3p/autolab_compare_path_30_01_01.png

The result in very surprising, especially because my noise is mostly focused on error in the rotation. It might be due to optimizations in the GMapping code towards noisy data, which might cause ideal data to be regarded as even more erroneous than actual erroneous data.
Below is the development in error. The seconds are reported 100 times to high, minor visualization error. Comparision http://s15.postimage.org/56wu2rmmj/Odometry_error_development.png

Secondly I have tried off the Hector SLAM mapping using the launch file supplied by allenh1. Somehow it did not work at all when i set the parameter "rosparam set use_sim_time true", so I had to run it without. With this I can only use the ideal values, I need simulation time to test with the noisy data.
Nevertheless I got the same results as allenh1 and here is the comparison with the ground truth:

Comparision http://s17.postimage.org/9645ftnxb/autolab_compare_path_hector.png

Since the tutorial launch file in Hector_SLAM sets use_sim_time to true I guessed this could the same, but apparently not, any obvious reasons why? The initial tests shows a good result using this SLAM method.

Edit: Thanks to the tip from Stefan I got Hector SLAM up and running with my erroneous data. Time to time I get a strange error:
Transform failed during publishing of map_odom transform: Unable to lookup transform, cache is empty, when looking up transform from frame [/base_laser_link] to frame [/odom_error]

Apparently it does not affect the mapping, but there is no visualization of the path. The result map is:

Comparision http://s16.postimage.org/pqrxf828l/autolab_compare_path_hector_error.png

It seems the long narrow path between waypoint 4 and 5 (see my original post) causes the SLAM process to become lost quite easily.
I tried to omit the odometry from the Hector mapping, while it removed some problems it brought new ones.

Comparision http://s8.postimage.org/npass98at/autolab_compare_path_hector_error_no_Odom.png

Regards and thanks

Sebastian Aslund

Originally posted by Aslund with karma: 289 on 2012-07-18

This answer was ACCEPTED on the original site

Post score: 0

Original comments

Comment by Stefan Kohlbrecher on 2012-07-18:
Do you play back your bagfile with the --clock option appended? If not, sim time will not be published by rosbag and this can lead to all sorts of problems.

Comment by Aslund on 2012-07-18:
Thanks Stefan it solved the problem, I have updated my post with the noisy data.

Comment by Stefan Kohlbrecher on 2012-07-18:
Hector_Slam does not use odometry for state estimation, so it should not matter if odometry is available or not. How did you generate your noisy data?

Comment by Aslund on 2012-07-18:
My noisy data is generated quite simply. I read the laser data, add a noise based on a normal distribution to each range and finally publish to a seperate topic, here "base_scan_error". For the odometry I create a new frame "odom_error" with reference to "odom".

Comment by Aslund on 2012-07-18:
The "odom_error" frame is updated at each new speed command. Using the translational and rotational speed the error in each is calculated using a set of weights and sampled through a normal distribution. The pose in "odom_frame" is then updated with the calculated speed error and the time step.


Rosanswers logo

Not sure if you've got the same issue I had - but my fix here was to set the minimumScore parameter to a very large value.

Originally posted by zsaigol with karma: 225 on 2014-08-06

This answer was NOT ACCEPTED on the original site

Post score: 3


Your Answer

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