How to train GR00T N1.7 on an SO-101

What is actually different about an SO-101

The honest answer first, because it saves you reading the rest twice: from the training backend’s point of view, nothing at all. An SO-101 episode contains the same six actuator columns as an SO-100 episode, in the same LeRobot v2.1 layout, and the fine-tune runs with the same defaults on the same GPU tier. There is no SO-101 switch in the training form and there does not need to be one.

What differs sits upstream of the dataset: the wrist, the cable routing, and therefore the calibration and the poses your demonstrations will contain. None of that changes the software path. All of it changes your data, and the data is the only thing the policy ever sees.

Before you start

• An assembled SO-101 with its own calibration, not one inherited from another arm
• The 7.4 V supply for the STS3215 servos, verified against the label rather than the connector shape
• One camera fixed in place at minimum, two if you have a wrist view
• The client installed and paired, and the arm showing as online in your dashboard
• A LeRobot v2.1 dataset of 50 or more reviewed episodes of a single task

Calibration is the part that genuinely differs

Calibration was always per physical unit, and copying a calibration file between two arms was never valid. On an SO-101 it is worse than invalid. The revised wrist puts the flex and roll limits in different places than the older build, so a file borrowed from an SO-100 does not throw an error. It quietly offsets what every recorded joint value means, and you find out four hours into a fine-tune that the policy reaches consistently past the object.

ay-robots calibrate

# SO-101 on /dev/cu.usbmodem58FA0821911
#  [1/6] shoulder_pan    range ok
#  [2/6] shoulder_lift   range ok
#  [3/6] elbow_flex      range ok
#  [4/6] wrist_flex      range ok
#  [5/6] wrist_roll      range ok
#  [6/6] gripper         range ok   full closure reached
# calibration stored for robot "so101-bench-left"

Two things are worth watching during the sweep. First, that the gripper reaches full closure without the servo straining, because a gripper that stops a millimeter short turns every grasp in your dataset into a near miss. Second, that wrist roll travels the whole way in both directions without the cable loom catching. The improved routing makes that less likely than on the older arm, but a loom that has been re-run after a repair can still limit travel.

If both arms are paired to the same account, name them at pairing time. Cross-loading a calibration is a two-click mistake when both robots are called "my arm".

Recording: what carries over and what to reconsider

Everything from the SO-100 recording discipline carries over unchanged: fifty kept episodes as the floor, one task sentence used word for word, failures discarded rather than kept, cameras bolted down. The thing to reconsider is reach. The revised wrist makes some approach angles comfortable that were awkward before, and demonstrations tend to drift toward whatever is comfortable. If you record every episode with the new wrist angle and later want the dataset to serve an SO-100 as well, it will not, because half your poses are outside what that arm does gracefully.

The related question people ask is whether SO-100 and SO-101 episodes can share one dataset. They can, the columns line up exactly. Expect a small cost, because zero points differ between physical units and the model has to absorb that as noise. If you are going to mix, mix by adding to an existing fifty rather than by assembling fifty out of two piles of twenty five. A dataset that is half one arm and half another mostly teaches the model that the mapping is uncertain.

GR00T reads v2.1, and only v2.1

The trainer accepts LeRobot v2.1 datasets and rejects v3.0. Since the client records v2.1 by default, this normally bites people who imported a dataset from elsewhere, or who flipped the setting once for an experiment and never flipped it back before recording fifty episodes.

On the run page the rejection looks like an aborted takeoff. The status moves QUEUED, then RUNNING for under a minute, then FAILED, and there is no loss chart because the trainer never reached the first step. The message talks about the dataset metadata rather than announcing a version mismatch, so it reads like a platform fault. It is not, and re-uploading the same directory reproduces it exactly.

# The one line that decides whether the run starts
grep codebase_version meta/info.json
#   "codebase_version": "v2.1",

# robot_type is bookkeeping for you, not a switch in the trainer
grep robot_type meta/info.json
#   "robot_type": "so101",

Run the fine-tune

1. 1
   Select the SO-101 dataset in the Training page

   Datasets appear once processing has finished. Check the episode count on the card against what you think you recorded, since a partial upload is the quietest way to train on thirty episodes while believing you trained on sixty.

2. 2
   Pick GR00T N1.7

   It is listed with the A100 80 GB tier it requests. N1.5 is kept only for reproducing older projects and is worse than N1.7 on every axis that matters, so pass it by unless reproduction is the goal.

3. 3
   Read the pre-filled hyperparameters and leave them there

   Batch size 32, learning rate 1e-4, 20 000 steps, gradient accumulation 1, plus the save steps field that only GR00T shows. No seed field appears, because this entry point has none. Defaults are the correct first answer on an arm with a well recorded fifty episodes.

4. 4
   Start the run and note the queue

   The pool buys an 80 GB card on the spot market and picks by VRAM rather than by name, so you may land on an A100 or an H100. Nothing is billed while the job waits in QUEUED.

5. 5
   Check the loss shape early, then leave it alone

   A visible drop over the first few hundred steps means the data loaded. After that, staring at the curve tells you nothing you can act on, and the GPU telemetry panel is the more useful thing to glance at: a card at full utilization is a run progressing at the rate you are paying for.

6. 6
   Take two checkpoints into the evaluation

   Pick one from the end of the run and one from the second half, and compare them on the arm rather than on the chart. Save steps decides how many candidates you have to choose between.

Defaults for this model

Cost and wall clock

This model runs on the A100 80 GB tier, which the pool rents at 1.20 to 2.00 USD per hour. A default 20 000 step run on a fifty to one hundred fifty episode SO-101 dataset takes 3 to 6 hours, so about 4 to 12 USD end to end. Spot prices move, so treat the wider end of the range as normal rather than as a warning sign.

Plan around the duration rather than the price. The useful cadence on an SO-101 is one run per dataset change: record a targeted block of episodes, start the fine-tune before you stop for the day, evaluate in the morning against the same protocol you used last time.

Back onto the arm

Select the checkpoint for the paired SO-101 and start inference from the client. Restore the recording conditions first: camera positions, lighting, reset procedure, and the task sentence exactly as it appears in the dataset. At about 152 ms per action step the arm will move in discrete increments, which is normal for this model and still the fastest of the ones this platform trains.

If the checkpoint was trained on SO-100 data and you are running it on an SO-101, it will load and it will move. Treat it as an untested policy rather than a working one. The differences show up at the grasp, where wrist limits and gripper closure differ most, and the twenty attempt protocol will tell you in ten minutes whether it transferred.

Physical success rate is the only metric that decides anything here. Twenty attempts with the object in twenty positions, written down while they happen. A run with a clean loss curve and four successes out of twenty is a four out of twenty policy, and the curve is not evidence to the contrary.

When it does not work

Frequently asked questions