Developer guide
SO-101 and LeRobot observability: what to record before your next run
An evidence checklist for the SO-101 workflow, from calibration context and camera freshness to a useful saved run.
Start with a question the recording should answer
An SO-101 arm can appear to behave differently between two runs even when the task instruction is identical. Before changing the policy, decide what you need to compare. Did the controller receive a different target? Did a camera stop updating? Did calibration change? Was the scene reset in the same way? A recording is useful when it makes those questions answerable.
Our La Machine integration showed why a single activity log is insufficient. Camera views, leader input, follower measurements, and sent targets each describe a different part of the task. The first instrumentation milestone should be a coherent record of one supervised run, including its gaps.
Keep the robot identity and setup with the run
Give the recording a run identifier and store a small setup record beside it. Include the arm role, controller version, calibration reference, camera configuration, and whether the environment is hardware or simulation. Keep device identifiers local unless they are needed for a deliberately shared report. A later review should not have to guess which physical arm produced a reading.
LeRobot's official workflow covers SO-101 setup and the path from teleoperation to dataset recording and policy evaluation. Use the upstream instructions for the exact release you install. An observability article should complement that workflow, not replace calibration instructions with a supposedly universal command.
Separate leader input, sent target, and follower measurement
A leader arm is an input device in a teleoperation workflow. A target sent to the follower is a request. A follower reading is reported state. Store them with explicit roles and units. If you plot all of them as one line called position, the graph can hide the difference you are trying to diagnose.
For a comparison, choose the same joint and a short interval around an unexpected event. Check whether a target changed, whether the reported follower state changed, and whether timestamps support the order you infer. Do not derive intent from joint motion alone. A bent elbow does not tell you which instruction selected the movement.
Make camera age visible
Keep each frame's camera identity and capture time when available. Also retain when your observer received it. A feed may be reachable while its most recent image is old. A frozen image should not continue to reassure the operator because the browser still displays it.
For replay, show the closest eligible frame at or before the selected moment and disclose its age. If there is a long gap, leave a gap. Reusing a much older image without a label makes the recording appear more complete than it is. Our historical camera and dashboard images illustrate why scene evidence belongs beside telemetry, with its own clock.
Review the run without commanding the robot
Build review around the saved record. Scrubbing a timeline should inspect data without sending targets to a connected arm. Keep any execution replay as a separate, explicit operation with its own authorization and hardware checks. The word replay otherwise hides two very different actions.
Use the record to write a short outcome: task observed complete, task observed incomplete, or outcome unknown. Explain the evidence behind the label. A dropped object, an occluded camera, and a disconnected collector should not all collapse into the same generic failure message.
A useful first acceptance check
Ask a second person to inspect your saved run without watching the original demonstration. Can they identify the requested task, the hardware used, the observed motion, the freshest camera evidence, and the unresolved questions? If they cannot, improve the recording before adding more charts.
ClawMetry's SO-101 work began with a specific hackathon setup. Reproducing it on another machine requires checking that setup's interfaces and versions. Start with observation and use the controller's supported local procedures for any physical intervention. A trace is evidence for review. It is not proof of a certified safety function.
Sources and evidence
External sources support the attributed background. Integration accounts describe historical project evidence. Guidance and proposed tests are identified in the article.