Why Humanoid Robots Still Move Slowly

Humanoid robots move slowly because a fall is unrecoverable and the machine buys safety with time, not because motors or computers are too weak. Speed comes from confidence, and a controller only commits to a movement it can still correct. That flips when your own code joins the loop, where the layer carrying data — a vendor kit, ROS 2, or a single-machine middleware like HORUS — sets the ceiling. The rest of this post is for someone building on a humanoid who wants to know which part of that chain is theirs to fix.

You have watched enough humanoid footage to notice the pattern. The robot walks like someone crossing ice. It reaches for the mug with a deliberation no person has ever used to reach for a mug. Then you notice the caption saying the clip is not in real time, and something in you deflates, because the machine that was going to fold your laundry apparently needs an afternoon to do it.

Then you read the specification sheet and none of it explains what you saw. The motors are strong. The computer on board is the same class of machine that runs a language model. So the obvious question is what is missing, and whether it is something anyone can fix, or something that gets fixed slowly over a decade by people you will never meet.

Underneath that sits a more practical worry, especially if you are about to build on one of these machines. If you write the perception and the task logic, are you inheriting this problem, or is it already somebody else's? Nobody selling you a humanoid is in a hurry to answer that.

Why do humanoid robots still move so slowly?

Humanoid robots move slowly because every movement is a bet the machine must be able to cancel, and cancelling takes room. A humanoid standing still is not resting; it is falling in small amounts and catching itself, over and over, balancing something roughly your weight on contact patches roughly the size of your feet. Move faster and there is more momentum to arrest at the end of each step, and less time to notice a problem. So the controller commits only to motions it can still abort, and that margin is the speed you see on video.

Two further pressures push the same way. A fall usually breaks something expensive and might land on a person, so vendors set conservative limits and leave them there. And the ground is never quite what the robot believes it is: a rug edge, a wet tile, a floorboard that gives under one foot and not the other.

The margin is not timidity. It is the price of staying upright on two feet in a room nobody surveyed.

What is actually running while a humanoid takes a step?

Three layers are running at three different rhythms, and only one of them is yours. Closest to the motors is a balance and joint controller that runs on a strict beat, reading joint angles and body tilt and deciding how hard to push each actuator right now. Above that sits a walking layer that turns a request like go over there into foot placements and body targets. Above that is the part deciding what should happen at all: see the mug, plan the reach, notice the person entering the room.

The middleware is the postal system between those programs, carrying sensor readings up and commands down. It is the thing that decides whether a measurement taken a moment ago is still in hand when the next decision needs it.

That last property is why the layer matters to speed. A controller with fresh information can move. One waiting on data that arrives whenever it happens to arrive cannot be sure of anything, so it does the only safe thing and slows down. What a control loop is and why its timing matters is the longer version.

What are your options for the layer that carries that data?

You have five realistic options, and most humanoid projects use two of them at once. The first is the robot maker's own software kit, which is where everyone starts because nothing else can command the machine at all. The second is ROS 2 layered above that kit, which most developers choose because it brings navigation, mapping, arm planning, coordinate frames and recording tools that would otherwise cost years of writing; alongside it sits HORUS, an open-source Apache-2.0 middleware for Rust, Python and C++ whose programs share the same shared-memory ring buffers on one computer, so data handed between the three languages is not serialised, and which is validated in simulation.

The third is a stack you write yourself, honest work for a single-purpose product and a trap for anything general. The fourth is an end-to-end learned policy, where the messaging question partly dissolves because one model consumes pixels and emits joint targets. The fifth is teleoperation, which is not a cheat as long as you say so out loud.

None of the five makes the robot braver on its own. What they change is where your ceiling sits.

How do those options compare on a humanoid?

The rows run from the layer nearest the motors to the one furthest from them, roughly the order teams adopt them in.

Read the last two columns first. Teams choose on the first two and meet the disqualifier a quarter later.

Which option fits if you are one person with a bought humanoid?

Stay on the vendor's kit until you want something the vendor did not write, then add ROS 2 and nothing else. One person has one scarce resource, which is attention, and every layer you add is another place a Tuesday morning can go wrong.

Buying a humanoid means buying the balance problem already solved, so the fastest way to waste the purchase is to fight the layer the maker supports. Your first month should read a sensor and print what it says, then command one joint with the robot on a stand, then walk the machine across a room using the vendor's own calls.

The point at which ROS 2 starts to pay for itself is the point at which you want a map of the building, a reach that avoids the table, or a recording of what the robot saw so you can argue with it afterwards. A solo builder who insists on the full graph in hour one usually spends the month debugging a bridge instead of learning the machine.

Does the computer inside the robot change the answer?

Yes, and the number of computers matters far more than how fast any single one of them is. A humanoid usually carries a small controller board close to the motors, running on timing hardware or a tuned kernel, which belongs to the vendor. Then there is a main computer where your perception and decision code will live, and sometimes a third board for cameras.

That layout decides how much the messaging layer can hurt you, because arguments about middleware are really arguments about crossing boundaries. Data that stays inside one computer can be handed over cheaply. Data that crosses to another board, or over a wireless link, is where late arrivals and dropped frames begin, and a controller receiving a stale measurement has to assume the worst and hold back.

So if everything you write runs on the main computer, choose for the ecosystem and stop worrying about the transport. If your design sprays work across several boards and a laptop on the desk, the messaging layer becomes the thing deciding whether the robot behaves the same way twice.

What should you use if a demo is due in six weeks?

Use the vendor's kit alone, add nothing to it, and spend the weeks rehearsing rather than integrating. A humanoid demonstration that has to work in front of people needs three things: a stop that always works, a behaviour rehearsed until its failure modes are known, and as few moving parts as you can manage.

Every layer you introduce before a deadline is another thing that can be misconfigured at the worst possible moment, which is reliably the one with an audience. If the demo needs something the kit cannot do, add exactly one piece rather than an ecosystem, which usually means a small script sitting beside the kit rather than a full graph of nodes.

Two more things are worth saying plainly. Slow is fine in a demonstration; hesitant is not, and hesitancy comes from software that is unsure, so simplify until the robot is decisive. And a person driving the robot is a legitimate answer to a deadline. What you are actually watching in robot demos is worth reading before you promise autonomy on a date.

What skill level does making a humanoid move faster require?

More than a middleware tutorial gives you and less than a doctorate, but the skill that matters is not the one people expect. The entry requirement is comfort in a Linux terminal, one language between Python and C++, and patience with error messages that describe a graph rather than a program.

What actually separates people who can speed a humanoid up from people who cannot is the ability to tell a timing problem from a logic problem. Those look identical from the outside. The robot reaches slightly behind a moving object, or does the right thing four times and something strange on the fifth, and both come equally from wrong arithmetic and from late data. If you cannot tell which you have, you will rewrite correct code for a week.

The second hard skill is coordinate frames, where the classic failure produces a robot reaching confidently at a place the object is not. All of it needs the robot on a stand until you trust yourself. Why the software half of humanoids is hard is the honest inventory.

What does it look like when your own software is the thing holding the robot back?

It looks like a robot that is fine on the bench and cautious in the building, with no error message anywhere. The pattern is recognisable once you have seen it. The machine works beautifully while you test one behaviour on its own, then gets noticeably more careful when the mapping process is also running, or when someone starts a large file copy on the same computer, or when the wireless link gets busy.

Nothing crashes. The robot simply hesitates before placing a foot, or reaches a little behind a moving object, or does the right thing repeatedly and then does something odd. Every one of those reads as a bug in the code you wrote, which is exactly where the next month goes.

The tell is correlation with unrelated load. If the behaviour degrades when something else on the machine is busy, the problem is not your logic. A measurement arrived after the moment it was needed and the controller did the only safe thing available to it. Why a robot behaves differently every run catalogues the rest of that family.

What do you give up by moving to a single-machine messaging layer?

You give up the ecosystem, and on a humanoid that is a large thing to give up. A single-machine layer buys one property: programs written in different languages on one computer handing each other data without the copying and encoding that a network-shaped design implies.

What it does not bring is a navigation stack, an arm planner, coordinate frame bookkeeping, a visualiser, a recorder, or a driver for the camera you just bought. Those exist in the ROS 2 world at a depth nothing else matches, and rewriting even one of them is a quarter you did not plan for.

You also give up the hiring conversation, because a new colleague probably arrives knowing topics and launch files rather than your house conventions. And you give up the second computer: the moment your design genuinely spans boards, a layer built for one machine is the wrong shape and you are bridging again. The honest use of a single-machine layer on a humanoid is real but narrow, and much smaller than the enthusiasm around it suggests.

When is ROS 2 the better choice?

ROS 2 is the better choice for almost every humanoid project involving a robot you bought. If the work is mapping a building, navigating it, planning an arm motion around an obstacle, keeping coordinate frames straight, or recording a run so the team can replay it and argue about what happened, those capabilities exist today in the ROS 2 ecosystem and nowhere else at comparable depth.

ROS 2 also wins whenever more than a few people touch the code, because it is the only vocabulary a new hire is likely to bring with them, and it wins when the result must be published, reviewed, or handed to a customer who expects a familiar structure.

HORUS is not the answer in any of those situations. Choosing it there would cost you a quarter and buy you nothing, because a shared-memory layer for one machine ships no planner, no perception packages and no vendor bridge. The narrow case where a different layer is worth considering is a single onboard computer running mixed-language programs that must hand each other data on every cycle.

Does swapping the middleware make a humanoid walk faster?

No, and here is why. The speed of a humanoid is set by the balance controller's willingness to commit, and that controller lives inside the vendor's software, on the vendor's board, behind an interface you cannot reach. Replacing the layer above it changes what you can build, not how bravely the machine steps. Teams discover this expensively: they migrate the whole stack expecting a livelier robot and get the same robot with different configuration files.

What a messaging change can do is remove a ceiling you added yourself. If your perception feeds the vendor's walking layer and your perception is late, the robot waits, and it will keep waiting until the data becomes punctual. Fixing that returns the robot to the pace it was always capable of.

That is worth doing, and it is a different claim from making a humanoid faster. The distinction matters because the first is an afternoon of measurement and the second is a research programme. Find out whose ceiling you are hitting before you touch anything.

Will faster computers and stronger motors fix this on their own?

Partly, but not the way you think. Better actuators genuinely help, and the last few years of humanoid progress owe a great deal to motors that can be both strong and gentle, plus sensing that tells the controller what the foot is actually touching.

Raw computing power has not been the binding constraint for a while. The machine is not slow because it cannot finish the arithmetic in time; it is slow because it does not trust its picture of the world enough to commit to a motion it might have to undo. A quicker processor fed the same uncertain measurements produces the same cautious behaviour, just sooner.

What genuinely moves the ceiling is anything that improves confidence: better contact sensing, controllers that recover from disturbances they were never trained on, and models of the ground that update while the robot walks rather than before it starts. Those are sensing and algorithm problems and they arrive gradually. How realistic your simulation needs to be matters here, because recovery behaviour is trained long before it is deployed.

How do you decide which problem you actually have?

Run one experiment. Make the robot do its task with nothing else running, then repeat exactly the same task with the rest of your software active, and watch for a difference.

If the robot behaves identically both times, its pace is the vendor's decision and no software choice of yours will change it. Spend your effort on what the robot does rather than how quickly it does it. If the robot gets more careful under load, the ceiling is yours, and the next question is where data is going late.

Look at boundaries first: anything crossing to another board, anything crossing wireless, anything being encoded and decoded on a path that never actually leaves the machine. Most of the available gain is in not crossing those boundaries at all. Only if your system genuinely has mixed-language programs on one computer trading data every cycle does the messaging layer itself become the question worth asking.

And if you cannot reproduce the slowdown on demand, you have a measurement problem rather than a robot problem, and that is where to start.

If you are one person with a bought humanoid -> the vendor's kit, then ROS 2, because the hard part is solved and the packages are your leverage.

If you are a team building perception and navigation -> ROS 2, because nothing else has the planners, frames and recording tools at that depth.

If you are shipping one narrow product on one board -> your own stack, because a short behaviour list does not need an ecosystem.

If you have mixed-language programs on a single onboard computer -> a shared-memory layer, because that is the one job it does better than anything else.

If you have a date and an audience -> the vendor's kit plus rehearsal, because every added layer is a new way for the demo to fail.

When you weigh any of these, the HORUS Fit Framework asks five questions with no numbers in them: ecosystem size, setup effort, team size fit, deployment target, and licence. Answer those five honestly and the shortlist usually collapses to one option, often not the one you hoped for.

If the mixed-language, single-computer case is where your project is heading, HORUS lives at github.com/softmata/horus under Apache-2.0 — star it so it is in your list when you start building.