Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reduce max_rot_vel to 0.5 #140

Open
wants to merge 1 commit into
base: indigo
Choose a base branch
from

Conversation

k-okada
Copy link

@k-okada k-okada commented Oct 28, 2015

I followed http://wiki.ros.org/turtlebot_gazebo/Tutorials/indigo/Make%20a%20map%20and%20navigate%20with%20it tutorial and found strange behavior of the robot.
It rotate around during move to the target

This PR fixes in simulation, but I'm not sure what is the correct value for the real robot. Where can I find specification sheet for the base system.

rotate_bot

@tfoote
Copy link
Contributor

tfoote commented Oct 28, 2015

We need to look a little closer at what's going on.

Just reducing the max rotation rate means that it prevents the robot from exploring the full range of possibilities. This will likely cause a problem if there really is an obstacle in the way.

@stonier
Copy link
Member

stonier commented Oct 29, 2015

Changing the parameter might seem to 'fix' it, but what is the root cause? I like to know that before fixing things so as to avoid inadvertantly masking problems instead of really fixing them.

I can't immediately see an explanation for this, nor for why there is an association between symptom and parameter change so I'd like to see a little more digging as well.

@stonier
Copy link
Member

stonier commented Oct 29, 2015

For reference, the kobuki really can reach those angular rates...If i remember correctly, the limits we have in the kobuku keyop smoother are the same as the robot's specification.

@k-okada
Copy link
Author

k-okada commented Oct 29, 2015

that's interesting, i checked a pr2 setting as a reference,
https://github.com/PR2/pr2_navigation/blob/hydro-devel/pr2_navigation_local/config/dwa_local_planner.yaml
Does this mean that kobuki is small and so it can move quickly than PR2?

@tfoote
Copy link
Contributor

tfoote commented Oct 29, 2015

It can certainly turn faster than the PR2. The PR2 is also limited for safety reasons. It can actually drive at over 2m/s but it starts getting very dangerous due to it's high inertia.

@k-okada
Copy link
Author

k-okada commented Oct 30, 2015

Yes I agree on we should be very careful on changing value, another workaround is to change min_rot_vel, If we change them to, say 0.1, I think we can get better results. From local path visualization, it seems that the robot try to rotate quickly, rather than follow the path.

max_rot_vel: 5.0  # choose slightly less than the base's capability
min_rot_vel: 0.4  # this is the min angular velocity when there is negligible translational velocity

screenshot from 2015-10-30 10 05 52

@rohbotics
Copy link
Contributor

Is this still an issue, or can it be closed?

@surfertas
Copy link

surfertas commented May 8, 2017

@stonier Did you ever figure out the root cause? I am running into similar issues, and changing max_rot_val to 1.0 from 5.0 in the dwa_local_planner_params.yaml, found under /opt/ros/kinetic/share/turtlebot_navigation/param folder, resolved the issue, but like you said its a temporary fix. I dont like limiting the rotational velocity to 1.0 when the capacity is much larger. (Sorry for posting after the thread has been closed.)

@ruffsl
Copy link

ruffsl commented May 2, 2018

Still hitting this issue when showing the turtlebot gazebo navigation demo to students.
This blog post lead me here:
https://surfertas.github.io/rviz/turtlebot/2017/05/08/turtlepi-spin.html

I've found lowering the max_rot_vel just a bit while increasing the acc_lim_theta does are rather good job in stabilizing motion in the simulation while not unnecessarily slowing the trajectory.

max_rot_vel: 3.0 
acc_lim_theta: 6.0

The physics of a real turtlebot are of course different, so I'm not sure how this might affect a real platform.

I think you could get away just increasing the acc_lim_theta, but then the low coefficient of friction in simulation causes the robot to more or less do drifting burnouts in local pursuit of its plan.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants