-
Notifications
You must be signed in to change notification settings - Fork 226
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
base: indigo
Are you sure you want to change the base?
Conversation
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. |
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. |
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. |
that's interesting, i checked a pr2 setting as a reference, |
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. |
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.
|
Is this still an issue, or can it be closed? |
@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.) |
Still hitting this issue when showing the turtlebot gazebo navigation demo to students. 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.
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 |
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.