LeRobot 0.6 connected training, evaluation, and deployment more closely

LeRobot v0.6.0 introduced new policies, a reward-model interface, simulation benchmarks, and deployment tooling. The announcement also described human-in-the-loop corrections, dataset improvements, and cloud training options as parts of a more connected robot-learning workflow.

The central idea is iteration. A deployed policy produces failures and observations that can inform the next training round, rather than ending the experiment at a benchmark score. That only works when data capture and evaluation are consistent enough to compare revisions.

Select a supported policy and benchmark before exploring the entire release. Follow the migration and hardware guidance in the source, then validate rollout and correction behavior in a controlled environment. Introduce new components one at a time so failures remain diagnosable.

A robot policy needs a complete path to action

A policy checkpoint is only one part of a robot system. Observations must reach the model in the expected format, actions must be interpreted by the correct hardware interface, and evaluation must reflect the task the robot is supposed to complete. A mismatch at any of those boundaries can make a promising policy unusable.

Consider a simple pick-and-place exercise. The camera view, gripper state and timing of each action are part of the task definition. If training data used a different viewpoint or action convention, an apparently small configuration difference can change what the policy’s output means.

Establish a known-good baseline

Before introducing a new release into a working setup, preserve the existing environment, configuration and a short reference recording. Confirm that the robot can still execute a basic non-learning motion through its ordinary control interface. This distinguishes a policy issue from a connection, calibration or mechanical issue.

Then test the observation pipeline without executing model-generated movement. Inspect image dimensions, channel order, timestamps and state values. A model can accept an input tensor that is technically the right shape but represents the wrong thing.

Evaluate in stages

Begin with recorded observations or a suitable simulation, then progress to tightly bounded physical tests. Use conservative motion limits and an accessible stop mechanism. An evaluation should not rely on the model itself to decide when a dangerous or unintended movement must stop.

Define success before collecting results. For a manipulation task, success might require the object to reach a target area and remain stable, not merely appear in the gripper for a moment. Record attempted trials as well as completed trials so that interrupted and failed attempts do not disappear from the result.

Keep data and deployment connected

When a test fails, save enough context to diagnose it: the policy revision, configuration, observations, requested actions and relevant timing. A final video is helpful but may not expose the coordinate or timing mismatch that caused the failure.

Use those findings to decide whether the next change belongs in the dataset, the policy, the evaluation or the hardware integration. Retraining should not be the default response to every failure. Sometimes the model is behaving consistently with the inputs it was given, while the surrounding system is interpreting them incorrectly.

A release that brings these stages closer together can make experimentation more manageable. The practical goal remains the same: a traceable route from a recorded experience to a tested policy and finally to controlled behaviour on the intended robot.