Navigation stack - only in place turning

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

quotschmacher
17 ●1 ●1 ●4

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.

Sven

edit retag flag offensive close merge delete

add a comment

1

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

michikarg
2108 ●19 ●37 ●52 http://hcai.in.tum.de/...

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 http://www.ros.org/wiki/navigation/Tutorials/Navigation #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

Comments

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 ( 2014-08-02 23:26:03 -0600 )edit

add a comment

3

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

Lorenz

22731 ●129 ●202 ●316 http://ias.in.tum.de/p...

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

Comments

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 ( 2014-08-02 23:28:47 -0600 )edit

add a comment

1

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

Procópio

flag of United Kingdom of Great Britain and Northern Ireland

4402 ●23 ●64 ●67 https://www.linkedin.c...

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.

cheers

edit flag offensive delete link

add a comment

0

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

quotschmacher
17 ●1 ●1 ●4

@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

Comments

hi, welcome to answers.ros.org. 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 ( 2012-04-17 00:15:48 -0600 )edit

add a comment

0

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

quotschmacher
17 ●1 ●1 ●4

Hi,

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

Comments

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

2ROS0 ( 2014-08-02 23:29:57 -0600 )edit

add a comment

0

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

quotschmacher
17 ●1 ●1 ●4

@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)

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

Comments

Ups sorry, i meant that link: http://www.ros.org/wiki/navigation/Tutorials/Navigation%20Tuning%20Guide

michikarg ( 2012-04-16 22:36:11 -0600 )edit

Did you try to use another local planner?

michikarg ( 2012-04-16 22:36:25 -0600 )edit

add a comment

0

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

michikarg
2108 ●19 ●37 ●52 http://hcai.in.tum.de/...

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

add a comment

0

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

quotschmacher
17 ●1 ●1 ●4

@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

Comments

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 ( 2012-04-18 05:08:14 -0600 )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 ( 2012-04-18 05:11:53 -0600 )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 ( 2012-04-19 22:24:58 -0600 )edit

add a comment

Navigation stack - only in place turning

8 Answers

Comments

Comments

Comments

Comments

Comments

Comments

Question Tools

Stats

Related questions

Navigation stack - only in place turning edit

8 Answers

Comments

Comments

Comments

Comments

Comments

Comments

Question Tools

Stats

Related questions

Navigation stack - only in place turning