The SO-101 robot arm: what changed, and what did not

What the SO-101 is

The SO-101 is the second iteration of the same open hardware design: five joints, a gripper, six actuators, printed structure, one serial bus. The maker is the same pairing of TheRobotStudio and the LeRobot project, the servo family is the same Feetech STS3215, and the supply voltage is the same 7.4 V. The revision sits in the wrist, and parts come in at roughly 130 to 170 euro rather than the 110 to 150 of the older arm.

It is worth saying plainly what this page will not do. It will not put a number on what the revised wrist buys you, because this platform does not measure arm mechanics. It measures policies: success rate on physical attempts, training cost, inference latency. A mechanical revision that improves how a joint holds under load shows up in those numbers only indirectly, mixed with your camera placement and your demonstration quality. Anyone quoting you a percentage for a wrist change is guessing.

What can be stated exactly is the support status. The catalog marks both the SO-100 and the SO-101 as fully supported, which means neither is a second class citizen in the driver, the recorder or the trainers. The cockpit you drive at /live runs an SO-100, but it is the same cockpit you will use here.

Specifications

What changed, and what did not

Laying the two arms side by side is the fastest way to see how narrow the difference actually is. Everything that touches your workflow is in the unchanged column.

Because the servo family and the bus are unchanged, the failure modes are unchanged too. The hardware fix pages that are scoped to Feetech chains apply here word for word: /fix/arm-twitches-then-sags for the sag that looks like a software bug and is a power problem, /fix/joint-stops-early for a joint that refuses part of its travel, and /fix/gripper-does-not-close for the one that has usually been solved by looking at the calibration rather than the fingers.

Coming from an SO-100

The question people actually arrive with is whether existing work survives the swap, and the answer splits cleanly in two. Data survives without qualification. Trained policies survive as candidates, not as finished results.

Datasets carry over because a LeRobot v2.1 recording contains joint positions, camera frames and a task string, and nothing in that layout names an arm model. Six numbers per control step is six numbers per control step. An SO-100 dataset trains for an SO-101 with no conversion step, and the two can sit in one dataset if the demonstrations really are the same task performed the same way.

Checkpoints are the delicate case. The action space has the same width, so a policy fine-tuned on SO-100 data will load and it will move the arm. Whether it succeeds is a separate question, because the calibration zero is a property of one physical machine, the wrist geometry has been revised, and your cameras have almost certainly moved during the swap. Any of those alone is enough to shift the mapping the policy learned. Treat a transferred checkpoint as something to evaluate, not something to deploy. /glossary/checkpoint and /glossary/fine-tuning cover what is and is not stored in one.

From the carton to the first movement

1. 1
   Confirm the supply says 7.4 V

   Do this before the first screw goes in, especially if this is a second arm and you already have supplies on the bench. /learn/so-100-getting-started carries the full build, and every step in it applies here apart from the wrist assembly order.

2. 2
   Set the ids while the connectors are reachable

   The bus addresses servos by id, so each one has to be written before it disappears inside a link. This is the step that costs a disassembly if you skip it.

3. 3
   Install the client and pair this machine

   The installer from /download brings the CLI and the desktop client together with the driver. The pairing code comes from the Robots page in the dashboard and is exchanged once.

   bash

   curl -fsSL https://www.ay-robots.com/install.sh | sh
   ay-robots pair 4QD2-8HRM-1XV6
   ay-robots status

4. 4
   Count the servos in the device list

   One arm, one serial port, six servos answering, plus your cameras. If a servo is missing here, the chain is open somewhere and no amount of software will find it for you.

   bash

   ay-robots devices

5. 5
   Calibrate this arm, even if you calibrated the last one

   The zero reference belongs to one physical machine. Guide the joints to the neutral pose and press Enter, then send the arm home to see the first commanded motion.

   bash

   ay-robots calibrate
   ay-robots home

# Record with the same task string every single episode
ay-robots record --task "put the lid on the jar" --episodes 40 --cameras wrist,top

# Review, then push the dataset to the cloud
ay-robots datasets list --local
ay-robots datasets upload jar-lid --name jar-lid-so101

# Training is started under Training in the dashboard or via the MCP tool start_training.
# There is no ay-robots train.

# Bring a finished checkpoint back to this arm
ay-robots run --model act --checkpoint s3://runs/jar-lid-so101/step-100000 --task "put the lid on the jar"
ay-robots stop

What the platform trains and runs on an SO-101

Four written guides, one per policy family, exactly as for the SO-100. The episode floors and the GPU tiers below are properties of the model, not of the arm, so they read the same on every fixed arm here.

Full hyperparameter defaults sit on /policies/smolvla, /policies/act, /policies/groot-n1-7 and /policies/pi0-5. If a run refuses your dataset immediately after upload, the cause is almost always the format rather than the arm, and /fix/dataset-rejected-v3 covers the one that catches most people.

Where the SO-101 sits against the other three

Against the SO-100 the SO-101 is a revision. Against the other two supported arms it is a different kind of machine, and those differences are not subtle.

• Against the SO-100: identical servos, identical voltage, identical software, a revised wrist, and roughly 20 euro more in parts. Both are marked fully supported.
• Against the Koch v1.1: a different servo ecosystem. Koch runs Dynamixel XL330 and XL430 on 5 V and 12 V rails at roughly 250 to 350 euro, so the driver, the wiring and the budget all differ while the dataset and training path do not.
• Against LeKiwi: LeKiwi is an SO-100 arm on a three wheel holonomic base at roughly 400 to 500 euro. Its wheel velocities enter the action vector, so its datasets are a different shape and its checkpoints do not interchange with a fixed arm.

Frequently asked questions