My arm draws, weighs, throws and docks a drone

Each task on the ladder reuses a module’s deliverable, so replaying the ladder on the printed arm adds props, not new subsystems: the wave, drawings by every controller under payload, weighing, cup sorting, the melody, 20 throws per policy, 10 dock cycles with the 230 g dummy of the Volume 2 drone, and the ball in a cup as a stretch. Hardware checks need a video for trainer review. The throw and the ball in a cup run without the 3 rad/s rate limit, in a cleared zone, with faces out of the throw line.

Each check is fixed before the run. Drawings are scanned, registered to the arm’s frame by the printed marks on the sheet and overlaid on the command, with the RMS deviation reported. Weighing reports its error against the scale. The melody needs an RMS strike-time error under 20 ms after compensation. The dock needs 10 of 10 cycles without a safety latch, with the shoulder’s RMS current per cycle under its rated-torque current, about 0.9 A. The real throw’s hit rate and the ball in a cup’s success rate over 20 tries are reported, whatever they show.

Keep a video of every task, the scans, the microphone recordings and the latch log, each run with its commit, config and seed. The dock is the hand-off: in Volume 2 the drone lands on a pad within the arm’s reach, and the arm lifts it by the same handle into the cradle and back onto the pad for the next flight, in a layout settled when Volume 2 is revised. This companion describes the replay and its checks; it claims no hit rates, drawings or dock cycles, which only your own runs can supply.