Search code examples
rosslam

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

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

Gmapping (using odometry) I 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 here: enter image description here

KartoSlam(using odometry) The map produced by KartoSlam tested in a lab's room with the default parameters is this. enter image description here

CRSM Slam (no odometry used) The map produced by CRSM Slam tested in a lab's room, which does not use odometry is this. As you can see the CRSM map is far better than the previous two. enter image description here

The questions :

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

Solution

  • I find that a good way to test the basic odometry is:

    1. Launch the turtlebots with just minimal no gmapping or any other slam.
    2. Start rviz and make sure the fixed frame is set to a world frame like odom or map (verify the name from your TF tree).
    3. Add the laser to it and set a Decay Time of about 100 secs.
    4. Keep the robot infront of a wall and command it to move towards the wall. As the robot moves forward the 'position of the wall' in the laser data in your world frame should look more or less stationery. This gives you the assurance that your forward odometry is ok.
    5. Then put the robot near a corner or someplace where there are big 3D objects in the laser's view. Then command the robot to rotate. Once again all the corners and 3D objects should stay stationary.

    If you can do the above successfully then you should be able to make reasonable 'raw' maps before using any SLAM algorithms.