SO-100 Build Mistakes That Cost a Weekend

An SO-100 built wrong usually still works. That is the problem. The arm powers up, teleoperation feels smooth, the cameras appear in the recorder, and you spend a Saturday collecting fifty episodes. The build error surfaces four days later, when the policy you fine-tuned closes on air two centimetres left of the cube.

Four decisions on a SO-100 are invisible on the bench and expensive in the dataset: servo ids, horn angle, cable routing, and matching the supply to the servo variant. Checked against LeRobot main (release v0.6.1, 3 August 2026) and the SO-ARM100 repository as it stands today.

What actually breaks, and when you find out

Ranked by cost, not likelihood. The second is the weekend-eater: it gives no signal until a training run has already finished.

Mistake 1: servo ids, and the order they have to be set in

The six servos share one half-duplex serial bus, addressed by id, and every STS3215 leaves the factory as id 1. Until each has a distinct id, six devices answer to one address. The SO-100 assembly guide configures motors before assembly, because once the arm is together the connectors are unreachable.

# install lerobot with the Feetech SDK
pip install -e ".[feetech]"

# find which serial port belongs to which arm
lerobot-find-port
# Finding all available ports for the MotorBus.
# ['/dev/tty.usbmodem575E0032081', '/dev/tty.usbmodem575E0031751']
# Remove the USB cable from your MotorsBus and press Enter when done.

The id map is fixed in the source, not chosen by you. so_follower.py declares shoulder_pan on 1 through gripper on 6, and the leader uses the same names. The setup script walks the list in reverse, gripper first, shoulder_pan last.

1. 1
   Connect exactly one motor

   Power the board, plug in USB, and run one 3-pin cable to the gripper motor only. It must not be chained to another motor at the far end.

   bash

   lerobot-setup-motors \
       --robot.type=so100_follower \
       --robot.port=/dev/tty.usbmodem585A0076841

2. 2
   Answer the prompt

   Press Enter and the script writes the id and 1 Mbps baud rate into that motor's EEPROM, then moves on.

   text

   Connect the controller board to the 'gripper' motor only and press enter.
   'gripper' motor id set to 6
   Connect the controller board to the 'wrist_roll' motor only and press enter.

3. 3
   Repeat down to shoulder_pan

   Move the board cable to the next motor each time. Finding a motor sweeps the STS/SMS baud table, 1000000 down to 19200, so a servo repurposed from another robot is still found.

4. 4
   Do the leader with the teleop flags

   The leader takes --teleop.type and --teleop.port instead of --robot.*. Same procedure, same id order.

   bash

   lerobot-setup-motors \
       --teleop.type=so100_leader \
       --teleop.port=/dev/tty.usbmodem575E0031751

5. 5
   Only now chain them

   Plug each motor into the next, and shoulder_pan (id 1) into the board. The ids live in EEPROM, so this never repeats.

Mistake 2: the horn angle, and why it only shows up after training

This is the expensive one. Waveshare's wiki page for the ST3215, the 12 V sibling of the SO-100's servo, lists a 360 degree magnetic encoder at 360/4096 resolution and, under mechanical limited angle, says: no. lerobot's model table gives the sts3215 the same 4096 counts. What stops your joint is the printed link bolted to the horn hitting another printed part, so the horn angle when you tighten the M3 screw decides where the 0/4095 seam falls inside that travel.

The LeRobot SO-100 page hints at it at step 6: install both horns, and try not to move the motor position while attaching them, especially on the leader arms where the gears were removed. That reads like a tidiness note. Here is what calibration does with the position you leave behind.

# lerobot/motors/motors_bus.py - set_half_turn_homings docstring
# "The function computes and writes a homing offset such that the present
#  position becomes exactly one half-turn (e.g. 2047 on a 12-bit encoder)."

# lerobot/motors/feetech/feetech.py - _get_half_turn_homings does the arithmetic
max_res = self.model_resolution_table[model] - 1   # 4096 - 1 = 4095 for sts3215
half_turn_homings[motor] = pos - int(max_res / 2)  # int(4095 / 2) = 2047

# lerobot/robots/so_follower/so_follower.py - calibrate()
input(f"Move {self} to the middle of its range of motion and press ENTER....")
homing_offsets = self.bus.set_half_turn_homings()

full_turn_motor = "wrist_roll"
unknown_range_motors = [m for m in self.bus.motors if m != full_turn_motor]
range_mins, range_maxes = self.bus.record_ranges_of_motion(unknown_range_motors)
range_mins[full_turn_motor] = 0
range_maxes[full_turn_motor] = 4095

Read that order carefully. The homing offset is chosen before anything is known about the joint's real travel. If the pose you held is not the mechanical midpoint, the seam lands inside the travel, and the sweep that follows records the range with a plain min and max over a value that wraps modulo 4096.

# record_ranges_of_motion - the two lines that cannot see a wrap
mins  = {motor: min(positions[motor], min_) for motor, min_ in mins.items()}
maxes = {motor: max(positions[motor], max_) for motor, max_ in maxes.items()}

# _normalize - what the dataset and the policy actually get
bounded_val = min(max_, max(min_, val))

if norm_mode is MotorNormMode.RANGE_M100_100:      # body joints, use_degrees=False
    norm = (((bounded_val - min_) / (max_ - min_)) * 200) - 100
elif norm_mode is MotorNormMode.RANGE_0_100:       # the gripper, always
    norm = ((bounded_val - min_) / (max_ - min_)) * 100
elif norm_mode is MotorNormMode.DEGREES:           # body joints, the default
    mid = (min_ + max_) / 2
    max_res = self.model_resolution_table[self._id_to_model(id_)] - 1
    normalized_values[id_] = (val - mid) * 360 / max_res   # val, not bounded_val

A bad range does not raise. Under the default use_degrees=True the five body joints take the DEGREES branch, where each sample is measured from the midpoint of the recorded range: a midpoint 200 counts off shifts that joint by about 18 degrees for the whole dataset, and a pose on the far side of the seam arrives as a jump of nearly a full turn. The gripper is the one column always clamped.

Issue 3585 is the dramatic version: when a present position sits outside the calibrated band and something writes a goal, the firmware clamps to the nearest limit, sets torque enable on its next PID tick even though the host disabled torque, and drives there. That is the arm that snaps when you start teleop. Start at arm twitches then sags.

The SO-101 adds a gear-ratio mistake the SO-100 does not have

On the SO-100 the bill of materials is one line item, twelve identical STS3215 servos, and the leader is made movable by removing the gears from its six. On the SO-101 nothing is removed: the follower stays on six 1/345 motors while the leader mixes three ratios in fixed positions, so a servo in the wrong socket is a new way to build the arm wrong.

Gear removal on the SO-100 is its own ordering trap: SO-ARM100 issue 31 is somebody who assembled the whole leader before finding the instruction. The maintainer's answer: not strictly necessary, but without it the leader cannot be driven one-handed for long. SO-100 against SO-101 has the rest.

Mistake 3: the 7.4 V rule

The platform lists the SO-100 and SO-101 as 7.4 V arms on Feetech STS3215 servos, at roughly 110 to 150 EUR and 130 to 170 EUR of parts. That voltage names the servo variant, and it matters because an identical-looking 12 V STS3215 is sold in the same shops.

The other supported arms have their own rails: Koch v1.1 runs Dynamixel XL330 and XL430 on 5 V and 12 V rails, and LeKiwi is a 7.4 V arm on a 12 V base. On a LeKiwi both supplies sit on one robot, the easiest place to plug the wrong barrel into the wrong board.

Mistake 4: cable routing, which becomes dropped frames

The LeRobot assembly notes say it in an aside: inserting cables beforehand is much easier than afterward. What they do not spell out is the later cost. A 3-pin cable crossing a rotation axis under tension is tugged every time that joint sweeps. It rarely disconnects outright. It intermittently corrupts a packet on a 1 Mbps bus.

Failed to sync read 'Present_Position' on ids=[2,3,4,6] after 1 tries.
[TxRxResult] There is no status packet!

• Insert both 3-pin cables before the motor goes into its printed holder. Retrofitting means taking the joint apart.
• Loop the cable with slack around the rotation axis instead of stretching it across. The guide says which wire goes behind the shoulder holder and which routes upward.
• Use the printed cable holders. The motor 3 to motor 4 cable gets its own screw for a reason.
• With power off, sweep every joint to both limits and watch the cable. If it goes taut, it fails during recording, not now.
• Rule the host out too: on issue 1252 an SO-101 owner found the error got much worse with two arms and two cameras on one cheap USB hub.
• A dropped read is not a harmless retry. It is a repeated or missing frame in an episode, and it trains as a moment where the arm did not move.

Mistake 5: not recalibrating after you touch the hardware

Calibration is a file, and the file outlives the hardware it describes. lerobot writes one JSON per arm id under your Hugging Face cache and reads it at connect time. Swap a servo, re-seat a horn or reprint a link, and it describes an arm that no longer exists.

# where the file lives (override with HF_LEROBOT_CALIBRATION)
ls ~/.cache/huggingface/lerobot/calibration/robots/so_follower/
# my_awesome_follower_arm.json

# per joint: id, drive_mode, homing_offset, range_min, range_max
cat ~/.cache/huggingface/lerobot/calibration/robots/so_follower/my_awesome_follower_arm.json

# after any mechanical change, delete it and calibrate from scratch
rm ~/.cache/huggingface/lerobot/calibration/robots/so_follower/my_awesome_follower_arm.json

lerobot-calibrate \
    --robot.type=so100_follower \
    --robot.port=/dev/tty.usbmodem58760431551 \
    --robot.id=my_awesome_follower_arm

That reuse prompt is the trap: the default keeps the old numbers and writes them back to the motors, exactly wrong after a repair. Far enough out you get a hard error instead of silence, which is the good case. Issue 1296 is the reported version, Magnitude 2114 exceeds 2047 (max for sign_bit_index=11), raised because Homing_Offset uses sign bit index 11.

How a build error becomes bad training data

A LeRobot dataset stores joint states and actions as numeric columns. A mechanically wrong arm produces no error there, just plausible numbers describing something other than what happened, and imitation learning fits them faithfully.

A 30 minute acceptance pass

Run this on a freshly built arm, and again after any repair, before going near recording a dataset.

1. 1
   Recalibrate both arms from scratch

   Type c at the reuse prompt. Hold every joint at mid-travel for the first Enter, then sweep all but wrist_roll to both limits.

   bash

   lerobot-calibrate --robot.type=so100_follower \
     --robot.port=/dev/ttyACM0 --robot.id=follower_a
   
   lerobot-calibrate --teleop.type=so100_leader \
     --teleop.port=/dev/ttyACM1 --teleop.id=leader_a

2. 2
   Read the calibration file, do not assume it succeeded

   A span near the full 4096 counts, or suspiciously narrow, is the signature of the wrap problem. wrist_roll is the only joint legitimately at 0 to 4095.

   python

   import json, pathlib
   
   f = pathlib.Path.home() / ".cache/huggingface/lerobot/calibration" \
       / "robots/so_follower/follower_a.json"
   cal = json.loads(f.read_text())
   
   for joint, c in cal.items():
       span = c["range_max"] - c["range_min"]
       flag = ""
       if joint != "wrist_roll" and span > 3600:
           flag = "  <-- suspiciously wide, check for a wrap"
       if span < 400:
           flag = "  <-- suspiciously narrow, joint may not have been swept"
       print(f"{joint:<14} ho={c['homing_offset']:>6}  "
             f"[{c['range_min']:>4}, {c['range_max']:>4}]  span={span:>4}{flag}")

3. 3
   Teleoperate for five minutes with the data view on

   Drive every joint to both limits, gripper included. Watch for status packet errors, and for a channel that jumps or flattens while the joint moves smoothly.

   bash

   lerobot-teleoperate \
     --robot.type=so100_follower --robot.port=/dev/ttyACM0 --robot.id=follower_a \
     --teleop.type=so100_leader --teleop.port=/dev/ttyACM1 --teleop.id=leader_a \
     --display_data=true

4. 4
   Add the cameras and repeat

   Cameras change control loop timing. A bus that was fine without them can start dropping reads once frames share the loop.

   bash

   lerobot-teleoperate \
     --robot.type=so100_follower --robot.port=/dev/ttyACM0 --robot.id=follower_a \
     --robot.cameras="{front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}}" \
     --teleop.type=so100_leader --teleop.port=/dev/ttyACM1 --teleop.id=leader_a \
     --display_data=true

5. 5
   Record two throwaway episodes and read the numbers

   Two, not fifty. Open the parquet and check every joint column. A jump of nearly a full turn, a gripper column that saturates, or a flat channel while the arm moved: that is the calibration fault.

Do it yourself, or do it on AY-Robots

git clone https://github.com/huggingface/lerobot
cd lerobot
pip install -e ".[feetech]"

lerobot-find-port
lerobot-setup-motors --robot.type=so100_follower --robot.port=/dev/ttyACM0
lerobot-calibrate  --robot.type=so100_follower --robot.port=/dev/ttyACM0 --robot.id=follower_a
lerobot-teleoperate --robot.type=so100_follower --robot.port=/dev/ttyACM0 --robot.id=follower_a \
                    --teleop.type=so100_leader --teleop.port=/dev/ttyACM1 --teleop.id=leader_a

What none of this fixes

A perfect SO-100 does not give you a working vision-language-action model. It removes one class of explanation, which is worth a lot while debugging, and nothing else.

• It does not fix too little data. ACT, GR00T N1.7, GR00T N1.5 and Pi0.5 each want at least 50 episodes here; only SmolVLA starts at 30.
• It does not fix camera placement, lighting, or a task ambiguous from the frames. See collecting good VLA training data.
• It does not fix inference latency: 20 ms per action step for ACT, 485 ms for Pi0.5, and internet round trips on top turn a working policy hesitant.
• It does not detect a horn at the wrong angle, and no hosted pipeline can, from the dataset alone.
• It does not make a v3.0 dataset loadable by GR00T. That is a conversion down to v2.1, with its own page.

With no hardware yet, the no-hardware starting points let you drive a real arm, compare models on the arena leaderboard across 85 VLA models and 332 benchmark results, or rent a GPU. If you would rather be paid to drive arms than build them, there is operator work.

Where to go next

After the acceptance pass: SO-100 getting started, data collection, your first training run, running the policy. The complete SO-100 guide covers the same ground end to end, and the VLA overview the models on the other side of the dataset.