turtlebot / turtlebot_apps

A group of simple demos and exmaples to run on your TurtleBot to help you get started with ROS and TurtleBot.
http://www.ros.org/wiki/turtlebot_apps
196 stars 225 forks source link

reduce max_rot_vel to 0.5 #140

Open k-okada opened 8 years ago

k-okada commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 7 years ago

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

surfertas commented 7 years ago

@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 commented 6 years ago

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.