[JTC] set_hold_position results into not exactly reaching desired target

[firesurfer]

Describe the bug

In #558 (included in rolled out version 3.14.0) set_hold_position was added which commands the current position as the target after sampling the last point of the trajectory (

ros2_controllers/joint_trajectory_controller/src/joint_trajectory_controller.cpp

Line 346 in 1dac309

traj_msg_external_point_ptr_.initRT(set_hold_position());

).

This results into not reaching the target exactly. (In our case a UR16e arm).
As far as I see there is no way to disable or tune this behavior

To Reproduce

Take some robot arm. Move rather fast from A to B. Check if the desired target has been reached within a tolerance of for example 0.001rad

Expected behavior

In case the checks (e.g. arm is within goal tolerance) were successful set the last point of the trajectory as target

Environment (please complete the following information):

• iron
• ros2control : 3.14.0

[christophfroehlich]

Could you explain why you can't solve this by reducing the tolerances to meet your requirements at the target?
The problem before the change was that it did not stop at the target if the last sampled velocity is not zero. We could add an option for using the desired states instead of the measured ones.

[firesurfer]

@christophfroehlich If I understand the code correctly the goal tolerances are just there for checking if the goal has been reached after sampling the last point of the trajectory. If the arm takes just a tiny bit of time to precisely reach the target this check would fail.

I worked around this in the previous version of the JTC by implementing our own check after the action has been executed successfully, but this only works under the precondition that the JTC actually sets the last point of the trajectory as desired target.

[christophfroehlich]

this is not 100% correct, it checks for he duration of the goal_time parameter, not only once.
this means, if you set a nonzero goal_time it should act as you desire

[firesurfer]

I did set the goal_time. Seems to work now. It was just confusing because there was a change in behavior compared to the previous version.

Nevertheless I think

We could add an option for using the desired states instead of the measured ones.

would be rather nice to have.