Handle joint delta safety stops without exiting - #23
Merged
Merged
Conversation
stevenaya
force-pushed
the
agent/safety-stop-behavior-draft
branch
2 times, most recently
from
September 4, 2026 14:25
df1cd5b to
3ad3b9b
Compare
kou
pushed a commit
that referenced
this pull request
Sep 8, 2026
## Summary - align configured arm limits and numeric precision with the current OpenArm model - use the full J1/J2 range for the pedestal configuration while retaining the cell-specific range - update the gripper limit precision and position-limit tests Follow-up PRs #27 and #23 have been rebased on top of this change. ## Testing - `.venv/bin/pytest -q` (40 passed) - `.venv/bin/ruff check .` Co-authored-by: stevenaya <stevenaya@users.noreply.github.com>
stevenaya
force-pushed
the
agent/safety-stop-behavior-draft
branch
2 times, most recently
from
September 8, 2026 10:12
b30e13d to
a0bc4b5
Compare
kou
pushed a commit
that referenced
this pull request
Sep 9, 2026
## Summary - expose the wall-clock time captured immediately before dispatching the latest accepted position target; - publish the cached command and timestamp only after arm and gripper dispatch calls succeed; - keep an owned copy of the accepted target so caller-side mutations cannot change driver state; - invalidate dispatch metadata when a new start session begins. ## Why Downstream nodes need a wall-clock dispatch marker to correlate the command accepted by the driver with external observations. This is a software dispatch timestamp, not motor acknowledgement or physical motion time. The existing monotonic timestamp remains dedicated to velocity limiting. The boolean send result now belongs to draft PR #23, where safety rejection introduces real `False` paths. ## Validation - `pytest` (41 passed) - `ruff check .` - `ruff format --check .` Co-authored-by: stevenaya <stevenaya@users.noreply.github.com>
stevenaya
force-pushed
the
agent/safety-stop-behavior-draft
branch
from
September 16, 2026 19:14
a0bc4b5 to
ad88a35
Compare
stevenaya
marked this pull request as ready for review
September 16, 2026 19:19
This was referenced Sep 16, 2026
stevenaya
force-pushed
the
agent/safety-stop-behavior-draft
branch
from
September 17, 2026 06:14
ad88a35 to
b80a06b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Falseand latch force-stop safety rejections while keeping the driver process alive; expose the reason through read-onlysafety_stop_reason.start(). Failed startup leavesstarted=Falseand position commands blocked.Recovery and compatibility
Inspect and resolve the cause, then call
stop()followed bystart(). The latch blocks new targets; explicitstop()disables the motors. Holding behavior depends on the motor and communication state.Method arguments and
get_health()'s(motor_status, bus)return structure stay unchanged. Existing callers can ignore boolean results, and legacy trajectory hooks returningNoneremain supported. Configuration and CAN exceptions keep their existing behavior.Feedback-freshness enforcement and Dora/UI status propagation are deferred. Current health diagnostics remain observational; startup can still read cached feedback. Dora integration is tracked separately in enactic/dora-openarm#35.
Timing and messages
Keep the 40 ms command-time cap to bound velocity-limited catch-up after scheduling pauses or command gaps. Normal 250 Hz operation still uses its actual approximately 4 ms interval. J1-J8 diagnostic numbering and the delta-limit type annotation are retained.
Related to #22.
Validation