Torque / self-protection gap: velocity limiting alone cannot prevent hardware damage on non-self-protecting followers

[johnnynunez]

Context

The rate-limiter harness (PR #727) limits velocity — deliberately and honestly scoped: it does not and cannot limit torque, detect collisions, or protect the mechanism. On self-protecting followers (Franka/UR-class controllers) that gap is covered by the robot. On low-cost position-servo followers (Feetech SO-101, Damiao DevArm) nothing covers it:

• A target reached at perfectly legal velocity still pushes with maximum torque if it collides on the way (or at the goal).
• The servo/firmware either stalls at full current (heat, stripped gears) or — worse — latches a fault silently.

This issue proposes making that gap explicit and closing what's closeable from the teleop stack's side.

Evidence from one week of hardware sessions

• SO-101 motor 4 stripped a gear: convention mismatch at t=0 executed at full torque (issue [Design] Make the follower contract explicit: t=0 / post-reset targets must be ramped or guarded #730 covers the t=0 half; this issue covers the torque half — at any t).
• SO-101 gripper opened into the robot's own body at startup (curled initial pose): legal-velocity motion, full-torque collision, no detection.
• DevArm B601 drove ~13 rad into its mechanical stop from a 2π-wrapped gripper reading: the Damiao firmware silently latched over-temperature faults (0xC) and dropped torque with no notification to the stack (rebot_devarm_leader: add a 'calibrate' subcommand to measure sign/offset_rad (leader/follower zeroing is never cross-verified) #734 covers the wrap; the silent-stall half belongs here).

Pattern: the harness makes motion smooth, but smooth motion into an obstacle is still a full-torque press.

Proposal (tiered, from cheap to ambitious)

1. Document the scope honestly in the harness/limiter docs: "velocity-limited ≠ safe; on followers without torque control you MUST configure servo-side current/torque limits." One paragraph, prevents false confidence.
2. Follower-side protection recipes: for the common buses, document (or helper-script) the servo registers that matter — e.g., Feetech Torque_Limit / Max_Current-class registers, Damiao current limits and fault-flag polling — so integrators can set electrical self-protection to match the mechanism.
3. Stall/fault feedback into the retargeting graph: a standard input port for follower state (present current, temperature, fault flags) so a governor node can react (back off, disengage clutch, signal the operator via the feedback channel from [RFC] In-headset operator feedback as a first-class concern (HUD, haptic grammar, runtime scale control) — seeking design direction #738) instead of continuing to command into a stall. This is the piece that would have caught both the gripper-vs-body press and the DevArm stop-press within milliseconds instead of after gear/thermal damage.
4. (Ambitious) command-vs-measured divergence monitor: persistent tracking error beyond a threshold at low velocity ≈ contact — even with no current sensing, this heuristic detects "pressing against something" on any position-servo follower.

Items 1–2 are documentation; item 3 is a graph-API design question we'd value the team's direction on before prototyping; item 4 can live entirely in a retargeter node and we're happy to prototype it.

---

Part of the field-integration feedback series (SO-101 + reBot DevArm, June 29 – July 6). Priority suggestion: P0/P1 — this is the residual hardware-damage vector after #730/#731 land.