Open k-okada opened 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.
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, 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?
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.
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
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. 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.
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.