SO-100 Gripper Design: Why the End Effector Decides the Task

The gripper is not an accessory, it is the task

Most people building an SO-100 give their attention to the five arm joints and treat the sixth as a switch. Those five move the end effector to a place. The gripper decides whether anything happens once it gets there. Plenty of failures that look like a vision or policy problem are contact problems, and contact is geometry plus stiffness plus force: a printed part and three numbers written into a servo.

Everything below comes from the SO-ARM100 design files, the LeRobot driver source, the Feetech datasheet and two public LeRobot datasets you can measure yourself. Where a number came out of a file, the command that produced it is here too.

What the SO-100 gripper actually is

Open the kinematic model, not the product photo. In so101_new_calib.urdf there are five revolute arm joints plus one called gripper, and that one is revolute too. No prismatic joint, no second finger joint. One motor, one hinge, one moving jaw closing against a jaw moulded into the wrist roll body.

Two rows do the damage. The first is revolute. A parallel jaw keeps both faces opposed however far it opens; a pivoting jaw does not. Near 100 degrees the moving face points almost sideways, the contact normals stop being opposed, and the grasp is no longer antipodal. Squeeze a cylinder in that pose and the jaw wedges it toward the hinge or squirts it past the tip. For a two-point grasp to resist anything at all the line joining the contacts has to lie inside the friction cone at both of them, and a pivoting jaw walks the contacts off that line as it opens. Roa and Suarez (Autonomous Robots, 2015) is the standard review of the grasp quality measures built on this, and the first family it surveys is exactly where the contact points sit on the object.

The second is five degrees of freedom plus the gripper, not six. Five joints cannot span pose. For any object position there is one family of approach azimuths, set by shoulder pan, plus roll about the tool axis. If the object's long axis lies badly relative to that plane the grasp is unavailable, and no training data changes it. Both arms in the SO-100 against SO-101 comparison share this layout.

Check the geometry yourself

curl -sL -o so101.urdf \
  https://raw.githubusercontent.com/TheRobotStudio/SO-ARM100/main/Simulation/SO101/so101_new_calib.urdf

python3 - <<'PY'
import re, math
t = open('so101.urdf').read()
for m in re.finditer(r'<joint name="([^"]+)" type="([^"]+)">(.*?)</joint>', t, re.S):
    name, typ, body = m.groups()
    lim = re.search(r'lower="([-\d.]+)" upper="([-\d.]+)"', body)
    if not lim:
        print(f'{name:20s} {typ}')
        continue
    lo, hi = float(lim.group(1)), float(lim.group(2))
    print(f'{name:20s} {typ:10s} {math.degrees(lo):7.1f} to {math.degrees(hi):7.1f} deg'
          f'   span {math.degrees(hi-lo):6.1f}')
PY

The gripper line prints -10.0 to 100.0 deg, span 110.0. That is the entire vocabulary your imitation learning run has for the word grasp.

The force ceiling LeRobot writes into your servo

The STS3215 takes a target angle, not a target force. Grip force is emergent: command the jaw past the object surface, the servo sees a standing position error and pushes with whatever the gains and torque limit allow. So grip force is not tuned in the policy. It is written into the motor, and LeRobot writes it on every connect.

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

Read the comments. The stock configuration gives the gripper half the available torque and half the current, dropping to a quarter once overload protection trips. That is sensible: the gripper spends its life stalled against something, and a stalled STS3215 cooks itself. It is also a firm bound on what your task can require, and better training does not negotiate with it.

That is arithmetic on the published stall torque, not a measurement: 19.5 kg.cm is 1.91 N.m, half is 0.96 N.m, force is torque over lever arm. It is optimistic twice over, since stall torque is a peak not a continuous spec and Protection_Current usually trips first. Treat it as the number you never exceed.

The policy is blind to contact

This is the entire observation the driver assembles per control step:

obs_dict = self.bus.sync_read("Present_Position", num_retry=self.config.num_read_retries)
obs_dict = {f"{motor}.pos": val for motor, val in obs_dict.items()}

Present_Position, nothing else. The STS3215 reports current, load, voltage and temperature over the same bus, and none of it reaches the observation vector. So a vision-language-action model has two ways to know a grasp worked: see the object, or notice commanded and reported gripper position disagreeing because a blocked jaw stops short.

That second channel is weak. Across the 11939 frames of lerobot/svla_so101_pickplace the mean gap between commanded and reported gripper position is 2.34 on the 0 to 100 scale, buried in a channel that also carries servo lag. Hence the wrist camera, and hence the people bolting sensors onto the jaw. LeFlexiTac (May 2026) swaps the SO-10x stock jaw for a tactile gripper and reports an ACT policy going from 7 out of 30 to 23 out of 30 on retrieving a pen from a cluttered bag, where the camera sees nothing at contact.

Measure the gripper span in your own data before you train

Almost nobody does this, and it takes five minutes. Your episodes contain a gripper channel; look at its distribution, because a fine-tuning run reproduces whatever degeneracy is in there.

1. 1
   Read the metadata

   info.json gives the format version, the robot type, the frame count and the names of the six action dimensions.

   bash

   curl -sL -o info.json \
     https://huggingface.co/datasets/lerobot/svla_so101_pickplace/resolve/main/meta/info.json
   python3 -c "import json;d=json.load(open('info.json'));\
   print(d['codebase_version'], d['robot_type'], d['total_episodes'], d['total_frames']);\
   print(d['features']['action']['names'])"

2. 2
   Read the summary statistics

   stats.json holds min, max, mean and std per dimension. The gripper is the last of the six.

   bash

   curl -sL -o stats.json \
     https://huggingface.co/datasets/lerobot/svla_so101_pickplace/resolve/main/meta/stats.json
   python3 -c "import json;s=json.load(open('stats.json'))['action'];\
   print({k:[round(float(x),2) for x in s[k]] for k in ('min','max','mean','std')})"

3. 3
   Get the histogram, not just the extremes

   Min and max hide the shape, and the shape is where the surprise lives. Download one parquet shard and bin the gripper channel.

   bash

   curl -sL -o f0.parquet \
     https://huggingface.co/datasets/lerobot/svla_so101_pickplace/resolve/main/data/chunk-000/file-000.parquet
   
   python3 - <<'PY'
   import pandas as pd, numpy as np
   df = pd.read_parquet('f0.parquet')
   g = np.stack(df['action'].values)[:, 5]
   n = len(g)
   print(f'frames {n}  episodes {df.episode_index.nunique()}')
   print(f'gripper min {g.min():.2f}  max {g.max():.2f}  mean {g.mean():.2f}')
   for lo, hi in [(0,5),(5,10),(10,20),(20,30),(30,40),(40,100)]:
       m = ((g >= lo) & (g < hi)).sum()
       print(f'  [{lo:3d},{hi:3d})  {m:6d}  {100*m/n:5.1f}%')
   PY

4. 4
   Cross-check against a second dataset

   One dataset is an anecdote. Run the same query against lerobot/svla_so100_pickplace and see whether the pattern repeats.

   bash

   curl -sL https://huggingface.co/datasets/lerobot/svla_so100_pickplace/resolve/main/meta/stats.json \
     | python3 -c "import json,sys;s=json.load(sys.stdin)['action'];\
   print('min', round(float(s['min'][5]),2), 'max', round(float(s['max'][5]),2))"

Against lerobot/svla_so101_pickplace, 50 episodes of SO-100 follower pick and place at 30 fps, this is what comes back.

The maximum across the dataset is 33.0. Per episode the widest opening runs from 17.8 to 33.0, median 23.2. Two thirds of the jaw's travel never appears once. lerobot/svla_so100_pickplace is a separate 19631-frame recording and stops at 34.93. The pattern repeats, and a policy cannot output an action it never saw.

Why a narrow distribution is worse than it looks

ACT and SmolVLA in LeRobot default to MEAN_STD normalisation on the action vector, so each dimension is divided by its own standard deviation before the loss. (Pi0.5 is the exception: configuration_pi05.py sets QUANTILES for state and action.) The gripper's std here is 9.0, the smallest of the six, but normalisation compensates for scale, so it is not underweighted. The problem is worse: the channel is nearly constant, so it is nearly free to predict. A useful diagnostic is the copycat baseline from Wen et al. (NeurIPS 2020), where an imitator echoes the current state instead of predicting the next action. Predict action equals state, then take the mean squared error per dimension in those normalised units:

import pandas as pd, numpy as np, json
df = pd.read_parquet('f0.parquet')
a = np.stack(df['action'].values)
s = np.stack(df['observation.state'].values)
std = np.array([float(x) for x in json.load(open('stats.json'))['action']['std']])

mse = ((a - s) ** 2).mean(0) / std ** 2          # copy-the-state error, MEAN_STD units
names = ['shoulder_pan','shoulder_lift','elbow_flex','wrist_flex','wrist_roll','gripper']
for n, v in zip(names, mse):
    print(f'{n:16s} {v:.3f}   {100*v/mse.sum():4.1f}% of total')

Four of the six dimensions sit under nine percent of that error each, and the one that decides success carries half of it while contributing one sixth of the loss. That is how a training curve stays clean while the arm reaches the object, hovers and never closes. If that is your symptom, loss falls but the policy does nothing and gripper does not close are the two pages to read.

Compliance is the cheapest accuracy you will buy

A rigid jaw demands the policy place the end effector within a millimetre or two. A compliant jaw deforms around the object, turning positioning error into a harmless bend. Dollar and Howe's SDM Hand (IJRR, 2010) argued for underactuated elastomer-jointed fingers on exactly that ground, and the Fin Ray effect gripper of Crooks et al. (2016) showed how far a passive triangular structure with buckling crossbeams goes.

The SO-ARM100 repository ships this. Optional/Compliant_Gripper holds Compliant_Moving_Jaw_SO101.stl and Compliant_Wrist_Roll_Follower_SO101.stl, replacing both jaws. They are hollowed out with internal ribs, printed in TPU 95A at 20 percent, and the README states the external geometry is identical to the rigid parts apart from some removed holes and the added cavities and ribs, so the assembly does not change. It came out of the June 2025 Hugging Face LeRobot hackathon and credits the Fin Ray Effect.

How much does jaw shape matter next to the algorithm on top of it? Georgadarellis et al. (17 March 2026, UMass Amherst) had eight participants open bandage packages across 15 bimanual trials in three conditions: bare hands, a modified UMI gripper spreading load across the whole finger face, and the same gripper with angled fingers concentrating load at the tips. The distributed version succeeded on 65.8 percent of trials; the concentrated version and bare hands on all of them. Hands were roughly 15 times faster than the distributed grippers and 4 times faster than the concentrated ones.

What varied was the angle of two printed fingers, and a third of the demonstrations stopped existing. Collect data through a gripper like that and you have a hardware problem wearing a policy problem's clothes. The UMI paper (Chi et al., 2024) makes the general case for handheld rigs; its own gripper is a 780 g printed parallel jaw with an 80 mm finger stroke, soft fingers, and a fiducial marker so finger width is logged continuously rather than as a flag.

What a policy can learn about your gripper, and what it cannot

Splitting this cleanly is the most useful thing to do before spending money on a run. One column is worth more data; the other is worth a different printed part.

Getting a gripper-aware dataset onto a trained policy

A gripper checklist before you record 50 episodes

The recording workflow sits in the SO-100 data collection guide and in how to collect high-quality VLA training data. Still assembling? Start at the complete SO-100 setup guide.

Where none of this helps

• No software layer changes the mechanics. AY-Robots can rent the GPU, size the run and serve the checkpoint; it can do nothing about a 110 degree jaw or a 50 percent torque cap. If the task needs a parallel jaw, a suction cup or three fingers, the answer is a different end effector.
• All five trainable policies consume the same six-value action vector, so bolting a tactile sensor onto the jaw takes you off the supported path. Legitimate research, not something a hosted form absorbs.
• Grasp planning is a separate discipline from behaviour cloning. If the real question is which grasp on a novel object is robust, that is what Dex-Net 2.0 answers: 6.7 million synthetic point clouds, 0.8 second planning, 93 percent success on eight known objects and 99 percent precision on 40 novel ones. A demonstration-trained SO-100 policy reproduces the grasps you showed it, nothing more.
• None of it removes the need for consistent human demonstrations, and gripper timing is what separates a usable dataset from an unusable one. The operator page is where that side starts.