Poor quality maps produced from odometry based slam algorithms tested in real TurtleBot

Question

We are currently testing several slam algorithms in a real TurtleBot(ROS Kinetic). Despite the fact that everything seems to be working fine on TurtleBot we have come across a problem on the maps coming from odometry based slam algorithms. Although we changed the TurtleBot base to figure out whether the base had hardware or odometry issues, the maps remained the same. The lidar we use has maximum range up to 17m.

Gmapping (using odometry)

We tested gmapping with these parameters:

<launch>
<arg name="scan_topic"  default="scan" />
<arg name="base_frame"  default="base_footprint"/>
<arg name="odom_frame"  default="odom"/>
<node pkg="gmapping" type="slam_gmapping" name="slam_gmapping" output="screen">
<param name="base_frame" value="$(arg base_frame)"/>
<param name="odom_frame" value="$(arg odom_frame)"/>
<param name="map_update_interval" value="5.0"/>
<param name="maxUrange" value="12.0"/>
<param name="maxRange" value="17.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="minimumScore" value="500"/>
<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="200"/>
<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)"/>
</node>
</launch>

The map from Gmapping tested in the whole lab is the following.

KartoSlam(using odometry)

The map produced by KartoSlam tested in a lab's room with the default parameters is the following.

CRSM Slam (no odometry used)

The map produced by CRSM Slam tested in a lab's room, which does not use odometry is the following. As you can see the CRSM map is far better than the previous two.

---

The questions :

1. Where shall we look for the fix, since we have tried the algorithms on two different TurtleBots?
2. How could we improve the map quality, since what we get so far is really poor?

---

Originally posted by VagZikopis on ROS Answers with karma: 51 on 2019-01-25

Post score: 2

---

Original comments

Comment by gvdhoorn on 2019-01-25:
Can you please attach your images directly to your post? I've given you sufficient karma to do that.

Comment by VagZikopis on 2019-01-25:
Thank you very much

Answer 1

Solved Found out that gmapping was getting input from the 3d Sensor and not the Lidar. The problem was that gmapping_demo(from turtlebot_navigation) was working with an asus_xtion_pro_3dsensor.launch file which was causing the problem. In order to solve it, we made a launch file where we were turning up only the gmapping node from slamgmapping package. This node was taking input from the Lidar and the results where fixed.

---

Originally posted by VagZikopis with karma: 51 on 2019-04-05

This answer was ACCEPTED on the original site

Post score: 0