ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A
Ask Your Question

Navigation stack - only in place turning

asked 2012-04-10 07:25:57 -0500

quotschmacher gravatar image

Hi there,

I have a Robot that runs pretty good under ROS. I can teleop it, have a valid URDF-model, I can create maps with the help of the laser scanner. The robot itself is differential driven. It has a rectangular shape with 4 wheels. The motorized wheels are located in the front, where the base_link is located, too. When I follow the tutorials to get the whole navigation stack running. The Path to a navigation goal is calculated and displayed as well. But the robot does not follow the path. It is performing in place rotations instead of forward driving. The cmd_vel-topic says so, too. The angular.z component is at the maximum set in my parameters and the linear x and y component are zero (y should be 0 as it is non holonomic). Is this a known problem? Is it caused by the uncircular shape of the robot? Could anybody help me?

Thanks so far.


edit retag flag offensive close merge delete

8 Answers

Sort by » oldest newest most voted

answered 2012-04-15 23:59:05 -0500

michikarg gravatar image

hmm it seems like this is a problem of the local planner... This usually happens when the robot thinks it is too close to an obstacle.

Are you sure the local and global costmap show no obstacles close to the robot?

You can also try to use another local-planner. ROS offers the "base_local_planner" and "dwa_local_planner" (see #4 for more information).

But my guess still is that there is something set up wrong with the localization and/or obstacles...

edit flag offensive delete link more


Couple of Qs: Isn't dwa one of the parameters that can be set in base_local_planner? Then why does it have a different package with different names for the same parameters? And why does Navigation Stack spin like that when it is close to obstacles?

2ROS0 gravatar image 2ROS0  ( 2014-08-02 23:26:03 -0500 )edit

answered 2012-04-10 10:28:36 -0500

Lorenz gravatar image

My guess is that the controller in move_base that is generating cmd_vel has a hard time to find the right control commands. This controller basically takes the odometry message and tries to follow the planned path as close as possible. Verify that your odometry message actually makes sense, in particular the velocity values are important for move_base. Check that they actually match the actual velocities of your robot. Be sure that velocities are actually sent in the robot's base frame, not in the odometry frame. I.e. when the robot is driving straight forward with 1 m/s x velocity should be exactly 1 and y zero, no matter in which direction the robot is moving in the odometry frame. Try plotting the velocities with rxplot, drive forward, turn 90 degrees and drive forward again. Both times, only the x velocity must be 1.

edit flag offensive delete link more


Could you explain what you mean by the controller "takes the odometry message"? Does that mean the tf b/w odom and base_link or something else? Could you explain the control in more detail?

2ROS0 gravatar image 2ROS0  ( 2014-08-02 23:28:47 -0500 )edit

answered 2012-04-17 01:11:37 -0500

Procópio gravatar image

I once had the same problem. I resolved it in a bizarre way, and I do not know why it worked, but it worked and I was happy. When I had everything prepared, before giving a goal for the robot to follow, I launched

rosrun dynamic_reconfigure reconfigure_gui

And in the pop-up button, I opened the navigation configuration, and after that everything worked. For more info on this, check this question I made.


edit flag offensive delete link more

answered 2012-04-10 23:50:50 -0500

quotschmacher gravatar image

@michikarg The laser scanner is defined in the costmap_commons and displayed in rviz, and the costmaps are, too.

@Lorenz In fact I never really tested if the robot is driving the wanted speed. I will check that tomorrow, as i am not in the university today. The other stuff should be working. The odometry seems to be right (moving 1 meter in rviz means moving 1 meter in reality) and slow rotations are recognized correctly, too. I limited the navigation stack to slow rotations as they are no problem.

edit flag offensive delete link more


hi, welcome to please, have in mind that this website is not a forum, so you should not post answers responding to answers, and so on. if you have updates, you should update your question, if you want to answer to suggestions, do so in the "post comment" in the respective suggestion

Procópio gravatar image Procópio  ( 2012-04-17 00:15:48 -0500 )edit

answered 2012-04-18 04:33:50 -0500

quotschmacher gravatar image

@michikarg May be the question is a bit stupid, but how do I change the local planner? I thought the only change I could make using the navigation stack was switching dwa on or off?!

edit flag offensive delete link more


as I tried to tell you before, this is not a forum, you should NOT post answers as it were a forum. if you have a new question, create a new question. if you have updates, update your current question, if you want to comment on answers, use the "post a comment".

Procópio gravatar image Procópio  ( 2012-04-18 05:08:14 -0500 )edit

i will be glad to answer how to change the local planner as soon as you post it in the proper way. right now this page should be devoted to your "in place rotation" problem only. each new post should be a direct answer to your first question. i hope you understand. cheers

Procópio gravatar image Procópio  ( 2012-04-18 05:11:53 -0500 )edit

When launching move_base, you can set rosparams that define which local planner should be used. As Procópio said, it would be nice if you could open a new question, then i can post an example move_base.launchfile...

michikarg gravatar image michikarg  ( 2012-04-19 22:24:58 -0500 )edit

answered 2012-04-10 08:32:26 -0500

michikarg gravatar image

I don´t think this problem is caused by the shape of the robot, it seems more like your robot is performing some kind of recorvery behaviour (e.g. turning in place). I recommend to visualize all costmaps and laser scans to check if it is a problem of your localization and if your sensors are correctly configured (e.g. did you define the laser scanner (or another sensor) in the costmap_commons.yaml)?

edit flag offensive delete link more

answered 2012-04-16 09:02:44 -0500

quotschmacher gravatar image

@michikarg today the robot should move a straight path and followed it (with the accurcy I told him) and afterwards he should drive an other path (shown in the screenshot) screenshot

The green path is the global path. The yellow obstacles are the inflated obstacles by the local planner. The robot moved a bit from its starting position to where the footprint is in the picture and then performed this recovery behavior... My inflation radius is set pretty low (0.30) in the costmap_common_params.yaml and in the base_local_planner_params.yaml dwa is set to true.

And the link you posted does not exist ;)

But thanks untill here!

edit flag offensive delete link more


michikarg gravatar image michikarg  ( 2012-04-16 22:36:11 -0500 )edit

Did you try to use another local planner?

michikarg gravatar image michikarg  ( 2012-04-16 22:36:25 -0500 )edit

answered 2012-04-15 07:50:49 -0500

quotschmacher gravatar image


I compared the cmd_vel-topic with the odom-topic and the speeds are neartly the same. I found out, that the navigation_stack only generates really short local paths. And one time the robot reached the goal, an other time it had to drive a path, drove a bit, performed the in place turnings and then aborted, saying

Aborting because a valid plan could not be found. Even after executing all recovery behaviours

And the robot only hab to drive a straight path for lets say 70 centimeters... So I think now I can say that the tourning really is a recovery behaviour, but I dont't know why if the planned global path has no obstacles in its way...

edit flag offensive delete link more


I have had similar problems. Did you resolve them in any way?

2ROS0 gravatar image 2ROS0  ( 2014-08-02 23:29:57 -0500 )edit

Your Answer

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

Add Answer

Question Tools



Asked: 2012-04-10 07:25:57 -0500

Seen: 5,813 times

Last updated: Apr 18 '12