# 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,

~<name>/inflation_radius (double, default: 0.55)

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

~<name>/robot_radius (double, default: 0.46)

The radius of the robot in meters, this parameter should only be set for circular robots, all others should use the footprint parameter described above.

The footprint parameter's default setting is empty [], meaning the Costmap2DROS defaults to assuming your robot is (2*0.46) = 0.92 meters wide (that's robot radius), which compounds with the obstacle dilation described above, to where now your navigation system might think your robot won't fit unless the corridor is (1.1 + 0.92) = 2.02 meters wide. Even at that point, it could consider the corridor to be a "tight fit" because it would believe the sides of your robot are scraping the walls.

A relatively straightforward test would be to check and correct the robot_radius parameter, or disable it by entering values for the footprint parameter, then try setting the inflation_radius to zero or something close to zero.

If this doesn't work, please edit your question to post the local_ and global_costmap settings and then please also provide a dimensioned drawing (sketch, etc.) of how your maze is actually arranged, along with the coordinates you're asking the robot to maneuver to.

FYI, if the image you've posted of your map is exactly your map, you've said (with your map.yaml file) that the bottom-left pixel is -10 meters, -10 meters, and each pixel is 5 cm. This means that the coordinates of approximately the middle of the top-left chamber in your "maze" is (1.6, -0.35), the center of the top-right is approximately (3.05, -0.05), and the center of the bottom chambe is approximately (2.8, -1.35). Again, all these dimensions are in meters. I don't know if these numbers sound correct to you or not, but this is how you've defined your map. This may or may not be contributing to the navigation trouble.

• They are well more than that, and in fact extremely simple. I will attach the map above. Do the error messages tell you that it is the range of the lidar that is causing the problem? – pitosalas Aug 27 '18 at 15:18
• To clarify, if you look at the map you see that it hardly qualifies to be called a maze. And the spacing is well more than 33cm between walls. I wonder if the error messages I included above give you anymore of a clue as to what might be wrong? – pitosalas Aug 28 '18 at 1:39