joint_states/effort goes to zero when published a torque using effort_controllers/JointGroupEffortController in Gazebo

[amjack0]

I am using effort_controllers/JointGroupEffortController wit ur5 arm in Gazebo. I set up my controller (interface etc) like this,

UR5 package Link

My controller yaml looks like this,

`arm_controller:
type: effort_controllers/JointGroupEffortController
joints:

• shoulder_pan_joint
• shoulder_lift_joint
• elbow_joint
• wrist_1_joint
• wrist_2_joint
• wrist_3_joint`

I run roslaunch ur_gazebo ur5.launch and I can see my controller topic /arm_controller/command
So, When I publish rostopic pub a desired torque of lets say 60 Nm on effort_controllers/JointGroupEffortController. Then it would go to 60 Nm then goes to Zero and the to 60 Nm and again to zero.

I checked my ur5.urdf.xacro for friction, damping, safety controller and limits. Not sure what's wrong.

I plot joint_states/efforts to analyze this issue. This issue is seen for every joint. (In the plot, only shoulder_lift_joint is analyzed.)
Plot of the joint state effort looks like this, rqt plot

ROS Melodic , 18.04
gazebo-9.0.0
Universal Robot (UR5) `https://github.com/ros-industrial/universal_robot/tree/melodic-devel

[bmagyar]

The effort controller will keep sending the last command you sent it, you can see that here

You may however want to revisit what's happening with those interfaces and whether your robot supports effort mode in gazebo at all. I've found some traces of position joint interface being default all over the UR description package. You should examine which controllers you have actually running. It may also be an internal Gazebo issue, your computer not being able to run the simulation at a high-enough frequency but the controller running fast enough to report some intermediate 0-s...? I can only guess. The forward command controller is doing fine however on all fronts, there's not much that can go wrong with the code, you can see it for yourself.

[amjack0]

I have done changes locally in this repository, which uses EffortJointInterface as default. look here git repo
So I am actually running effort_controllers/JointGroupEffortController.
So, it can be an internal Gazebo issue as you mentioned.

computer not being able to run the simulation at a high-enough frequency but the controller running fast enough to report some intermediate 0-s...?

Would be nice if there's way to fix this ? I will try to play with control frequency but not sure if it will fix this.

Thanks alot @bmagyar

[Cdfghglz]

I am experiencing similar issues - the command only occasionally turns into an effort in gazebo, otherwise 0.

@amjack0 do you have any updates on this topic?

[amjack0]

I had some bugs related to threads and spin. I would recommend to check the frequency settings with your system.

[Cdfghglz]

Thank you @amjack0 for the reply.

Below some of what I interpret as frequency settings. Do you mean anything else?

• C++ code poducing .../command 500Hz
• joint_state_controller publish_rate 500Hz
• gazebo RT factor between 0.1 and 0.5
• gazebo settings

    <physics name='default_physics' default='0' type='ode'>
      <max_step_size>0.0002</max_step_size>
      <real_time_factor>1</real_time_factor>
      <real_time_update_rate>5000</real_time_update_rate>
    </physics>