4

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?

gonidelis
  • 885
  • 10
  • 32
  • Are your transformations between the odometry, base and laser frame correct? Have you done mapping with pure odometry, to see if you have systematic errors in the odometry signals? – Tik0 Jan 25 '19 at 16:22
  • @Tik0 How could I ensure that the transformations are correct? I just rely on the transformations that are already made by the algorithms that I choose to run. What more should I check? As I mentioned I tried to change the base so I ran the algorithms with 2 different bases and the outcome is the same. – gonidelis Jan 25 '19 at 17:03
  • Please ensure that all your transformations and messages comply with [REP-105](http://www.ros.org/reps/rep-0105.html). However, [here](https://answers.ros.org/question/237295/confused-about-coordinate-frames-can-someone-please-explain/?answer=237330#post-id-237330) you'll find also some advice regarding the odometry. Also, you have the tool [rviz](http://wiki.ros.org/rviz) and [roswtf](http://wiki.ros.org/roswtf) for debugging frames. But first I would just draw the odometry messages to see if they make sense in the first place. If they show systematic errors, they could taint your SLAM. – Tik0 Jan 25 '19 at 18:05

1 Answers1

1

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.

Miroslav Glamuzina
  • 4,472
  • 2
  • 19
  • 33
Vik
  • 690
  • 7
  • 22