B grade Authoritative secondary, traced to origin

Build a desktop arm: from parts to the smallest loop that produces data

Using the SO-101 route as the example. The goal is not a waving arm; it is reaching the state where you can teleoperate stably and collect a batch of clean demonstrations — the foundation everything after it sits on.

Type: Desktop 5 DOF + gripper (leader-follower teleoperation)
Budget: About USD 110–150 (spare servos extra)
Servos: Feetech STS3215 × 12 (bus, position feedback)
Software: LeRobot: teleoperate → record → train → eval
Time: Printing 1–2 days; assembly and bring-up within the first week
Reference: github.com/huggingface/lerobot

Desktop arm: how the body goes togetherTap a number — or the legend below — to jump to its entry

What counts as moving: The MVP is not 'the servos move'. It is 10 minutes of teleoperation with zero drift, 50 demonstrations of usable consistency, and data that saves and replays. Behind those three checks stand three thresholds: servo homing (backlash and mechanical zero agreeing), camera calibration (extrinsic error goes straight into your dataset), and the data pipeline (LeRobot format saving and replaying). Until you are past all three, training talk is masonry without a foundation.
Parts and sourcing: About USD 110–150: twelve Feetech STS3215 servos (six per arm, bus-connected with position feedback, around USD 14 each), a bus-to-USB adapter board, one 12 V supply per arm, about 1 kg of filament, M2/M3 screws and bearings, and one USB camera (a phone works temporarily, but switching cameras means recalibrating). Add two spare servos. At this price, stall-burning one is not unlikely, and waiting for a courier mid-assembly wears worse than the failure itself.
Assembly order: Order: print (two mating parts first to check tolerance, then the whole batch) → build the leader arm (light damping for teaching) → build the follower → wire the bus as a daisy chain, never a star → power each servo alone and verify direction → gripper last. Two details you cannot skip: home the servos in software before assembly, not after — adjusting after mounting cures assembly error into your calibration; and when a hole is tight, drill it out to 3.2 mm rather than force the screw — forced assembly stress cracks printed parts under load, starting at the hole edge.
Software stack: Install in layers, never all at once: layer one is LeRobot only (Python 3.10+, pip, Linux or WSL2) — configure the port and servo IDs and you can teleoperate, which already reaches the MVP. Layer two is ROS 2 + MoveIt (for reuse when you swap arms later); layer three is MuJoCo simulation (verify trajectories in sim before hardware). The most expensive beginner mistake is installing all three at once — three dependency problems stack into 'unknown which layer is broken'.
Bring-up to first motion: First power-up sequence: unloaded — one servo on the bus, read its ID and position in software, confirm communication; then one at a time, verifying direction and sign of each; only then on the arm under load. Three common stalls with telltale symptoms: ① ID conflict — two servos sharing an ID; one moves, the other twitches along; ② supply sag — voltage drops when six servos act together; the whole arm resets mid-motion; ③ adapter driver — an old CH340 driver on Windows fails to enumerate; the device simply never appears in the port list. Each has a signature symptom, and none of them is fixed by recompiling.
Where to go next: Three paths after MVP: collect data and train a first policy (50 demonstrations are enough for a small ACT, proving the whole chain); add a mobile base (LeKiwi is exactly this route — put the arm on a rover and your data scenes grow); move to a high-torque layout (Thor-class, at which point you will finally understand why bus servos cost what they cost). Not recommended: wrist cameras or force sensors on day one. Sensors are amplifiers — they amplify noise as faithfully as signal. Stabilise MVP data quality first.
What we checked: We verified: the BOM structure and servo model against LeRobot's official docs and repo; the daisy-chain wiring and the symptom signatures of the three common faults, consistent across community build logs; and that LeRobot's teleoperate / record / train flow exists and is documented. We did not build this one ourselves — the time figures and the 'first week to MVP' come from community reports at order-of-magnitude precision, not from our own bench. The grade stays where it is for that reason.

This site's call

The most recommended first machine of any type. Not because it is strong — it is weak — but because it is cheap enough to afford every beginner mistake, and its software chain happens to turn 'collect data, train a policy' into scripts. Finish this one and half the traps in quadrupeds and humanoids are already familiar.

Symptoms, causes, first moves

Symptom	Likely cause	First move
One joint moves, another twitches along	ID conflict	Put servos on the bus one at a time; reassign IDs
Whole arm resets mid-motion	Supply sag under simultaneous load	Measure rail voltage; use a higher-current supply
Device never appears in port list	USB adapter driver (CH340)	Swap the cable before blaming the driver
Teleoperation drifts after minutes	Homing missed or loose mounting	Re-home; check servo brackets for play

Time expectation

Printing 1–2 days, assembly an evening, MVP within the week — provided you do not mount the gripper on day one. Every rework after that starts by taking the gripper off.

Sources

LeRobot official documentation (BOM, assembly, teleoperate / record / train flow)
Community build logs (fault symptoms and time figures)

Objects in this entry

Last checked 2026-09-28