Skip to content

reduce max_rot_vel to 0.5#140

Open
k-okada wants to merge 1 commit into
turtlebot:indigofrom
k-okada:fix_max_rot_vel
Open

reduce max_rot_vel to 0.5#140
k-okada wants to merge 1 commit into
turtlebot:indigofrom
k-okada:fix_max_rot_vel

Conversation

@k-okada

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

Copy link
Copy Markdown

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

tfoote commented Oct 28, 2015

Copy link
Copy Markdown
Contributor

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

stonier commented Oct 29, 2015

Copy link
Copy Markdown
Member

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

stonier commented Oct 29, 2015

Copy link
Copy Markdown
Member

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

k-okada commented Oct 29, 2015

Copy link
Copy Markdown
Author

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

tfoote commented Oct 29, 2015

Copy link
Copy Markdown
Contributor

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

k-okada commented Oct 30, 2015

Copy link
Copy Markdown
Author

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
Copy Markdown
Contributor

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

@surfertas

surfertas commented May 8, 2017

Copy link
Copy Markdown

@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

ruffsl commented May 2, 2018

Copy link
Copy Markdown

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