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

Revision history [back]

click to hide/show revision 1
initial version

-- 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

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

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

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

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.

Regards and thanks

Sebastian Aslund

-- 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

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

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

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

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

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

Regards and thanks

Sebastian Aslund