why effort_controllers/JointTrajectoryController is asking for PID gains in Gazebo

asked 2020-12-23 02:50:42 -0500

updated 2020-12-23 02:59:18 -0500

When I use effort_controllers/JointEffortController (I also set up hw interface etc) Gazebo is not asking for PID gains, which makes sense as It is an effort based controller. As what I found, Only position and velocity controllers need PID gains. Now when I use effort_controllers/JointTrajectoryController Gazebo is throwing errors for PID gains. And when I dont provide it Gazebo freezes. Is there any solution to get rid of this PID gains completely as I just want pure torque control. I tried providing zero gains, but then my commanded torques becomes zero. providing PID as 1 also did not help. So, in the case of effort_controllers/JointTrajectoryController when I command a desired torque and then I read the actual acting torques from /joint_states- effort they are not same. Which is of course due to PID gains.

I want to get rid of PID loop. Do I have to write my own custom action server on effort_controllers/JointEffortController.


  type: effort_controllers/JointTrajectoryController
  - shoulder_pan_joint
  - shoulder_lift_joint
  - elbow_joint
  - wrist_1_joint
  - wrist_2_joint
  - wrist_3_joint
    shoulder_pan_joint: {p: 400, d: 20, i: 0, i_clamp: 0}
    shoulder_lift_joint: {p: 500, d: 20, i: 0, i_clamp: 0}
    elbow_joint: {p: 400, d: 15, i: 0, i_clamp: 0}
    wrist_1_joint: {p: 100, d: 10, i: 0, i_clamp: 0}
    wrist_2_joint: {p: 50, d: 10, i: 0, i_clamp: 0}
    wrist_3_joint: {p: 30, d: 10, i: 0, i_clamp: 0}

    goal_time: 0.6
    stopped_velocity_tolerance: 0.05
    shoulder_pan_joint: {trajectory: 0.1, goal: 0.1}
    shoulder_lift_joint: {trajectory: 0.1, goal: 0.1}
    elbow_joint: {trajectory: 0.1, goal: 0.1}
    wrist_1_joint: {trajectory: 0.1, goal: 0.1}
    wrist_2_joint: {trajectory: 0.1, goal: 0.1}
    wrist_3_joint: {trajectory: 0.1, goal: 0.1}
  stop_trajectory_duration: 0.5
  state_publish_rate:  25
  action_monitor_rate: 10
edit retag flag offensive close merge delete


In the documentations link The example at 3.2.4. Minimal description, effort interface It is written that gains: # Required because we're controlling an effort interface In the joint_trajectory_controller doc link text a lot is written there. But basically "effort_controller" = output type "/JointTrajectoryController" = input type. A Trajectory is at least Position and maybe vel and acc as well (but can output/comand effort). "effort_controller/JointEffortController" thus takes in effort not position as the Trajectory controller will. There is a "effort_controllers/JointGroupEffortController" though maybe thats what you are really looking for.

Dragonslayer gravatar image Dragonslayer  ( 2020-12-23 08:07:09 -0500 )edit

thanks for the reply, as per your suggestion I tried something like,

 type: effort_controllers/JointGroupEffortController
 - shoulder_pan_joint
 - shoulder_lift_joint
 - elbow_joint
 - wrist_1_joint
 - wrist_2_joint
 - wrist_3_joint

This launches the effort_controllers/JointGroupEffortController and provides this topic, /arm_controller/command. I would not prefer to write a publisher but I want the action client. So Do I have to write my own Action server or it is there in ROS already?


amjack gravatar image amjack  ( 2020-12-23 09:42:13 -0500 )edit

I dont know about all in ROS or related packages others have made. What are you trying to achieve? Command just force to all joints at the same time, and only once? Or are the comands "sequenced" somewhere (trajectory idea)?

Dragonslayer gravatar image Dragonslayer  ( 2020-12-23 13:22:16 -0500 )edit

I have a trajectory, consisting of waypoints. I want to publish my torques for each waypoint to generate the trajectory. For this I have already written a client over effort_controllers/JointTrajectoryController. But this has a PID loop and I want pure torque control without PID.

So yes, I want just force to all joints at the same time in sequence to simulate the trajectory. @Dragonslayer

amjack gravatar image amjack  ( 2020-12-23 14:04:34 -0500 )edit

The thing is, that to achieve the waypoint=position input, the controller needs some way to "translate" into effort to command (PID). Lets say you got a position range of 0-360, and you start at 0 and your next waypoint is 10, what effort would you like to be outputed? What the pid does here is "throtteling up" to achieve the goal in time(more or less) and "throtteling down" to reach the goal without overshoot etc. If you just want 10 (the goal position) to be the effort command I havent seen that before.

If you really want a effort sequence ordered via service, yes I think you might have to write it all yourself. But as the position_controller/jointtrajectorycontroller just funnels through input=output you might fake it, by "labeling" effort as position. With a real hardwareinterface you can put in position whatever you want, however gazebo will ...(more)

Dragonslayer gravatar image Dragonslayer  ( 2020-12-24 04:55:25 -0500 )edit

I believe the OP Is trying to get something to execute his "effort trajectories", not positions.

gvdhoorn gravatar image gvdhoorn  ( 2020-12-24 07:13:48 -0500 )edit

@gvdhoorn is right, I have effort trajectories.

So I am doing computed torque control, in which the applied torque is calculated as,

Acceleration = K_p(currentAngle - desiredAngle) + K_v (currentVelocity -  desiredVelocity) + desiredAcceleration
torque = M * Acceleration + Coriolis*Velcoity + Gravity + friction

This series of torques is calculated to generate torque waypoints which gives torque trajectories as gvdhoorn mentioned.

I would just send each torque waypoints to controller, which would send this torques directly to robot without PID loop in between. As I already have my gains K_p and K_v for tuning position and velocity errors.

For this I have already written a custom action server. But I am still not sure If I have to use effort_controllers/JointEffortController or effort_controllers/JointGroupEffortController for my case.


amjack gravatar image amjack  ( 2020-12-25 06:07:13 -0500 )edit

Looks like impedance control? Now I get it you actually have angle, vel, etc., and the logic for it. I dont know enough to give you a clear answer, but I would assume JointGroupEffortController was written for some good reason, and has some advantage. As you want to order a group of joints I personally would use that one. Are you planning on putting your work up on github? I likely be looking for such control loop in the near future.

Dragonslayer gravatar image Dragonslayer  ( 2020-12-25 06:36:29 -0500 )edit