[Design] Make the follower contract explicit: t=0 / post-reset targets must be ramped or guarded

[johnnynunez]

Context

A week of hardware-in-the-loop integration (Quest 3 → CloudXR → Isaac Teleop retargeting → LeRobot followers: SO-101, reBot DevArm B601) surfaced a recurring bug class: retargeter output may be arbitrarily far from the physical robot's actual state at t=0 and after resets, and nothing in the library states or checks what the consumer is expected to do about it.

The stock pipeline implicitly assumes a follower that protects itself (Franka/UR-class velocity envelopes in the controller). Low-cost position servos (e.g., Feetech on the SO-101) execute any bus target at full torque with no hardware envelope — so an unguarded first frame turns any convention/state mismatch into a violent jump.

Evidence

• SO-101 motor 4 (wrist_flex) stripped a gear on an uncommanded full-speed jump at t=0: a gripper drive-direction mismatch (unmeasured drive_mode) was executed at full torque by the first unconditional send_action(), with silent clipping masking the magnitude. Gear damage confirmed acoustically (~140 Hz tone, impact events at ~10.8 Hz ≈ 1 knock/rev).
• The same pattern links Teleoperation - gripper widely open et start huggingface/lerobot#3942 (mirrored gripper slams open at t=0) and the DevArm leader/follower zeroing mismatch — different mechanisms, same class: state consumed without verification at t=0.
• We fixed this at the LeRobot layer (feat(teleop): add startup joint-mismatch guard to teleoperate/record loops huggingface/lerobot#3954, StartupJointGuard: first-frame command-vs-observation guard, ramp or abort) — but every non-LeRobot consumer of Isaac Teleop will re-discover this the hard way.

Proposal

One (or both) of:

1. Document the follower contract explicitly: retargeter output is a desired target, not a safe command; consumers MUST ramp/guard the first frame and after any reset/re-engage. A short section in the retargeting docs would already prevent broken hardware.
2. Provide a baseline-injection hook on rate-limiting/retargeter nodes so consumers can seed the limiter from measured robot state at startup (today the first emitted command becomes the de-facto baseline, which is exactly the unsafe case).

Related: PR #727 (rate limiter + anomaly-rejection tier) covers in-band spikes, but cannot know the physical pose at t=0 without such a hook.

Happy to contribute the implementation — raising for design discussion first.

---

Part of the field-integration feedback series (SO-101 + reBot DevArm, June 29 – July 6). Priority suggestion: P0.