Joint out of control when close to its limits

[lklimkiewicz7]

I'm pretty new to ROS and may not understand something basic, but I have following problem:

I have a simulated arm, which has limits on every joint and I'm using ForwardCommandController to control it. Unfortunately when I command some joint to move to its limit or near it, there are chances that it will get stuck there. Then I can still control other joints and sometimes this dead joint comes to live again - probably because it gets a little bit farther from its limit due to other movements.

Is this behavior expected or I'm doing something wrong?
How to allow controlling joints which are near they limits?

I don't have experience with real robots and I'm not sure whether it's gz_ros2_control or ros2_control issue.

[mrjogo]

I also just ran into this issue of joints getting "stuck" if they are commanded to their limit (presumably because overshoot goes past the limit). To reproduce (on Humble):

ros2 launch ign_ros2_control_demos gripper_mimic_joint_example.launch.py
# in another terminal
ros2 topic pub -1 /gripper_controller/commands std_msgs/msg/Float64MultiArray '{data: [0.39]}'
ros2 topic pub -1 /gripper_controller/commands std_msgs/msg/Float64MultiArray '{data: [0.0]}'

(in this case it's commanding past the joint limit to illustrate the issue) The gripper will close with the first /gripper_controller/commands command and won't open with the second.

[azeey]

This is similar to gazebosim/gz-sim#1684 which is caused by dartsim/dart#1683 and fixed by dartsim/dart#1774 and released in DART 6.13.1. That version of DART will soon be available on packages.osrfoundation.org for Gazebo Harmonic.

[christophfroehlich]

I'm tempted to close this issue as it seems to be not related with gz_ros2_control but with gz_sim itself.

[christophfroehlich]

I'll reopen this, as it got reported again and it seems that there is no fix for Fortress. (@azeey?)

[azeey]

I'll reopen this, as it got reported again and it seems that there is no fix for Fortress. (@azeey?)

Yeah, this has resurfaced in gz-sim as well (see gazebosim/gz-sim#1684 (comment)). It looks like the behavior depends on the commanded value.

Also, unfortunately, the fix cannot be backported to Fortress since we use the version of DART in Ubuntu Focal/Jammy, which don't receive any updates, and the fix actually needs to go into DART.