why effort_controllers/JointTrajectoryController is asking for PID gains in Gazebo
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
.
arm_controller
type: effort_controllers/JointTrajectoryController
joints:
- shoulder_pan_joint
- shoulder_lift_joint
- elbow_joint
- wrist_1_joint
- wrist_2_joint
- wrist_3_joint
gains:
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}
constraints:
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
Asked by amjack on 2020-12-23 03:50:42 UTC
Comments
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.
Asked by Dragonslayer on 2020-12-23 09:07:09 UTC
thanks for the reply, as per your suggestion I tried something like,
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
Asked by amjack on 2020-12-23 10:42:13 UTC
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)?
Asked by Dragonslayer on 2020-12-23 14:22:16 UTC
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
Asked by amjack on 2020-12-23 15:04:34 UTC
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?
Asked by Dragonslayer on 2020-12-24 05:55:25 UTC
I believe the OP Is trying to get something to execute his "effort trajectories", not positions.
Asked by gvdhoorn on 2020-12-24 08:13:48 UTC
@gvdhoorn is right, I have effort trajectories.
So I am doing computed torque control, in which the applied torque is calculated as,
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
andK_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
oreffort_controllers/JointGroupEffortController
for my case.@Dragonslayer
Asked by amjack on 2020-12-25 07:07:13 UTC
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.
Asked by Dragonslayer on 2020-12-25 07:36:29 UTC
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
Asked by amjack on 2020-12-26 09:18:14 UTC
Well, I tried
effort_controllers/JointEffortController
andeffort_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 achieveImpedance control
using ros control. @Dragonslayer @gvdhoornAsked by amjack on 2020-12-29 17:37:33 UTC
What result did you expect, what did you get?
Asked by Dragonslayer on 2020-12-30 07:09:30 UTC
When I publish a desired torque of lets say
10 Nm
oneffort_controllers/JointGroupEffortController
. Then it would go to10 Nm
then goes toZero
and the to10 Nm
and again tozero
. Which makes the robot motion very jerky. Not sure what's wrong. @DragonslayerAsked by amjack on 2020-12-30 13:11:25 UTC
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?Asked by Dragonslayer on 2020-12-30 13:44:11 UTC
initially I thought there is some issue with my server-client but this problem is there with
rostopic pub /
. When I readjoint_states
this is happening at not a fixed rate. @Dragonslayer Look hereAsked by amjack on 2020-12-30 13:58:28 UTC
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?
Asked by Dragonslayer on 2020-12-30 17:09:37 UTC
x axis is the
time
which is scaled by default byrqt_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 useUr5 robot
in Gazebo. @DragonslayerAsked by amjack on 2020-12-31 04:19:10 UTC
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?Asked by Dragonslayer on 2020-12-31 07:24:27 UTC
This can be an issue, have a look at my repo . I think I have defined them correctly, look here @Dragonslayer
Asked by amjack on 2020-12-31 09:31:32 UTC
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"?Asked by Dragonslayer on 2020-12-31 10:16:24 UTC
should_pan_joint is first joint, I tried various values on all the joints, behavior is same , its jerky for all joints.
@Dragonslayer
Asked by amjack on 2020-12-31 10:27:00 UTC
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.
Asked by Dragonslayer on 2020-12-31 11:09:05 UTC
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 @DragonslayerAsked by amjack on 2020-12-31 12:19:42 UTC
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
Asked by Dragonslayer on 2021-01-01 06:45:15 UTC