What calibration actually captures
One thing: a zero point. You power the arm, guide the joints by hand to the neutral pose while the servos are untorqued, and confirm. That confirmation reads all six servo positions once and stores each one as that joint reference, together with its offset from the servo center. That is the whole procedure. The arm never moves on its own and no range of travel is measured, so a calibrate that returns immediately has succeeded, it has not hung.
The save step does warn you about one thing: a captured zero that sits far from the servo center. A joint zeroed near one end of its scale saturates against the raw endstop later, so recapture that one from a more neutral pose.
ay-robots devices # the backend sees a serial port and your cameras
ay-robots calibrate # one reading of all six servos, no motion
ay-robots home # move to the home pose and check that it looks rightSO-100, SO-101 and the LeKiwi arm use Feetech STS3215 servos at 7.4 V. A 12 V supply destroys them in seconds, with no warning and nothing to recover. Koch v1.1 uses Dynamixel servos with 5 V and 12 V rails depending on the servo, so its wiring is not a template for the others.
Why a policy is worthless without it
A policy learned a mapping from pixels and joint values to joint targets on one specific arm. Joint values only mean something relative to the zero point, so if the reference moves, every command the policy issues lands somewhere other than where it learned it should. The failure does not look random. It looks like an arm performing the right motion in the wrong place, which people routinely misdiagnose as a bad training run and try to fix with more episodes.
- Recalibrate after any mechanical work: a re-seated horn, a replaced servo, a joint you tightened.
- Calibrate per physical unit, not per arm model. Two SO-101s off the same print are two calibrations.
- In a leader-follower pair, the follower is the one whose calibration enters the dataset.
- Do not mix episodes recorded before and after a recalibration into one dataset without checking that the arm still agrees with itself.
Why a home position near the edge of the servo scale causes trouble
The neutral pose you capture is not just a number. It is where every episode begins and the point every commanded angle is measured from. Put it near the end of a joint’s travel and two problems follow. The joint has almost no room left in one direction, so a correction the policy asks for on that side cannot be executed and the command saturates at the last position the scale can express, quietly, while nothing in the loss curve during training ever hinted at it. And the joint values your demonstrations occupy sit crowded at one end of the scale instead of spread across it, which is exactly the input distribution the normalization statistics are computed from.
The fix is cheap if you catch it before recording: pick a neutral pose roughly in the middle of each joint’s travel, recalibrate, and check with the home command that the arm settles somewhere it has room to move in both directions. It is expensive afterward, because the dataset carries the problem and no hyperparameter reaches it. /learn/so-100-getting-started walks the calibration step with an arm in front of you, and the capture itself is either the calibrate command in a terminal or the calibration wizard on the Hardware page for your robot in the dashboard.
Where this term does the explaining: symptoms whose cause sits in exactly what it describes.