# Is this SLAM performance typical or am I doing something wrong?

I'm experimenting with SLAM for the first time. I am using ROS on a Turtlebot3, which has a Raspberry Pi and a single Lidar sensor, Robotis LDS-01. I am running a configuration with three computers, the Pi, a computer running just Roscore and a computer where I do my development. I have a very simple maze set up covering around a 3x3M carpeted area. I am using gmapping to make the map. As I am a remote worker, I've not had an "expert" looking over my shoulder although I am very active on boards to ask questions.

My experience with SLAM is that I am not impressed with the results so far. I've been following these instructions from Robotis as a starting point.

I run gmapping and traverse the maze completely and do get a map that is pretty accurate although the resolution is I think 5x5cm by default so its a little rough. Its super simple.

But then I save the map and run navigation, using move_base, amcl and map_server. To my eye the results are not impressive:

• when I use RVize to give the initial pose hint, the map is not particularly well aligned with the results of the lidar

• When I ask to navigate it will get there but throwing lots of errors in the console. See below for a sampling of the errors

• the robot moves in fits and starts. Sometimes stopping for a few seconds, sometimes repeating the same motion over and over again, and in general not being smooth.

Questions:

• Does it sounds like I have a setup problem fundamentally?
• Is this just what you get when you use just LIDAR?
• Is my maze too small?
• Is this because I need to "tune" my SLAM?
Sampling of Errors from slam
$roslaunch turtlebot3_navigation turtlebot3_navigation.launch map_file:=$HOME/map.yaml

[INFO] [1535381131.875583266]: Got new plan
[ INFO] [1535381132.075471469]: Got new plan
[ WARN] [1535381132.180568313]: DWA planner failed to produce path.
[ INFO] [1535381132.275184519]: Got new plan
[ INFO] [1535381132.475446249]: Got new plan
[ WARN] [1535381132.575722364]: Rotate recovery behavior started.
[ERROR] [1535381132.576713131]: Rotate recovery can't rotate in place because there is a potential collision. Cost: -1.00
[ INFO] [1535381132.675482447]: Got new plan
[ INFO] [1535381132.875441949]: Got new plan

[ INFO] [1535381156.901500928]: Got new plan
[ INFO] [1535381157.101396956]: Got new plan
[ INFO] [1535381157.301632070]: Got new plan
[ INFO] [1535381157.302170120]: Goal reached
[ WARN] [1535381169.092857809]: Costmap2DROS transform timeout. Current time: 1535381169.0925, global_pose stamp: 1535381168.5424, tolerance: 0.5000
[ WARN] [1535381169.093196300]: Could not get robot pose, cancelling reconfiguration
[ WARN] [1535381170.092852095]: Costmap2DROS transform timeout. Current time: 1535381170.0926, global_pose stamp: 1535381168.5424, tolerance: 0.5000
[ WARN] [1535381170.192729304]: Could not get robot pose, cancelling reconfiguration
[ WARN] [1535381171.097531131]: Costmap2DROS transform timeout. Current time: 1535381171.0972, global_pose stamp: 1535381168.5424, tolerance: 0.5000
[ WARN] [1535381171.292652884]: Could not get robot pose, cancelling reconfiguration
[ WARN] [1535381172.097543923]: Costmap2DROS transform timeout. Current time: 1535381172.0973, global_pose stamp: 1535381168.5424, tolerance: 0.5000
[ WARN] [1535381172.393145114]: Could not get robot pose, cancelling reconfiguration
[ WARN] [1535381190.292336646]: Costmap2DROS transform timeout. Current time: 1535381190.2920, global_pose stamp: 1535381189.7725, tolerance: 0.5000
[ WARN] [1535381190.292683124]: Could not get robot pose, cancelling reconfiguration
^C[rviz-5] killing on exit

Here is map.yaml:

resolution: 0.050000
origin: [-10.000000, -10.000000, 0.000000]
negate: 0
occupied_thresh: 0.65
free_thresh: 0.196

And here is the map:

Your lidar has a minimum range for 12 cm, which means your maze corridors should probably be double that range (for either side of the sensor), plus the width of the sensor itself, which is 9.5 cm. That is, if your maze corridors are narrower than (12 + 12 + 9.5) = 33.5 cm, you're likely operating inside the minimum range of the scanner and may not be getting valid data.

:EDIT:

It seems like you might have a navigation issue that could be caused by your Costmap2DROS parameters. Specifically,

The radius in meters to which the map inflates obstacle cost values

If you are using the default value here, then it seems that the left wall would get a 0.55 meter buffer, the right wall would also get a 0.55 meter buffer, which now means your navigation algorithm might not let you pass through a corridor that's less than 1.1 meters wide.

This could combine with the navigation system's perception of the robot, defined by default as