This PR provides a temporary fix for stretch_ros2#140, where the wrist pitch falls if trajectory cancel requests are invoked in rapid sequence. This issue manifests on the web app if an operator spams a button in press-and-hold mode (and maybe other modes as well).
The way this PR fixes it is by _removing all "stop trajectory" commands that are sent to stretch_driver from the web app_. This is far from an ideal solution, because what that means is that trajectories cannot be interrupted. e.g., if an operator is in the "Fastest" speed and presses "arm lift up" but immediately lets it go since they made a mistake, the arm will still move the entire 12cm up. However, it is important to note that this does not harm current functionality, because the bug in stretch_ros2#139 results in stretch_driver not processing cancellation commands anyway, and executing the trajectory to completion even if a cancellation was invoked.
Thus, I propose the following:
We merge this in, to fix the wrist pitch dropping issue.
Once stretch_ros2#139 and stretch_ros2#140 are addressed, we re-add "stop trajectory" commands (which can be easily toggled by a boolean flag). This will add the desirable behavior (which has never been present in this web app) of immediately stopping motion, as opposed to waiting until the previously-commanded incremental motion finished.
Testing procedure
[x] Recreate the issue: pull master, re-build the workspace, and launch the app ./launch_interface. In the operator interface, spam "wrist pitch up". Verify that the wrist falls.
[x] Verify the fix: pull this branch, re-build the workspace, and launch the app ./launch_interface. In the operator interface, spam "wrist pitch up". Verify that the wrist does not fall.
[x] Verify no negative consequences: In each of the below modes, on the "Fastest" speed, click all joint motion (base translate, base rotate, wrist pitch, wrist roll, wrist yaw, arm lift, arm length) and verify that the motion never continues forever.
[x] Press-and-hold
[x] Click-click
[x] Step-actions
[x] Run the above tests on the following configurations:
Description
This PR provides a temporary fix for
stretch_ros2
#140, where the wrist pitch falls if trajectory cancel requests are invoked in rapid sequence. This issue manifests on the web app if an operator spams a button in press-and-hold mode (and maybe other modes as well).The way this PR fixes it is by _removing all "stop trajectory" commands that are sent to
stretch_driver
from the web app_. This is far from an ideal solution, because what that means is that trajectories cannot be interrupted. e.g., if an operator is in the "Fastest" speed and presses "arm lift up" but immediately lets it go since they made a mistake, the arm will still move the entire 12cm up. However, it is important to note that this does not harm current functionality, because the bug instretch_ros2
#139 results instretch_driver
not processing cancellation commands anyway, and executing the trajectory to completion even if a cancellation was invoked.Thus, I propose the following:
stretch_ros2
#139 andstretch_ros2
#140 are addressed, we re-add "stop trajectory" commands (which can be easily toggled by a boolean flag). This will add the desirable behavior (which has never been present in this web app) of immediately stopping motion, as opposed to waiting until the previously-commanded incremental motion finished.Testing procedure
master
, re-build the workspace, and launch the app./launch_interface
. In the operator interface, spam "wrist pitch up". Verify that the wrist falls../launch_interface
. In the operator interface, spam "wrist pitch up". Verify that the wrist does not fall.Before opening a pull request
From the top-level of this repository, run:
pre-commit run --all-files
To merge
Squash & Merge