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, a printed structure and one serial bus. The maker is the same pairing of TheRobotStudio and the LeRobot project, the servos are the same Feetech STS3215, the supply is the same 7.4 V. The revision sits in the wrist, and parts land at roughly 130 to 170 euro rather than 110 to 150.

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 shows up in those numbers only indirectly, mixed with your camera placement and your demonstration quality.

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

Specifications

What changed, and what did not

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

Coming from an SO-100

The question people actually arrive with is whether existing work survives the swap. The answer splits cleanly: data survives without qualification, trained policies survive as candidates rather than as results.

Datasets carry over because a LeRobot v2.0 recording holds 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, and the two can share 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 will move the arm. Whether it succeeds is separate, because the calibration zero belongs to one physical machine, the wrist geometry has been revised, and your cameras almost certainly moved during the swap. Any one of those shifts the mapping the policy learned. /glossary/checkpoint and /glossary/fine-tuning cover what is actually 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, especially if this is a second arm and there are already supplies on the bench. /learn/so-100-getting-started carries the full build and 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 is issued by the pairing screen at /dashboard/client/robots/new, which you reach by adding a robot inside an environment. It generates the code on load, hands it to a client on the same machine without asking, and shows it for fifteen minutes so a remote host can be paired by hand.

   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 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, 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 through the
# start_training tool on the MCP server. The CLI has no training subcommand.

# 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 GPU tiers below are properties of the model rather than the arm, so they read the same on every fixed arm here.

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 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: identical servos, identical voltage, identical software, a revised wrist and roughly 20 euro more in parts. Both hold full support.
• 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 driver, wiring and budget differ while the dataset and training path do not.
• Against LeKiwi: 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.

Frequently asked questions