You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Start up JTC with e.g. velocity or acceleration control.
Start any trajectory.
Cancel the trajectory goal mid-execution so the trajectory is aborted
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.
The text was updated successfully, but these errors were encountered:
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
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)
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.
The text was updated successfully, but these errors were encountered: