Degrees of Freedom: What Five Joints and a Gripper Cannot Do

The SO-100 has six servos. Five of them move the arm and the sixth opens and closes the jaws. That sounds like plenty until the first time you ask it to plug a cable into a socket that faces sideways, and the arm arrives at the socket with the gripper pointing 40 degrees off. You add episodes. You retrain. It still arrives 40 degrees off, because no amount of data can add a joint.

Six numbers, five joints

A rigid body floating in space needs six numbers to pin down completely: three for where it is and three for how it is turned. Those six numbers are the degrees of freedom of a free body in three dimensions. A robot arm that can independently set all six can put its end-effector anywhere in its workspace at any orientation. An arm with five independent joints can set at most five of them, and which five is decided by the geometry of the joint axes, not by the software.

The last row is the whole article. Every SO-100 style arm can put the jaws at any reachable point and can tilt them up or down and spin them about their own axis. What it cannot do is choose the compass direction from which it approaches. That is fixed the moment you choose the target position.

What is actually inside the arm

The joint list is not a matter of opinion. Here it is as LeRobot 0.6.2 declares it, from the SO-100 and SO-101 follower driver. The same six names, the same bus ids, the same servo model:

motors={
    "shoulder_pan":   Motor(1, "sts3215", norm_mode_body),
    "shoulder_lift":  Motor(2, "sts3215", norm_mode_body),
    "elbow_flex":     Motor(3, "sts3215", norm_mode_body),
    "wrist_flex":     Motor(4, "sts3215", norm_mode_body),
    "wrist_roll":     Motor(5, "sts3215", norm_mode_body),
    "gripper":        Motor(6, "sts3215", MotorNormMode.RANGE_0_100),
}

Five joints move the arm. The sixth is the jaw, which does not move the end-effector anywhere, it only changes the gap between the fingers. Google DeepMind's MuJoCo Menagerie, which ships a converted model of this arm, describes it plainly as a 5DOF arm. The Koch v1.1 uses Dynamixel XL430 and XL330 servos instead of Feetech, but the joint names and the topology are identical, so everything below applies to it unchanged.

The one constraint that explains everything

Look again at the axis column. shoulder_lift, elbow_flex and wrist_flex all turn about the same direction, (0, 1, 0). Three parallel revolute axes form a planar chain: whatever they do, the links stay in one plane perpendicular to those axes. shoulder_pan turns about the vertical and aims that plane. wrist_roll turns about (-1, 0, 0), which lies inside the plane, so spinning it rotates the jaw about the tool axis without ever tipping the tool axis out of the plane.

So the arm is a planar three-link manipulator living in a vertical plane, mounted on a turntable, with a roll joint at the end. Position within the plane costs two freedoms, in-plane pitch costs a third, the turntable is a fourth and roll is the fifth. Nothing is left over to swing the tool axis sideways out of the plane.

This is checkable rather than arguable. The script below parses the official URDF, builds forward kinematics from the joint origins and axes, then samples 20000 random configurations inside the joint limits and measures how far the tool axis ever gets out of the arm plane.

import re
import numpy as np

S = open("so101_new_calib.urdf").read()
J = {}
for m in re.finditer(r'<joint name="([^"]+)" type="([^"]+)">(.*?)</joint>', S, re.S):
    name, typ, body = m.groups()
    o = re.search(r'<origin xyz="([^"]*)" rpy="([^"]*)"', body)
    a = re.search(r'<axis xyz="([^"]*)"', body)
    J[name] = dict(
        xyz=np.array([float(v) for v in o.group(1).split()]),
        rpy=np.array([float(v) for v in o.group(2).split()]),
        axis=np.array([float(v) for v in a.group(1).split()]) if a else np.zeros(3),
        rev=(typ == "revolute"),
    )

CHAIN = ["shoulder_pan", "shoulder_lift", "elbow_flex",
         "wrist_flex", "wrist_roll", "gripper_frame_joint"]

def rot_rpy(r, p, y):
    c, s = np.cos, np.sin
    return (np.array([[c(y), -s(y), 0], [s(y), c(y), 0], [0, 0, 1]])
            @ np.array([[c(p), 0, s(p)], [0, 1, 0], [-s(p), 0, c(p)]])
            @ np.array([[1, 0, 0], [0, c(r), -s(r)], [0, s(r), c(r)]]))

def rot_axis(a, t):
    a = a / np.linalg.norm(a)
    K = np.array([[0, -a[2], a[1]], [a[2], 0, -a[0]], [-a[1], a[0], 0]])
    return np.eye(3) + np.sin(t) * K + (1 - np.cos(t)) * (K @ K)

def fk(q):
    T, frames = np.eye(4), {}
    for i, name in enumerate(CHAIN):
        j = J[name]
        A = np.eye(4)
        A[:3, :3], A[:3, 3] = rot_rpy(*j["rpy"]), j["xyz"]
        T = T @ A
        if j["rev"]:
            B = np.eye(4)
            B[:3, :3] = rot_axis(j["axis"], q[i])
            T = T @ B
        frames[name] = T.copy()
    return T, frames

print("axis directions at the zero pose (base frame):")
_, F0 = fk(np.zeros(6))
for name in CHAIN[:5]:
    print("  %-14s %s" % (name, np.round(F0[name][:3, :3] @ J[name]["axis"], 4)))

rng = np.random.default_rng(0)
lo = np.array([-1.91986, -1.74533, -1.69, -1.65806, -2.74385, 0.0])
hi = np.array([1.91986, 1.74533, 1.69, 1.65806, 2.84121, 0.0])
worst = 0.0
for q in rng.uniform(lo, hi, size=(20000, 6)):
    T, F = fk(q)
    normal = F["shoulder_pan"][:3, :3] @ np.array([0.0, 1.0, 0.0])
    worst = max(worst, abs(float(T[:3, 2] @ normal)))
print("max |tool_axis . plane_normal| over 20000 poses: %.1e" % worst)

pip install numpy scipy
curl -sLO https://raw.githubusercontent.com/TheRobotStudio/SO-ARM100/main/Simulation/SO101/so101_new_calib.urdf
python check_plane.py

# axis directions at the zero pose (base frame):
#   shoulder_pan   [-0.  0. -1.]
#   shoulder_lift  [-0.  1.  0.]
#   elbow_flex     [-0.  1.  0.]
#   wrist_flex     [-0.  1.  0.]
#   wrist_roll     [-1. -0. -0.]
# max |tool_axis . plane_normal| over 20000 poses: 1.0e-05

One honest wrinkle: the plane is not quite through the pan axis. The shoulder is mounted 18.3 mm to one side, so the approach line is off-radial by a fixed 3.5 degrees at a 0.30 m working radius and by 7.0 degrees at 0.15 m. That offset is a constant of the mechanism, not something you can steer.

Hard versus impossible, measured

Take a point 0.30 m out from the shoulder-pan axis and 0.15 m up, and ask for a horizontal approach at a series of azimuths away from the radial line. Solve for the best joint configuration each time, weighting position 1000 times higher than orientation so the solver is allowed to sacrifice orientation freely. The residual orientation error is what the mechanism physically cannot deliver.

The error tracks the request almost one for one. There is no elbow-up trick, no clever redundancy resolution, no wrist singularity to exploit. The small discount, 28.2 instead of 30, is the 18.3 mm shoulder offset plus a millimetre and a half of position slop. That is the entire budget you have.

Why tabletop picking still works

There is one escape, and it is the reason a five-joint arm is useful at all. If the tool axis points straight down, it lies in every vertical plane at once, so the plane constraint stops binding. wrist_roll is then vertical too, and spinning it sets the jaw yaw directly. A top-down grasp of an object lying at any rotation on the table is fully controllable.

The catch is that a straight-down approach is not reachable everywhere. The flex chain has to fold the wrist through nearly 90 degrees, and wrist_flex only has 95 degrees of travel each way on the SO-101. Here is the reachable set for the two standard approach directions, solved on a grid in front of the arm:

Read that as a design rule rather than a table of numbers. Top-down picking works close in and low down, roughly 0.15 m to 0.25 m out and near the table surface. Horizontal reaching works further out and higher up. The band in between, around 0.25 m out at mid height, is where neither approach is clean, and it is exactly where people tend to put the object because it looks comfortable.

• Maximum horizontal radius from the shoulder-pan axis, optimised over the SO-101 joint limits: 0.4408 m.
• Tool-frame height range relative to the base plate: -0.2249 m to 0.5270 m, so the arm can reach below its own mounting level if you clamp it to a table edge.
• Link offsets: 0.11257 m upper arm, 0.1349 m forearm, 0.0637 m wrist, 0.0985 m from the roll axis to the gripper frame.

LeRobot already assumes you cannot honour orientation

Its kinematics wrapper (see the robot docs for the supported arms) uses placo, targets the frame named gripper_frame_link, and solves the end-effector pose as a weighted soft task rather than a hard constraint:

def inverse_kinematics(
    self,
    current_joint_pos: np.ndarray,
    desired_ee_pose: np.ndarray,
    position_weight: float = 1.0,
    orientation_weight: float = 0.01,
) -> np.ndarray:
    ...
    self.tip_frame.configure(self.target_frame_name, "soft", position_weight, orientation_weight)

The processor that turns Cartesian actions into joint commands carries the same default and says why in its docstring: set the weight to zero for position-only IK on under-actuated arms, and a small non-zero value gives soft-orientation IK on the 5-DOF SO-101, where the wrist tracks orientation only partially. Upstream has already decided that on this arm, orientation is a suggestion.

Tasks that are impossible rather than hard

The useful distinction when you plan a data collection session: hard tasks get better with more episodes, impossible ones do not. Here is how a handful of common demo tasks sort out.

Notice the pattern. If the task's required approach is vertical, or radial, or rotationally symmetric about one of those, the arm is fine. If the task specifies a fixed non-radial horizontal axis, no policy will ever learn it. Sorting your task list this way before you start recording episodes is fifteen minutes that saves a weekend.

Check your own arm in twenty minutes

Numbers from a URDF are the nominal machine. Your arm has its own travel after calibration, its own cable routing that clips a few degrees off wrist_roll, and its own mounting height. LeRobot ships a tool for exactly this.

1. 1
   Install LeRobot with the kinematics extra

   The IK and FK helpers live behind an optional dependency because placo pulls in Pinocchio. Without this extra, the kinematics import fails at runtime rather than at install time.

   bash

   pip install "lerobot[kinematics]"
   # resolves placo>=0.9.6,<0.9.16 plus pinned urdfdom and tinyxml2 wheels

2. 2
   Grab the URDF the tool expects

   The upstream example in lerobot_find_joint_limits.py points at the SO-101 calibrated URDF even while its --robot.type is so100_follower. That is the pairing to copy: the two arms share the upper arm and forearm offsets.

   bash

   curl -sLO https://raw.githubusercontent.com/TheRobotStudio/SO-ARM100/main/Simulation/SO101/so101_new_calib.urdf

3. 3
   Find your real joint and end-effector bounds

   This runs a live leader-follower loop, does 5 seconds of warmup, then records the min and max of every joint and of the end-effector position while you drive the arm through its full travel. Push every joint to both stops.

   bash

   lerobot-find-joint-limits \
     --robot.type=so101_follower \
     --robot.port=/dev/ttyACM0 \
     --robot.id=my_follower \
     --teleop.type=so101_leader \
     --teleop.port=/dev/ttyACM1 \
     --teleop.id=my_leader \
     --urdf_path=./so101_new_calib.urdf \
     --target_frame_name=gripper \
     --warmup_time_s=5 \
     --teleop_time_s=30 \
     --control_loop_fps=30

4. 4
   Run the plane check with your measured limits

   Paste the min and max you just measured into the lo and hi arrays of check_plane.py. The residual will still be about 1e-05, which is the point: tightening the limits cannot create the missing freedom.

   bash

   python check_plane.py

5. 5
   Test the specific grasp pose you care about

   Append the sweep below, set TARGET to the actual grasp point in metres in the base frame, and read off the approach error for the azimuth your task needs. Anything above about 10 degrees means redesign the fixture, not the policy.

   python

   from scipy.optimize import minimize
   LO = np.array([-1.91986, -1.74533, -1.69, -1.65806, -2.74385])
   HI = np.array([1.91986, 1.74533, 1.69, 1.65806, 2.84121])
   BOUNDS = list(zip(LO, HI))
   TARGET = np.array([0.3388, 0.0, 0.15])   # 0.30 m out from the pan axis, 0.15 m up
   
   def best_pose(want_axis, restarts=120):
       def cost(q):
           T, _ = fk(list(q) + [0.0])
           return 1000 * np.sum((T[:3, 3] - TARGET) ** 2) + np.sum((T[:3, 2] - want_axis) ** 2)
       sols = [minimize(cost, rng.uniform(LO, HI), bounds=BOUNDS) for _ in range(restarts)]
       q = min(sols, key=lambda r: r.fun).x
       T, _ = fk(list(q) + [0.0])
       return (np.linalg.norm(T[:3, 3] - TARGET) * 1000,
               np.degrees(np.arccos(np.clip(T[:3, 2] @ want_axis, -1, 1))))
   
   for off in (0, 5, 10, 20, 30, 45, 60, 90):
       r = np.radians(off)
       mm, deg = best_pose(np.array([np.cos(r), np.sin(r), 0.0]))
       print("off-radial %2d deg -> position %.2f mm, approach %.1f deg" % (off, mm, deg))

lerobot-record \
  --robot.type=so101_follower --robot.port=/dev/ttyACM0 --robot.id=my_follower \
  --teleop.type=so101_leader --teleop.port=/dev/ttyACM1 --teleop.id=my_leader \
  --dataset.repo_id=me/topdown_pick --dataset.num_episodes=50

Five ways to design around the missing joint

Every one of these works by making the required approach radial or vertical, or by adding real freedom somewhere else in the system. None of them involves the model.

The mobile base option is worth spelling out because LeKiwi does exactly this and is supported here. Its driver declares the same six arm motors with an arm_ prefix plus three wheel motors, base_left_wheel, base_back_wheel and base_right_wheel, on ids 7 to 9. Three omniwheels on a 0.125 m base radius give a holonomic planar base: x, y and yaw. The yaw is the freedom the arm is missing, so a LeKiwi can drive around an object and approach from any azimuth. It does not get you in-hand reorientation, and base odometry error stacks on top of arm error, but for reach-around tasks it is the honest fix. The side by side comparison covers the trade.

What this means when you train a policy

An imitation learning policy on this arm outputs the six joint targets directly. It never sees a Cartesian pose, so it cannot command an infeasible one. That sounds reassuring and is actually the problem: the infeasibility shows up silently in the data instead.

• During recording, the human teleoperator physically cannot demonstrate the impossible approach, so they unconsciously substitute the nearest possible one.
• The LeRobot dataset therefore contains a consistent, confident demonstration of a grasp that misses.
• Training loss goes down normally, because the policy is learning a coherent mapping. Nothing in the loss curve flags a kinematic problem.
• At evaluation the arm reproduces the compromise pose accurately and the object slips, which reads as a grasp quality problem.
• Adding episodes reduces variance around the wrong pose, which can make the failure look more deterministic and therefore more like a bug.

The diagnostic is not in the loss curve, it is in geometry. Before blaming the ACT chunk size or the camera setup, take one frame from a successful human demonstration, read the six joint values, run forward kinematics, and check whether the pose the human actually used is the pose the task needs. Half the time it is not, and the human was quietly compensating. Our guide on collecting high quality VLA training data covers the recording side of this; the full SO-100 guide covers the build and teleoperation setup.

That last point is worth keeping in mind when you compare models. Benchmark numbers in the arena were produced on whatever hardware each paper used, often a 7-DoF Franka or a bimanual ALOHA. A high score there says something about representation quality and nothing about whether the policy can reach your socket. Model choice and kinematics are independent axes, and only one of them is fixed by your hardware.