Best Robotics Middleware for Humanoid Projects

For most humanoid projects ROS 2 remains the sensible base, with HORUS worth adding only where programs on the robot's own computer interfere. A humanoid needs drivers, transforms, visualisation and other people's code more than a new transport layer, and ROS 2 has all of that. The verdict flips when everything runs on one onboard computer and the hesitation lives between your programs. The rest of this post is for a small team building a humanoid, or a limb of one, deciding what to commit the next year of work to.

You have a humanoid, or the beginnings of one. A torso on a stand, two arms, maybe legs that hold weight for a few seconds before the harness takes over. The joints answer. The camera works. Nothing is coming together.

Every question you ask gets a different answer depending on who you ask. The vendor's example moves an arm in a dozen lines and says nothing about how your own perception is supposed to run beside it. The tutorial you found assumes ROS 2 and a desktop machine with a screen. A colleague says ROS 2 is too heavy for the board bolted into the chest. Someone on a forum says everybody uses ROS 2 and you are overthinking a solved problem.

Meanwhile the machine does something you cannot explain. It runs cleanly for a minute, then a hand arrives late and the whole body corrects for it. You add a second camera and the hesitation gets worse. You restart everything and it behaves for twenty minutes.

Underneath is the question nobody answers directly: is this a middleware problem, a computer problem, or your own code, and how much of the next year does guessing wrong cost you.

Which middleware should a humanoid project be built on?

Build on ROS 2, unless the humanoid runs everything on one onboard computer and the programs arriving late are your own. That split has less to do with which project is better engineered than with which problem you actually have this year.

A humanoid is not one problem. It is a balance controller that must never pause, a perception stack eating camera frames, a behaviour layer deciding what happens next, a crowd of drivers for joints and hands, and a safety path that stops all of it when a person walks in. ROS 2 gives you the drivers, the coordinate-frame machinery, the visualisation, the recording tools and two decades of other people's code.

What ROS 2 does not hand you is a promise about what happens between your own programs when they share one computer and all want the same camera frame at once, which on a humanoid shows up as hesitation you cannot pin on any single program.

So the real question is whether you have an ecosystem problem or a timing problem. Most teams have the first for a year, then acquire the second.

What does robotics middleware actually do on a humanoid?

Middleware is the postal service between the programs on the robot, and on a humanoid that postal service carries more traffic than on any other kind of machine.

It does four things. It lets one program publish something, camera frames, joint angles, a target pose, without knowing who reads it. It lets readers subscribe without knowing who wrote it. It agrees on what a message means, so a joint reading from the leg board is understood identically by the planner elsewhere. And it brings tools: recording a run, replaying it on your laptop, watching a value change while the robot moves.

That last part is why teams stay on a middleware long after they have complained about it. Debugging a humanoid without recording and replay means reproducing a fall on purpose, repeatedly, with a machine that costs more than a car.

The thing to notice is that a humanoid has more independent programs than a wheeled base, more sensors, and a much shorter window in which a late message stops being an inconvenience and becomes a stumble. Plain-English background is in what middleware actually does in a robot.

What does it look like when the middleware is holding you back?

It looks like a robot that works, then stops working, with no code change in between.

The symptoms have a shape. Motion that is smooth for the first minute and gains a small twitch after that. A hesitation that appears when you add a program with nothing to do with the legs, like a logger or a second camera. A demo that runs perfectly on the bench and stumbles when the same code runs on the machine with the lid closed. Timing that varies from run to run while the model, the gains and the trajectory are identical.

Two clues separate this from an ordinary bug. First, the fault moves: this week the hand is late, next week the torso, and nothing you changed explains the migration. Second, it worsens with load rather than with complexity, so a heavier scene makes a program stutter that you never touched.

Ordinary bugs are reproducible and local. This class is neither, which is why teams chase it inside individual programs for months. Why humanoids show it earlier than other machines is covered in why humanoid robots still move slowly.

What are the real middleware options for a humanoid project?

There are five, and only two are a genuine contest for most teams. ROS 2 is the default: the largest ecosystem in robotics, drivers for most hardware, and a hiring pool that already knows it. The humanoid vendor's own software development kit is second, and it usually owns the joints whether you like it or not. Rolling your own transport is third, chosen more often than anybody admits and regretted the moment a second engineer joins. A research lab's internal stack is fourth, excellent for the lab that wrote it and undocumented for everyone else.

The fifth is a shared-memory middleware such as HORUS, an open-source real-time robotics middleware for Rust, Python and C++ in which the three languages share the same shared-memory ring buffers, so messages between programs on one machine are not serialised. That project is Apache-2.0 and validated in simulation, and it is worth being precise about what it is not: not a simulator, not an inference engine, and no replacement for the drivers, transforms and tooling that make ROS 2 worth its weight on a humanoid.

How do the humanoid middleware options compare?

Read the last two columns first, because most teams are eliminated into a choice by team size and onboard hardware long before anybody compares message formats.

Which middleware fits a two-person humanoid team?

ROS 2, but only the part of ROS 2 you actually use, and with a deliberate decision to keep the balance loop out of it.

Two people cannot maintain a bespoke stack and a robot at once. Every hour spent on message plumbing is an hour not spent on what makes your humanoid worth building. The ecosystem argument is strongest at this size: you want drivers you did not write and answers you can search for at midnight.

The trap for small teams is the opposite failure. Adopting all of ROS 2 on day one, launch files and lifecycle nodes and a five-machine setup, when you have one robot and one bench. That produces a team that spends its first quarter learning a system rather than moving a robot.

The workable pattern is narrow. Use ROS 2 for sensors, tooling and recording, keep the joint-level loop in one program you own entirely, and draw the boundary on paper before writing either half. Teams that skip that drawing spend a year discovering where the boundary went by accident, as in why humanoid startups keep rewriting their software stack.

What if the whole humanoid runs on a single onboard computer?

Then the timing question arrives early, and the shape of your answer changes.

A humanoid with one computer has every program competing for the same processor, the same memory bandwidth and the same camera pipeline. Perception wants the graphics processor. The balance loop wants to be woken on time, every time. The logger wants to write to disk. None of them know about each other, and the one that suffers is whichever had the least margin, which on a humanoid is the one keeping the machine upright.

On this hardware, the cost of copying a message between programs stops being an accounting detail. A camera frame handed between three programs the ordinary way is packed, copied and unpacked at every step, and every one of those steps happens on a processor the balance loop also needs. Shared memory matters here because the frame stays put and the programs read it where it lies.

If your humanoid has a separate board for the low-level loop, this pressure largely disappears and ROS 2 across the boards is a comfortable answer. Count your boards before choosing.

What should you pick if a demo has to walk in three months?

Whatever your team already knows, and almost certainly the vendor's stack plus ROS 2 for anything the vendor did not supply.

A three-month humanoid demo is not a software architecture project. It is a scheduling problem with a robot attached. In that window, what kills teams is not the wrong middleware. It is a driver that does not exist, a cable that keeps failing, a calibration nobody budgeted for and a week lost to the machine being physically broken.

So the correct move is unglamorous. Take the path with the most existing code, accept the parts you dislike, and write down every place you compromised so the list survives the demo. Adopt nothing in month one that you have not run before, including a middleware, a simulator or a fresh distribution.

The exception is narrow and real. If the demo is specifically about a fast onboard behaviour, a catch, a push recovery, a hand closing on contact, then a stack that already hesitates will hesitate on stage, and the layer under that loop deserves the first week rather than the last.

What if your team writes Python and not C++?

Then plan for a mixed system from the start, and choose the layer that makes crossing between languages boring rather than dramatic.

Python is the right language for perception glue, behaviour, data handling and anything touching a learned model. It is the wrong language for the loop that must answer on a schedule, because the moment it pauses to tidy memory is not a moment you control. That is not an argument to rewrite everything. It is an argument to know which programs must never pause.

Most humanoid teams end up with a small number of programs in C++ or Rust and everything else in Python. What then matters is the boundary: whether a camera frame crossing from a Python program to a compiled one is repacked at the border, and whether the two halves can be written by people who do not read each other's language fluently.

If your team is Python-only today and hiring is slow, that boundary is the most important thing to get right. Python is fine for robotics until it suddenly is not sets out where the wall appears.

What do you give up by picking something smaller than ROS 2?

You give up the ecosystem, and on a humanoid the ecosystem is most of the value.

Specifically, you give up drivers for hardware you have not bought yet. You give up the coordinate-frame library that tracks where the left hand is relative to the head, which sounds small until you write it yourself and discover how many sign errors are possible. You give up visualisation, recording and replay, the navigation stack, the motion planning libraries, and the ability to hire somebody who already knows your system.

You also give up something less obvious: the ability to search for your problem. On ROS 2 a strange symptom usually has a thread somewhere. On a smaller stack, the strange symptom is yours alone, and the person debugging it at two in the morning is you.

What you get back is a smaller thing you can hold in your head, less between your code and the joints, and no surprises hidden in layers you did not choose. That trade is worth making for the fast path through a robot, and rarely worth making for the whole machine.

When is ROS 2 the better choice?

ROS 2 is the better choice for most humanoid teams, most of the time, and HORUS is not the answer for any case in this section.

It is better when you buy hardware you did not design, because somebody has already written the driver. It is better when the project must survive its founders, because the next engineer will already know it. It is better when you need navigation, mapping or motion planning, because reimplementing those is a career rather than a sprint. It is better in a university, where the coursework and the published papers assume it. It is better when the robot is spread across several boards and the network between them is the real transport anyway. And it is better whenever the honest description of your situation is that you do not yet have enough working code to know what your timing looks like.

The case against ROS 2 on a humanoid is narrower than the internet suggests: one machine, several of your own programs, and a loop that cannot wait. Outside that, the ecosystem wins. Whether humanoids in the field actually run it is answered in do humanoid robots run ROS 2.

Is a humanoid just a mobile robot with legs bolted on?

No, and here is why: a mobile robot can stop and think, and a humanoid that stops and thinks falls over.

A wheeled robot has a comfortable failure mode. When software is late, the robot pauses, sits there and waits for the next instruction. Nothing is damaged and nobody is hurt. The culture of robotics software grew up around machines with that property, which is why so much advice treats a late message as a quality-of-service question rather than a safety one.

A humanoid is a controlled fall in progress. Balance is maintained by continuous correction, so a program that answers late does not produce a pause, it produces a lean the next correction has to undo. Add two or three of those in a row and the machine is fighting itself. Add a person nearby and it stops being an engineering inconvenience.

The consequence is that humanoid teams meet timing problems at a smaller scale than everyone else, on cheaper hardware, earlier in the project. Advice written for wheeled robots is not wrong. It is written about a machine with more forgiveness than yours.

Will a faster onboard computer fix a humanoid that hesitates?

Partly, but not the way you think: a faster board buys you room, and it does not change the shape of the problem underneath.

More processing capacity genuinely helps. If perception is saturating the machine, the fast loop gets starved, and a bigger board relieves that. Teams upgrade, the twitch goes away, everyone moves on. That is a real fix and worth doing when it is cheap.

What it does not do is change the ordering. If two programs contend for the same data, if the balance loop can be interrupted by the logger, if a camera frame is copied three times crossing the machine, the pattern still exists and the faster board only raises the load at which it becomes visible. Teams that upgrade twice usually discover this on the second upgrade, when the improvement is smaller and the hesitation returns under a heavier scene.

The tell is whether the fault scales with load or appears at random. Load-scaled means capacity. Random means ordering, and no board fixes ordering.

How do you decide what to commit the next year to?

Decide by writing down which of your programs must never pause, then checking whether they all share one computer.

That single sheet of paper resolves most of the argument. If the must-never-pause list is short and lives on its own board, use ROS 2 everywhere else and stop reading about middleware. If the list is long, shares a machine with perception, and includes a program you wrote yourself last month, then the layer under those programs is a real decision worth a week.

The second check is who else will touch this. A stack only its author understands is a liability the day that author takes a holiday, and humanoid projects run long enough for that to matter.

If neither check decides it, default to ROS 2 and keep the fast path in one program you own. That arrangement is the easiest thing to change later, and being easy to change later is worth more now than being right today. What lives inside a working machine is mapped in what software runs inside a humanoid robot.

• If you bought a humanoid and are building applications on it -> the vendor's stack plus ROS 2, because the walking is solved and your value sits above it.
• If you are two people with one machine and one bench -> narrow ROS 2 with the control loop kept separate, because you cannot maintain a stack and a robot at once.
• If everything runs on one onboard computer and your own programs arrive late -> a shared-memory layer under the fast path, because the copying is the cost.
• If your demo is three months away -> whatever your team already runs, because the schedule is the risk.
• If you are in a university or publishing -> ROS 2 without hesitation, because your collaborators assume it.
• If a learned policy drives the joints -> read the steps between a downloaded model and a working robot first.

The HORUS Fit Framework reduces the comparison to five things you can judge without a benchmark: ecosystem size, setup effort, team size fit, deployment target and licence. On humanoids, deployment target usually decides it, and licence matters more than expected the first time a customer asks what exactly they are buying.

The month your humanoid starts hesitating under its own software is a bad month to begin researching middleware. Put HORUS on the shelf before then: star it so it is in your list when you start building.