The SO-100 robot arm: hardware, servos and what runs on it

What the SO-100 is

The SO-100 is a five joint arm with a gripper, six actuators in total, designed by TheRobotStudio together with the LeRobot project and published as open hardware. The structure is printed, the electronics are six bus servos on a single chain, and a complete set of parts runs roughly 110 to 150 euro. That price is the entire reason the design exists: it puts a manipulator capable of recording real demonstration data on a desk next to a laptop instead of in a lab.

What the money does not buy is precision. There is no force or torque sensing anywhere in the arm, the gearing has backlash you can feel by hand, and the pose it returns to drifts over a long session as the servos warm up. None of that is a defect to engineer around. Learning from demonstrations tolerates all three, which is why this class of hardware and this method arrived together rather than one following the other.

On this platform the SO-100 is the reference machine. Features are validated against one before they are claimed to work anywhere else, and /live is a real SO-100 in a rack that anyone can drive from a browser with no account and no signup. If you want to know how the joint limits and the gripper behave before ordering parts, that is the cheapest test available.

Specifications

The cost figure covers the arm only. Cameras, the supply and the machine you drive it from sit outside it, and so does a second arm if you intend to teleoperate with a leader, an arrangement explained in /glossary/leader-follower. Five joints plus a gripper is also the number that decides the width of every action your policy will ever emit, which /glossary/degrees-of-freedom puts in context.

One bus, six ids, and the number that ends arms

The six STS3215 servos are not wired individually. They are daisy chained on a single half duplex serial line, each servo holding a numeric id, and the whole chain reaches the host as one serial port. That is what makes the arm cheap, and it is also why a fault looks strange the first time you meet one: a bad connector at the third joint does not take out the third joint, it takes out that joint and everything past it.

The practical consequence is that the device list is the first thing to read when something is wrong, not the last. If no port appears at all, the problem sits in the cable, the driver or the port name, and /fix/arm-not-detected works through those in order. If the port is there but a servo stays silent, the chain is broken at a locatable point and /fix/servo-not-responding bisects it. Cameras have their own version of the same story in /fix/camera-not-detected.

The commands you will actually type

curl -fsSL https://www.ay-robots.com/install.sh | sh
ay-robots version

# The pairing code comes from the Robots page in the dashboard
ay-robots pair 4QD2-8HRM-1XV6
ay-robots status

# Six servos and every camera the backend can see, with serial ports
ay-robots devices

# Once per physical arm, before the first recording
ay-robots calibrate

# Back to the neutral pose whenever the scene needs a reset
ay-robots home

Everything the arm does locally is in that list plus record, run and stop. Training is deliberately absent: it happens on a rented cloud GPU and is started in the web dashboard under Training, or through the start_training tool on the MCP server. Reaching for a train subcommand is the most common wrong turn on this platform, because older material elsewhere on the internet documents one that never existed here.

From the carton to the first movement

1. 1
   Sort the kit and check the supply

   Count the servos and find the power supply before you pick up a screwdriver. If the label does not say 7.4 V, stop there and get one that does. The full build with photographs is in /learn/so-100-getting-started.

2. 2
   Write the servo ids before assembly

   Each servo needs its id written to it while you can still reach the connector. Doing this after the arm is screwed together turns into a disassembly job, and the order matters because the chain is addressed by id, not by position.

3. 3
   Install the client

   One command gives you the CLI and the desktop client, and the robot driver ships inside both. There is no Python environment to build and no dependency tree to lose an evening to.

   bash

   curl -fsSL https://www.ay-robots.com/install.sh | sh

4. 4
   Pair the machine

   The pairing code from the Robots page is exchanged once for a permanent credential on this machine. The status command confirms both halves, the backend and the pairing.

   bash

   ay-robots pair 4QD2-8HRM-1XV6
   ay-robots status

5. 5
   Read the device list

   You want one arm on one serial port and every camera you attached. Six responding servos here means the chain is electrically sound, which is the single most useful thing to know before you start bolting on cameras.

   bash

   ay-robots devices

6. 6
   Calibrate, then home

   Guide the joints to the neutral pose, press Enter to store the zero reference, then send the arm home. That commanded movement is the moment the build is proven. What the zero actually is, and why every later number depends on it, is in /glossary/calibration.

   bash

   ay-robots calibrate
   ay-robots home

What the platform trains and runs on an SO-100

All five supported policies train on SO-100 data, and four of them have a guide written specifically for this arm. The choice between them is mostly a question of what you are willing to spend per run and how quickly you want an answer about your dataset.

The model pages at /policies/smolvla, /policies/act, /policies/groot-n1-7 and /policies/pi0-5 carry the full default hyperparameters. GR00T N1.5 at /policies/groot-n1-5 still trains, but it is kept for reproducing runs that started before N1.7 existed rather than for beginning new work.

The route from an empty desk to a running policy is the same whichever model you pick. Record episodes while teleoperating the arm, review and discard the ones that went badly, upload the dataset, start a run in the dashboard, then hand the resulting checkpoint back to the arm.

# Records episodes. You drive the arm from the client or the web cockpit while this runs.
ay-robots record --task "pick up the red cube and place it in the bowl" --episodes 30 --cameras wrist,top

# Enter ends an episode, Ctrl-C discards the one in progress rather than saving half of it
ay-robots datasets list --local
ay-robots datasets upload cube-to-bowl --name cube-to-bowl-v1

# Training has no CLI command. Start it under Training in the dashboard,
# or through the start_training tool on the MCP server.

# When the checkpoint exists, bring it back to the arm
ay-robots run --model smolvla --checkpoint s3://runs/cube-to-bowl-v1/step-20000 --task "pick up the red cube and place it in the bowl"
ay-robots stop

How it differs from the SO-101, the Koch v1.1 and LeKiwi

Four arms are supported here and they are not four grades of the same product. Two are the same machine a revision apart, one belongs to a different servo ecosystem entirely, and one is an arm bolted to something that drives.

• SO-101 is the direct successor with a revised wrist. Same Feetech servos, same 7.4 V, same software path from device list to deployed checkpoint, roughly 130 to 170 euro in parts.
• Koch v1.1 uses Dynamixel XL330 and XL430 servos on 5 V and 12 V rails instead of one Feetech chain. That changes the driver, the wiring and roughly 250 to 350 euro of the budget. Everything downstream of the serial port is unchanged.
• LeKiwi is an SO-100 arm on a three wheel holonomic base, roughly 400 to 500 euro. The wheel velocities become extra entries in the action vector, which makes its datasets and its checkpoints incompatible with a fixed arm in both directions.

If you are choosing with no other constraint, the SO-100 and the SO-101 are the two to decide between, and the honest tiebreaker is which set of parts you can actually get hold of. Nothing in the software prefers one over the other.

Frequently asked questions