PhysicalAI LeRobot Plugin
Bridges LeRobot robot and teleoperator configs into PhysicalAI, the Python library and runtime for robot control, transport, and CLI workflows. It registers with Physical AI Studio, the application that discovers catalog plugins and provides robot setup, teleoperation, and workflow experiences. Part of the physicalai-plugins monorepo.
Overview
This plugin lets Studio users select supported LeRobot hardware from a schema-driven UI, auto-resolve serial devices, and run them through a PhysicalAI-compatible adapter without writing robot-specific glue code.
Each installed LeRobot follower robot and teleoperator is registered as a Studio catalog entry:
- follower type:
LeRobot_<follower_type>_Follower - leader type:
LeRobot_<teleoperator_type>_Leader
Screenshots
Placeholder images — replace them with real screenshots.
Installation
uv add physicalai-lerobot-plugin
Run with the PhysicalAI CLI
The PhysicalAI CLI run
subcommand executes a RobotRuntime from a YAML config. The bundled config
teleoperates a LeRobot follower with its matching leader teleoperator:
uv run physicalai run --config packages/physicalai-lerobot-plugin/examples/runtime/teleop.yaml
The example uses the so101_follower / so101_leader pair; set config_type
and config_kwargs to any of the bundled follower/leader types below. Press
Ctrl+C to stop.
Third-party LeRobot extensions
Install this package first, then install a LeRobot extension into the same
Python environment. On Studio startup, the catalog invokes LeRobot's native
third-party discovery and imports installed extension packages with names that
start with lerobot_robot_ or lerobot_teleoperator_.
For example, after installing a compatible LeSlider package, its registered
follower and leader types appear automatically in the Studio catalog. An
extension must import its config registration code from its package root and
use LeRobot's register_subclass(...) mechanism. Hardware SDK dependencies
remain the responsibility of the extension package.
Bundled LeRobot followers
bi_so_followerbi_rebot_b601_followerbi_openarm_followerso100_followerso101_followerkoch_followeromx_followerhope_jr_handhope_jr_armopenarm_followerrebot_b601_followerreachy2earthrover_mini_plusunitree_g1lekiwilekiwi_client
Bundled LeRobot leader teleoperators
so100_leader(forso100_follower)so101_leader(forso101_follower)koch_leader(forkoch_follower)omx_leader(foromx_follower)openarm_leader(foropenarm_follower)rebot_102_leader(forrebot_b601_follower)reachy2_teleoperator(forreachy2)
Payload models
How payload fields are built
Payload classes are generated dynamically from each LeRobot config dataclass.
- Fields are derived directly from the selected LeRobot config dataclass.
- Complex fields are supported recursively:
- nested dataclasses,
dict[...],list[...], tuples, optional/union types
- nested dataclasses,
- Required/default behavior:
- fields without dataclass defaults are required
- fields with defaults/factories are optional in payload
- Runtime endpoint resolution:
portfields are resolved at build time through the Studio factory when possible (including nested bimanual arm configs)- for configs with a serial
portfield, the schema is annotated with a Studio "Select robot" connection section bound to thatport; the payload model itself adds no extra Studio fields
Common payload fields
There is no fixed cross-robot payload contract anymore. Fields come from the selected LeRobot config type.
Payload examples
1) LeRobot_so100_follower_Follower
{
"port": "/dev/ttyACM0",
"disable_torque_on_disconnect": true,
"use_degrees": true,
"id": "so100-main"
}
2) LeRobot_hope_jr_hand_Follower
{
"port": "/dev/ttyACM1",
"side": "left",
"disable_torque_on_disconnect": true,
"id": "hope-left-hand"
}
3) LeRobot_bi_so_follower_Follower (nested bimanual config)
{
"left_arm_config": {
"port": "/dev/ttyACM0",
"disable_torque_on_disconnect": true
},
"right_arm_config": {
"port": "/dev/ttyACM1",
"disable_torque_on_disconnect": true
},
"id": "bi-so-main"
}
Notes
- Test-only robots are intentionally not registered by this plugin.
- Payload models are generated from LeRobot config dataclasses, so fields can differ by robot type.
Development
uv sync
uv run pytest
See docs/creating-a-studio-plugin.md for the full plugin development guide.
Metadata
Release files for physicalai-lerobot-plugin 0.3.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| physicalai_lerobot_plugin-0.3.1.tar.gz | 16.3 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| physicalai_lerobot_plugin-0.3.1-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 33.7 kB
Release files / physicalai_lerobot_plugin-0.3.1.tar.gz
| Download URL | physicalai_lerobot_plugin-0.3.1.tar.gz |
|---|---|
| Size | 16.3 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
252b8cf4160f7813f9c01ada7d959ed81bd5133af863d2d40c07d41e7f0c4e3c
|
|
BLAKE2b-256 checksum How to use checksums |
9c60a2c4166c2537755f9de41d2ef0b44dbcf055b76ad4bcc103b74c900a55d7
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 10, 2026.
Transparency logRelease files / physicalai_lerobot_plugin-0.3.1-py3-none-any.whl
| Download URL | physicalai_lerobot_plugin-0.3.1-py3-none-any.whl |
|---|---|
| Size | 17.4 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
1b955ec0d7161ad1f51d50263d6dee1d9e2f3b58b337e8f07b1890d37e0cc679
|
|
BLAKE2b-256 checksum How to use checksums |
e91fbea695802faf5c8cc8617b92604d129171573d250cfc6835ad17fdbc057d
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 10, 2026.
Transparency log