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 parts run roughly 110 to 150 euro. That price is the reason the design exists: it puts a manipulator that can record real demonstration data on a desk next to a laptop.

What the money does not buy is precision. There is no force or torque sensing, the gearing has backlash you can feel by hand, and the pose the arm returns to drifts 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.

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 anyone can drive from a browser with no account. 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 covers the arm only. Cameras, the supply and the host machine sit outside it, and so does the second arm you need to teleoperate with a leader, an arrangement explained in /glossary/leader-follower. Five joints plus a gripper also fixes the width of every action the policy will 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 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 why a fault looks strange the first time: a bad connector at the third joint takes out that joint and everything past it.

So the device list is the first thing to read when something is wrong, not the last. If no port appears, the problem is 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 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 code comes from /dashboard/client/robots/new, which issues one as it loads
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 starts in the web dashboard under Training, or through the start_training tool on the MCP server. Reaching for a training subcommand is the most common wrong turn here, because older material elsewhere documents one that never existed.

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 set while you can still reach the connector. Afterwards this becomes a disassembly job, and the bus addresses servos by id rather than by position.

3. 3
   Install the client

   One command gives you the CLI and the desktop client with the driver inside both. There is no Python environment to build.

   bash

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

4. 4
   Pair the machine

   Add a robot inside one of your environments in the dashboard and follow the link to pair a real robot, or go straight to /dashboard/client/robots/new. That screen issues the one-time code by itself, and if the client is already running on the machine you are browsing from it redeems the code for you. Typing it is the route for a client on another host. Either way the code is exchanged once for a permanent credential, and 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

   One arm on one serial port, six servos answering, plus your cameras. That tells you the chain is electrically sound before you bolt anything else on.

   bash

   ay-robots devices

6. 6
   Calibrate, then home

   Guide the joints to the neutral pose, press Enter to store the zero, then send the arm home. That commanded movement proves the build. /glossary/calibration explains why every later number depends on the zero.

   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 have a guide written for this arm. The choice is mostly what you are willing to spend per run and how fast you want an answer about your dataset.

Full defaults sit on /policies/smolvla, /policies/act, /policies/groot-n1-7 and /policies/pi0-5. GR00T N1.5 at /policies/groot-n1-5 still trains, but it exists to reproduce runs that started before N1.7 rather than to begin new work.

The route from an empty desk to a running policy is the same whichever model you pick: record while teleoperating, discard the episodes that went badly, upload, start a run in the dashboard, then hand the 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 and they are not four grades of one product. Two are the same machine a revision apart, one belongs to a different servo ecosystem, and one is an arm bolted to something that drives.

• SO-101: the direct successor with a revised wrist. Same servos, same 7.4 V, same software path, roughly 130 to 170 euro in parts.
• Koch v1.1: Dynamixel XL330 and XL430 servos on 5 V and 12 V rails instead of one Feetech chain. Different driver, different wiring, roughly 250 to 350 euro. Everything past the serial port is unchanged.
• LeKiwi: an SO-100 arm on a three wheel holonomic base, roughly 400 to 500 euro. Wheel velocities join the action vector, so its datasets and its checkpoints do not interchange with a fixed arm.

Frequently asked questions