I Went Looking for an Open-Source Humanoid Robot

Menlo Research's Asimov 1 sent me down this rabbit hole. Here was a 1.2 m humanoid with a public repository, downloadable mechanical files, open electronics, a simulator, and a licence written for hardware. It looked like a straightforward answer to a straightforward question: can you download a humanoid robot and build it yourself?

The answer became less tidy with every project I opened.

Some teams publish the design but not the bill of materials. Some publish nearly everything, then forbid commercial use. Some call a robot open source because its SDK and URDF are on GitHub, even though the machine itself cannot be reproduced. A few older projects are more genuinely open than the robots attracting attention today.

By the end of the search, I had found four full-body projects with convincing, licensed build packages: RoboParty's Roboto Origin, Berkeley Humanoid Lite, Poppy Humanoid, and the University of Hamburg's NICO. Asimov is close and unusually ambitious, but its public self-source path is still unfinished. ToddlerBot may have the best small-robot learning stack of the group, yet its hardware licence is non-commercial.

That is the useful story. There is no single open-source humanoid movement. There is a spectrum running from complete open hardware to publicly visible files and open software wrapped around a robot you still have to buy.

Asimov is open, but the build is still being finished

The Asimov 1 repository is not an empty announcement. It contains fabrication-ready STEP files for seven mechanical subassemblies, native KiCad electronics, a wiring harness, a fabrication manifest, a MuJoCo model, and onboard software. The 35 kg robot has 25 actuated degrees of freedom plus two passive toe joints. Its hardware is licensed under CERN-OHL-S-2.0 and its software under GPL-2.0.

That licence matters. CERN-OHL-S gives other people real rights to make and modify the hardware, with reciprocal obligations when they distribute products or changed source. Menlo also publishes a substantial manual and offers an unassembled kit. This is much more than a vendor placing an SDK beside a proprietary machine.

Then I opened the self-source page. The BOM is marked “Request access.” The hardware release, BOM revision, wire manifest, electronics release list, and firmware compatibility are still labelled TBC. The page warns builders not to begin manufacturing from filenames alone. The mechanical files are neutral STEP exports rather than the original parametric design source.

The commercial route has its own limits. Menlo's product page tells buyers to expect more than 100 hours of assembly and lists the kit at $20,000. Tools and hands are not included. The repository still places the locomotion policy on its roadmap.

I would therefore call Asimov an open-licensed hardware release in progress, not yet a complete public recipe. It is still one of the most interesting projects I found, especially for locomotion and whole-body control. It simply needs to be described as it exists, not as the finished platform implied by the phrase “build it yourself.” A manipulation team would also need to choose and integrate a hand; the separate guide to open-source humanoid robot hands covers that problem.

I needed a better test than “the repository is public”

Before comparing alternatives, I needed a definition. The Open Source Hardware Association says that anyone must be allowed to study, modify, distribute, make, and sell the design or hardware based on it. The design source should be available in the form its author would use to make changes.

For a humanoid, that means more than seeing the outside shape. Native CAD or a public Onshape document exposes design intent; an STL is mainly a manufacturing output. A bill of materials turns shapes into purchasable parts. Schematics, PCB source, wiring, and firmware explain the electronics. Robot descriptions, calibration, low-level control, and simulation make the body usable. A licence supplies the legal permission that a public download button does not.

I also kept reproducibility separate from openness. A project can meet the legal definition and still be painfully difficult to build. Another can be exceptionally well documented for university research while a non-commercial clause keeps it outside the strict open-hardware definition. The distinction is not a judgement on the engineering. It tells a builder what freedom the files actually provide.

Berkeley Humanoid Lite feels like a reproducible recipe

Berkeley Humanoid Lite made the contrast with Asimov obvious. It is smaller—0.8 m, 16 kg, and 22 actuated DoF—but the size is part of the idea. The non-standard structural parts and cycloidal gearboxes can be made on ordinary desktop 3D printers. The paper puts the US hardware cost below $5,000.

The repository joins the mechanical design to the rest of the system. It includes URDF, MJCF, and USD robot models, motor-controller firmware, low-level real-robot code, policy training, sim-to-sim validation, motion capture, teleoperation, and deployment. The code is MIT-licensed and the other project assets use CC BY-SA 4.0, which permits commercial use while requiring attribution and share-alike distribution.

The team says a robot can be assembled in about three days and reports zero-shot sim-to-real locomotion. More importantly, it documents why this may fail. Printed gearboxes are less durable than metal ones. A later release note calls the V1 actuators fragile for high-performance tasks and its motor-controller connectors unreliable during extended use. That candour makes the project more useful, not less. A reproducible failure mode is engineering information.

Berkeley Humanoid Lite is the first project I would study for a new low-cost full-body build. Its value is not that it competes directly with an industrial humanoid. It is that a lab can understand the actuator, change a joint, print a replacement, and trace a learned policy from simulation into hardware.

Roboto Origin opens a more industrial machine

Roboto Origin takes almost the opposite route. RoboParty describes a 1.25 m, 34 kg, 23-DoF prototype and publishes the chain from mechanical design to training and deployment. The main repository collects native SolidWorks parts and assemblies, manufacturing drawings, BOM spreadsheets, PCB designs, firmware, URDF and MJCF models, ROS 2 deployment code, and Isaac Lab training.

The licensing is unusually deliberate. RoboParty-owned hardware design, PCB, BOM, manufacturing, URDF, and mesh files use CERN-OHL-W-2.0. Firmware and deployment software are generally GPL-3.0; the training repository uses BSD-3-Clause; documentation uses CC BY-SA 4.0. Third-party vendor files keep their own terms rather than being swept under a misleading project-wide licence.

This is not a desktop-printer build. The hardware package includes CNC manufacturing work and depends heavily on Chinese sourcing. The current V2 design is also incompatible with V1. Anyone reproducing it needs to freeze matching mechanical, PCB, firmware, robot-description, and controller revisions before ordering parts.

Roboto Origin is the strongest large full-stack release I found. It is also a reminder that “the files are available” and “I can build this safely” are very different milestones.

ToddlerBot was designed as a data machine

I expected ToddlerBot to be a charming small humanoid. Its more important idea is that a research robot should collect its own training data.

The Stanford platform is 0.56 m tall, weighs 3.4 kg, and packs 30 active DoF into a printable body. Its reported BOM is below $6,000. The paper and repository connect the CAD and assembly guide to zero-point calibration, motor system identification, a digital twin, reinforcement-learning environments, whole-body teleoperation, imitation learning, and deployment.

For real-world data collection, a second upper body acts as the leader for the robot's arms while a handheld controller commands walking and body modes. That means observations, actions, images, calibration, and simulation parameters can be kept in one inspectable system. The team also reports independent reproductions, which is stronger evidence than a polished build video from the original lab.

ToddlerBot's catch is written plainly in its repository. The code and documentation are MIT-licensed, but the Onshape design and STL files use CC BY-NC-SA 4.0. That non-commercial restriction fails the OSHWA definition. ToddlerBot is an excellent source-available research platform; a company does not receive unrestricted rights to build on the hardware.

Microban takes the same research-only bargain to a much smaller scale. The roughly 30 cm, 19-DoF robot has Onshape, STEP and STL files, a detailed BOM, assembly guidance, software, and a separate reinforcement-learning environment. Its published parts total is about $567 before optional configuration tools. The hardware is also CC BY-NC-SA 4.0.

The older robots are not footnotes

The current wave did not invent open humanoids. It rediscovered why they are useful.

Poppy Humanoid came from Inria's Flowers team more than a decade ago. The 83 cm, 25-DoF platform published SolidWorks source, STEP, Parasolid, STL, URDF, a BOM, assembly guidance, and software. Hardware uses CC BY-SA 4.0 and software GPL-3.0. Its official repository still quotes an $8,000–$9,000 build, but the last tagged hardware release dates to 2015, so that is not a 2026 procurement quote.

NICO, the Neuro-Inspired COmpanion, is a 101 cm, 7 kg, 30-DoF platform developed for multimodal interaction and manipulation. Its CAD repository includes native Autodesk Inventor parts and assemblies alongside printable STLs under CC BY-SA 3.0. Its software API is GPL-3.0. NICO uses proprietary DYNAMIXEL servos and third-party hands, and its software instructions target an older robotics stack, but the creator-controlled design is genuinely open.

InMoov belongs to this history too, but not to a list of walking bipeds. It is a life-size printable maker robot with an active software community; its official legs are explicitly non-motorised, and its hardware carries a non-commercial licence.

Open platform is a different kind of achievement

iCub complicated my neat categories. The Italian Institute of Technology and Robotology community have maintained public control software, YARP middleware, firmware, robot models, documentation, and selected mechanical and electronics source over many years. IIT still supplies the robot, and the software remains active.

The current public hardware repositories say that they mirror only selected material from private engineering repositories. They do not form a complete iCub3 manufacturing package. Licences also vary by layer: CERN-OHL-W-2.0 for current public hardware, CC BY-SA for models, GPL for core control software, and BSD terms elsewhere.

Calling iCub closed would clearly be wrong. Calling every part of the current robot open hardware would also be wrong. “Open research platform” captures what the project achieved: researchers can inspect, extend, simulate, and share a common embodied system without pretending that they can clean-room manufacture every production component.

The DARwIn-OP and ROBOTIS OP family belongs in the same category. DARwIn-OP published source code, circuit diagrams, CAD, fabrication material, and assembly manuals. Its current descendant, the roughly 51 cm, 20-DoF ROBOTIS OP3, still provides STP parts, schematics, URDFs, manuals, and ROS software.

OP3 software is Apache-2.0, but the current hardware-data collection does not present one clear top-level licence, and ROBOTIS states that DYNAMIXEL firmware is not open source. The robot remains unusually inspectable and modifiable for a supported commercial platform. It is not open all the way down.

Some incomplete robots are still useful

The new LeRobot Humanoid is a good example. Its current release is a 12-DoF lower body with no arms, not a complete humanoid. Within that boundary, the package is excellent: public Onshape CAD, printable geometry, a machine-readable BOM, wiring and assembly instructions, motor commissioning, MuJoCo and real-robot control, system identification, data collection, and training environments. Hugging Face reports about $2,500 in parts. For biped learning, that may be more useful than a grander full-body promise.

AGILOped is further along physically and less complete as a recipe. The University of Bonn's 1.10 m, 14.5 kg robot uses 10 actuators to control 12 joints and has walked, jumped, mitigated falls, and stood back up. Its model repository releases STEP hardware, URDF, and MuJoCo assets under MIT, with the shared NimbRo ROS stack under BSD-3-Clause. I could not find a complete procurement BOM or assembly manual, and its two simple arm joints are for fall mitigation rather than manipulation.

K-Bot is the reverse case: the licence survived, but the company did not. Its public repository points to Onshape CAD and places the hardware under CERN-OHL-S. Its software terms are inconsistent—the README says GPL-3.0 while the root licence and major subrepositories use MIT. Former K-Scale mechanical engineer Aaron Xie says the company dissolved and refunded preorders in November 2025.

The robot had reached physical prototypes, but the surviving public material does not offer a complete BOM and electrical build path. K-Bot is now a useful design archive and possible community revival, not a supported product. Open licensing preserved more than a closed shutdown would have, but it could not preserve suppliers, documentation work, or engineering support.

The biggest trap is confusing an open SDK with an open robot

Once I knew what to look for, several familiar names fell out of the hardware list.

Unitree publishes G1 URDF and MJCF descriptions, SDKs, training tools, and datasets. Booster publishes T1 models and a training-to-deployment stack. Fourier publishes GR-series models and developer software. Pollen Robotics publishes Reachy 2's ROS 2 stack and SDK, while its CAD page still says “Page in progress.”

All of that work is valuable. None of it gives a builder the editable mechanical source, electronics, BOM, and permissions needed to reproduce those robots. These are open development platforms around commercial hardware.

The closer cases are messier. HopeJR contains full-body concepts, URDFs, newer arm and hand files, PCBs, and an experimental LeRobot integration. Its older Humanoid subtree has an Apache-2.0 licence, while the repository root and newer Arm subtree do not state comparable terms. There is no complete whole-robot BOM, assembly path, or walking controller.

OpenLoong applies the Solderpad Hardware License 2.1 to its QingLoong drawings and documents. That is a real open-hardware licence. The public tree is still mainly STEP exports and PDFs, without an evident complete BOM, native parametric CAD or ECAD, or full arm and hand source. The licence is ahead of the reproduction package.

Fourier calls N1 its first open-source humanoid and announced a BOM, CAD, assembly material, and operating software. Its linked N1 repository currently identifies itself as an SDK documentation site and contains neither that hardware package nor an explicit hardware licence. AgiBot's Lingxi X1 hardware repository goes the other way: it holds native SolidWorks archives, whole-machine STEP, BOM spreadsheets, drawings, and assembly material, but no licence granting hardware reuse.

Public files are not the same as open hardware. Open software is not the same as an open robot. A promised release is not the same as a maintained archive.

Why the hardware files matter to robot learning

I care about this distinction because the body is part of the training data.

Joint axes, limits, gear ratios, motor models, camera placement, latency, calibration, and controller behaviour determine what an action means. A command of 0.4 is useless to another team unless it knows the unit, joint, control mode, update rate, limits, and physical transmission behind that number.

Native CAD and a URDF or MJCF make the robot embodiment inspectable. Firmware and low-level control code explain how requested positions or torques became movement. Calibration and system-identification tools make a simulator auditable. Versioned hardware lets another lab reproduce a collection rig or explain why its supposedly identical robot behaves differently.

Hardware and data rights are separate. An open robot can generate a private dataset. An open dataset collected on a proprietary robot can still be useful. In either case, the dataset should record the exact robot revision, modifications, source commit, controller, calibration, sensors, action schema, failures, and licence. The humanoid data evaluation checklist approaches the same problem from a buyer's side.

Where I landed

If I wanted to reproduce a current full-body humanoid from public files, I would begin with Berkeley Humanoid Lite or Roboto Origin. Berkeley offers the more accessible workshop project; Roboto Origin exposes a larger, more industrial engineering chain. I would consider Asimov through its supported kit route, but I would wait for a public, revision-locked BOM before attempting the self-source route.

For compact robot learning and data collection, ToddlerBot is the most coherent package I found, provided the non-commercial hardware terms fit the work. Microban lowers the cost further. For bipedal locomotion, LeRobot Humanoid offers the cleaner build guide and AGILOped the stronger physical demonstration. For teaching and interaction, Poppy and NICO remain credible despite their age. For a supported shared research ecosystem, iCub and ROBOTIS OP3 still deserve attention even though neither is a clean whole-machine hardware release.

The label is not the answer. Open source does not make a humanoid cheap, safe, reliable, or easy to assemble. It does make the machine legible. The best projects let another person follow the design decisions, reproduce the failures, and change the body without asking permission. That is the part worth preserving.