Mix and match
Pick a lower body (legs, a quadruped or a wheeled base), a torso, arms, hands and a head from any project in the catalog that publishes the part separately: humanoids, bimanual systems, arms, hands and mobile bases. The page checks what is known about the combination, adds up the bill of materials, and lists where to buy it.
Pick the modules
The combination
Every module is drawn from its own project's published geometry, posed at zero and placed by matching the joints at the boundaries: the waist output, the shoulders, the wrists, the head mount. Parts from other robots are scaled to the legs' robot so proportions read as one body (the legend shows the factor; switch it off to see true sizes), then pushed into contact so nothing floats or sits inside another part. Colour is the donor robot; a dot at each joint carries its checklist colour. Where two designs meet, what you see is the two parts brought together, not an adapter that exists.
Geometry: our own model; Duke Humanoid V2's viewer model (Apache-2.0); Berkeley Humanoid Lite assets (CC BY-SA 4.0); LeRobot Humanoid model (Apache-2.0); Open Duck Mini v2 (Apache-2.0); MEVITA (MIT); SO-ARM101 simulation model (Apache-2.0); LEAP Hand simulation assets (MIT); LeKiwi URDF (Apache-2.0); XLeRobot URDF (Apache-2.0); Solo 12 model (BSD-3-Clause); RP1 description model, RoboParty (CERN-OHL-W-2.0 per its hardware docs). Each is decimated for the browser; download the originals from the projects.
Compatibility checklist
Built this combination, or found a check to be wrong? Report it with photos and the changes you needed, and it becomes a verified entry in tools/catalog_src.py.
Totals
Bill of materials
| Module | Item | Qty | Unit | Total | Vendor |
|---|
Sourcing
Grouped by vendor, with the lines each supplies. Order the actuators and any machined parts first: they set the lead time and have no drop-in substitutes.
How the checks work
- Mechanical joints compare the interface at each boundary (waist output, shoulder output, wrist output, head mount). Same design and a built robot: verified. Same actuator output pattern across designs: the bolt circle matches but the coupler and plate are unverified. Anything else needs an adapter bracket.
- Electrical counts the actuator families in the combination. One family means one bus, one protocol and one voltage; each extra family adds a driver, a bus adapter and usually a DC-DC converter.
- Payload compares the mass above the hips with what the chosen legs carry in their own robot. Over 115 % of that is flagged; the legs' torque margins were sized for their own upper body.
- Scale flags modules from robots whose height differs by more than a third; hip spacing, shoulder width and reach stop making sense before the bolts do.
- Software: any mixed combination needs a new robot description and a retrained or retuned controller. The existing stacks only cover their own robot.
Prices are the modules' published BOMs where the project itemises them (Fully Open Humanoid, Duke Humanoid V2, LeRobot Humanoid, LeKiwi, SO-ARM101, Amazing Hand), the project's or vendor's published total for a complete unit (OpenArm, LEAP, RUKA, Solo 12, TidyBot++), and are marked as estimates where a total was split by joint count or by subtraction (Berkeley Humanoid Lite, XLeRobot). Modules without a published price are counted as unknown, never as zero.
Wheeled bases and carts take the lower-body or torso slot: LeKiwi and TidyBot++ carry a torso, the XLeRobot cart replaces both legs and torso. Arms with built-in grippers (SO-ARM101, OpenArm) do not need a hands module; a licence check flags donors under non-commercial or unstated hardware terms.