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.

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

arm_controller:
 type: effort_controllers/JointGroupEffortController
 joints:
 - 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?

@Dragonslayer

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

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

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 be harder to fool.

Whats your usecase for this, may I ask?

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

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

@Dragonslayer

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.

Yeah, Thanks for your suggestions. This work is for my thesis and I am not sure if I'm allowed to put the entire work on github. Although discussions like these are always possible ! @Dragonslayer

Well, I tried effort_controllers/JointEffortController and effort_controllers/JointGroupEffortController with my custom action server and client. I am not happy with the results, Not sure what can be the best way to achieve Impedance control using ros control. @Dragonslayer @gvdhoorn

What result did you expect, what did you get?

When I publish a desired torque of lets say 10 Nm on effort_controllers/JointGroupEffortController. Then it would go to 10 Nm then goes to Zero and the to 10 Nm and again to zero. Which makes the robot motion very jerky. Not sure what's wrong. @Dragonslayer

This happens with your action server or with a simple rostopic pub ... as well? You read the "outcome" from joint_states? How fast is this happening?

initially I thought there is some issue with my server-client but this problem is there with rostopic pub /. When I read joint_states this is happening at not a fixed rate. @Dragonslayer Look here

What time interval is the x axis? ms? It seems to be a wave, could it be that at abrupt stop the inertia unloads the "sensor" and "swings in" at position, like airtime in a rolercoaster, up and down(bouncing)? Is the stable looking part at the end a new comand or is this all one comand input? Am I seeing this right its ordered 60Nm. Is this sensible for your usecase, or just a try value, could be limits playing tricks? Do you use some sort of robot arm for simulation, or some unusual setup?

x axis is the time which is scaled by default by rqt_multiplot. It's just one command, Yes you are seeing right, 60 Nm. It is just a try value . This value is way within the limits, so no tricks with limits. I use Ur5 robot in Gazebo. @Dragonslayer

I dont find a quick answer, so is the time axis showing vibration/shaking or longtime movement? In the ur5 urdf I see only positionInterface, did you replace these as well when changing to JointGroupEffortController? -> <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface> Maybe we see somehow the effort comand going in but the positionInterface acting against it?

This can be an issue, have a look at my repo . I think I have defined them correctly, look here @Dragonslayer

Please link the files you are actually loading. In the one transmission.xacro I see the <xacro:macro name="ur_arm_transmission" params="prefix hw_interface"> while in the original repository they put in the Interface type as mentioned above(manually). Iam not big in xacro, I would always first try a straight forward adaption, but maybe thats not even what you load after all, or its not a problem. Just what jumped at me. Did you try with different efforts at all? 0.6, 6, 60, 600 etc.? What is joint 1, "shoulder"?

should_pan_joint is first joint, I tried various values on all the joints, behavior is same , its jerky for all joints.

@Dragonslayer

I only saw jerkiness with bad pid gains or back fighting limits (control frequency shouldnt be an issue in sim) (mostly in real world). No warns or errors in the logs i assume? Computer powerfull enough? Maybe quickly puting together a few revolute joints in a test contraption and try that might be advisable here. Such urdf, yaml and launcher should be done in an hour. UR5 is complex and as its written with position Interface some background stuff might interfere, calibration going crazy or whatever.

Yeah , No log warnings. Let's see , may be an issue with interface as you described. But, I need to find a solution and make it work somehow !! lets see, what ros2_control brings on the table ! Thanks @Dragonslayer

AFAIK ros2_control is just ros_control for ros2. If I had to solve the issue, I would first check with a simple new contraption as mentioned above, and second with a calculated value input for gravity compensation/position at some intermediate position (45° up in the air). At the moment I dont think its clear which part of the software creates the issue. All the best @amjack