Skip to content
WE BUILDHUMANOIDS

GUIDE · 4 MIN READ

Open-source humanoids

What open-source means for humanoid robots: hardware, code and licences, the sim-to-real workflow, and teleoperation, with examples from public projects.

REVIEWED BY WBH · · DRAFTED WITH AI ASSISTANCE FROM THE CITED SOURCES

For: People who build, program or evaluate humanoid robots.

What open-source covers, and what it does not

Before you build on an open-source humanoid project, read its licence section as carefully as its installation steps.

The code in the Berkeley Humanoid Lite repository is licensed under the MIT licence, while the other assets in the repository are under Creative Commons Attribution-ShareAlike 4.0. [1]

In the ToddlerBot repository, the codebase, documentation included, is released under the MIT licence. The design files (the Onshape document and the STL files) carry a Creative Commons non-commercial licence, which the project says allows you to use and build upon its work non-commercially. [2]

The HOMIE teleoperation project calls itself fully open-sourced, yet states that using it for any commercial purpose is strictly forbidden. It also asks for a form to be filled in before it releases its hardware design files. [3]

Treat "open" as a claim to check, not a guarantee. Look separately at the licence for code, for design files and for any pretrained models.

Framework code can be permissive: ProtoMotions 3 releases its source under the Apache-2.0 licence, and says that NVIDIA-provided pretrained models fall under the NVIDIA Open Model License unless a model card says otherwise. [4]

Hardware you can build yourself

Berkeley Humanoid Lite is presented by its authors as an accessible, customizable 3D-printed humanoid robot. [5] ToddlerBot is presented by its authors as a low-cost, open-source humanoid robot platform. [6]

The Berkeley Humanoid Lite team says its core design is a modular 3D-printed gearbox for the actuators and the robot body. The authors report that all components can be sourced from widely available e-commerce platforms and that the total hardware cost stays under $5,000, based on U.S. market prices. [5]

The Berkeley Humanoid Lite authors say they tested the printed actuators to validate their durability and to alleviate concerns about the reliability of plastic components. [5]

ToddlerBot's authors describe a compact robot of 0.56m and 3.4kg, built from an entirely 3D-printed, open-source design and commercially available components, for a total cost under 6,000 USD. They say its documentation allows assembly and maintenance with basic technical expertise, as validated by a successful independent replication of the system. [6]

These are claims by the projects' own authors, so judge them against your own parts prices and printing capacity.

What a project repository contains

The Berkeley Humanoid Lite repository describes itself as the workspace for the project, containing everything its authors need, including policy training, sim2sim validation, real-world deployment, motion capture and teleoperated manipulation controls. [1]

Its directory structure follows the Isaac Lab convention, where each submodule can be installed as an extension. [1]

  • One submodule holds the Isaac Lab environment and task definitions. [1]
  • One holds the robot descriptions in URDF, MJCF and USD, with a script that exports them from the Onshape project. [1]
  • One holds the low-level code that runs on the real robot, and only this part is needed to deploy to the hardware. [1]

MuJoCo defines models in its native MJCF format and can also load URDF files. [7]

The ToddlerBot README says its codebase includes low-level control, RL training, DP training and real-world deployment. [2]

If you want to bring your own robot to a general framework, ProtoMotions 3 lists three steps: add a MuJoCo `.xml` spec file, fill in the robot's config fields, and register the robot in a factory file. [4]

From simulation to hardware

The Unitree RL Gym README gives a compact view of its workflow: Train, Play, Sim2Sim, Sim2Real. [8]

In the Sim2Sim step, the README says to deploy the policy trained in Gym to other simulators, to ensure it is not overly specific to Gym characteristics. [8]

Domain randomization is another way to prepare for the gap between simulation and the real world [9]. Isaac Lab lists domain randomization among its features, for robustness and adaptability. [10]

ToddlerBot's authors credit zero-point calibration and transferable motor system identification for a high-fidelity digital twin, which they say enables zero-shot policy transfer from simulation to the real world. [6] The Berkeley Humanoid Lite authors report zero-shot transfer for a locomotion controller developed with reinforcement learning. [5]

When you deploy, keep the interface between policy and robot narrow. ProtoMotions 3 exports a single ONNX model with the observation computation included, so a deployment framework only has to supply raw sensor signals. [4]

Teleoperation and data collection

The HOMIE project combines a reinforcement-learning locomotion policy with an exoskeleton-based hardware system. Its exoskeleton arms are isomorphic to the controlled robot, so the upper-body joint positions can be set directly from the exoskeleton readings without inverse kinematics. [3]

Its HomieDeploy component holds the deployment code, both for the PC connected to the project's hardware system and for the Unitree G1 with Dex3 hands. As noted above, its licence forbids commercial use. [3]

ToddlerBot's authors say a user-friendly teleoperation interface makes real-world data collection easier, for learning motor skills from human demonstrations. [6]

A checklist before you commit to a platform

Use the projects above as a model for what to look for:

  • Licences: confirm the terms for code, design files and models separately, and whether commercial use is allowed. [2]
  • Access: check whether any hardware files sit behind a request form. [3]
  • Deployment code: look for the part that runs on the robot, as the Berkeley Humanoid Lite repository separates it from the rest. [1]
  • Simulator fit: check that the robot description formats suit the simulator you plan to use. [7]
  • Sim2sim testing: look for a workflow that validates a policy in a second simulator before hardware. [8]

None of these replaces building and testing the robot yourself. The sources describe what each project reports, and your parts, printers and calibration will differ.