Living dossier

Open-Source Robotics

Back to topics•Blog
Mehran Mozaffari·
10 resources0 related posts

Open-source robotics won the software war while the hardware price quietly collapsed

The field, honestly defined, is the set of projects where a single person with a consumer GPU, a 3D printer, and a few hundred dollars of servos can reproduce a result that five years ago required a lab, a six-figure manipulator, and a custom codebase. That definition excludes a lot that gets filed under it. Humanoid companies with open code but closed bills of materials are not this field. Robotics frameworks that are open source but assume an integrator budget are adjacent. And university repos that publish a paper PDF and a requirements.txt with no documentation are the field's chronic failure mode, not its substance.

The substance is a stack that now closes end to end in the open. Hugging Face's LeRobot (Apache-2.0, 27,100 stars, installable with pip install lerobot) supplies the data format, the training code, and the hardware interface. TheRobotStudio's SO-100/SO-101 arms supply physical hardware with STL and STEP files in the repository and a community around a shared Discord. Physical Intelligence's openpi and NVIDIA's Isaac GR00T supply foundation-model weights with published fine-tuning recipes. Open X-Embodiment supplies the shared data commons. MuJoCo and ROS 2 plus MoveIt supply simulation and the classical motion stack. Each piece is genuinely fetchable, licensed, and documented — which is why 2026 is the first year "open-source robotics" describes a workflow rather than an aspiration.

What still does not fit, and why the distinction matters: commercial platforms with open SDKs (Reachy 2 is integrated into LeRobot, but the robot itself is a purchase), and safety-critical industrial deployments where certification, not reproducibility, is the binding constraint. A builder who understands which side of that line a project sits on avoids the two most expensive mistakes in the field: treating a research artifact as a product, and paying integrator prices for something a hacker ecosystem already solved.

LeRobot turned robot learning into a pip install and a Parquet file

The single most consequential artifact in the field is not a robot; it is the LeRobotDataset format and the tooling around it. Before it, every lab's robot data lived in a bespoke format that died with the grant. LeRobot standardized it: synchronized MP4 video (or images) for vision, Parquet for state and action streams, hosted on the Hugging Face Hub where thousands of datasets are already public, streamable, and visualizable. The repository documents tools to delete episodes, split by index or fraction, merge datasets, and load any of them with one constructor call — LeRobotDataset("lerobot/aloha_mobile_cabinet") handles video decoding for you.

The same standardization runs through the hardware layer. A unified Robot class decouples control logic from vendor specifics — connect(), get_observation(), send_action() — with native support for SO100, LeKiwi, Koch, HopeJR, OMX, EarthRover, Reachy 2, OpenARM, Unitree G1, and reBot B601, plus teleoperation devices as mundane as gamepads, keyboards, and phones. Third-party hardware (UFACTORY xArm, UR5e, Franka, AgileX Piper, Trossen WidowX, ARX5, I2RT YAM, GELLO, SpaceMouse, Meta Quest, ROS 2 bridges) arrives through a plugin convention: any installed package prefixed lerobot_robot_, lerobot_teleoperator_, or lerobot_camera_ is auto-discovered and usable from the CLI. That plugin contract is how an ecosystem grows without the core team bottling it.

The policy layer covers the field's whole algorithmic spectrum in one table: imitation (ACT, Diffusion, VQ-BeT, Multitask DiT), reinforcement learning (HIL-SERL, TDMPC, QC-FQL), vision-language-action models (Pi0, Pi0-FAST, Pi0.5, GR00T N1.7, SmolVLA, XVLA, EO-1, MolmoAct2, WALL-OSS, EVO1), world models (VLA-JEPA, LingBot-VA, FastWAM), and reward models (SARM, TOPReward, Robometer). Training is one command with a config flag (lerobot-train --policy.type=act --dataset.repo_id=...), evaluation runs against LIBERO and MetaWorld through a unified script, and a published compute-hardware guide states GPU and RAM needs per policy instead of leaving you to find out after the OOM.

My position: LeRobot is the field's center of gravity and the correct default choice for anyone learning-first. The ICLR 2026 paper gives the work academic standing, and the 27k-star, 5.5k-fork repository with an active Discord is the healthiest community in open robotics. Its weakness is the inverse of its strength — it standardizes the ML workflow so well that people mistake it for a robotics framework. It has no story for certification, industrial fieldbuses, or safety-rated motion. That is what the next section is for.

ROS 2 and MoveIt still own everything that must not learn on the job

The classical stack did not die; it specialized. ROS 2 (6,000 stars on the meta-repository, Apache-2.0, supported by the non-profit Open Source Robotics Foundation) remains the middleware where drivers, deterministic control loops, and multi-vendor integration live. Its release discipline is documented in REP-2000, its packages are on a buildfarm, its Docker images are official, and its community infrastructure (Discussion Forum, Zulip, Robotics Stack Exchange as the preferred support venue, the yearly ROSCon conference) is the most mature in the field. It even has a science citation. Nobody building a robot that must operate near humans should hand-wave this layer away in favor of a Python policy loop.

MoveIt 2 is the manipulation layer on top, BSD-3-Clause licensed, led commercially and technically by PickNik. The repository ships an entire planner zoo behind one interface — OMPL for sampling-based planning, CHOMP and STOMP for optimization-based planning, the Pilz industrial motion planner for deterministic ISO-style moves, plus moveit_servo for real-time reactive control and the MoveIt Setup Assistant for configuration. The branch policy is the honest part: main is distro-portable development, while humble/jazzy/kilted branches accept only bug fixes and bloom to the buildfarm — the release hygiene that makes it deployable. There is also the split to know about: MoveIt Pro is PickNik's commercially supported product, sitting on the open core the same way supported Linux distros sit on upstream.

Position, stated without charity: if your robot has a safety boundary, a real-time controller, or an integration partner, the ROS 2 plus MoveIt layer is not optional and the licences (Apache-2.0, BSD-3) are unambiguous. But it is the wrong backbone for learning-first projects — the data you collect in ROS bags does not flow into training pipelines without conversion, which is exactly the fragmentation LeRobotDataset was built to end. The pragmatic stack uses both: ROS 2 as the nervous system, LeRobot as the learning layer, with community ROS 2 bridges already in LeRobot's plugin list.

flowchart TD
    T[Teleoperate: leader arm or gamepad<br/>through lerobot-record] --> D[LeRobotDataset<br/>Parquet states plus MP4 video on the Hub]
    D --> TR[lerobot-train<br/>ACT or Diffusion or Pi0 or GR00T]
    S[Simulation branch<br/>MuJoCo and MJX rollouts] --> TR
    TR --> EV[lerobot-eval<br/>LIBERO and MetaWorld]
    EV -->|passes| DEP[Deploy: policy runs on the follower arm]
    EV -->|fails| D
    DEP --> ROS[ROS 2 plus MoveIt layer<br/>safety and classical planning around it]

The stack on one page, licences and cost shapes included

Project Role in the stack Licence Real cost shape Watch for
LeRobot Learning layer: dataset format, training, hardware interface Apache-2.0 Free software; GPU cost per policy, documented in its compute guide No safety or certification story
ROS 2 Middleware: drivers, deterministic control, integration Apache-2.0 Free; the cost is engineer time on DDS and release hygiene Distro discipline per REP-2000
MoveIt 2 Manipulation planning (OMPL, CHOMP, STOMP, Pilz, servo) BSD-3-Clause Free core; MoveIt Pro is the paid support lane Planner configuration is a skill
MuJoCo with MJX Physics simulation and parallel rollouts Apache-2.0 Free; GPU watts for accelerator-scale rollouts Contact model is not your hardware
SO-100 / SO-101 Reference arms for imitation learning Open STL and STEP files in the repo Servos plus filament; two arms for the full loop Backlash, drift, recalibration
openpi (π0 family) Open VLA base and expert checkpoints Apache-2.0 code; Gemma terms on weights Over 8 GB GPU for inference, over 22.5 GB LoRA, over 70 GB full fine-tune Ubuntu 22.04 only
Isaac GR00T N1.7 NVIDIA's generalist foundation model Repository public; weight terms to verify NVIDIA-stack gravity, Docker-first Read the weight licence before commercial use
Open X-Embodiment Cross-embodiment data commons, RT-X models Apache-2.0 code, CC-BY materials Download bandwidth and TFDS storage RLDS workflow predates LeRobotDataset

Read the licence column as the actual gate. Three Apache-2.0 or BSD tools and one open-hardware design mean an individual can build the entire pipeline without a licence conversation. The moment foundation-model weights enter the stack, the conversation starts: Gemma-lineage terms in openpi's case, unverified terms in GR00T's. And the cost column is the honest summary of the field: software free, data free, hardware a few hundred dollars, and the GPU line item the only place where this hobby can silently become a data-center bill.

Two foundation-model families now define the ceiling, and the licences differ in kind

Physical Intelligence's openpi (13,600 stars) publishes the strongest open weights in manipulation: π0, a flow-based vision-language-action model; π0-FAST, the autoregressive variant built on the FAST action tokenizer; and π0.5, the knowledge-insulation upgrade with better open-world generalization. The base checkpoints are pre-trained on more than 10,000 hours of robot data, and the fine-tuned "expert" checkpoints demonstrate what that buys: π0-FAST-DROID does simple tabletop manipulation zero-shot in new scenes, π0-ALOHA-towel folds diverse towels zero-shot, π0.5-LIBERO claims state of the art on the benchmark. The honesty is notable — the README says plainly that π0 was developed for Physical Intelligence's own robots, that adapting it to ALOHA or DROID-class platforms is an experiment, and that it "may or may not work for you."

NVIDIA's Isaac GR00T N1.7 is the corporate counterweight: a foundation model for generalist robots with 8,000 stars, a Docker-based getting-started path, and first-class integration inside LeRobot's policy table. The two families are converging on the same interface — both train from LeRobot-format data — which means the data you collect is portable across them.

The GPU bill is the part that gets left out, and openpi states it in a table: inference needs more than 8 GB (RTX 4090 class), LoRA fine-tuning more than 22.5 GB, full fine-tuning more than 70 GB — an A100-80GB or H100. The stack is Ubuntu 22.04 only, training is JAX with PyTorch support added in September 2025, and the recommended deployment splits robot and model: the policy server runs on a beefy machine and streams actions to the robot over a websocket. Foundation-model robotics is currently a two-computer hobby. LeRobot's own published compute guide makes the same cost ladder concrete per policy, and it is the honest planning tool for the rest of the field. Light behavior-cloning policies (ACT, VQ-BeT, TDMPC) train in roughly 2–6 GB of VRAM; diffusion-class policies need 8–14 GB; SmolVLA fits in 10–16 GB; the large VLA group (π0, π0-FAST, π0.5, XVLA) wants 24–40 GB on an A100-40GB or better, and the multimodal group (GR00T, EO-1) sits in the same envelope. Wall-clock anchors for a typical 50-episode dataset at 5 epochs: ACT on a single RTX 4090 finishes in about 30–60 minutes; diffusion takes 2–4 hours; π0.5 on an A100-40GB runs 4–8 hours, and a four-H100 cluster brings it to under four. Two operational details from that guide are worth more than the tables: AdamW optimizer state adds 30–100 percent over the forward-backward pass alone, and when the dataloading time approaches the update time, adding GPUs stops helping — fix the data path first. For people without GPUs at all, the same guide documents managed training through Hugging Face Jobs, billed by the second, with flavors from a T4 up to A100s submitted straight from lerobot-train. The fine-tuning cost of this field is therefore a published, priceable quantity — which is more than can be said for most robotics research code.

The licence difference decides adoption more than the FLOPS do. LeRobot is Apache-2.0 without asterisks. Open X-Embodiment splits cleanly: all software Apache-2.0, all other materials CC-BY. Openpi's repository ships both an Apache licence and a separate Gemma licence file — the π models build on a Gemma-class vision backbone, so the weights, unlike the code, carry that lineage's terms; read both before shipping anything commercial. GR00T's repository page shows no unqualified open-source licence badge at all — treat the weights as licence-gated until you have read NVIDIA's terms. The pattern generalizes across the field: the tools are open, the biggest model weights are open with conditions, and "open source robotics" is not a single licence. The Gemma terms themselves deserve a close read, because they are what "the weights carry Gemma conditions" actually means. The definitions capture not just Gemma and its modifications but Model Derivatives — including any model created by transferring weight patterns, including distillation methods and models trained on Gemma outputs' synthetic data — so fine-tuning π0 does not launder the licence. Distribution has pass-through obligations: downstream recipients must receive the same use restrictions, a copy of the agreement, and a Notice file naming the Gemma Terms of Use. The restrictions incorporate Google's Prohibited Use Policy by reference, and two clauses have no Apache-2.0 equivalent at all: Google reserves the right to restrict usage it believes violates the terms, and on termination you must delete every copy of the model and derivatives in your control. Outputs remain yours; the weights never fully are. Against that baseline, Apache-2.0 and BSD-3 projects are not merely cheaper — they are a different legal species, and any team planning a product on open robotics weights should budget a licence read before the first GPU hour.

The $-scale hardware bet: SO-101 and what a printed arm actually buys

TheRobotStudio's SO-ARM100 repository (7,300 stars) is the hardware catalyst. The SO-100, designed with the LeRobot team, has been superseded by the SO-101 — improved wiring, easier assembly with no gear removal, updated motors for the leader arm — and the SO-100 documentation is formally deprecated. Leader and follower arms ship as STL and STEP files; you print the parts, buy the serial bus servos, and wire them into LeRobot's teleoperation and recording loop, or buy a kit from the linked vendors. The repository carries a citation file, which tells you the design is meant to be a citable artifact, not a weekend fork.

Position: this is unambiguously the right first robot for imitation learning — the entire toolchain from teleoperate to trained policy assumes it, the community debugs it in public, and two arms (one leader to teleoperate, one follower to act) is the complete bill of materials for a dataset. The honest limits: a printed 3D-printed arm with hobby servos has backlash, flex, and thermal drift that no software fixes; calibration is a recurring chore rather than a one-time step; and every policy you train inherits the noise floor of the cheapest component. Teams doing precision work graduate to industrial arms through exactly the third-party plugin list LeRobot maintains — but they keep the SO arms as the data-collection and prototyping bench, because the iteration loop matters more than the payload.

Simulation is where Apache licences beat hardware reality

MuJoCo (14,851 stars, Apache-2.0, maintained by Google DeepMind) is the physics engine under most of modern robot learning: a C core tuned for articulated bodies in contact, a Python binding installable from PyPI, monthly releases, and MJX — a JAX rewrite that runs rollouts on accelerators for massively parallel training and differentiable physics. The converter ecosystem matters as much as the engine: onshape-to-robot turns CAD assemblies into MJCF models, gz-mujoco converts two ways between SDFormat and MJCF, and OpenUSD export bridges to graphics pipelines. A designer can go from a CAD tab to a simulated, policy-trainable model without touching proprietary software anywhere in the path.

Position: for policy training, MuJoCo is the default and MJX is the reason parallel-rollout experiments got cheap; for photorealistic perception research, other simulators exist, but for contact-rich manipulation the field has effectively standardized here. The classical stack keeps its own simulators for integration testing, and the converter tools are the bridge between those worlds. The failure mode to plan for is not the licence (Apache-2.0, unambiguous) but the gap itself: policies that look brilliant in MJCF rollouts meet printed-arm backlash and servo lag on hardware, which is why the SO-101's role as a cheap reality-check bench matters — catching the sim-to-real gap early costs one printed iteration, not one industrial arm.

The data commons and the lesson it taught twice

Open X-Embodiment is the field's attempt at a shared data commons: robot datasets from many labs converted into one RLDS episode format, plus the RT-X models (RT-1-X checkpoints in both TensorFlow and JAX) trained across them. The repository (2,014 stars) is Apache-2.0 for code and CC-BY for the rest, with the observation and action spaces documented precisely — a 3 Hz control loop, seven action dimensions from end-effector pose to gripper opening.

The honest assessment is that the commons succeeded as a proof and aged as a workflow. The RLDS/TFDS/gsutil path reflects the TensorFlow era; LeRobotDataset with Parquet and streamable MP4 on the Hub is the format new projects actually adopt, and even openpi's fine-tuning pipeline starts with "convert your data to a LeRobot dataset." The lesson the field has now taught itself twice — once with bespoke lab formats, once with a unified-but-heavyweight research format — is that robot data only compounds when the format is boring, streamable, and attached to a hub with visualization. Position: cite Open X-Embodiment for the cross-embodiment result it proved, but build new collection on LeRobotDataset.

sequenceDiagram
    participant L as Leader arm
    participant F as Follower arm
    participant R as lerobot-record
    participant H as Hub dataset
    participant S as Policy server
    L->>F: operator moves leader joints
    F->>R: follower states and camera frames
    R->>H: episodes as Parquet plus MP4
    S->>H: loads dataset for fine-tuning
    Note over L,H: same leader motion produces the supervised action label
    loop control at policy rate
        F->>R: latest observation
        R->>S: websocket observation payload
        S->>R: action chunk
        R->>F: joint targets
    end
    Note over F,S: openpi remote-inference pattern keeps the GPU off the robot

What changed in the last twelve months, dated

Three shifts altered real plans. September 2025: openpi released PyTorch support and π0.5 — the second one matters because open-world generalization, not benchmark tricks, is what makes a foundation model worth fine-tuning; the same month added an improved idle filter for DROID training. The SO-101 superseded the SO-100 across the ecosystem, with LeRobot, vendors, and tutorials all moving to the new arm; anyone buying hardware today should buy 101s and expect deprecated docs if they follow 100 links. And LeRobot's policy table grew from a handful of imitation methods to a categorized index spanning VLAs, world models, and reward models, with a plugin discovery convention that pulls the third-party hardware ecosystem in without core-team review. The ICLR 2026 acceptance of the LeRobot paper is the academic ratification of what the star count already said.

Where it breaks

The calibration treadmill. Trigger: any SO-101-based pipeline longer than one session. Hobby servos drift with temperature and load; a policy trained on Monday's calibration degrades by Thursday. Budget recalibration as a recurring operating cost, not a setup step.

The sim-to-real cliff on printed arms. Trigger: policies trained purely in MuJoCo rollouts, deployed to a printed arm. Backlash, flex, and motor latency are not in the MJCF model. The mitigation the field actually uses: collect a small real-robot dataset early with the same arms, and fine-tune rather than transfer blind.

The GPU bill at fine-tuning time. Trigger: openpi full fine-tuning. Above 70 GB of GPU memory, the hobbyist path ends — LoRA on a 24 GB card is the realistic ceiling for individuals, and anything larger rents data-center hardware. Plan the experiment budget around the 22.5 GB line, not the 8 GB inference line.

Ubuntu-only research stacks. Trigger: openpi states Ubuntu 22.04 support only. macOS or Windows machines are fine as editors and clients, not as training hosts; the policy-server-over-websocket pattern exists precisely so the robot can be anywhere while the GPU machine runs Linux.

Format gravity. Trigger: datasets collected in ROS bags, proprietary vendor formats, or RLDS when the target pipeline expects LeRobotDataset. Every conversion is a place where timestamps desynchronize and videos transcode; minimize format crossings by recording into the target format from the start.

Deprecated-hardware documentation rot. Trigger: following SO-100 guides after the SO-101 transition. The old docs are explicitly deprecated; assembly steps and motor configs differ, and community help has moved to the new arm.

Licence assumptions at shipping time. Trigger: building a product on openpi or GR00T weights. The code licences (Apache) do not automatically cover the weights' lineage (Gemma terms in openpi's case; GR00T's terms to verify). Sort this before the business depends on it.

Open questions

Whether foundation-model fine-tuning collapses to consumer GPUs the way LLM inference did — LoRA cost curves are falling, but the 70 GB full-fine-tune line has not moved. Whether GR00T's weights become genuinely open or stay strategically gated, which decides whether NVIDIA's stack is a commons or a funnel. Whether the SO-101 ecosystem can produce a successor with encoded absolute positions or better bearings before backlash fatigue caps dataset quality. And whether LeRobotDataset's Parquet-plus-video design survives contact with 10 kHz force-torque and tactile data, where streaming video assumptions stop holding. The field's center of gravity moved to the data layer faster than anyone predicted; where it goes next depends on whether open datasets keep compounding or fragment back into lab silos.

Resources

Core libraries and models:

Hardware and the classical stack:

Simulation: