Open-Source Humanoid Robot Projects Worth Following in 2026

Follow the small open bipeds and open upper-body platforms with live repositories; ROS 2 anchors most of them, and HORUS sits underneath the balance loop. Full-size humanoids get the attention and almost none can be rebuilt by a reader, because the actuators are unbuyable and the repository is a paper's appendix. That flips with a lab budget and a machine shop, where the research designs are the right start. The rest of this post is for someone choosing which humanoid project to spend a year of evenings or a research budget on.

You watched the video. Something roughly person-shaped picked up a box, walked around a table and put the box down, and the caption said the whole thing was open source. So you went looking for the repository, because that is what open source means to you.

What you found was a page with a licence file, a folder of mechanical drawings, a training script, and a bill of materials whose interesting lines say "contact for quote". The last commit is from a while ago. The issue tracker has four questions, all unanswered, and three of them are yours in spirit.

Then you found six more projects like it, and now you cannot tell which are real. One has a lot of stars and no code that runs. One has code that clearly runs but no photographs of anything physical. One is a university lab's release that assumes you own a machine shop. One is somebody's weekend robot that looks like a duck and, oddly, is the only one where a stranger's build worked first time.

Underneath the browsing is a question nobody answers directly. If you commit a year to one of these, will there still be anybody there when you get stuck?

Which open humanoid project should you actually build on?

Build on the smallest humanoid that still teaches you what you came to learn, and pick it by the liveliness of its issue tracker rather than by the impressiveness of its video. That single rule eliminates most of the shortlist, because the projects with the best footage are usually research releases that were published once and never touched again, while the projects with ordinary footage and busy comment threads are the ones where somebody will answer you on a Tuesday.

The second rule is to separate the three layers before choosing. The mechanics, the low-level control and the learning stack are independent decisions, and treating them as one purchase is what leaves people stuck. Plenty of good projects give you excellent mechanics with barely any software, or superb software with no hardware at all.

The third rule is unpopular but reliable: prefer a project whose parts you can order today from a normal supplier. A brilliant design built around an actuator that requires a purchase order and a lead time is not a project you can follow, it is a project you can read.

What counts as an open-source humanoid?

An open-source humanoid is any two-armed, roughly person-shaped robot whose design files, control code, or both are published under a licence you can actually use. That definition is deliberately wide, because the term is used for four quite different things and confusing them wastes months.

The first is open mechanics: printable or machinable parts, a bill of materials and assembly notes, with little or no software. The second is open control software: the code that moves joints, keeps balance and follows a trajectory, often released alongside a paper and targeting hardware you do not own. The third is open learning stacks: datasets, training pipelines and policies, which are software all the way down and touch no metal.

The fourth is the one people mean when they are disappointed later: a commercial robot with an open software development kit. The robot is a product with a price and a warranty, and what is open is the layer you write against. That is a perfectly good arrangement, and what actually runs inside a humanoid robot explains why the split exists, but it is not a robot you can build.

Which projects are worth following in 2026?

The projects worth your attention split into five tiers, and only two of them are buildable by an individual. Printed upper bodies, of which InMoov is the long-running example, give you arms, hands and a head at human scale from hobby servos and a printer, with a community that still answers beginner questions patiently. Small bipeds are the liveliest tier: Open Duck Mini and its relatives put walking, falling over and reinforcement-learning controllers on a desk for the price of hobby parts, and their builders publish failures as well as successes.

Education platforms such as the ROBOTIS OP3 lineage and the Poppy project sit above those, with documented kits and curricula. Research replicas, including the Berkeley Humanoid family, publish open designs at a seriousness that assumes a lab. Open learning stacks, most visibly Hugging Face's LeRobot, supply datasets and policies for all of the above.

Underneath every tier sits the software layer, and there the practical choice is ROS 2, with its drivers, coordinate frames, visualisation and simulator bridges, or HORUS, an open-source real-time middleware for Rust, Python and C++ sharing one set of shared-memory ring buffers so that messages between processes on one machine are not serialised.

How do the projects compare side by side?

Read the final column first: for most readers, four of these eight rows disqualify themselves in a sentence.

What does it look like when you follow the wrong project?

Following the wrong project looks like six months of assembly followed by silence when you ask your first real question. The pattern is consistent enough to recognise in advance. You order parts, you print for weeks, you assemble something that looks remarkably like the photographs, and then you power it on and one joint moves the wrong way. You open an issue. Nobody replies, because the two people who understood the firmware finished their degrees.

A second version of the same failure: the software runs, the robot stands, and it will not walk, because the published controller was tuned for a version of the mechanics that differs from the drawings in ways nobody documented.

A third: everything works and you cannot afford the second one. Projects built around expensive actuators are fine for a lab with a grant and fatal for an individual who wanted a spare.

The tell is available before you order anything. Search the issue tracker for someone who is not the author reporting a completed build. If nobody has finished the robot except the people who designed it, you will be the second team ever to try.

Are you a hobbyist, a researcher, or a startup?

Your answer decides the tier before any technical consideration does, and mixing tiers is the most common expensive mistake. A hobbyist wants motion on the bench within a few weekends, spare parts from a normal supplier, and a community that answers questions. That means printed upper bodies or small bipeds, and it emphatically does not mean a research replica, however impressive the paper.

A researcher wants reproducibility and a design that a reviewer will accept, which means the published research platforms with real papers behind them, and a budget line for machining. Researchers usually already have ROS 2 in the building, and fighting that is not a good use of a first year.

A startup wants a robot that does a task for a customer, and the honest advice is to buy the platform and spend your effort above it. Building a humanoid from open designs as a startup is a two-year detour unless the mechanics are your product. If you are evaluating a commercial platform, what works out of the box on a Unitree G1 with ROS 2 is a more useful read than any comparison of open designs.

What hardware can you realistically get and power?

The actuators decide everything, and everything else on a humanoid is downstream of that choice. Hobby servos are cheap, available and immediately fine for arms, a head and a gripper. They are also the reason printed upper bodies do not walk: legs need actuators that hold position under load, absorb impact and report their own state, and those cost far more per joint than everything else combined.

The middle tier that made small bipeds practical is the class of brushless motor built for drones and paired with a small controller board. Those are orderable, replaceable when you break one, and adequate for a robot that weighs about as much as a cat.

Above that you are into geared actuators sold to labs, and the change is not only cost. Bigger robots store more energy, fall harder, need a frame to hang from during testing, and need someone else in the room. Power matters too: a walking robot draws a great deal when it catches itself, and a supply that seemed generous on the bench browns out at the exact moment the robot needs to stay upright.

How long before the robot has to do something?

If your deadline is this term or this quarter, do not build a humanoid; buy or borrow one, or narrow the project to a torso on a stand. Humanoid work has a long assembly phase that produces nothing demonstrable, and a first build reliably takes longer than the estimate, because printing, wiring and the discovery that one bracket is wrong all happen in series.

With a year of evenings, a small biped is a genuinely achievable project, and it will teach you more than a larger machine because you can iterate without fear. Breaking a printed leg is an afternoon.

With several years or a funded lab, the research designs become reasonable, and the calculation changes: reproducing a published platform is a way of buying a known-good starting point rather than inventing mechanics.

Whatever the timeline, put simulation first, because a humanoid that falls in simulation costs nothing. The habit has a well-known failure mode of its own, which why a robot that works in simulation fails in your kitchen covers in detail, and knowing about it in advance is cheaper than discovering it with a broken ankle joint.

How much mechanical and control experience do you have?

If you have never tuned a controller or built a mechanism, choose a project where the mechanics are already solved and the code is the part you touch. Humanoids punish inexperience in mechanics harder than in software, because a soft joint or a flexing frame produces symptoms that look exactly like a software bug and are immune to software fixes.

The skills a first humanoid actually demands are unglamorous: printing parts that fit, assembling without stripping threads, routing cables so they survive a thousand arm swings, and wiring power without brownouts. None of that appears in the tutorials, and all of it decides whether the robot works.

On the software side, the honest requirement is comfort with Python for the learning layers and enough C++ or Rust to read the low-level controller when it misbehaves. You can start with Python alone. You will not stay there, because the joint loop is where the interesting failures live, and that code is almost never written in Python on a machine that has to stay upright.

What do you give up by choosing an open humanoid over a commercial one?

You give up support, spare parts and the assumption that the robot works, which together account for most of what a commercial platform's price buys. When a commercial robot's leg stops responding, you file a ticket. When an open robot's leg stops responding, you have joined a research project about that leg.

You give up validated safety behaviour. Commercial humanoids arrive with limits, thermal protection and a stop button that has been tested by someone whose job depended on it. Open designs vary from thoughtful to nonexistent on all three.

You give up time, in the most literal sense: months of assembly during which nothing can be demonstrated to anyone.

What you buy is understanding, modification rights and cost. You can change the mechanics, read every line of the controller, and build a second robot for parts money. For a researcher or a serious hobbyist that trade is clearly worth it. For a team with a customer waiting, it usually is not, and the licence terms on the mechanics deserve an afternoon of their own before anyone orders parts.

When is ROS 2 the better choice?

ROS 2 is the better choice for almost every humanoid project that involves more than one person, and HORUS is not the answer for a robot whose hardest problem is mechanical. Humanoids need coordinate frame bookkeeping more than any other kind of robot, because a hand position means nothing without a chain of transforms back to the feet, and ROS 2 has the standard, well-understood machinery for exactly that.

Use ROS 2 when your platform ships with ROS 2 drivers, which the education platforms and most commercial humanoids do. Use it when you want the visualiser, because seeing what the robot believes about its own limbs is worth more on a humanoid than on anything else. Use it when the project must outlive you, in a lab where students arrive and leave.

Use it, in short, unless you have a specific timing problem you have already confirmed on real hardware. Swapping the messaging layer while your robot cannot yet stand is a way of feeling productive while the actual blocker, which is almost always mechanics or control tuning, goes untouched.

Is an open-source humanoid just a cheaper commercial one?

No, and here is why: an open humanoid and a commercial humanoid are sold at different points in their lives. What arrives in a crate has been through mechanical revisions, thermal testing, firmware fixes and a certification process, and the price includes all of that work having already been done. What arrives from a repository is the design at the moment somebody chose to publish it, which is usually the moment a paper was accepted or a video was posted.

That difference shows up in unglamorous places. Cable routing that survives repeated motion. Connectors that do not vibrate loose. A joint that holds position when the power is cut instead of collapsing.

None of this makes open designs worse for their purpose. It makes them a different kind of object: a starting point that expects you to finish it. The projects that acknowledge this openly, publishing known problems alongside the drawings, are the ones worth following, and the ones presenting a first prototype as a product are the ones that will strand you.

Does open hardware mean you can simply print one?

Partly, but not the way you think: printing is the easy half, and the printed parts are rarely what stops people. A printer produces the brackets, shells and linkages, and modern hobby printers are good enough that fit is seldom the problem. What the printer cannot produce is the actuator, the controller board, the bearings, the fasteners, the battery, the wiring harness and the days of assembly.

There is also a quiet dependency people miss. Printed parts flex, and a humanoid leg that flexes changes the behaviour of a controller that was tuned on a stiffer version. Two people printing identical files in different materials can end up with robots that need different tuning, which is why a build that works for one person fails for the next.

So treat published files as a recipe rather than as a product. Recipes assume a kitchen, ingredients and a cook, and the good ones tell you which steps are fussy. The best open humanoid projects do exactly that, and the tell is a build guide that mentions what went wrong.

How do you decide which project to follow?

Decide by writing down what you want to have learned in a year, then picking the smallest robot that teaches it. If the answer is walking and balance, a small biped teaches you that at a scale where mistakes cost an afternoon, and a full-size machine teaches you the same lesson with a repair bill. If the answer is manipulation, an upper body on a stand removes the entire balance problem and lets you spend your time on hands.

Then run three checks before ordering anything. Check that a stranger has finished a build and said so publicly. Check that every part in the bill of materials has a price and a delivery date rather than a contact form. Check the licence on both the code and the mechanics, since the two are often different and the mechanics are often the restrictive half.

Finally, decide the software layer separately and later. The messaging layer is the cheapest decision to change and the easiest to overthink, and the robot standing up is what makes the decision obvious.

Here is the whole decision in five lines.

• If you want human-scale arms on a bench this year -> a printed upper body, because balance is what makes humanoids hard.
• If you want to understand walking -> a small open biped, because falling should be cheap.
• If you must reproduce a published result -> a research replica, because reviewers ask for the same platform.
• If a customer is waiting -> a commercial robot with an open interface, because assembly is not your product.
• If your onboard programs already fight for the same computer -> a shared-memory middleware, because the problem is between your own processes.

The HORUS Fit Framework compresses any of these into five axes: ecosystem size, setup effort, team size fit, deployment target, and licence. For humanoids, deployment target and licence are the two that surprise people, since a design that suits a lab bench often cannot be carried onto a robot.

When your humanoid grows past one program on one board, you will want the shared-memory option already bookmarked rather than hunted for at midnight. Put HORUS in your list now: star it so it is there when you start building.