-
Notifications
You must be signed in to change notification settings - Fork 35
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
base controller never achieves velocities in gazebo #402
Comments
Hi there, out of curiosity, which lab are you from and did you recently test the navigation behavior as done in #392? So as a first step you should definitely try to tweak these configurations and see whether/how it changes behavior. |
Thanks for the reply. I'm with the Robot Learning Lab in Freiburg, Germany. That I can very much imagine. But I don't think a suboptimal configuration can explain why it never even comes close to achieve the target velocity. I've been digging in the code a bit now, and I'm not sure if I misunderstand it, or whether the PID arguments for the wheels are completely wrong:
where the signature is I've replaced it with
and now it actually (almost) achieves the commanded velocity |
Sorry, I don't have the cycles to look at that in detail...
Could you test your code on the physical robot as well and provide controller parameters (assuming they need to be adapted)?
I will try this on our own robot then and if it works well we can merge it upstream.
This snippet got attention in the past as well and it's definitely possible that this is plain wrong.
It's astonishing how well it works on the physical system though, so it's hard to believe!
|
I completely understand. If we manage to test this on the actual robot, I'll let you know, though I am a bit afraid to test it there, also given that it is working well there as is. I was also a bit too fast. With this change I achieve velocities up to 0.25m/s in gazebo, but the robot is still not able to move any faster, no matter how large the output of the controller (I guess it gets capped at the effort limits anyway). Is it possible that some things in the gazebo physics changed so that the original efforts are just no longer sufficient to move the robot appropriately in simulation? And you wouldn't have any hints at what parameters to best look at for this? |
If we manage to test this on the actual robot, I'll let you know,
though I am a bit afraid to test it there, also given that it is working well there as is.
Yes, that's why I will not be the first to test changes in this code. :)
It might be a good idea to jack up the robot for such initial experiments.
But it's not necessarily working perfectly on the real system as observed in the other issue.
Is it possible that some things in the gazebo physics changed so that the original efforts are just no longer sufficient to move the robot appropriately in simulation?
That's absolutely possible! As I said, sadly nobody modified the PR2 side of the simulation in a long time. :/
I don't know what parameters best to adapt here, but I would not aim for physical plausibility.
The spring mechanism in the arm lift joints is modelled by disabling gravity for the arms, so there is not much plausible about the model anyway...
|
Hi,
I am starting the pr2 with all default configurations in gazebo (ROS noetic). I then send twist commands to the base controller as outlined in the tutorial (http://wiki.ros.org/pr2_controllers/Tutorials/Using%20the%20robot%20base%20controllers%20to%20drive%20the%20robot0), vaying the velocities and publishing them at 50 hz.
Doing so I find that:
Somewhat related to #392 though the differences in gazebo are just so much larger that I assume it is something else.
I was wondering if anyone experienced the same and or what configurations I might best look at to solve this? There is at least one other person encountering the same issue, but no solution: https://stackoverflow.com/questions/64525521/gazebo-simulated-pr2-robot-maximum-speed-is-not-respected
The text was updated successfully, but these errors were encountered: