Best Open Robot Foundation Models Compared

Published

An open robot model is useful only when a developer can obtain the weights, understand the license, reproduce inference, and adapt the policy to real hardware. A paper, demo video, or API waitlist is not enough.

This comparison therefore excludes closed systems such as Figure Helix and partner-only Gemini Robotics VLA releases. It covers models with accessible weights and public workflows. It does not rank vendor benchmark numbers against each other because the robots, datasets, tasks, evaluation protocols, and intervention rules differ.

For the broader model landscape, including closed commercial systems, start with Robot Foundation Models Explained. For architecture terminology, see Vision-Language-Action Models Explained.

Comparison matrix

ModelWeightsCode and model licensePrimary embodimentsPublic training dataPractical status
SmolVLA 450MAvailableLeRobot code and model documentation, verify checkpoint licenseSO-100, SO-101, LeKiwi and LeRobot-compatible armsCommunity LeRobot datasetsBest low-cost entry point
OctoAvailableOpen repository and checkpoints, verify dependenciesMultiple manipulation armsOpen X-Embodiment mixtureMature research baseline
OpenVLA 7BAvailableMIT code; weights inherit Llama 2 restrictionsManipulation arms represented in OXEOpen X-Embodiment mixtureReproducible but compute-heavy
Physical Intelligence openpiAvailablePublic code and checkpoints; check repository termsALOHA, DROID Franka and custom adaptationsSome recipes use public DROID and LIBERO dataStrong research workflow, substantial compute
NVIDIA GR00T N1.7AvailableApache 2.0 code; weights under NVIDIA Open Model LicenseBimanual, semi-humanoid and humanoid systemsMixture described, full raw training corpus not publicEarly Access, not GA

“Open” is not one binary property. OpenVLA’s repository code is MIT licensed, but its checkpoints inherit restrictions from the Llama 2 base model. GR00T publishes code and weights under different licenses. Before commercial use, record both licenses and the licenses of training data and dependencies.

SmolVLA: best first reproducible workflow

SmolVLA is a 450 million parameter VLA in Hugging Face LeRobot. It accepts camera images, robot state, and a language instruction, then generates chunks of continuous actions. Hugging Face publishes installation, data recording, training, and inference recipes.

Its main advantage is accessibility. The model is designed to run on consumer hardware and can be adapted to affordable arms such as the SO-101. Official documentation recommends recording roughly 50 episodes as a starting point, with enough demonstrations for each task variation.

That recommendation is not a performance guarantee. Camera position, action normalization, gripper calibration, demonstration consistency, and the difference between the pretraining distribution and your task determine whether 50 episodes are sufficient.

Choose SmolVLA when the objective is to learn the full data-to-policy workflow on obtainable hardware. See the robotics development kit guide for compatible starting platforms.

Octo: established multi-embodiment baseline

Octo is a generalist diffusion policy pretrained on about 800,000 trajectories from Open X-Embodiment. It supports language or image goals, multiple camera inputs, and adaptation to new observation and action spaces.

Octo remains valuable as a transparent research baseline. Its model and fine-tuning code are public, and its design makes embodiment adaptation explicit. It is less convenient than the current LeRobot ecosystem for a first low-cost build, but useful when comparing a new policy against a widely cited generalist model.

Choose Octo when reproducibility and comparison with established multi-robot research matter more than a turnkey hardware path.

OpenVLA: larger model with licensing nuance

OpenVLA is a 7 billion parameter VLA trained on roughly 970,000 Open X-Embodiment trajectories. The repository includes inference, LoRA fine-tuning, full fine-tuning, dataset preprocessing, and evaluation workflows.

The larger model raises the compute requirement. It is not the natural choice for a small edge computer. It is appropriate for teams evaluating whether a larger vision-language backbone improves their manipulation tasks and that can support workstation or server inference.

Commercial teams must read the model notes carefully. The code is MIT licensed, but the released checkpoints derive from Llama 2 and inherit the Llama Community License. “Open source code” does not automatically mean unrestricted model use.

Physical Intelligence openpi: public checkpoints, research-grade setup

openpi provides public implementations and checkpoints for pi-zero, pi-zero-FAST, and pi-zero-point-five. The repository includes base checkpoints plus task-specific examples for ALOHA, DROID and LIBERO.

This is a serious adaptation path, not a one-command universal robot policy. Physical Intelligence explicitly warns that the models were built for its own robots and may not transfer successfully to another platform. Data conversion, normalization statistics, action-space mapping, JAX or PyTorch support, and substantial accelerator memory are part of the work.

Choose openpi when the team can invest in dataset engineering and wants to study flow-matching or autoregressive action generation on established research embodiments.

GR00T N1.7: accessible humanoid model in Early Access

NVIDIA Isaac GR00T N1.7 publishes pretrained weights and reference code for generalized humanoid and bimanual skills. The repository supports fine-tuning and inference with custom demonstrations and integrates with NVIDIA’s simulation and data stack.

NVIDIA labels N1.7 Early Access. Its own repository says commercial support, fully validated benchmarks, stable features, and normal contribution workflows are GA items. That makes it an available model for evaluation, not evidence that a production humanoid application is ready.

Choose GR00T when the target embodiment is humanoid or bimanual, NVIDIA infrastructure is acceptable, and the team can tolerate Early Access changes. Connect it to the Isaac Sim, Gazebo and MuJoCo comparison and the robot SDK directory.

How to choose without misusing benchmarks

Start with embodiment compatibility. A model evaluated on a Franka arm does not automatically output valid commands for a humanoid. Then check action representation, control frequency, camera configuration, normalization statistics, inference hardware, and whether safety constraints sit outside the learned policy.

Use a local evaluation set that includes normal tasks, task variations, recoverable failures, and hard stop conditions. Report task success, interventions, cycle time, unsafe command rate, and hardware resets separately. Do not copy a success percentage from a paper into a purchasing decision.

The practical recommendation is SmolVLA for an affordable first workflow, Octo for an established open baseline, OpenVLA or openpi for compute-rich research, and GR00T for Early Access humanoid work. None should receive direct actuator authority without limits, monitoring, and an emergency stop.

Frequently asked questions

Is GR00T fully open source?

The code is Apache 2.0 and weights are accessible under NVIDIA’s Open Model License. Treat code and model licensing separately, and note the current Early Access status.

Which model is easiest to run on affordable hardware?

SmolVLA has the clearest low-cost path through LeRobot and SO-101-class arms. Actual real-time performance still depends on the computer, cameras, and control loop.

Can benchmark scores be compared directly?

Usually not. Different papers use different robots, task definitions, datasets, resets, and evaluation procedures. Re-evaluate candidate models on the same hardware and tasks.

Do open weights make a model safe to deploy?

No. Openness improves inspection and adaptation. Safety still requires action limits, collision controls, supervision, validation, and rollback.

What should be documented before commercial use?

Record code, checkpoint, base-model and dataset licenses; supported embodiments; compute; model version; evaluation evidence; known failure modes; and the responsible deployment owner.

Sources