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
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,
This launches the
effort_controllers/JointGroupEffortControllerand 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 ...(more)
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,
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_pandK_vfor 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/JointEffortControlleroreffort_controllers/JointGroupEffortControllerfor 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/JointEffortControllerandeffort_controllers/JointGroupEffortControllerwith my custom action server and client. I am not happy with the results, Not sure what can be the best way to achieveImpedance controlusing ros control. @Dragonslayer@gvdhoornWhat result did you expect, what did you get?
When I publish a desired torque of lets say
10 Nmoneffort_controllers/JointGroupEffortController. Then it would go to10 Nmthen goes toZeroand the to10 Nmand again tozero. Which makes the robot motion very jerky. Not sure what's wrong. @Dragonslayer