Yes, this in the rotate_recovery behavior inside the navigation stack. However, the actual cause of this is typically more complex. If your robot has an odd-shaped footprint, than that can be the cause. But if you are using a turtlebot, with a circular footprint and centered drive wheels, you should pretty much always be able to rotate in place -- unless localization drifts/jumps, thus putting you on top of an obstacle that was already in the cost map.
Originally posted by fergs with karma: 13902 on 2014-06-25
This answer was ACCEPTED on the original site
Post score: 1
Original comments
Comment by Ken_in_JAPAN on 2014-06-25:
Thanks @fergs, I try to experiment a navigation with turtlebot2. As Turtlebot2 can rotate in place, you say that such a error doesn't arise without drift/jumps?
Comment by Pi Robot on 2016-09-18:
@fergs, I run into this situation quite often with my Kobuki when it is stopped in a hallway and needs to go to the next goal location. I am using amcl and an existing map for localization and the DWA global planner. Is there any way to force a rotation in place as a last resort recovery behavior?