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

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

asked 2019-01-25 05:37:36 -0500

VagZikopis gravatar image

updated 2019-01-25 06:02:12 -0500

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:

<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)"/>

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

KartoSlam(using odometry)

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

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. image description 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?
edit retag flag offensive close merge delete


Can you please attach your images directly to your post? I've given you sufficient karma to do that.

gvdhoorn gravatar image gvdhoorn  ( 2019-01-25 05:40:32 -0500 )edit

Thank you very much

VagZikopis gravatar image VagZikopis  ( 2019-01-25 06:02:37 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2019-04-05 06:35:23 -0500

VagZikopis gravatar image

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.

edit flag offensive delete link more

Question Tools

1 follower


Asked: 2019-01-25 05:37:36 -0500

Seen: 407 times

Last updated: Apr 05 '19