Servo Wear and SO-100 Arm Maintenance: What Breaks First

An SO-100 rarely dies in one dramatic moment. What happens is slower and more irritating. The gripper stops closing the last two millimetres. The shoulder sags a degree when you park it. A joint that used to hold still now hums when the arm is extended. None of that stops a recording session, which is exactly the problem: the rig keeps working well enough to produce episodes that are subtly worse than the ones you recorded last month, and three weeks later you are debugging a policy that was never the thing at fault.

This page covers what wears out first on a Feetech STS3215 arm, what the vendor's numbers actually promise, which registers warn you before a joint gives up, and a maintenance routine short enough that you will really run it. Hardware numbers come from three documents opened for this article: the Feetech STS3215 product specification (edition A/1, 2023-06-23, the 7.4 V 19 kg.cm part the SO-100 bill of materials calls C001), the ST3215 memory table V3.7, and the lerobot source at tag v0.6.1, released 2026-08-03. Those three disagree in four places, each named where it comes up rather than smoothed over.

What the datasheet actually promises

The SO-100 and the SO-101 both run six Feetech STS3215 bus servos at 7.4 V, and the follower uses the C001 variant with 1/345 gearing on all six joints. That part number matters, because most of the bench reports you will find online were run on the 12 V variant, which is a different motor with a different torque curve. Here is what the 7.4 V specification says about the servo you actually have.

One item on the list does not wear at all. The angle sensor is a 12 bit magnetic type whose life the datasheet gives as no limit, so unlike a potentiometer servo the position feedback does not degrade with the rest of the unit. That cuts both ways. Position readings stay trustworthy, which is what makes the register checks below worth doing. But everything mechanical between the sensor and the workpiece does wear: gear backlash, the fit of the horn on the printed part, screws seated in plastic. A clean-looking observation.state is not evidence of a healthy arm, only of an honest encoder.

What breaks first, and in what order

Failures on this arm are not random across the six joints. Load, duty and the way people use the arm all push in the same direction, and the pattern is consistent enough to plan spares around. Bus ids below are the ones lerobot assigns in the SO follower definition, gripper last at id 6.

The gripper case is the one most people hit. On lerobot issue 2819 a user reported a follower gripper servo that went stiff and then stopped working, and a maintainer named the mechanism: the servo can break when overloaded for too long, for example if you close the teleoperation gripper fully while the follower gripper is already holding something. In leader-follower teleoperation the leader has no idea the follower has hit an object. The operator squeezes the handle, the follower gripper stalls, and it keeps stalling until somebody lets go. That is why lerobot writes a torque ceiling into the follower gripper and nowhere else.

The leader arm wears differently

The follower fights gravity all session. The leader fights the operator, and that difference is built into the hardware. On the SO-101 the follower is six identical 1/345 servos, while the leader mixes three gear ratios so it can hold its own weight without being stiff in the hand. The lerobot assembly guide gives the assignment per joint, which is what you need before ordering a spare.

The SO-ARM100 README states the reason the SO-101 exists in one line: improved wiring, easier assembly with no gear removal, and updated motors for the leader arm. The gear removal it refers to belonged to the older SO-100 leader build. If you still run an SO-100 leader whose servos were modified that way, those units sit outside anything the datasheet describes, and they are the first place to look when the leader feels notchy under the hand. The follower is unaffected either way.

The registers that see it coming

The STS3215 reports more about itself than most people ever read, and all of it comes over the same serial bus that carries position commands, so you can sample it during a real session instead of setting up a test. Addresses and units below come from the ST3215 memory table V3.7; the names are the keys lerobot uses in its Feetech control table, so they copy straight into code.

One honest caveat about Present_Load: the memory table describes it as the voltage duty cycle of the control output driving the motor, not a calibrated torque reading. It is a proxy, and still worth logging, because a duty cycle that climbs for the same motion means the servo is working harder for the same result. If you want a number with units, use Present_Current and the Kt constant instead.

from lerobot.motors import Motor, MotorNormMode
from lerobot.motors.feetech import FeetechMotorsBus

JOINTS = ["shoulder_pan", "shoulder_lift", "elbow_flex",
          "wrist_flex", "wrist_roll", "gripper"]

# Status byte at address 65. Bit names from the ST3215 memory table V3.7.
# The SCServo SDK labels bit 1 "angle" and has no constant for bit 4 at all,
# so do not take these names from the SDK.
ERR_BITS = [(1, "voltage"), (2, "sensor"), (4, "temperature"),
            (8, "current"), (16, "angle"), (32, "overload")]

bus = FeetechMotorsBus(
    port="/dev/ttyACM0",  # from lerobot-find-port
    motors={n: Motor(i + 1, "sts3215", MotorNormMode.RANGE_M100_100)
            for i, n in enumerate(JOINTS)},
)
bus.connect()

print(f"{'joint':<14}{'temp C':>8}{'volt V':>8}{'load %':>8}{'mA':>8}  status")
for name in bus.motors:
    try:
        temp = bus.read("Present_Temperature", name)
        volt = bus.read("Present_Voltage", name) * 0.1
        # lerobot decodes the sign bit (bit 10) of Present_Load for you
        load = abs(bus.read("Present_Load", name)) / 10.0
        curr = bus.read("Present_Current", name) * 6.5
        stat = bus.read("Status", name)
    except RuntimeError as exc:
        # read() raises as soon as the status packet carries a non-zero error
        # field, so a motor that is already in overload reports here, not below
        print(f"{name:<14}{'read refused':>32}  {exc}")
        continue
    flags = ",".join(n for b, n in ERR_BITS if stat & b) or "ok"
    print(f"{name:<14}{temp:>8}{volt:>8.1f}{load:>8.1f}{curr:>8.0f}  "
          f"{flags}  ~{curr / 1000 * 7.8:.1f} kg.cm")

bus.disconnect()  # disable_torque=True by default

Run that twice: once cold, once right after a session. The cold reading is your baseline and it should be boring; the hot reading is the one that ages. Log both with a date, because the value of these numbers is entirely in the trend. If the script cannot reach a motor at all, that is a different problem and the servo not responding and arm not detected pages cover it.

Where the vendor's own documents disagree

The numbers people quote for protection thresholds come from whichever document they happened to open. Four disagreements turned up while checking this article, and none has a resolution a reader could verify, so they are listed rather than picked.

What lerobot changes, and what it leaves alone

Before you tune anything, know what the stack already did to your servos. lerobot writes settings on every connect, so the values in your motors are not factory values. Vendor default against what the SO follower actually writes at v0.6.1:

Three rows are worth arguing about. Acceleration 254 is the highest value the register accepts, chosen so teleop feels responsive; every commanded step is taken as fast as the servo can take it, and peak current follows. Halving P from 32 to 16 makes the loop softer, and going further resolved a vibration report on SO-ARM100 issue 24: the user dropped P to 8 on the base and shoulder motors and cut Minimum_Startup_Force (address 24) from 16 to 5, after which the vibration was almost gone. Both are one-line writes to try before suspecting the gearbox.

The third is a documentation problem rather than a setting. lerobot writes 25 to the gripper's Overload_Torque with the source comment "25% torque when overloaded". But address 36 is the threshold that starts the overload countdown; the torque held afterwards is address 34, Protective_Torque, which lerobot does not touch. Read literally, the write lowers the gripper's overload threshold from 80 percent to 25 percent, sensible for the joint most likely to stall, but not what the comment describes. Reported here as a discrepancy between comment and register map, not as a bug.

Reading wear out of a recorded dataset

A teleoperation rig already logs the two signals you need. Every frame in a LeRobot dataset holds an action (where the leader said to go) and an observation.state (where the follower actually was). The gap between them is tracking error, and it grows as a gearbox loses efficiency or a motor loses torque. The measured evidence comes from an independent bench test, run on the 12 V C018 variant rather than the 7.4 V part: mean absolute position deviation was about 22.5 encoder counts (roughly 2 degrees) under a 10 kg.cm dynamic load, rising to about 30 counts (2.6 degrees) at 15 kg.cm. Load and tracking error move together, which is the property the method below leans on.

1. 1
   Pick one dataset and one pose

   Use a recording where the arm reaches the same waypoint in every episode. A pick-and-place task with a fixed home pose is ideal. Comparing across tasks tells you nothing.

2. 2
   Check the units before you compute anything

   In lerobot v0.6.1 the SO follower's use_degrees defaults to True, so a fresh recording is in degrees. Older ones may not be: the config dump in lerobot issue 2819, from version 0.4.3, shows 'use_degrees': False. Check meta/info.json rather than assuming, because comparing a degree recording against a normalized one produces a large fake drift.

   bash

   python -c "import json,sys; d=json.load(open(sys.argv[1])); print(d['features']['action'])" meta/info.json

3. 3
   Average the per-joint gap for each episode

   Take the mean absolute difference per joint per episode. LeRobotDataset.select_columns returns the underlying Hugging Face dataset with only those columns, which keeps the video frames out of memory.

   python

   import numpy as np
   from lerobot.datasets.lerobot_dataset import LeRobotDataset
   
   ds = LeRobotDataset("your-user/your-so100-task")
   names = ds.meta.features["action"]["names"]
   rows = ds.select_columns(["episode_index", "action", "observation.state"])
   
   sums, counts = {}, {}
   for row in rows:
       ep = int(row["episode_index"])
       err = np.abs(np.asarray(row["action"], dtype=float)
                    - np.asarray(row["observation.state"], dtype=float))
       sums[ep] = sums.get(ep, 0) + err
       counts[ep] = counts.get(ep, 0) + 1
   
   for ep in sorted(sums):
       mean = sums[ep] / counts[ep]
       cells = "  ".join(f"{n.split('.')[0]}={v:5.2f}"
                         for n, v in zip(names, mean))
       print(f"ep {ep:03d}  {cells}")
   

4. 4
   Repeat on a dataset from a month ago

   Run the same script against an older recording of the same task on the same arm. You are looking for one joint whose mean gap has grown while the others have not.

   bash

   python joint_gap.py 2>&1 | tee gap-$(date +%F).txt
   diff <(cut -c1-80 gap-2026-07-10.txt) <(cut -c1-80 gap-2026-08-24.txt)
   

5. 5
   Confirm on the hardware before you believe it

   A growing gap can also be a loosened horn screw, a changed leader arm, or a recalibration in between. Go back to the register script and check whether that joint also runs hotter or draws more current. Two independent signals pointing at one joint is a finding; one is a hypothesis.

Two caveats, both important. First, the leader-follower gap is never zero, because the follower is chasing a moving target and there is real lag in the loop, so the absolute value is meaningless. Only the change over time on the same setup means anything. Second, if you re-ran calibration between the two recordings, the zero moved and the comparison is void. That is not a small footnote: it is the single most common way this analysis produces a confident wrong answer.

A maintenance routine you will actually run

A routine only works if it is short. The failures above are dominated by heat, stalls and screws pulling out of plastic, so those are the three things this checks. Everything here takes minutes, not an afternoon.

Two habits do more than the whole table. Give the arm rest between recording blocks: the independent bench test, again on the 12 V part, measured about 15 C of rise after ten minutes of continuous motion lifting 1.5 kg on a 10 cm lever, which is 15 kg.cm, three times the 7.4 V part's rated torque. Do not expect that number on an SO-100; the point is that heat accumulates across a session and the servo has no fan. And keep spares: the SO-ARM100 bill of materials lists the STS3215 at 13.89 USD or 12.20 EUR per servo, read on 2026-08-24, cheap enough that one spare of each gear ratio in a drawer beats a week of downtime.

1. 1
   Swap the dead servo

   Power down, unplug the 3-pin cables on both sides, remove the four M2x6 screws holding the motor and the M3x6 horn screw, and fit the replacement. Match the part number against the leader table above; a follower joint always takes the 1/345 C001.

2. 2
   Give the new servo its bus id and baud rate

   A new servo arrives with id 1. Connect only that motor to the board and run the setup, which writes id and baud into EEPROM. The script walks the joints in reverse and prompts for the gripper first, so you can stop after the one you replaced.

   bash

   lerobot-setup-motors \
       --robot.type=so101_follower \
       --robot.port=/dev/ttyACM0
   

3. 3
   Recalibrate the whole arm

   Not just the joint you touched. Calibration writes a homing offset and a range into every servo, and it is what makes leader and follower agree on what a given angle means.

   bash

   lerobot-calibrate \
       --robot.type=so101_follower \
       --robot.port=/dev/ttyACM0 \
       --robot.id=my_awesome_follower_arm
   

4. 4
   Decide what happens to your old data

   Datasets recorded before the swap are referenced to the old zero. If the new offset is close, a fine-tuned policy may cope. If not, you see it as a policy that works in one setup and nowhere else, and no amount of retraining fixes a mislabelled joint origin.

Do it yourself, or let the platform carry part of it

There is no version of this where somebody else tightens your screws. But much of the work around servo wear is not the wrenching, it is the recording, the comparing and the knowing what healthy looks like, and that part can be shared. Same goal, keeping a rig usable for months, two ways.

Where none of this helps

Being straight about the limits. Servo wear that has already crossed into failure is not detectable earlier by better software, because the STS3215 has no wear sensor. It has a thermometer, an ammeter and a duty-cycle estimate, and all three report load right now, not the state of the gear teeth. If the failure mode is a chipped tooth, the first signal you get is the noise it makes, which is why listening is on the weekly list.

The second limit is remote work. Teleoperating across the internet is genuinely useful for recording demonstrations and it is how a lot of operator work gets done, but a remote operator cannot hear a gearbox or feel play at the end effector. Nor does remote inference fix a hardware problem: control loops run between 20 ms and 485 ms per action step depending on the model, and adding public-internet round trips to that turns a working policy hesitant. That is a latency limit, not a wear limit, and no amount of maintenance changes it.

Where to go next

If you are building the rig rather than maintaining it yet, the complete SO-100 setup guide covers assembly and first teleoperation, and the SO-100 against SO-101 comparison explains why the newer arm dropped the gear-removal step and re-geared the leader. If your problem is that the data is bad rather than the hardware, the data quality guide and the recording tutorial are the better starting points. And if a specific joint is misbehaving right now, joint stops early, arm twitches then sags and gripper does not close each start from the symptom instead of the theory.

Frequently asked questions