How to train SmolVLA on an SO-101

What the SO-101 changes, and what it does not

The SO-101 is the SO-100 with a revised wrist. Five joints plus a gripper, six Feetech STS3215 bus servos, 7.4 V, LeRobot v2.1 recordings, the same trainer with the same defaults. If you have already trained SmolVLA on an SO-100, the only genuinely new material on this page is the section about mixing data between the two arms.

The wrist revision matters for two things: where a wrist camera can be mounted, and how the final joint reaches into a grasp. Both are pose-level and pixel-level details, and a policy learned by imitation is made almost entirely of pose-level and pixel-level details. That is the whole reason this page exists separately.

Before the first run

• An assembled SO-101 registered on /robots and paired with the client, with all six servos answering on the bus.
• A fresh calibration on this physical arm. Calibration is per unit, not per model, and an SO-100 profile on the same machine does not carry over.
• A scene camera on a mount that will not move, and a wrist camera if your wrist has a bracket for one.
• Thirty or more reviewed episodes of a single task, uploaded as LeRobot v2.1.

ay-robots devices
# Confirm six servos respond before you calibrate. Five means a cable,
# not a configuration problem, and no amount of software fixes it.

ay-robots calibrate
# Per physical arm. Zero points differ between units of the same model,
# so an SO-101 next to an SO-100 needs its own pass even on one machine.

Recording for a language conditioned policy

SmolVLA trains on your camera frames, your joint actions and the sentence attached to each episode. That sentence is a real input, not metadata, so it needs the same discipline as the rest of the recording. Keep one sentence per task and keep it byte-identical across episodes. Paste it, never retype it.

There is a habit specific to SO-101 owners here. Most people arrive at this arm from an SO-100 and re-record a task they already had. When you do that, resist the urge to improve the wording of the task string. A better sentence makes the two datasets incomparable, and comparing them is the main reason to re-record in the first place.

Where the language conditioning genuinely pays off is a second task in the same scene. Thirty episodes of one job plus thirty of another, same table, same cameras, trains a single policy you steer at inference by changing the sentence. Plan the scene for both from the start, because moving the tripod later invalidates the half you already recorded.

Mixing SO-100 and SO-101 episodes

Everyone who owns both arms asks this. The honest answer is that it works and it costs you something. Joint values mean slightly different poses on the two arms even after both are calibrated, and the wrist camera returns a different image of the same grasp. A mixed dataset therefore teaches the model that one observation sometimes implies two slightly different actions, which is the exact ambiguity that flattens a policy into a useless average.

1. Mix only in substantial blocks. Forty SO-100 episodes plus forty SO-101 episodes is a mixed dataset. Forty plus six is a clean dataset with six pieces of noise in it.
2. Both arms calibrated, and the scene camera in the same physical position for both recording sessions. If the tripod moved between them, you are not mixing arms, you are mixing scenes.
3. Keep the task string identical across the two blocks. Different wording turns one mixed dataset into two small single-arm datasets.
4. Evaluate on both arms afterwards. A mixed policy that works on one and not the other is common, and it tells you which arm dominated the data.
5. If you only care about the SO-101, thirty fresh SO-101 episodes will beat sixty mixed ones. Mixing is for when you want one policy to run on both.

Starting the run

1. 1
   Upload and let it finish processing

   Open Datasets and wait until the upload leaves the processing state. The trainer cannot see a dataset that is still being archived, and it will simply not appear in the picker.

2. 2
   Open Training and select SmolVLA

   Pick the dataset first, then the model. The parameter form is model-specific, so it redraws when you change the model and quietly discards values that do not apply.

3. 3
   Read the six fields it offers you

   Batch size, learning rate, steps, gradient accumulation, seed and log frequency. That is the whole surface. Chunk size and action steps are ACT parameters and do not appear for SmolVLA.

4. 4
   Fix the seed and name the run for the arm

   Put so101 in the policy name. When you later have runs from both arms in one list, the model name and the date will not tell you which hardware produced which policy.

5. 5
   Start it and check the first log lines

   The pool leases a 24 GB card on the spot market, so expect a wait before the first metrics appear. Once loss is printing, confirm it is moving downward before you walk away from a paid GPU.

Defaults and the reasons to touch them

Seed and log frequency are available for the whole lerobot family, meaning ACT, SmolVLA and Pi0.5. GR00T exposes neither, so a reproducibility workflow built around a fixed seed does not survive the move to N1.7.

Cost, and what the cheap run is for

A SmolVLA run rents from the 24 GB tier at roughly 0.30 to 0.60 USD per hour and takes 2 to 5 hours, so about 1 to 3 USD. That price is the actual argument for this model. It lets you treat a training run as a measurement rather than an event.

The measurement worth making on a new SO-101 dataset is whether the data is learnable at all. If SmolVLA cannot get the arm to make task-shaped attempts, the problem is nearly always in the demonstrations, and moving to a bigger model reproduces the failure at 1.20 to 2.00 USD per hour on an A100 instead. Establish the data is good on the cheap tier, then spend the A100 hours on a dataset you already trust.

Deploying to the SO-101

Load a checkpoint in the client, pass the task string you recorded with, and put the cameras back exactly where they were. SmolVLA runs at about 245 ms per action step, so the arm advances in perceptible increments. On an SO-101 that is most visible in the wrist, which now has to complete its rotation into the grasp in fewer, larger commanded jumps than a 20 ms policy would use.

Evaluate over twenty attempts with varied object placement, recording each outcome as it happens. Compare two or three checkpoints from the second half of the run rather than trusting the final one. Then, separately, run the same protocol with a reworded instruction to find out whether the language robustness you assumed is actually there.

Four failures and their SO-101 flavor

Loss falls but the arm does nothing useful

On a fresh SO-101 the first suspect is not your technique, it is a dataset that still contains SO-100 episodes. A recycled dataset with a handful of old-arm episodes in it produces exactly this: a clean curve and an arm that reaches to a pose that was correct on different hardware. Check the episode list, and if the set is mixed, retrain on the SO-101 block alone as a control.

The policy ignores the instruction

Two causes, and on this arm the second is more common. Either every episode carried the same string, so the text input never varied and the model learned to disregard it, or you reworded the string when you moved the task over from the SO-100 and the dataset now contains two near-synonyms with fifteen episodes each. Neither has enough behind it to teach anything.

It only works in the lighting you recorded in

The printed SO-101 wrist sits closer to the grasp than the older one and can throw a hard shadow across the object under a single overhead lamp. Move the light, or add a second, and record ten episodes under each condition. Lighting variety in the dataset is worth more here than more episodes under the one condition that happens to work.

The gripper closes at the wrong moment

The SO-101 gripper closes over a revised travel, so a policy carrying any SO-100 data has learned a closing distance that no longer matches the hardware. Combine that with roughly 245 ms per action step, which already commits the close about a quarter of a second early, and near misses become the norm. Re-record the grasp slowly on the SO-101 itself: approach, settle, close, settle, lift.

The upgrade path from here

SmolVLA gives up accuracy on fine positioning in exchange for fitting on a cheap card. Once more data stops moving your success rate, the next run is GR00T N1.7 on the same v2.1 dataset: an 80 GB card, batch size 32, about 152 ms per action step, no seed field, roughly 4 to 12 USD. /train/groot-n1-7-on-so-101 covers it, and /policies/groot-n1-7 has the specifications.

For background on the model itself see /policies/smolvla, and if you are still deciding between the two models on the 24 GB tier, /compare/act-vs-smolvla is the direct comparison.