Safety Limits for an Autonomous Arm: Joints, Torque, Stop

A trained policy does not know what a table edge is. It emits joint targets and the arm follows them. When the policy is right this looks like competence. When it is confused, because a camera moved 3 cm or you picked the wrong checkpoint, it looks the same from the outside, right up to the moment a joint drives into its own bracket and starts pulling stall current.

The safety layer decides which of those two mornings costs you a servo. This page covers it on an SO-100 class arm: what LeRobot enforces, what the Feetech firmware enforces, what nobody enforces, and how to wire a stop you can reach. Code details are read out of lerobot main on 24 August 2026 (release v0.6.1); servo numbers come from the Feetech STS3215 product specification for the 7.4 V, 19 kg.cm model, edition A/0, 10 April 2020.

What an autonomous arm can actually do

The SO-100 is small. Small is not harmless. At 7.4 V a Feetech STS3215 gives 19.5 kg.cm of stall torque, about 1.91 Nm at the output shaft, and swings at 52 RPM unloaded, which is 312 deg/s. It will not break your arm. It will crush a fingertip against a table, snap a printed bracket, tear a USB connector out of a camera, and destroy the servo that was doing the pushing.

Mind the gap between rated and stall torque: a factor of about four. A policy that parks the gripper against a fixed object asks one servo to hold near stall indefinitely, at four times its specified current. That is the most common way a first autonomous run ends, and it is silent until the plastic smells warm.

Layer 1: joint limits that live in the servo

The strongest limit on the arm is the one people assume is missing. When you run calibration and sweep each joint by hand, LeRobot does not only write a JSON file. It writes two registers per servo:

def write_calibration(self, calibration_dict: dict[str, MotorCalibration], cache: bool = True) -> None:
    for motor, calibration in calibration_dict.items():
        if self.protocol_version == 0:
            self.write("Homing_Offset", motor, calibration.homing_offset)
        self.write("Min_Position_Limit", motor, calibration.range_min)
        self.write("Max_Position_Limit", motor, calibration.range_max)

The 12-bit magnetic encoder gives counts of 0 to 4095 over a full turn at 0.088 deg per count, and once written they sit in non-volatile memory. Reboot the host, swap the laptop, restart the process: the limits stay. That is why a joint that stops early is far more often a calibration problem than a policy problem, and why no code change fixes it.

lerobot-calibrate \
  --robot.type=so100_follower \
  --robot.port=/dev/tty.usbmodem58760431541 \
  --robot.id=my_follower_arm

For reference, the SO-ARM100 project declares this in so101_new_calib.urdf, the file LeRobot's tooling recommends. These are modelling limits for kinematics, not measured servo limits, but they give the shape of the envelope you calibrate inside.

Finding the bounds you actually want

Mechanical limits are not the limits you want during an autonomous run. If the task lives in a 20 cm square in front of the arm, shoulder_pan has no business holding 220 degrees of authority. LeRobot ships a tool that measures the envelope you actually use, by teleoperating through it:

1. 1
   Point the tool at a URDF

   The kinematics need a model. The script's docstring recommends so101_new_calib.urdf from the SO-ARM100 repository, the file the table above came from.

   bash

   git clone https://github.com/TheRobotStudio/SO-ARM100.git
   ls SO-ARM100/Simulation/SO101/so101_new_calib.urdf

2. 2
   Sweep the workspace by hand

   A 5 second warmup records nothing, then 30 seconds of measurement. Drive to every corner of the region the task needs, using the leader arm or a gamepad.

   bash

   lerobot-find-joint-limits \
     --robot.type=so100_follower \
     --robot.port=/dev/tty.usbmodem58760432981 \
     --robot.id=my_follower_arm \
     --teleop.type=so100_leader \
     --teleop.port=/dev/tty.usbmodem58760434471 \
     --teleop.id=my_leader_arm \
     --urdf_path=SO-ARM100/Simulation/SO101/so101_new_calib.urdf \
     --target_frame_name=gripper \
     --warmup_time_s=5 \
     --teleop_time_s=30 \
     --control_loop_fps=30

3. 3
   Keep both blocks it prints

   It prints an end-effector box in metres plus a per-joint min and max. The box is the useful one, because a human can check it against the table.

   text

   # End Effector Bounds (x, y, z):
   max_ee = [0.3312, 0.1904, 0.2871]
   min_ee = [0.0421, -0.2013, 0.0184]
   
   # Joint Position Limits (radians):
   max_pos = [...]
   min_pos = [...]

Layer 2: torque and current caps

LeRobot does write protection registers, but far less broadly than people assume. This is the whole of it, from SOFollower.configure():

def configure(self) -> None:
    with self.bus.torque_disabled():
        self.bus.configure_motors()
        for motor in self.bus.motors:
            self.bus.write("Operating_Mode", motor, OperatingMode.POSITION.value)
            self.bus.write("P_Coefficient", motor, self.config.position_p_coefficient)  # 16
            self.bus.write("I_Coefficient", motor, self.config.position_i_coefficient)  # 0
            self.bus.write("D_Coefficient", motor, self.config.position_d_coefficient)  # 32

            if motor == "gripper":
                self.bus.write("Max_Torque_Limit", motor, 500)     # 50% of max torque to avoid burnout
                self.bus.write("Protection_Current", motor, 250)   # 50% of max current to avoid burnout
                self.bus.write("Overload_Torque", motor, 25)       # 25% torque when overloaded

The asymmetry is reasonable: the gripper spends its life clamped against something, so the gripper is what burns out. But the five joints that carry the arm's mass, and that can reach the table, run at factory protection settings during an autonomous run.

The datasheet is precise about factory behaviour. A joint blocked above 80 percent of locked rotor for 2 seconds enters overload protection; running current above 2 A for 2 seconds enters overcurrent protection; above 70 C the servo switches torque output off. Those work. One clause changes what they mean under an autonomous policy.

Layer 3: the per-step cap almost nobody turns on

The default here will surprise you. SOFollowerConfig.max_relative_target is typed float | dict[str, float] | None and defaults to None. With no cap set, send_action skips the clamp and writes whatever the policy produced. A LeRobot issue asking what a sensible value would be was closed as stale with no maintainer answer, which tells you how much settled guidance exists.

def ensure_safe_goal_position(
    goal_present_pos: dict[str, tuple[float, float]], max_relative_target: float | dict[str, float]
) -> dict[str, float]:
    """Caps relative action target magnitude for safety."""
    ...
    for key, (goal_pos, present_pos) in goal_present_pos.items():
        diff = goal_pos - present_pos
        max_diff = diff_cap[key]
        safe_diff = min(diff, max_diff)
        safe_diff = max(safe_diff, -max_diff)
        safe_goal_pos = present_pos + safe_diff
        safe_goal_positions[key] = safe_goal_pos

Turning it on is one flag, taking a scalar for every joint or a dict so you can be strict where gravity is:

# one cap for every joint
lerobot-rollout \
  --strategy.type=base \
  --policy.path=${HF_USER}/my_policy \
  --robot.type=so100_follower \
  --robot.port=/dev/ttyACM1 \
  --robot.max_relative_target=5 \
  --task="put the brick in the box" \
  --duration=60

# per joint, in degrees, tighter on the joints that carry the arm
--robot.max_relative_target='{shoulder_pan: 4, shoulder_lift: 3, elbow_flex: 4, wrist_flex: 6, wrist_roll: 10, gripper: 20}'

Here is what catches people: the cap is per control tick, not a velocity limit, so the same number produces very different arms depending on loop rate. With inference latency of 20 ms for ACT and 485 ms for Pi0.5, at one policy call per tick, a five degree cap means this:

The last row matters most. With action chunking the model is not called every tick: it emits a chunk and the loop replays it at a fixed rate, which is what LeRobot's --inference.type=rtc path is for on the slow VLAs. Under chunk replay the cap applies at the replay rate, so 5 degrees at 30 Hz is 150 deg/s whichever model produced the chunk. Pick the cap against your loop rate, then watch the arm at that speed before you trust it.

Layer 4: workspace bounds, which nothing enforces

A joint limit is not a box in space. Every joint can sit inside its range while the end effector is 5 cm below the table. On a 5 degree-of-freedom arm you cannot eyeball the map from joint space to Cartesian space, which is why the tool prints the end-effector box separately.

The honest state of it: LeRobot gives you the kinematics and the measurement tool, and no runtime filter. There is no max_ee config field. If you want a Cartesian bound respected during a rollout, you write it:

import numpy as np
from lerobot.model import RobotKinematics

kin = RobotKinematics("so101_new_calib.urdf", "gripper")
LO = np.array([0.02, -0.22, 0.015])   # metres, from lerobot-find-joint-limits
HI = np.array([0.34,  0.20, 0.30])

def guarded_send(robot, action):
    q = np.array([action[f"{m}.pos"] for m in robot.bus.motors])
    ee = kin.forward_kinematics(q)[:3, 3]
    if np.any(ee < LO) or np.any(ee > HI):
        obs = robot.get_observation()
        hold = {f"{m}.pos": obs[f"{m}.pos"] for m in robot.bus.motors}
        return robot.send_action(hold)     # freeze in place
    return robot.send_action(action)

Doing this properly is an active research area, not a config flag. Any-Body Guard (Beaudin et al., June 2026) builds the filter in configuration space from forward kinematics and object-centric scene representations, reports zero collisions in its hardware experiments, and transfers across embodiments without retraining. That is the direction of travel, and it is still research code on research setups rather than something you drop into a LeRobot config this afternoon.

The stop button

Ask what happens when you need the arm stopped right now. The keyboard controls in lerobot-record (Right or n, Left or r, Esc or q) are recording flow control, not a stop. The real one is lerobot-rollout --interactive=true: the robot stays idle until you type /start, and /stop ends the control loop from stdin. Ctrl-C works too, but it tears down through disconnect(), where disable_torque_on_disconnect defaults to True, so the arm goes limp. On a raised arm, limp means it falls.

1. 1
   Put a switch on the DC side

   An inline rocker or latching mushroom button between the power supply and the motor control board. Reachable with one hand while the other is on the keyboard, and not behind the arm.

   text

   PSU --> [ switch ] --> motor control board --> servo bus
                           USB stays connected

2. 2
   Clamp the arm down

   The SO-ARM100 bill of materials includes table clamps for both arms. This is not tidiness: an unclamped arm that pushes against a fixed object levers itself off the desk instead of stalling.

3. 3
   Clear the drop zone

   There are no brakes, so cutting power drops the arm through whatever is under it. Nothing you care about goes under a raised arm, cameras included.

4. 4
   Start idle, then say go

   Interactive mode runs connect, calibrate and camera-open while the arm is stationary. Motion starts only when you type /start, with your hand near the switch.

   bash

   lerobot-rollout \
     --strategy.type=base \
     --policy.path=${HF_USER}/my_policy \
     --robot.type=so100_follower \
     --robot.port=/dev/ttyACM1 \
     --robot.max_relative_target=5 \
     --robot.cameras="{ front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}}" \
     --task="put the brick in the box" \
     --interactive=true

Two ways to get to the same guarded run

pip install lerobot

# 1. sweep the real limits into servo EEPROM
lerobot-calibrate --robot.type=so100_follower --robot.port=/dev/ttyACM1 --robot.id=arm1

# 2. measure the envelope the task needs
lerobot-find-joint-limits --robot.type=so100_follower --robot.port=/dev/ttyACM1 \
  --robot.id=arm1 --teleop.type=so100_leader --teleop.port=/dev/ttyACM0 --teleop.id=lead1 \
  --urdf_path=SO-ARM100/Simulation/SO101/so101_new_calib.urdf --teleop_time_s=30

# 3. run guarded, idle until you say go
lerobot-rollout --strategy.type=base --policy.path=$HF_USER/my_policy \
  --robot.type=so100_follower --robot.port=/dev/ttyACM1 --robot.id=arm1 \
  --robot.max_relative_target=5 --interactive=true --task="pick up the cube" --duration=60

Where all of this still does not save you

Four gaps are structural, and being straight about them beats a longer checklist.

• A per-step cap does not bound the destination. Clamping each tick to 5 degrees stops the jerk, not the journey. A policy convinced the target is inside the table walks there in 5 degree increments and arrives with full torque. The cap buys reaction time, which only helps if someone is reacting.
• Torque caps change the distribution. The demonstrations were recorded on an uncapped arm. Cap it and the policy is driving hardware it never saw. See policy only works in one setup.
• Servo protections do not latch under a control loop. Overload and overcurrent flags clear when a new position command arrives, and your loop sends one every tick. Temperature is the honest signal.
• Nothing here is redundant. Every layer runs in one process on one USB bus with no diagnostic coverage. If the serial link hangs, the servos hold their last target and none of your software runs at all. That is what the switch is for.

Pre-flight checklist for the first autonomous run

1. Calibration is fresh and swept to the real mechanical stops, so the EEPROM position limits mean something.
2. max_relative_target is a number, not None, and you have worked out what it becomes in deg/s at your loop rate.
3. The arm and its base are clamped to the table.
4. The power switch is on the DC side, reachable with your free hand, and not behind the arm.
5. Nothing you care about is inside the arm's reach or under it, cameras included.
6. The run starts with --interactive=true, so the arm is idle until you type /start.
7. You know your Present_Temperature threshold and how you would notice it crossing.
8. The first run is short. Use --duration=30 and take the win of a boring 30 seconds.

None of this makes a learned policy safe. It makes its mistakes cheap, which is the achievable goal on a desk arm. If the rest of the pipeline is still going up, the SO-100 setup and training guide covers parts to first episode, and the data-quality guide covers why recording conditions decide how confused the policy will be when it finally drives the arm alone.