Skip to content
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

Open
alexswerner opened this issue Jul 21, 2020 · 3 comments
Open

Effort controller with gravity compensation #469

alexswerner opened this issue Jul 21, 2020 · 3 comments

Comments

@alexswerner
Copy link

alexswerner commented Jul 21, 2020

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!

@mateus-amarante
Copy link
Contributor

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).

@alexswerner
Copy link
Author

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

  1. Fixed base manipulator robot with gripper in gazebo.
  2. When the arm is in PositionJointInterface mode, stable grasping is impossible, the objects always slip -> need EffortJointInterface
  3. Running standard ros_control JointTrajectoryController with integrated PID gives significant difference between desired and actual joint position due to lack of gravity compensation.

Is this a correct description of the situation?

@mateus-amarante
Copy link
Contributor

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.

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

No branches or pull requests

2 participants