Ask Your Question
2

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

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

VagZikopis gravatar image

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

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

Comments

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

gvdhoorn gravatar imagegvdhoorn ( 2019-01-25 05:40:32 -0600 )edit

Thank you very much

VagZikopis gravatar imageVagZikopis ( 2019-01-25 06:02:37 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted
0

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

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

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

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

Seen: 110 times

Last updated: Apr 05