[JTC] set_hold_position() doesn't actually stop the robot

[egordon]

Describe the bug
Upon aborting a goal or some other unrecoverable error, trajectory execution is stopped in the realtime loop by calling set_hold_position(), which sets an empty trajectory. This doesn't actually stop the robot. Instead, the empty trajectory does not have any valid point, so nothing at all is commanded to the hardware interface. This means that the last-commanded hardware state remains in place, which has no guarantee of actually stopping the robot.

To Reproduce

1. Start up JTC with e.g. velocity or acceleration control.
2. Start any trajectory.
3. Cancel the trajectory goal mid-execution so the trajectory is aborted
4. Observe that the robot continues to execute the last-commanded velocity or acceleration or effort.

This issue isn't visible with position-only control.

Expected behavior
We should handle this like a transition to the deactivate lifecycle state. Namely: set_hold_position() should echo the current position back to the robot, and velocity/acceleration should be commanded to 0.

I'll submit a PR to this effect.

Screenshots
N/A
But I can provide video of our physical robot (a modified Kinova JACO2) if necessary.

Environment (please complete the following information)

• OS: Ubuntu 22.04 Jammy
• ROS Version Humble
• With current package ros-humble-joint-trajectory-controller v2.20.0-1jammy.20230522.072811

Additional Context

Note the existing TODO with regards to effort interfaces, it is unclear how to stop an effort-only interface in a robot-agnostic way.

[christophfroehlich]

Duplicate of #514? At least the same behavior causing both issues IMHO.