Every docstring change for the API reference, on top of the infrastructure PR which contains none. Two halves: a repo-wide pass over what the renderer cannot handle, and `src/lerobot/robots/` taken to 100% as the worked example. **Renderer fixes, repo-wide.** Both of these render incorrectly the moment `[[autodoc]]` is on, and both were verified against a local build: - 24 Sphinx roles across three files. They are unsupported and render as literal `:pymeth:` text. Method references become doc-builder cross-references; the ones pointing at instance attributes become inline code, since attributes get no autodoc anchor and a cross-reference would be a dead link. - 43 `Attributes:` sections across 27 files. doc-builder parses a bare `Attributes:` as a synonym for `Parameters:` — `Robot`'s attributes rendered inside `<paramsdesc>`, presenting `config_class` and `name` to readers as constructor arguments when the actual parameter is `config`. Where the original carried no type, the type comes from the real class annotation rather than being invented. The four base classes every other module inherits from — `robot.py`, `teleoperator.py`, `motors_bus.py`, `camera.py` — are rewritten to the standard, since subclasses document only their deviations from that text. Three docstring errors corrected in passing: `Teleoperator.get_action` pointed at `observation_features`, which `Teleoperator` does not have; `send_feedback` documented a `Returns:` for a method returning `None`; and `config_class` was typed `RobotConfig` instead of `type[TeleoperatorConfig]`. **`robots/`, 109/306 -> 306/306.** The configuration dataclasses were the substantial part. Their fields were documented only with `#` comments above each field, which doc-builder cannot see: before this, `SO101FollowerConfig` rendered all eleven of its fields with not one description. Each config now carries an `Args:` block on the concrete registered class, covering inherited fields too, because doc-builder renders only a class's own docstring and several of these configs are thin multiple-inheritance shims whose body is `pass`. The inline comments are kept rather than removed, so fields stay annotated in the source as well as on the rendered page. Note this leaves each field described twice, and only the `Args:` block is checked against the signature by `make check-docstrings`, so the two can drift. Writing them turned up things worth stating plainly on the page rather than leaving in a comment: which configs have no serial port at all because they talk over a network or the cloud (Reachy 2, Unitree G1, LeKiwi's client, EarthRover), which manage their own calibration so `calibration_dir` does nothing, that OpenArm's default joint limits are deliberately tiny until `side` is set, and that reBot's `port` means a different thing depending on `can_adapter`. Two pre-existing docstring bugs that the doctest infrastructure surfaced are fixed here: `SerialMotorsBus` used `>>>` inside a ```bash block to show CLI output, which doctest read as Python and failed on with a SyntaxError, and `MotorsBus.torque_disabled`'s example referenced an undefined name. `ensure_safe_goal_position` gains a genuinely executing example so the doctest gate is not vacuous. **Gates ratcheted**, each of which the infrastructure PR left deliberately loose: - `check_docstrings.py`'s ignore list emptied — the ten objects it held all had bare `Attributes:` sections, now converted. - `check_config_docstrings.py`'s ignore list emptied — every registered robot config documents its port and calibration semantics. - `robots/` removed from the ruff `D` per-file-ignores, as are the two package-root files, whose one-line docstring issues are fixed here. D100 and D104 are ignored globally instead: they ask for a banner on every file and every `__init__.py`, which appears on no rendered page. - `interrogate` raised 52 -> 55 against a measured 55.3%. - The four `robots/` files carrying examples added to the doctest allowlist, which shipped empty. Verified: all 66 changed files under `src/lerobot/` are provably docstring-only (AST with docstrings stripped is byte-identical to main), no comment line is removed anywhere in `robots/`, and 708 tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
LeRobot aims to provide models, datasets, and tools for real-world robotics in PyTorch. The goal is to lower the barrier to entry so that everyone can contribute to and benefit from shared datasets and pretrained models.
🤗 A hardware-agnostic, Python-native interface that standardizes control across diverse platforms, from low-cost arms (SO-100) to humanoids.
🤗 A standardized, scalable LeRobotDataset format (Parquet + MP4 or images) hosted on the Hugging Face Hub, enabling efficient storage, streaming and visualization of massive robotic datasets.
🤗 State-of-the-art policies that have been shown to transfer to the real-world ready for training and deployment.
🤗 Comprehensive support for the open-source ecosystem to democratize physical AI.
Quick Start
LeRobot can be installed directly from PyPI.
pip install lerobot
lerobot-info
Important
For detailed installation guide, please see the Installation Documentation.
Robots & Control
LeRobot provides a unified Robot class interface that decouples control logic from hardware specifics. It supports a wide range of robots and teleoperation devices.
from lerobot.robots.myrobot import MyRobot
# Connect to a robot
robot = MyRobot(config=...)
robot.connect()
# Read observation and send action
obs = robot.get_observation()
action = model.select_action(obs)
robot.send_action(action)
Supported Hardware: SO100, LeKiwi, Koch, HopeJR, OMX, EarthRover, Reachy2, Gamepads, Keyboards, Phones, OpenARM, Unitree G1, reBot B601.
While these devices are natively integrated into the LeRobot codebase, the library is designed to be extensible. You can easily implement the Robot interface to utilize LeRobot's data collection, training, and visualization tools for your own custom robot.
For detailed hardware setup guides, see the Hardware Documentation.
LeRobot Dataset
To solve the data fragmentation problem in robotics, we utilize the LeRobotDataset format.
- Structure: Synchronized MP4 videos (or images) for vision and Parquet files for state/action data.
- HF Hub Integration: Explore thousands of robotics datasets on the Hugging Face Hub.
- Tools: Seamlessly delete episodes, split by indices/fractions, add/remove features, and merge multiple datasets.
from lerobot.datasets.lerobot_dataset import LeRobotDataset
# Load a dataset from the Hub
dataset = LeRobotDataset("lerobot/aloha_mobile_cabinet")
# Access data (automatically handles video decoding)
episode_index=0
print(f"{dataset[episode_index]['action'].shape=}\n")
Learn more about it in the LeRobotDataset Documentation.
SoTA Models
LeRobot implements state-of-the-art policies in pure PyTorch, covering Imitation Learning, Reinforcement Learning, Vision-Language-Action (VLA) models, World Models, and Reward Models, with more coming soon. It also provides you with the tools to instrument and inspect your training process.
Training a policy is as simple as running a script configuration:
lerobot-train \
--policy.type=act \
--dataset.repo_id=lerobot/aloha_mobile_cabinet
| Category | Models |
|---|---|
| Imitation Learning | ACT, Diffusion, VQ-BeT, Multitask DiT Policy |
| Reinforcement Learning | HIL-SERL, TDMPC & QC-FQL (coming soon) |
| VLAs Models | Pi0, Pi0Fast, Pi0.5, GR00T N1.7, SmolVLA, XVLA, EO-1, MolmoAct2, WALL-OSS, EVO1 |
| World Models | VLA-JEPA, LingBot-VA, FastWAM |
| Reward Models | SARM, TOPReward, Robometer |
Similarly to the hardware, you can easily implement your own policy & leverage LeRobot's data collection, training, and visualization tools, and share your model to the HF Hub.
For detailed policy setup guides, see the Policy Documentation. For GPU/RAM requirements and expected training time per policy, see the Compute Hardware Guide.
Inference & Evaluation
Evaluate your policies in simulation or on real hardware using the unified evaluation script. LeRobot supports standard benchmarks like LIBERO, MetaWorld and more to come.
# Evaluate a policy on the LIBERO benchmark
lerobot-eval \
--policy.path=lerobot/pi0_libero_finetuned \
--env.type=libero \
--env.task=libero_object \
--eval.n_episodes=10
Learn how to implement your own simulation environment or benchmark and distribute it from the HF Hub by following the EnvHub Documentation.
Third-Party Hardware
Beyond the natively supported hardware, the community maintains a growing ecosystem of plugins for other robots, teleoperators, cameras, and sensors - UFACTORY xArm, Universal Robots UR5e, Franka, AgileX Piper, Trossen WidowX, ARX5, I2RT YAM, GELLO, SpaceMouse, Meta Quest, ROS 2 bridges, tactile and depth cameras, and more.
Plugins are auto-discovered by package name: LeRobot imports any installed package prefixed with lerobot_robot_, lerobot_teleoperator_, or lerobot_camera_. Install one and use the type it registers straight from the CLI:
pip install lerobot_robot_<name> lerobot_teleoperator_<name>
lerobot-record \
--robot.type=<robot_name> \
--teleop.type=<teleoperator_name> \
--dataset.repo_id=${HF_USER}/my-dataset
Browse the full list in the Third-Party Robots & Teleoperators and Third-Party Cameras & Sensors documentation.
Resources
- Documentation: The complete guide to tutorials & API.
- Chinese Tutorials: LeRobot+SO-ARM101中文教程-同济子豪兄 Detailed doc for assembling, teleoperate, dataset, train, deploy. Verified by Seed Studio and 5 global hackathon players.
- Discord: Join the
LeRobotserver to discuss with the community. - X: Follow us on X to stay up-to-date with the latest developments.
- Robot Learning Tutorial: A free, hands-on course to learn robot learning using LeRobot.
- T-Shirt Folding Experiment: An end-to-end demonstration of folding t-shirts with LeRobot.
- LeLab: A web interface for LeRobot — teleoperate, calibrate, record datasets, replay, and train your SO arm from the browser, no CLI required.
Citation
If you use LeRobot in your project, please cite the GitHub repository to acknowledge the ongoing development and contributors:
@misc{cadene2024lerobot,
author = {Cadene, Remi and Alibert, Simon and Soare, Alexander and Gallouedec, Quentin and Zouitine, Adil and Palma, Steven and Kooijmans, Pepijn and Aractingi, Michel and Shukor, Mustafa and Aubakirova, Dana and Russi, Martino and Capuano, Francesco and Pascal, Caroline and Choghari, Jade and Meftah, Khalil and Ellerbach, Maxime and Moss, Jess and Wolf, Thomas},
title = {LeRobot: State-of-the-art Machine Learning for Real-World Robotics in Pytorch},
howpublished = "\url{https://github.com/huggingface/lerobot}",
year = {2024}
}
If you are referencing our research or the academic paper, please also cite our ICLR publication:
ICLR 2026 Paper
@inproceedings{cadenelerobot,
title={LeRobot: An Open-Source Library for End-to-End Robot Learning},
author={Cadene, Remi and Alibert, Simon and Capuano, Francesco and Aractingi, Michel and Zouitine, Adil and Kooijmans, Pepijn and Choghari, Jade and Russi, Martino and Pascal, Caroline and Palma, Steven and Shukor, Mustafa and Moss, Jess and Soare, Alexander and Aubakirova, Dana and Lhoest, Quentin and Gallou\'edec, Quentin and Wolf, Thomas},
booktitle={The Fourteenth International Conference on Learning Representations},
year={2026},
url={https://arxiv.org/abs/2602.22818}
}
Contribute
We welcome contributions from everyone in the community! To get started, please read our CONTRIBUTING.md guide. Whether you're adding a new feature, improving documentation, or fixing a bug, your help and feedback are invaluable. We're incredibly excited about the future of open-source robotics and can't wait to work with you on what's next—thank you for your support!


