Training a first LeRobot policy and evaluating it

Freeze the training inputs

This guide uses LeRobot v0.6.1, checked on 6 September 2026. Record the dataset identity and revision, selected episodes, camera feature names, action representation and environment versions before starting. In a private simulation, also record the simulator build, task definition and observation interface. The command can run successfully while learning the wrong task if those inputs are ambiguous.

Open representative episodes through the training-compatible loader first. Confirm the image content after preprocessing and the meaning of each action dimension. A model cannot recover a release event that the camera never observes, and more optimisation will not correct swapped action columns. Use the related inspection guide to resolve those defects before spending a long run on them. Keep this training record focused on what the selected experiment consumes.

References: Dataset and evaluation configuration at LeRobot v0.6.1 · Policy configuration at LeRobot v0.6.1

Choose an interpretable first baseline

The official ACT page recommends ACT as a first LeRobot policy. Treat that as the project's starting recommendation, not a guarantee of training time, required demonstration count or superiority on your task. The separate action-chunking guide explains its temporal behaviour. Here the useful aim is to establish a working experimental reference with a configuration you can inspect.

Write the experiment's decision in advance: can this observation and action interface produce any consistent task success under the declared starts? Resist changing architecture, camera layout and collection strategy together. If the first run fails, a narrow reference makes the next investigation easier. Establish a resource budget and checkpoint review point appropriate to your workstation; no universal number of training steps can establish learning for every dataset.

References: ACT policy documentation at LeRobot v0.6.1 · ACT configuration at LeRobot v0.6.1

Construct a local smoke run

After installing the training dependencies for v0.6.1, adapt this one-line example to an authorised local dataset: lerobot-train --dataset.repo_id=local/tray-demo --dataset.root=/absolute/path/to/dataset --policy.type=act --policy.device=cpu --policy.push_to_hub=false --wandb.enable=false --output_dir=outputs/train/act_smoke_001 --job_name=act_smoke_001 --steps=10 --batch_size=1 --num_workers=0 --env_eval_freq=0. The paths and identifier are placeholders; replace them with your actual values and quote paths containing spaces.

This deliberately short CPU example checks configuration, loading and checkpoint creation without controlling a robot. Its ten updates are illustrative and insufficient evidence of a trained policy. The flags were checked against the tagged tutorial and configuration source. Disabling model upload and online tracking does not guarantee zero network traffic: a vision backbone may still retrieve pretrained weights, and dataset access follows the chosen location.

References: Imitation learning tutorial at LeRobot v0.6.1 · Training configuration at LeRobot v0.6.1 · Dataset and evaluation configuration at LeRobot v0.6.1 · Policy configuration at LeRobot v0.6.1 · ACT configuration at LeRobot v0.6.1

Inspect the resolved run before extending it

Read the logged configuration and confirm that it describes the intended dataset, policy and compute device. In this release the policy configuration can fall back to an available device when the requested one is unavailable, so the command line alone is not sufficient evidence of GPU use. Confirm that the process reached model updates and produced the expected output artifact.

Separate loading time from computation time. If the first batch fails, retain the traceback and test that batch's images and feature shapes before modifying optimisation settings. If memory is exhausted during model computation, reduce one relevant workload factor and record it. A passing smoke run earns a longer experiment with a new output directory; it does not justify an immediate autonomous robot trial.

References: Policy configuration at LeRobot v0.6.1 · Training entry point at LeRobot v0.6.1

Record checkpoints and resumption correctly

Keep each experimental run in a distinct output directory. Store its resolved training configuration, dataset revision, seed, logs, policy weights and preprocessing artifacts together. The training source includes checkpoint handling for continued optimisation. Copying only an inference weight file does not establish that optimiser state and other continuation information were preserved.

For v0.6.1, resumption uses --resume=true with --config_path pointing to the saved training configuration or another supported checkpoint location. Treat resuming an interrupted experiment differently from starting a new experiment from pretrained weights. Review overrides explicitly because they can change the resumed configuration. After an interruption, record the resumed step and verify that the selected data and output location still match the intended experiment.

References: Training configuration at LeRobot v0.6.1 · Training entry point at LeRobot v0.6.1

Separate offline loss from task evaluation

The tagged configuration distinguishes held-out dataset loss from execution in a simulation environment. Dataset eval_split selects a held-out episode fraction, while eval_steps enables periodic offline evaluation; env_eval_freq addresses simulation evaluation. Verify these fields against your release when following older examples. A held-out fraction is useful, but it does not by itself ensure that near-identical collection sessions are independent.

Define an explicit task test beyond the loss curve. For a tray transfer, specify an accepted final location, completion deadline, permitted starting conditions and how intervention is scored. Keep final test attempts out of checkpoint selection. A policy chosen after repeatedly inspecting the same test conditions has partly been tuned to that test, even if their episodes never entered gradient updates.

References: Dataset and evaluation configuration at LeRobot v0.6.1 · Training configuration at LeRobot v0.6.1

Work a checkpoint comparison

Consider a hypothetical simulation review of two checkpoints under twenty matched starts. Checkpoint A completes twelve attempts and B completes fifteen, but B also requires two operator interventions. If success requires unassisted completion, those interventions must be reflected in the outcome record rather than hidden in a favourable video montage. Preserve every attempt identifier and the reason each attempt failed or was stopped.

This small example supports choosing what to investigate next, not a claim that B is universally better. Inspect whether failures cluster around an unseen orientation, occluded grasp or delayed correction. Compare completion time among accepted attempts while also reporting total failures and interventions. Repeat the most informative comparison with fresh starts and, when practical, another training seed before making a broader statement.

References: Training entry point at LeRobot v0.6.1 · Imitation learning tutorial at LeRobot v0.6.1

Hand over a bounded result

Package the selected checkpoint with its input contract and a concise evaluation report. State which starts were represented, what counted as success, how many attempts were made and what remained unresolved. Include failed rollouts as evidence for the next collection or configuration change. This preserves a useful result even when the first policy does not meet the project's target.

Simulation success concerns the modelled environment and its interfaces. Any move to physical hardware needs a competent person's review of observation mapping, action conversion, calibration, operating limits and stop arrangements. Learning software is not a substitute for that review. Keep the original baseline available so a later dataset or policy change can be evaluated against a known result rather than against memory.

References: Imitation learning tutorial at LeRobot v0.6.1 · Maintenance of work equipment

Checklist

• Freeze dataset revision, episode selection and action semantics.
• Inspect policy inputs after preprocessing.
• Use a short offline smoke run and a fresh output directory.
• Verify resolved device and privacy-related settings.
• Preserve weights, processors and full continuation artifacts appropriately.
• Separate held-out loss, checkpoint selection and final task testing.
• Report all attempts, interventions and failure categories.
• Keep physical deployment subject to competent-person review.

Common questions