comparison · Source researched

Building an open source humanoid: projects, requirements and first steps

Choose a named robot configuration and prove its software route before ordering the full body. ToddlerBot, Berkeley Humanoid Lite and Poppy expose different fabrication and setup work; use a matched BOM, design files and controller revision, then follow the project’s communication and calibration checks before attempting a behavior.

Published by Open Source Robotics · Sources checked 2026-10-22 · Updated 2026-10-22

Start with one reproducible milestone

A practical first milestone is a version-matched humanoid model running in its documented simulator, followed by the project's motor configuration and calibration checks on supported hardware. Walking is a later integration result. This is our proposed build sequence, not a report of a robot we have assembled.

Choose the route by the work you want to do. ToddlerBot documents a servo-based robot with separate board sourcing and calibration fixtures. Berkeley Humanoid Lite adds fabrication and commissioning of custom actuators. Poppy Humanoid offers modular assembly documentation, but its older release needs a deliberate software and parts compatibility check. None is an established beginner build recommendation from our own testing. ToddlerBot materials Berkeley tools Poppy release

Compare the work before choosing the robot

These checkpoints are planning recommendations derived from the documents, not tested build times or a ranking of reliability. The project-specific details below explain the conditions. The catalog profiles retain more of the source and cost history.

ToddlerBot: resolve the variant and board order first

The hardware guide distinguishes toddlerbot_2xc and toddlerbot_2xm, recommending 2xc as the default. It also says the robot BOM excludes PCB files and points to a separate board-sourcing guide. Create two procurement lines: the selected robot BOM and the communication-board manufacturing order. Confirm that neither is missing from your budget. BOM and sourcing notes

The assembly page links the 2.0 interactive manual while retaining older assembly material and a work-in-progress notice. Follow the resource for the selected revision instead of combining illustrations from different versions. Save the CAD/print revision and software commit beside your parts list. Assembly resources

Before buying the complete robot, investigate its software route. The setup guide uses Python 3.10 with platform-specific dependencies. The pinned README provides a simulation replay example using motion/push_up_2xc.lz4. For the 2xc route, that is a concrete initial exercise: follow the upstream setup, run its matching replay example and retain the command, revision and result. A displayed motion is not evidence that a physical build will reproduce it. Software setup Pinned replay example

Calibration requires printed fixtures. The upstream fine-tuning procedure can drive the robot upright and warns that disabling its motors can make it fall. Read that procedure and the stand documentation before powered work; a stand must support the torque direction involved. Do not replace the project's commissioning procedure with a generic “power on and walk” sequence. Zero-point calibration Stand requirements

Berkeley Humanoid Lite: budget for actuator fabrication

The tool list specifies a printer with at least a 200 × 200 × 200 mm build volume, soldering equipment, heat-insert tooling, a glue gun for motor-shaft magnets and hand tools. Decide whether you can perform this work or need a fabrication service before ordering a complete set of robot parts. Printing the frame alone does not complete the actuator work. Required tools

The software workspace separates training, robot-description assets and low-level control. Record their revisions together rather than mixing the newest branch of each. The onboard setup uses Ubuntu 22.04 and documents separate checks for actuator communication, IMU data and joystick input. Use those checks to isolate failures before attempting the full controller. Workspace layout Onboard checks

The reviewed low-level README requires joint-zero calibration after every power cycle because the actuators use a single motor-shaft encoder. Include that recurring step in your startup plan. Do not treat a saved calibration file or a successful CAN connection as proof that the robot is ready to walk. Calibration and controller sequence

This route suits a reader who wants to investigate actuator construction as part of the project. That is an editorial fit assessment, not a claim that it is cheaper or easier than ToddlerBot. Check the catalog's dated cost breakdown for missing items and exclusions; it is not a current delivered quotation.

Poppy Humanoid: prove the software route before committing

The pinned release describes a robot with 25 Dynamixel actuators. It warns that direct SolidWorks downloads can be Git LFS placeholders and directs readers to release assets or its cloning instructions. Check that the files contain actual geometry before planning manufacture. Reviewed release README

That release also documents an Odroid U3/XU4 route with an Ubuntu 14.04-based image. Treat it as a historical configuration to assess, not an instruction to install an old image on a newly selected board. First establish an obtainable, compatible software and motor-configuration route. If that remains unresolved, postpone the full-body order rather than assuming a current computer is a drop-in replacement. This is our planning recommendation based on the release's dependencies. Board and software history

Poppy remains useful for examining modular humanoid construction. Its presence here does not establish that the reviewed release can be reproduced unchanged with today's components. Use the profile and upstream documentation to identify the revision you intend to reproduce.

Build a budget that reaches a first result

Before comparing headline prices, make a worksheet for one named configuration. Record quantity, exact part, source, price currency, region, check date, availability and what is excluded. Mark an unresolved line as unknown, not zero. Our parts-estimate guide explains that method.

The rows are a planning framework, not a claim that every project requires every listed item. This guide does not establish current purchasing totals or a universal minimum GPU. Decide whether you intend to run a supplied behavior or train a new policy; those are different compute commitments.

Learn what the next stage actually needs

Use the learning catalog as a sequence of exercises, not a requirement to finish whole courses before starting.

These are our suggested exercises using the resources' documented subject matter. Modern Robotics uses mathematical foundations. For the advanced material in Underactuated Robotics, our suggested preparation is differential equations, linear algebra and introductory control; this is an editorial study recommendation, not a quoted course admission requirement. None is a complete assembly course or a certificate of readiness to operate a humanoid. Follow your robot's own simulator and controller versions; linking a MuJoCo lesson does not establish interchangeable robot models or policies. Modern Robotics materials MuJoCo programming guide Underactuated course notes

Keep a build record with explicit stop points

Use this sequence as an editorial checklist alongside the selected project's instructions:

• Freeze the configuration. Record robot variant, BOM, CAD and print revision, software commit, controller firmware, motor map and intended first behavior. Stop procurement if a required file, part or dependency cannot be identified.
• Check the software before full procurement. Follow the project's documented simulator or software setup and save the result. A successful import alone is not a reproduced task. If a working route is still unknown, resolve that gap before a full-body purchase.
• Follow the fabrication and assembly checks. Keep project-specific board, wiring and mechanical inspection steps with the build record. Do not substitute a generic wiring diagram from another humanoid.
• Commission using the project's procedure. Record communication, sensors, joint identity, calibration and the specified support arrangements before motion. Stop if identity, direction, calibration or support is unresolved; use upstream instructions to correct it.
• Attempt the documented behavior only after its prerequisites. Save the exact configuration, controller/policy revision and result. Separate a completed simulation, a powered hardware check and a demonstrated behavior in your notes.

Check openness by artifact

The reviewed ToddlerBot source assigns MIT terms to code/documentation and CC BY-NC-SA 4.0 to its design. Berkeley Humanoid Lite assigns MIT to code and CC BY-SA 4.0 to other assets. The reviewed Poppy release distinguishes CC BY-SA 4.0 hardware from GPL v3 software. These are source-specific declarations, not a blanket statement about every purchased component, external file or commercial use. Read the relevant terms for the artifacts you plan to reuse. ToddlerBot declarations Berkeley declarations Poppy declarations

This guide compares source documents and proposes a build-planning sequence. We have not assembled these robots, executed their setup or calibration procedures, trained their policies or measured build cost and performance. It does not establish a complete currently purchasable kit for any of them.

Suggest a correction