ROS 2 and LeRobot Side by Side: What Each Stack Is For

If you already run a robot on ROS 2, the first question about imitation learning is rarely "which model". It is "do I have to throw away my node graph". The answer is no. ROS 2 and the LeRobot stack solve different problems and touch each other along a narrow seam: joint states and camera frames in, joint commands out, at a fixed rate.

This describes ROS 2 Lyrical Luth, the LTS released 22 May 2026, and LeRobot 0.6.x (0.6.1 on PyPI from 3 August 2026, 0.6.2 on main). Both move fast, so every version and default below is dated on purpose. Platform numbers come from the policy catalog and the pricing page.

What each stack is actually for

Both projects use the word "robot". ROS 2 means a system of processes that has to keep running for years. LeRobot means an object that can be asked for an observation and handed an action.

ROS 2: a distributed system for a whole robot

ROS 2 is a communication layer plus a package ecosystem. Nodes are separate processes that find each other through distributed discovery with no central master, and exchange data over topics for continuous streams, services for request and response, and actions for long-running goals with feedback. The ROS on DDS article gives the reason for that choice: DDS already had distributed discovery and per-connection Quality of Service.

• ros2_control: the real-time loop. controller_manager reads hardware state, updates controllers and writes commands at an update_rate that defaults to 100 Hz and is declared read-only.
• Hardware components: System, Actuator and Sensor plugins exposing state and command interfaces. Your Feetech or Dynamixel driver lives here.
• MoveIt 2: collision-aware motion planning, IK and trajectory execution against a URDF.
• TF2: the transform tree, so "where is the gripper in the base frame" is a library call.
• rosbag2: record and replay every topic. MCAP has been the default storage plugin since Iron Irwini; Humble still defaulted to sqlite3.
• Tooling: ros2 topic hz, rqt, RViz, lifecycle nodes, launch files, parameter YAML.

LeRobot: a training pipeline that happens to touch hardware

LeRobot goes the other way. One Python package, Apache-2.0, Python 3.12 or newer, whose job is to get demonstrations off a real arm, into a dataset, through a training run, and back onto the arm as a policy. Everything is a console script. No message bus, no node graph, no discovery.

pip install lerobot

# the console scripts a manipulation workflow touches (pyproject.toml on main, 0.6.2)
lerobot-find-port          # which serial device is the arm
lerobot-setup-motors       # write servo IDs to EEPROM
lerobot-calibrate          # record range of motion per joint
lerobot-teleoperate        # leader drives follower, --fps default 60
lerobot-record             # write a LeRobotDataset while teleoperating
lerobot-train              # train a policy on that dataset
lerobot-eval               # evaluate a checkpoint
lerobot-rollout            # run a trained policy on hardware
lerobot-dataset-viz        # look at what you recorded

The structural fact that matters: LeRobot's unconditional install pulls torch, torchvision, numpy, opencv-python-headless, Pillow, einops, draccus, huggingface-hub, requests, gymnasium, safetensors and five build helpers. That is the whole list. No rclpy, no DDS, no colcon, and no ROS package in any optional extra either. It is a pip package that talks to a serial port.

Side by side

Read the last row twice. Most arguments about ROS 2 versus LeRobot are arguments about which job you are doing this week. A navigation stack, a safety controller and a fleet API mean ROS 2 is not optional. Fifty episodes of a gripper picking up a cube to fine-tune a vision-language-action model means ROS 2 is a lot of scaffolding around a serial port.

The overlap is one small interface

Bridging works because LeRobot asks very little of hardware. The base class in src/lerobot/robots/robot.py declares ten abstract members, and in a bridge only three carry traffic. The two feature properties are the entire schema negotiation, and their docstrings insist both stay callable whether or not the robot is connected.

# src/lerobot/robots/robot.py on main, abridged: docstrings removed
class Robot(abc.ABC):
    config_class: builtins.type[RobotConfig]
    name: str

    # schema, readable before connect()
    @property
    @abc.abstractmethod
    def observation_features(self) -> dict: ...   # {"shoulder.pos": float, "cam": (h, w, 3)}

    @property
    @abc.abstractmethod
    def action_features(self) -> dict: ...        # {"shoulder.pos": float, ...}

    # lifecycle
    @property
    @abc.abstractmethod
    def is_connected(self) -> bool: ...

    @abc.abstractmethod
    def connect(self, calibrate: bool = True) -> None: ...

    @property
    @abc.abstractmethod
    def is_calibrated(self) -> bool: ...

    @abc.abstractmethod
    def calibrate(self) -> None: ...

    @abc.abstractmethod
    def configure(self) -> None: ...

    @abc.abstractmethod
    def disconnect(self) -> None: ...

    # the loop
    @abc.abstractmethod
    def get_observation(self) -> RobotObservation: ...

    @abc.abstractmethod
    def send_action(self, action: RobotAction) -> RobotAction: ...

A ROS 2 bridge fills these in the obvious way. get_observation() returns the latest message from each subscribed topic, named; send_action() publishes to the command topics; connect() brings up the node and waits for a first value on every stream. Once that class exists, every LeRobot tool works unchanged, including dataset recording and fine-tuning.

The bridges that exist today

LeRobot's Third-Party Robots and Teleoperators page carries a "ROS 2 Bridges" heading, and as of August 2026 it lists exactly two entries. Two more projects do the same job at a different scope, and one is a complete arm stack rather than a plugin.

Three ways to connect the two

Path A: make the ROS 2 robot look like a LeRobot robot

The cleanest option when your ROS 2 side is already healthy. Map topics to features, install the plugin, and every LeRobot command works against the real arm. Here is the Rosetta contract format, quoted from its README.

robot_type: my_robot
robot_interface: ros2
fps: 30

observations:
  observation.state:
    channel: {topic: /joint_states, type: sensor_msgs/msg/JointState}
    align: {strategy: hold, timeline: header}
    select: [position.j1, position.j2]

  observation.images.cam:
    channel: {topic: /camera/image_raw/compressed,
              type: sensor_msgs/msg/CompressedImage}
    align: {strategy: hold, timeline: header}
    apply: [resize: [480, 640]]

actions:
  action:
    channel: {topic: /cmd, type: sensor_msgs/msg/JointState}
    align: {strategy: hold, timeline: header}
    select: [position.j1, position.j2]

# with lerobot_robot_rosetta installed, LeRobot sees --robot.type=rosetta
lerobot-record --robot.type=rosetta --robot.config_path=contract.yaml
lerobot-teleoperate --robot.type=rosetta --robot.config_path=contract.yaml

Two details from that plugin's README save a midnight debugging session. It hosts a ROS 2 lifecycle node itself, so ROS 2 must be installed on the machine running the LeRobot CLI even though the command looks like plain Python. And while connected a watchdog applies the contract's per-channel safety behaviour, zeros, hold or none, whenever no action arrives for two frame periods.

Path B: record rosbags, then convert offline

Path A puts the recording loop inside Python, and that costs something. The LeROS2 README is blunt: driving the follower from the LeRobot record loop "can introduce additional latency". Its recommendation is to wire leader-follower teleoperation natively in ROS 2, record a bag, and convert afterwards. Bags also keep native topic rates and full image resolution, so you can requantise later without re-recording.

# 1. record at native rates, MCAP by default since Iron
ros2 bag record -o episode_001 /joint_states /cmd \
    /wrist/color/image_raw/compressed /base/color/image_raw/compressed

# 2a. Rosetta: bags -> LeRobotDataset, using the same contract
rosetta_port \
    --raw-dir ./datasets/bags \
    --contract my_contract.yaml \
    --repo-id my-org/my-dataset \
    --root ./datasets/lerobot

# 2b. LeROS2: same job, quantised by fps or by a clock topic
leros2-convert \
    --config_path=./my-config.yaml \
    --dataset.repo_id=my-org/my-dataset \
    --dataset.fps=30 \
    --input_bag='./recordings/episodes/*/*.mcap'

Path C: run the policy as a ROS 2 node

Deployment is the mirror image. A ROS 2 node loads the checkpoint, subscribes to the observation topics and publishes actions. Both mature bridges expose it as an action server, so the policy is startable and cancellable like any other ROS 2 behaviour.

# terminal 1: load the checkpoint into a ROS 2 node
ros2 launch rosetta policy_runner_launch.py \
    contract_path:=my_contract.yaml \
    pretrained_name_or_path:=outputs/train/my_policy/checkpoints/last/pretrained_model

# terminal 2: send it a task
ros2 action send_goal /run_policy \
    rosetta_interfaces/action/RunPolicy "{prompt: 'pick up the red block'}"

• Rosetta: rosetta_interfaces/action/RunPolicy, goal field prompt. One contract, one checkpoint per launch.
• sacovo/lerobot_ros: lerobot_interfaces/action/RunPolicy, goal fields policy_name and task. Several policies live in one TOML file, and the available names are published on a latched policy_control/status topic.
• That second project refuses to actuate without a fresh policy_control/heartbeat from the operator, and clamps or rounds policy output per topic, which stops a continuous gripper prediction landing between the only two values your controller accepts.

End to end on an SO-100 class arm

On an SO-100 or SO-101 with a leader arm and two cameras, the whole path looks like this. The commands are the SO-101 ROS 2 stack's own; substitute your package and topic names.

1. 1
   Set up the servos with LeRobot first, not ROS

   Motor IDs and calibration live in servo EEPROM. The SO-101 stack is explicit: complete LeRobot motor setup and calibration for both arms before you teleoperate, plan or command them from ROS. The other order gives an arm that moves to the wrong angles for no visible reason.

   bash

   lerobot-find-port
   lerobot-setup-motors --robot.type=so101_follower --robot.port=/dev/ttyACM0
   lerobot-calibrate --robot.type=so101_follower --robot.port=/dev/ttyACM0 --robot.id=follower_1

2. 2
   Bring up the ROS 2 side and check the rates

   A ros2_control hardware component drives the servo bus, a controller publishes /joint_states, camera nodes publish compressed images. A camera that silently drops to 5 fps is the most common cause of a dataset that trains to a low loss and does nothing on hardware.

   bash

   ros2 launch so101_bringup teleop.launch.py
   ros2 topic hz /joint_states
   ros2 topic hz /wrist/color/image_raw/compressed

3. 3
   Record episodes as bags

   Teleoperate through ROS 2 and record each demonstration as its own bag. Aim past the platform minimum: 30 episodes for SmolVLA, 50 for ACT, GR00T N1.7, GR00T N1.5 and Pi0.5. Vary object placement or you train a confident single-position policy.

   bash

   ros2 launch so101_bringup recording_session.launch.py \
     experiment_name:=pick_and_place \
     task:="Pick up the cube and place it in the container." \
     use_rerun:=true
   
   # second terminal: r start, s save, d discard, q quit
   ros2 run episode_recorder teleop_episode_keyboard

4. 4
   Convert the bags to a LeRobotDataset

   Here the alignment strategy from the warning above gets applied. The SO-101 stack ships its own converter in a second Pixi environment and writes v3.0 directly; rosetta_port and leros2-convert are the generic alternatives. In v3.0 many episodes share Parquet and MP4 shards, with boundaries in meta/episodes/ rather than filenames.

   bash

   pixi run -e lerobot convert -- \
     --input-dir ~/.ros/so101_episodes/pick_and_place \
     --config    rosbag_to_lerobot/config/so101.yaml \
     --repo-id   local/so101_pick_place
   
   # look at it before you rent a GPU
   lerobot-dataset-viz --repo-id local/so101_pick_place --episode-index 0

5. 5
   Train

   Locally for ACT or SmolVLA on a 24 GB card, on rented hardware otherwise. Format version matters: the GR00T loader crashes on a v3.0 dataset and needs it converted down to v2.1 first.

   bash

   lerobot-train \
     --dataset.repo_id=local/so101_pick_place \
     --policy.type=act \
     --output_dir=outputs/train/so101_pick_place

6. 6
   Deploy back into the graph

   Either as a policy runner node, or through LeRobot's async inference pair, which decouples prediction from execution so the arm keeps running the current chunk while the next is computed. The client wraps a Robot instance, so it takes the same --robot.type your bridge registers.

   bash

   pip install "lerobot[async]"
   
   # on the GPU box
   python -m lerobot.async_inference.policy_server --host=127.0.0.1 --port=8080
   
   # on the robot
   python -m lerobot.async_inference.robot_client \
     --server_address=gpu-box:8080 \
     --robot.type=rosetta \
     --robot.config_path=contract.yaml \
     --task="pick up the cube" \
     --policy_type=act \
     --pretrained_name_or_path=my-org/so101-pick-place-act \
     --actions_per_chunk=50 \
     --chunk_size_threshold=0.5

Latency decides where the policy runs

Inference latency is not a benchmark number, it is a budget. Every action step costs the model time, and whatever you add on top comes out of the same budget.

ACT at 20 ms leaves room for a network hop. Pi0.5 at 485 ms does not: the model alone dominates a reactive loop, and a public-internet round trip on top turns a working policy into a hesitant one. Remote inference is viable for slow pick-and-place, not fast reactive motion. That is the argument for putting the policy node on the robot's own compute, and for action chunking: with async inference the arm executes the chunk it has while the next is computed, and chunk_size_threshold decides how early the client asks for it.

Doing it yourself versus doing it here

Where this platform does not help

The honest boundaries are more useful than the feature list.

• There is no ROS 2 bridge built into AY-Robots. If your robot lives on a ROS 2 graph you adopt one of the community bridges above; the platform meets you at the dataset.
• No motion planning, no collision checking, no navigation. Those stay in MoveIt 2 and Nav2.
• GR00T N1.7, GR00T N1.5 and Pi0.5 are cloud-only here. Only SmolVLA and ACT also run locally.
• GR00T's fine-tuning entry point is a tyro CLI that exposes no seed, so GR00T runs are not bit-for-bit reproducible. lerobot's default seed is 1000.
• The gradient accumulation field is real for GR00T N1.7 and N1.5 and inert for Pi0.5 and SmolVLA, because lerobot 0.5.1 had no such flag.

The pragmatic split: ROS 2 owns the robot, LeRobot owns the learning, the bridge is a YAML file, and this platform owns the GPU-shaped hole in the middle. The VLA overview explains why the policies behave as they do, the data collection guide covers what to record, and the SO-100 complete guide covers the hardware. If a run is already failing, the failure-mode index is faster.

Frequently asked questions