Introduction
Open source in robotics can mean very different things: code without weights, weights without training data, datasets without hardware interfaces or CAD without electronics. This guide therefore audits each layer separately. LeRobot, OpenVLA, Physical Intelligence openpi, Isaac Lab and MuJoCo are useful examples because they expose different combinations of reusable software, checkpoints, data interfaces and simulation tools under explicit licenses.
Key findings
- LeRobot currently identifies its framework as Apache-2.0 and provides dataset, training, evaluation and hardware tooling.
- OpenVLA publishes MIT-licensed software, while Physical Intelligence openpi publishes checkpoints and fine-tuning workflows with its own repository requirements.
- Code, model weights, datasets and hardware files can have different licenses and should be audited separately.
- Reproducibility requires a versioned environment, documented robot interface and enough compute to reproduce at least one baseline.
- Open source improves inspectability and reuse, but it does not guarantee hardware safety, support, low compute cost or commercial rights to every dataset used.
Open-Source Physical AI: Artifacts, Licenses and Reproducibility - evidence comparison
The table records what each source establishes and keeps missing data visible.
| System or method | What the evidence establishes | Evidence class | Main unresolved point |
|---|---|---|---|
| LeRobot | Apache-2.0 framework with robot interfaces, datasets, policies and tutorials. | Open-source framework | Open source does not guarantee safety, support or commercial rights. |
| OpenVLA and OpenPI | Release different combinations of code, weights and training recipes for robot policies. | Open model projects | Reproduction can require expensive compute and hardware. |
| Isaac Lab and MuJoCo | Provide simulation and training infrastructure with distinct licenses and ecosystems. | Open development tools | License compatibility across code, data and weights is complex. |
| Open humanoid hardware | Projects vary from software-only control stacks to partial or complete mechanical files. | Artifact-by-artifact verification | Open source does not guarantee safety, support or commercial rights. |
Evidence classification
- Officially documented specifications, standards or project status stated by the responsible organization.
- Real-system evidence demonstrations or deployments performed on physical hardware under described conditions.
- Company claim a numerical or operational statement reported by the company and not independently audited.
- Simulation or research evidence useful for mechanisms, but not proof of field deployment.
- Insufficient public evidence control mode, trial count, version or operating conditions are missing.
Definition and openness test
Open-source Physical AI covers hardware, datasets, simulators, policies, teleoperation tools and evaluation software that publish reusable artifacts under explicit licenses. A public demo or research paper is not open source when the code, weights or hardware files remain unavailable.
How the stack is assembled
Inventory code, weights, data, CAD, firmware and documentation separately. Verify the license for each artifact. Match supported robots and action formats. Reproduce installation and one baseline experiment. Track maintenance, releases and unresolved hardware safety issues. Latency, calibration and safety limits can change the result even when the high-level model remains the same.
How to compare open releases
For this open source Physical AI review, claims from Hugging Face, OpenVLA project, Physical Intelligence are kept with the exact robot, model or program that produced them. The page records released code, weights, datasets, hardware files, license scope, installation steps and reproducible hardware results; any field absent from the source remains undisclosed rather than being estimated from a video or marketing image.
Reproduction failure modes
Common failures include repositories that only run on undocumented hardware, weights whose terms conflict with the intended use, datasets with incomplete license or consent information, and hardware releases that omit tolerances, electronics or a bill of materials.
Maintenance status matters as much as the initial release. Pin a working version, record dependencies and verify that the project still supports the robot and simulator versions used in the experiment.
Practical developer uses
Credible applications include Low-cost robot learning labs, Reproducible policy research, Shared datasets and benchmarks and Hardware prototyping and education. These applications should be described with the robot, task boundary, operator role and environmental constraints. Experimental capability, commercial availability and routine deployment are reported as separate statuses.
What to verify before adoption
Before adopting a Physical AI project, verify the exact licenses for code, model weights and datasets, the supported robot and simulator versions, the minimum compute requirements and whether a published baseline can be reproduced from the documentation.
For physical hardware, also check emergency-stop behavior, actuator limits, firmware dependencies and whether the open release includes enough calibration information to reproduce the documented setup.
Limitations and missing information
- Open source does not guarantee safety, support or commercial rights.
- Reproduction can require expensive compute and hardware.
- License compatibility across code, data and weights is complex.
- Specifications, prices, repositories and deployment status can change after publication.
- Benchmarks from different robots or environments are not directly comparable.
Conclusion
Open-source Physical AI is not one binary property. LeRobot, OpenVLA, openpi, Isaac Lab and MuJoCo expose different combinations of code, weights, data and robot interfaces. A useful adoption decision records exactly which artifacts are open, their licenses, supported hardware, compute requirements and whether the published baseline can be reproduced on the intended robot.
Frequently asked questions
How should an open-source Physical AI project be evaluated?
List code, weights, datasets, robot interfaces, hardware files and documentation separately. For each layer record the license, version, supported robot and required compute, then reproduce one published baseline before assuming the project is portable to a new embodiment.
What do current open projects actually release?
LeRobot publishes an Apache-2.0 robotics framework with dataset, training and hardware tooling. OpenVLA publishes code under MIT and model artifacts for robot-action research. Physical Intelligence's openpi publishes robot-policy code, checkpoints and fine-tuning examples. These releases still differ in supported robots, datasets and compute requirements.
Sources and methodology
Sources for open-source Physical AI were rechecked on September 26, 2026 using current LeRobot, OpenVLA, Physical Intelligence openpi, Isaac Lab and MuJoCo materials. Licenses and released artifacts are recorded separately so a public repository is not treated as proof that the complete training or hardware stack is open.
Related TechniaHQRobot guides
Source review notes
Review date recorded July 11, 2026
Supported by the cited sources
- LeRobot: Apache-2.0 framework with robot interfaces, datasets, policies and tutorials.
- OpenVLA and OpenPI: Release different combinations of code, weights and training recipes for robot policies.
Not confirmed or incomplete
- Open source does not guarantee safety, support or commercial rights.
- Reproduction can require expensive compute and hardware.
- License compatibility across code, data and weights is complex.
Likely to change quickly
- Commercial availability, prices, model versions and software access.
- Deployment counts, company partnerships and repository maintenance status.
Share this article
Share the current TechniaHQRobot article page.
Continue reading
Open the latest robotics reporting, Physical AI analysis and hardware notes.