Training Pi0.5 on an SO-100

What you need before you start

• A calibrated SO-100 with all six STS3215 servos responding, as covered in /learn/so-100-getting-started
• The desktop client installed and paired, so there is no Python environment to build
• At least 50 kept episodes of one task, recorded as a LeRobot v2.1 dataset and uploaded
• Two cameras that have not moved since the first episode was recorded
• A billing method on the account, because the run rents an 80 GB card by the hour
• A task that rewards precision rather than speed, which is the whole reason to pick this model

Why Pi0.5 earns its 485 ms on this arm

Pi0.5 is a flow-matching vision-language-action model on a PaliGemma backbone, around three billion parameters. Flow matching means the action head learns a continuous path from noise to an action chunk instead of choosing among discretized bins. The practical consequence on an SO-100 is that the commanded trajectory is smooth by construction, and small corrections stay small instead of snapping to the nearest quantized value.

That matters most when the gripper is already touching something. Seating a lid, sliding a peg into a hole, stacking a second block on a first, closing a latch: these are tasks where the correct next action differs from the current one by a fraction of a degree, and where a policy that jumps produces a nudge that ruins the alignment. The SO-100 has no force sensing and a noticeable amount of backlash, so it cannot recover from a nudge the way a stiffer arm can. Continuity in the output is the cheapest substitute for compliance in the hardware.

It does not pay everywhere. At about 485 ms per action step the arm issues just over two commands per second. On a task that is mostly free-space transit, that time is spent doing nothing useful and the model is beaten on both cost and appearance by something smaller. Pick Pi0.5 when the hard part of your task happens in contact.

Pi0.5, pi0 and pi05: three names, one model

The naming trips people up on the first API call. The model id the training backend takes is the string pi0. The policy type written into the trained checkpoint is pi05. The dropdown in the UI says Pi0.5, and the vendor writes it with a Greek letter. Search traffic arrives here as "pi zero", "pi 0.5" and "π0", all of which mean the same model. If you pass pi05 as the model id it will not resolve, so use pi0 in anything programmatic and expect pi05 back in the artifact metadata.

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "start_training",
    "arguments": {
      "dataset_id": "ds_7c41a9",
      "policy_name": "so100-lid-seat-pi05-seed-42",
      "model_id": "pi0",
      "max_steps": 30000,
      "confirm_spend": true
    }
  }
}

What the dataset has to look like

The trainer reads LeRobot v2.1, which is what the client writes by default. Fifty episodes is the point where this model starts producing something you can evaluate seriously; below that you are measuring noise. Beyond the usual rules for clean demonstrations, two things matter specifically for a flow-matching policy.

1. Demonstration smoothness transfers directly. The model reproduces the shape of the trajectories you recorded, so a demonstration with a hesitation in it teaches a hesitation.
2. One task string, phrased identically across every episode. The language side of the backbone attends to it, and two phrasings of the same task split your data in half.
3. Vary object placement, not your approach strategy. Two incompatible strategies average into a path that touches neither.
4. Keep the grasp moment visible. If the wrist camera loses sight of the contact, the part of the task Pi0.5 is good at is the part it cannot see.

Start the run

1. 1
   Open Training and choose the dataset

   The dataset picker lists what has finished processing. Open the preview once and confirm the episode count and both camera streams before you spend anything: a dataset that uploaded with one camera missing trains perfectly well and gives you a worse policy for the same money.

2. 2
   Select Pi0.5 in the model list

   The card shows the A100 80 GB requirement and the inference figure. Selecting it swaps the parameter block to the pi0 defaults and reveals the two extra fields this trainer family exposes, seed and log frequency.

3. 3
   Review the parameters

   Batch size 1, learning rate 5e-5, 30000 steps, gradient accumulation 16. Set a seed now rather than later, and give the policy a name that contains the seed and the dataset version so the run is identifiable in three weeks.

4. 4
   Start it and let the pool find a card

   GPUs are rented on a spot market and selected by VRAM rather than by model name, so the job may sit queued for a while before an 80 GB card is available. Queued time is not billed.

5. 5
   Watch the run page, not the loss alone

   The run page plots loss, learning rate and gradient norm alongside GPU utilization, VRAM, temperature and power. Utilization tells you the job is really training; a card sitting near idle with the loss frozen means the data loader is the bottleneck, not the model.

6. 6
   Take two or three checkpoints from the second half

   The final checkpoint is the newest, not automatically the best. Keep a couple from the back half of the schedule and let the arm decide between them, because nothing on this page can.

The defaults, and when to change them

Cost and wall clock

An A100-tier run on this platform takes 3 to 6 hours at 1.20 to 2.00 USD per hour, so about 4 to 12 USD in total. Pi0.5 sits at the upper end of that band, and the reason is worth understanding, because it is not the reason most people assume.

Batch size 1 on an 80 GB card leaves memory to spare. The constraint is the clock: 30000 steps with 16 accumulation steps behind each of them is a lot of forward and backward passes, and they happen one small sample at a time. Nothing you can set in the form makes that materially faster, which is why the practical lever on cost is the step count and the honest question of whether this task needs this model at all.

Reproducing a run exactly

Seed and log frequency are exposed for the lerobot family, which is ACT, SmolVLA and pi0. GR00T does not have this: its fine-tune entry point has no seed field at all, so two GR00T runs on the same data are simply two different runs. With Pi0.5 you fix the seed and the run is deterministic, which turns hyperparameter changes into something you can actually attribute.

Use it properly. Hold the seed constant when you change one parameter, and vary only the seed when you want to know how much of the difference between two policies was luck. Put the number in the policy name; the run page keeps the configuration, but a name you can read in a list is faster than opening six runs to find out which was which.

Deploy the checkpoint to the arm

Before you load anything, confirm the arm is in the state the dataset assumes. Cameras in their recorded positions, same lighting, same scene reset, all six servos answering on the bus.

ay-robots devices

# SERIAL PORTS
#   /dev/cu.usbmodem58FA0821911   SO-100  (6 servos responding)
# CAMERAS
#   0  Scene cam    1280x720
#   1  Wrist cam    1280x720

# Only if a joint reads visibly off from where it physically sits
ay-robots calibrate

Then select the checkpoint in the client and run it against the same task string you recorded with. Expect the arm to look thoughtful. At 485 ms per action step you can watch it move, settle, and move again, and on a careful insertion that reads as competence. On a fast pick-and-place the same cadence reads as hesitation: reach, pause, reach, pause. That pattern is the inference interval, not a broken policy, and no amount of retraining removes it.

Evaluate it properly

Twenty attempts with the object in different starting positions, written down as you go. Then repeat the identical protocol for the second checkpoint. A four-attempt impression of a policy that takes half a second per action step is not an evaluation, it is a mood.

Separate the two failure families before you conclude anything. If the arm reaches the right place and fumbles the contact, that is a data problem and more targeted episodes will fix it. If the arm arrives too late because the object is no longer where it was half a second earlier, that is a latency problem, and the answer is a different model or a slower task, not more demonstrations.

Troubleshooting

Frequently asked questions