-
Notifications
You must be signed in to change notification settings - Fork 308
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
Effort controller with gravity compensation #469
Comments
Hello, let me try to help you. The gazebo_ros_control's default RobotHW does not apply PID control for the effort hardware interface, it simply applies the target effort to the simulated joint. The PID params are valid for position and velocity interfaces. Internally, it computes the position/velocity tracking errors and applies PID control to define effort values for the joints. Check these parts of gazebo_ros_control code. As far as I know, gravity compensation is a centralized control approach that requires the knowledge of all the joint positions to define the G(q) matrix. So, you need a "multi-joint scoped" solution. In this way, I suggest creating a multi-joint custom controller for the effort hardware interface that should compute the effort commands for all the joints with all the terms you want (PID + Gravity Compensation + Feedforward + ...). There is also a gravity_compensation ROS package and a Gazebo plugin but I'm not sure if they might be useful (I have just googled it). |
Many thanks for the feedback, the gazebo plugin seems indeed to be a way to implement this. I also found https://github.com/pal-robotics/gravity_compensation_controller_tutorial which seems to implement this as well. But just to reiterate the problem from my perspective - please let me know where I am going wrong
Is this a correct description of the situation? |
Good find. It seems this gravity_compensation_controller_tutorial does exactly what I suggested. It seems a great start. Thanks for sharing it. Talking about your situation's description: I do not have practical experience with grippers, but looking at gripper_action_controller, it should work with both interfaces (better with effort interface to consider max_effort input). The performance will depend on tuning and the target commands. I think the lack of gravity compensation is not the reason for the bad performance you are facing. I think your control constants might not be adequate for your model. I suggest reviewing your URDF model, looking for unrealistic params (like inertia and effort limits), and strugling a bit more with tuning. This package provides nice tools to tweak pid params. |
Hello,
I'm running a bunch of different Gazebo simulation with robot arms. To have working contact dynamics in gazebo I'm using the joint effort interface to define the controller. However this gives me a PID control for each joint. Now I want relatively precise tracking of the joint position so i increase the gains to e.g. 10^8 but still get errors from the joint trajectory controller that the robot is not tracking the desired trajectory. Of course that happens because the controller has neither gravity compensation or feed forward terms (M*ddq). What would be your approach to fix that? Are there any effort to create a decent generic arm controller? Or should i start one?
Great work so far guys!
The text was updated successfully, but these errors were encountered: