LeRobot: a PyTorch stack for real-world robot learning, from SO-100 arms to VLA policies

The fragmentation problem LeRobot is aimed at

Robot learning code usually accumulates around one lab's arm. The camera driver, the calibration file, the episode recorder and the training script are written for that arm, and moving to a different device means rewriting the data path. LeRobot's stated goal is to lower that barrier so shared datasets and pretrained models are usable across hardware. The README frames it as a hardware-agnostic, Python-native interface that standardizes control across platforms, from low-cost arms such as SO-100 to humanoids.

The audience follows from that. It is for people who have a physical robot and want to record demonstrations, train a policy such as ACT or Diffusion, and evaluate it on the same device without building the plumbing. It is not aimed at teams whose work happens entirely in simulation, and it is not a replacement for a robot operating system. The supported list in the README is concrete: SO100, LeKiwi, Koch, HopeJR, OMX, EarthRover, Reachy2, gamepads, keyboards, phones, OpenARM, Unitree G1 and reBot B601. If your hardware is not on that list, the README says you can implement the Robot interface yourself and still use the data collection, training and visualization tools.

How the Robot interface, dataset format and policies connect

Three pieces make up the architecture, and they are separable. The first is a unified Robot class that decouples control logic from hardware specifics. The flow in the README example is short: construct the robot with a config, call connect, read an observation with get_observation, pass it to a policy's select_action, and send the result back with send_action. Everything hardware-specific hides behind those methods, so a training script does not know which arm is attached.

The second piece is LeRobotDataset, which the README presents as the answer to data fragmentation. A dataset stores synchronized MP4 videos (or images) for vision alongside Parquet files for state and action data, and lives on the Hugging Face Hub. The README lists tools for deleting episodes, splitting by indices or fractions, adding or removing features, and merging datasets. That merge operation is the part worth noting: combining episodes recorded on two different arms is only meaningful if the feature schema lines up, which is why the format is standardized in the first place.

The third piece is the policy library, implemented in pure PyTorch. It spans imitation learning (ACT, Diffusion, VQ-BeT, a multitask DiT policy), reinforcement learning (HIL-SERL, TDMPC, with QC-FQL listed as coming soon), vision-language-action models (Pi0, Pi0Fast, Pi0.5, GR00T N1.7, SmolVLA, XVLA, EO-1, MolmoAct2, WALL-OSS, EVO1) and world models. Training is driven from the command line rather than from Python, which keeps the entry point uniform across policy types.

Installing LeRobot and training a first ACT policy

The README's quick start is two commands: install from PyPI, then run the info helper to confirm the environment. Note the Python requirement in pyproject.toml, which is 3.12 or newer.

pip install lerobot
lerobot-info

The README points to the installation documentation for the detailed guide, and that is where hardware-specific extras live. The info command is the cheap sanity check: it tells you what got installed before you spend time on a dataset.

Training is a single command with the policy type and the dataset repository id as arguments. The README's example uses ACT on the aloha_mobile_cabinet dataset hosted on the Hub.

lerobot-train \
  --policy.type=act \
  --dataset.repo_id=lerobot/aloha_mobile_cabinet

What you should see is a training run against that dataset, with checkpoints and logs produced by the training script. The Makefile shows the same command in a smaller, CPU-friendly form used for end-to-end tests, which is a useful reference if you want to confirm the pipeline works before committing a GPU.

lerobot-train \
  --policy.type=act \
  --policy.dim_model=64 \
  --policy.n_action_steps=20 \
  --policy.chunk_size=20 \
  --policy.device=cpu \
  --policy.push_to_hub=false \
  --env.type=aloha \
  --env.episode_length=5 \
  --dataset.repo_id=lerobot/aloha_sim_transfer_cube

Loading data outside a training run is equally direct. The README loads a dataset from the Hub by repository id and indexes it; video decoding is handled for you.

from lerobot.datasets.lerobot_dataset import LeRobotDataset

dataset = LeRobotDataset("lerobot/aloha_mobile_cabinet")

episode_index = 0
print(f"{dataset[episode_index]['action'].shape=}\n")

One caveat on the naming: the README's Robot example imports from lerobot.robots.myrobot, which is a placeholder for whichever robot module you are using, not a module that ships with the package. Substitute the module for your device.

Where LeRobot is the wrong tool

The README does not document a rollback path for a policy that misbehaves on hardware, and it does not describe a safety layer between select_action and send_action. That gap matters because the library is explicitly about real-world robotics. A policy that produces a bad action chunk on a physical arm has no described guard in this stack; whatever limits exist have to come from the robot side or from your own code around send_action. Anyone whose application needs a formal safety envelope should treat that as out of scope here.

The second boundary is simulation. The test targets in the Makefile include aloha environments, so simulation appears in the test path, but the README's framing is real-world robotics and the supported hardware list is physical devices. Teams whose workflow is built on a simulator as the primary environment are not the audience this README addresses.

Third, hardware support is a fixed list, not a general abstraction. The Robot interface makes adding a device possible, but until someone writes that module, the data collection and training tools are only as useful as the adapter you supply. Budget for that work if your arm is not on the list.

LeRobot against ROS 2

The comparison people reach for is ROS 2, and the difference is in what each one is for. ROS 2 is a middleware and communications layer: nodes, topics, message passing, and a large ecosystem of drivers and packages built around that transport. LeRobot is a learning stack. It defines a Robot interface, a dataset format and a set of policies, and its unit of work is an episode recorded for training, not a message on a topic.

In practice that means LeRobot does not give you the distributed process model, the driver ecosystem or the long-term interface stability that ROS 2 users expect. What it gives you instead is a path from recorded demonstrations to a trained policy in one command, plus a dataset format designed for storage and streaming on the Hub. A team already running ROS 2 on a robot would be adding LeRobot alongside it for the learning half, not replacing the transport. The README does not describe a ROS bridge, so that integration is something you would build.

Maintenance cadence, versioning and licence

The repository is not archived, and the last push was on 2026-09-20. The release history is regular: v0.5.1 on 2026-04-07, v0.6.0 on 2026-07-06, v0.6.1 on 2026-08-03. That is a roughly monthly cadence over the recent stretch, which is fast enough that pinning a version is worth doing for anything you intend to keep running.

There is a versioning wrinkle to plan for. The newest tagged release is v0.6.1, while pyproject.toml in the repository declares version 0.6.2. If you install from PyPI and read the version from the source tree, expect them to disagree at times. The package also requires Python 3.12 or newer, so an environment pinned to 3.11 will not work regardless of what the README's two-line quick start suggests.

On licensing: the project is Apache-2.0, and pyproject.toml carries the same identifier. That is a permissive licence with an explicit patent grant, which is generally the easy case for commercial use, but the policy implementations in the library are ports and integrations of models that may carry their own terms. Check the licence of each specific policy and each pretrained checkpoint you pull from the Hub separately. This is not legal advice.

Editorial conclusion

Adopt LeRobot if you have a supported arm or teleoperation device and want one pipeline from recording episodes to training a policy, and if you accept that the project moves fast: pyproject.toml already declares version 0.6.2 while the newest tagged release is v0.6.1. Do not adopt it as a ROS replacement or as a simulator-first stack; the README documents no rollback procedure, no safety layer and no simulation workflow. Before committing, check the hardware documentation for your exact device, confirm your Python is 3.12 or newer, and run lerobot-info after installing to see what the environment actually resolved to.

Frequently asked questions

Official sources

1. huggingface/lerobot on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases