Maker · Active Project

SO-ARM101 Leader/Follower Arm — Build & Pi 4 Migration Report

Part of the same project as the AIY Voice Kit final report and AIY Vision Kit final report — see the project roadmap for the overall plan.

Goal: assemble the SO-ARM101 leader/follower pair, validate teleoperation, and migrate the working setup from Mac to the target Pi 4 hardware.

Result: ✅ Phase 2 complete — both arms assembled, calibrated, and confirmed running live teleoperation at a stable 60Hz, first on a Mac for validation, then successfully migrated to the Pi 4 (1GB). Camera integration validated ahead of schedule.

Assembly

Refreshingly uneventful compared to the AIY kits — the SO-ARM101's 3D-printed parts and clear motor-ID-then-assemble sequence (built into Hugging Face's official LeRobot documentation) meant no real snags worth documenting. Motor IDs were set one at a time before each motor was mechanically installed into its joint — necessary since IDs can't be addressed individually once several motors share a daisy-chained bus.

Mac → Pi 4 Migration

The arm was first calibrated and teleoperated on a Mac to validate the mechanical build independent of any Pi-specific issues. Moving to the Pi 4 surfaced a few small, well-understood issues — none related to the arm itself:

"No space left on device" during install, despite plenty of free disk — caused by pip's temp directory defaulting to a small RAM-backed tmpfs on Raspberry Pi OS, too small for the torch wheel. Fixed by redirecting TMPDIR to the main disk during install.
Calibration transferred as files, not re-run — motor IDs live on the servos' own EEPROM, so only the host-side calibration JSON needed copying (via scp) from Mac to Pi; no need to redo the calibration procedure itself.
Port names differ by OS — macOS's /dev/tty.usbserial-XXXX vs. Linux's /dev/ttyUSB0/ttyUSB1, easily found with lerobot-find-port on either platform.
Camera discovery listed 6 devices, only 1 real — the Pi's internal CSI camera processing pipeline (bcm2835-codec/isp/unicam) shows up as multiple phantom "camera" entries even with nothing connected to the CSI port. The actual USB webcam was identified separately via v4l2-ctl --list-devices and lsusb.
First camera connection attempt timed out, second attempt succeeded — appears to be a one-off USB/driver settling quirk on first touch, not a reliability problem; simply retrying resolved it.

Result

Teleop loop time: 16.67ms (60 Hz)

Confirmed stable on the Pi 4 with the leader and follower both connected, and separately confirmed the same 60Hz stability holds with a USB webcam streaming simultaneously — meaning the 1GB Pi 4 comfortably handles the combined workload Phase 3/4 will need.

What This Demonstrated

Validating hardware/mechanical assembly independently of the target compute platform (Mac first, Pi second) — isolating "is the arm built correctly" from "does the Pi handle it," rather than debugging both at once
Understanding why calibration data is portable across machines while motor configuration is not, rather than just following steps
Correctly distinguishing real hardware (a USB webcam) from a host system's internal camera pipeline artifacts when several unfamiliar "camera" devices appear at once

Key takeaway: The arm itself was the easy part — every issue hit during the Pi 4 migration was a platform/environment quirk (disk paths, port naming, phantom camera devices), not a hardware or LeRobot problem. Isolating "did I build this right" from "does this specific computer run it right" by testing on the Mac first made each of those quirks trivial to diagnose instead of confusing.

For full setup details, see the session wrap-up and the complete Pi 4 migration log with all commands and troubleshooting.

Next: Phase 3 — recording leader→follower demonstrations for a first dataset. See the full pick-and-place project write-up for how this turned out.