Record, Train, Deploy, Retrain: The Robot Policy Loop

One fine-tune is not a system

Most people who train a first policy on an SO-100 do the same thing: record forty episodes, run a training job, load the checkpoint, watch the arm do something roughly correct, stop. Build that demo. But it is a single point measurement, and you want a slope.

The slope comes from repetition with feedback: deploy, watch it fail in a specific way, record data about that failure, retrain, deploy again. Each turn should cost less than the last, because the pure mechanism has been automated away. The rest of this is about which parts are mechanism.

What a full turn contains

Six stages. The last column matters most: where a stage goes wrong decides whether automating it saves time or hides a bug.

Why the loop exists: compounding error

Imitation learning from demonstrations is supervised learning on states the expert visited. At run time the policy visits states it causes. The moment it errs slightly it is somewhere the expert never was, and errors compound. Ross, Gordon and Bagnell formalized it: a classifier erring with probability epsilon under the expert's state distribution can make as many as T squared times epsilon mistakes over a T-step horizon under its own.

Practically: your first thirty episodes teach the happy path, the next thirty teach almost nothing. What moves the number is data in the states your checkpoint drifts into, which you only find by running it. That is why the loop closes, and why how you collect data beats how much you have.

Turn one: record the seed dataset

Everything starts with a LeRobot dataset. The desktop client from the download page records one out of a teleoperation session, and the recording tutorial walks it end to end. The commands below are from the LeRobot cheat sheet on main, checked 2026-08-24.

1. 1
   Find the ports

   Once per arm. It asks you to unplug the USB cable, then prints the port that disappeared.

   bash

   pip install 'lerobot[training]'
   lerobot-find-port
   lerobot-find-cameras

2. 2
   Calibrate leader and follower

   Put every joint roughly mid-range first. The --robot.id is the key LeRobot uses to find the calibration file later, so keep it stable.

   bash

   lerobot-calibrate \
       --robot.type=so101_follower \
       --robot.port=/dev/ttyACM0 \
       --robot.id=my_follower_arm

3. 3
   Record the seed episodes

   Right arrow saves, left arrow deletes the take and retries, Escape stops and encodes. Use the left arrow generously: a bad take costs nothing now and a confusing loss curve later.

   bash

   lerobot-record \
       --robot.type=so101_follower \
       --robot.port=/dev/ttyACM0 \
       --robot.id=my_follower_arm \
       --robot.cameras="{ top: {type: opencv, index_or_path: 1, width: 640, height: 480, fps: 30}, wrist: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30} }" \
       --teleop.type=so101_leader \
       --teleop.port=/dev/ttyACM1 \
       --teleop.id=my_leader_arm \
       --dataset.repo_id=${HF_USER}/pick_block_r1 \
       --dataset.num_episodes=40 \
       --dataset.single_task="put the red brick in a bowl" \
       --display_data=true

Turn one: train, and the format trap

Now pick a model. The policies page lists the five trainable here, and the head-to-head pages cover the pairs people agonize over. For a first loop, start cheap: ACT and SmolVLA give turns of about 1 to 3 USD over 2 to 5 hours, so you can afford to be wrong. GR00T N1.7 and Pi0.5 cost 4 to 12 USD over 3 to 6 hours.

# LeRobot main, checked 2026-08-24
lerobot-train \
    --dataset.repo_id=${HF_USER}/pick_block_r1 \
    --policy.type=act \
    --output_dir=outputs/train/act_r1 \
    --job_name=act_r1 \
    --policy.device=cuda \
    --policy.repo_id=${HF_USER}/act_pick_block_r1 \
    --steps=20000 \
    --wandb.enable=true

# resume from a checkpoint
lerobot-train --config_path=${HF_USER}/act_pick_block_r1 --resume=true

Evaluate: the step nobody automates, and mostly should not

This is where homemade loops fall apart. LeRobot has lerobot-eval, but read its arguments: it takes --env.type and runs episodes in a simulator. There is no built-in scorer for a real arm, because scoring a real rollout means a human deciding whether the block ended up in the bowl. That judgement carries the information; automating it early means optimizing a proxy.

Standardize the protocol around the judgement instead, so two checkpoints a week apart are comparable. Change it only when you also re-score the old checkpoint.

Deploy, and record what the policy does

Deployment used to be an afterthought in LeRobot. On main there is a dedicated CLI, lerobot-rollout, built around pluggable strategies whose names read like a list of what a deployment loop needs. On v0.5.1 you still use lerobot-record with a policy path, which is one reason to say which version you mean.

# LeRobot main: run the checkpoint, take over when it drifts
lerobot-rollout \
    --strategy.type=dagger \
    --strategy.num_episodes=20 \
    --strategy.record_autonomous=true \
    --policy.path=${HF_USER}/act_pick_block_r1 \
    --robot.type=so100_follower \
    --robot.port=/dev/ttyACM0 \
    --teleop.type=so101_leader \
    --teleop.port=/dev/ttyACM1 \
    --dataset.repo_id=${HF_USER}/pick_block_dagger_r1 \
    --dataset.single_task="put the red brick in a bowl"

# slow VLAs: overlap inference with execution instead of pausing at chunk boundaries
lerobot-rollout \
    --strategy.type=base \
    --inference.type=rtc \
    --inference.rtc.execution_horizon=10 \
    --policy.path=${HF_USER}/my_pi05_policy \
    --robot.type=so100_follower \
    --robot.port=/dev/ttyACM0 \
    --task="put the red brick in a bowl" --duration=60

Collect failures: corrections beat more demonstrations

Classic DAgger asks the expert to label every visited state without giving the expert control, which is awkward with a physical arm. HG-DAgger (arXiv 1810.02890, Kelly and colleagues, 2018) has the human take over instead, because labelling without control degrades label quality through perceived actuator lag. That matches a leader-follower rig: the policy drives, you grab the leader when it goes wrong.

The RaC protocol is worth copying: when failure looks imminent, first rewind the arm to a state the policy handles, then drive the correct continuation. You teach recovery and correction at once, and recovery is what plain demonstration data never contains.

Retrain: merge, prune, rerun

Aggregation in DAgger is literal: train on the union, not the newest batch. LeRobot exposes the set operations as a CLI so you do not write dataset-surgery scripts, which is the glue code Sculley and colleagues warned about in 2015, estimating a mature system might be at most 5 percent machine learning code and 95 percent glue.

1. 1
   Delete the takes you know are bad

   Before merging, and write down the indices. Deleting hard episodes because they look messy is the easiest way to stall a loop.

   bash

   lerobot-edit-dataset \
       --repo_id ${HF_USER}/pick_block_dagger_r1 \
       --operation.type delete_episodes \
       --operation.episode_indices "[3, 11, 17]"

2. 2
   Merge round one with the intervention data

   Merging writes a new dataset instead of mutating the inputs, so earlier rounds stay reproducible.

   bash

   lerobot-edit-dataset \
       --new_repo_id ${HF_USER}/pick_block_r2 \
       --operation.type merge \
       --operation.repo_ids "['${HF_USER}/pick_block_r1', '${HF_USER}/pick_block_dagger_r1']"

3. 3
   Hold out a split you never train on

   No substitute for real rollouts, but it catches a merge that broke something.

   bash

   lerobot-edit-dataset \
       --repo_id ${HF_USER}/pick_block_r2 \
       --operation.type split \
       --operation.splits '{"train": 0.9, "val": 0.1}'

4. 4
   Retrain from base, not last week's checkpoint

   Chaining fine-tunes accumulates drift you cannot audit. Going back to base costs a few dollars and keeps every checkpoint traceable to one dataset revision.

   bash

   lerobot-train \
       --dataset.repo_id=${HF_USER}/pick_block_r2 \
       --policy.type=act \
       --output_dir=outputs/train/act_r2 \
       --job_name=act_r2 \
       --policy.device=cuda \
       --steps=20000

The same loop, two ways

# minimal run registry: one JSON line per turn
cat >> loop.jsonl <<'EOF'
{"turn": 2, "dataset": "user/pick_block_r2", "policy": "act", "steps": 20000, "ckpt": "outputs/train/act_r2/checkpoints/last", "protocol": "v1", "success": "13/20"}
EOF

What to automate first, and what to keep manual

General MLOps answered the ordering question. Google's maturity model runs level 0 (all manual, predictions never logged), level 1 (training pipeline automated, triggered by schedule, new data or drift), level 2 (CI/CD for the pipeline code too). The useful part is the order: pipeline automation before deployment automation, logging before either.

• Same input, same output: automate it now.
• Someone must look at a robot and form an opinion: leave it manual, automate the scaffolding.
• Cheap to run, expensive to get wrong: automate it and log every input, so you can reconstruct it.
• Log the boring metadata on turn one: dataset revision, checkpoint path, protocol version, per-trial outcome. One JSON line, one afternoon saved.

A maturity ladder for one arm on one desk

Most single-arm projects should aim for rung two and stop. If you have not built rung one, train your first policy and then run it on the arm.

Where this breaks down, including here

• There is no real-world evaluator. Not in LeRobot, not here. lerobot-eval runs in simulation. Every success rate above was counted by a person watching an arm.
• Latency is physics. Cloud inference at 152 to 485 ms per action step plus a public round trip suits slow pick-and-place, not fast reactive motion. Only moving compute next to the servos changes it.
• DAgger assumes a competent expert on demand. On a real desk the expert is you at 9 pm, and the quality of your 9 pm corrections is now in the dataset.
• Format churn is real. GR00T needs v2.1 while Pi0.5 and SmolVLA want v3.0, and v0.6.0 renamed flags older tutorials still print.
• Automating too early hides regressions. A loop that retrains nightly and is never watched converges on something worse, and you hear it from a user, not a metric.

None of that argues against the loop. It argues for building the boring parts properly and keeping a person in the judging part. No hardware yet? The live arm runs with no signup, and the arena has 85 VLA models with 332 benchmark results. See also the SO-100 guide and what a VLA is.