Why
While drafting the t4 hardware acceptance for #33, we hit a limit in the safety
guard that no amount of software can close.
The torque_guard landing for #33 releases torque on every abnormal exit where
the process still has a bus — SIGINT, an unhandled exception, and the actual
incident that motivated the issue (a second process opening /dev/ttyACM*, which
contends the port but does not remove it). Those are real, and the guard fixes them.
But the servos are powered from the 12 V supply, while USB carries only data.
Physically unplug the USB and /dev/ttyACM1 disappears: every release write fails,
and the motors sit holding their last commanded goal. The host has no channel left to
tell them otherwise.
So a physical bus loss leaves the arm energized, and the CLI cannot prevent it.
The only thing that could close it
A servo-side watchdog: some way to make the STS3215 drop torque by itself when it
stops hearing from the host. If such a mechanism exists in the memory table (a
comms-timeout register, a torque-off-on-idle protection bit, or similar), then the
arm could safe itself on a yanked cable — which is exactly the unattended failure
mode #33 is about.
What to find out
- Does the STS3215 (firmware 3.10, as on our follower) expose any comms-loss /
idle-timeout behavior in its memory table?
- If yes: register address, width, units, EEPROM vs RAM, and whether it survives a
power cycle.
- If yes: does enabling it interfere with
gentle_move's deliberate stop-and-hold?
A watchdog that drops torque during a legitimate hold would break the gripper
contract — it would need a timeout longer than any real hold, or it is unusable.
This pairs naturally with the offset-register spike (task t5 of the
arm-explore-now-maps-the-arm-s-real-joint-space-it plan) — both are "what does this
servo actually offer us" questions against the same memory table.
Meanwhile
The #33 spec is amended to claim only what is achievable: the guard covers abnormal
exits where the bus survives. Physical bus loss is documented as a known limit.
Found while drafting the t4 hardware procedure for #33.
Why
While drafting the t4 hardware acceptance for #33, we hit a limit in the safety
guard that no amount of software can close.
The
torque_guardlanding for #33 releases torque on every abnormal exit wherethe process still has a bus — SIGINT, an unhandled exception, and the actual
incident that motivated the issue (a second process opening
/dev/ttyACM*, whichcontends the port but does not remove it). Those are real, and the guard fixes them.
But the servos are powered from the 12 V supply, while USB carries only data.
Physically unplug the USB and
/dev/ttyACM1disappears: every release write fails,and the motors sit holding their last commanded goal. The host has no channel left to
tell them otherwise.
So a physical bus loss leaves the arm energized, and the CLI cannot prevent it.
The only thing that could close it
A servo-side watchdog: some way to make the STS3215 drop torque by itself when it
stops hearing from the host. If such a mechanism exists in the memory table (a
comms-timeout register, a torque-off-on-idle protection bit, or similar), then the
arm could safe itself on a yanked cable — which is exactly the unattended failure
mode #33 is about.
What to find out
idle-timeout behavior in its memory table?
power cycle.
gentle_move's deliberate stop-and-hold?A watchdog that drops torque during a legitimate hold would break the gripper
contract — it would need a timeout longer than any real hold, or it is unusable.
This pairs naturally with the offset-register spike (task t5 of the
arm-explore-now-maps-the-arm-s-real-joint-space-itplan) — both are "what does thisservo actually offer us" questions against the same memory table.
Meanwhile
The #33 spec is amended to claim only what is achievable: the guard covers abnormal
exits where the bus survives. Physical bus loss is documented as a known limit.
Found while drafting the t4 hardware procedure for #33.