The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
A couple of things you can try. The Navigation Tuning Guide is extremely helpful as well: http://www.ros.org/wiki/navigation/Tutorials/Navigation%20Tuning%20Guide
Visualise the costmap using RVIZ as the robot navigates around. The navigation stack inflates obstacles out to a certain size to ensure the centre of the robot can pass through the space. If the move_base parameters aren't set correctly the robot may be trying to over-optimistically get through narrow spaces with the global planner, and when it gets nearby realises that it's tricker, so it gets stuck and has to replan.
Visualise the path generated from the planner in RVIZ as well, that way you can see if the robot is following the path correctly, or if it gets stuck in local situations and has to replan.
When you give a target position from RVIZ, it has an orientation included in that as well. Is the rotation behaviour you're talking about the final rotation when the robot has reached its goal?
Rotating on the spot can also be caused by the robot performing 'recovery behaviours'. The robot maintains costmaps of both local and global obstacles, and whenever it sees sensor data marks it on the map as impassible. However most robots can't see in every direction, so some of the obstacle data might be out of date. E.g. Take an extreme example: if the robot moves towards me it sees me as an obstacle and turns left to go around. If I then step in front of it again it thinks there's another obstacle there too. It can't see my original position now, but it remembers that there was also an obstacle there. This can lead to situations where the robot thinks it is totally surrounded, and hence stuck, even though it the people is gone and there's only a single wall in front.
The way it recovers is by slowly rotating on the spot and 'clearing out' obstacles if sensors tell it there are none near by. Check the move_base parameters, if your robot has multiple sensors it's common to allow one set only for marking obstacles as there, but not trusting them enough to clear out space as safe, or vise versa.
The diagram here: http://www.ros.org/wiki/navigation/Tutorials/RobotSetup
Is extremely useful to understand what the navigation stack is doing 'under the hood'. I'd reccomend visualising whatever you can in RVIZ and running some more experiments to see how in particular your setup is failing.
Cheers, Gav
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
