Do Humanoid Robots Run ROS 2?

Most humanoid robots you can buy expose a ROS 2 interface, but the vendor's own controller, not ROS 2, keeps them standing. ROS 2 sits above the balance loop, carrying camera frames, maps and task commands, while walking runs in code the maker ships. That flips if you built the legs yourself, where the controller and the layer under it become your problem. The rest of this post is for someone choosing what to build on top of a humanoid, weighing a vendor SDK, ROS 2 and HORUS.

You are trying to work out what you would actually be programming. The product page says the robot supports ROS 2, and a forum reply says nobody serious runs ROS 2 on a humanoid, and a conference talk says the whole stack is learned end to end, and none of the three explains the others.

Underneath that is a purchase you may be about to make, or a job you may be about to take, and a suspicion that the answer changes what you should be learning this month. If the robot is a ROS 2 machine, that is one reading list. If the interesting parts are locked inside the vendor's software, that is a very different one, and possibly a shorter one than you hoped.

What makes this hard to research is that everyone answers a different question. Some people mean the robot ships with ROS 2 packages. Some mean the robot's own control software is built on ROS 2. Some mean the demo you saw was driven from a laptop running ROS 2 tools. Those are three different claims, and only one of them is usually true.

Do humanoid robots actually run ROS 2 today?

Most humanoids sold to developers ship a ROS 2 interface, and almost none of them run their balance controller on ROS 2. That split is the whole answer, and it is stable across the market. Unitree publishes ROS 2 packages for its humanoids. PAL Robotics, Fourier and several research platforms do the same. Boston Dynamics offers a ROS 2 driver for Spot, which is not a humanoid but sets the pattern the industry copies. In every one of these cases, the ROS 2 layer starts where the vendor's responsibility ends: you receive joint positions, camera frames and battery state, and you send walking targets, arm goals and stop commands. What you do not receive is the loop that decides how much torque each ankle needs this instant to stop the machine tipping over. The exceptions run in both directions. A few closed products, including the best-funded consumer humanoids, publish nothing programmable at all. And iCub, one of the longest-running research humanoids, is built on YARP rather than ROS, a reminder that ROS 2 is a strong default rather than a law.

What does it mean to say a robot runs ROS 2?

Saying a robot runs ROS 2 means its programs find each other and exchange messages using the ROS 2 conventions, and nothing more than that. ROS 2 is middleware. It is the postal system between the parts of a robot's software: the camera program publishes pictures, the mapping program subscribes to them, and neither needs to know where the other lives. Around that postal system sits the reason people actually adopt it, which is the enormous set of packages that already speak it, covering navigation, mapping, arm planning, coordinate frames, visualisation, recording and replay. What ROS 2 is not is an operating system, a control algorithm or anything that knows what a leg is. Nothing in ROS 2 knows how to walk. So when a specification sheet says a humanoid supports ROS 2, the claim being made is about the postal system and the packages, not about the intelligence of the machine. What middleware actually does in a robot is the longer version of this distinction, and it is worth being sure of before spending money.

What are your options for the software layer on a humanoid?

You have five realistic options, and most teams end up combining two of them. The first is the robot maker's own software development kit, which is where every project starts because it is the only thing that can command the machine at all. The second is ROS 2 layered above that kit, which is what most developers do, because it brings navigation, perception and tooling that would otherwise take years to write. The third is a stack you write yourself, which is honest work for a single-purpose product and a trap for anything general. The fourth is a training setup such as Isaac Lab, used when your goal is a learned policy rather than a program. The fifth is a single-machine middleware such as HORUS, used when everything runs on one onboard computer and your Rust, Python and C++ programs need to hand data to each other without the copying that a network-shaped layer like ROS 2 implies. Most humanoid work is option one plus option two. Option five earns its place only when one computer holds the whole system and languages are mixed.

How do the humanoid software options compare?

The order below runs from the layer nearest the hardware to the layer furthest from it, which is also roughly the order teams adopt them.

Read the last two columns first. Teams pick on the first two and discover the disqualifier a quarter later.

Which option fits if you bought a humanoid rather than built one?

Start on the vendor's software development kit, then add ROS 2 once you want packages you did not write. Buying a humanoid means buying the hard part already solved, and the fastest way to waste that purchase is to fight the layer the vendor supports. Your first week should be spent reading a sensor and printing what it says, then commanding one joint on a stand, then walking the robot across a room using the vendor's own calls. Only when you want a map of the building, an arm plan that avoids the table, or a recording of everything the robot saw does ROS 2 start paying for itself, and by then you know enough about the machine to wire the bridge sensibly. The mistake in the other direction is common too: teams who insist on ROS 2 from the first hour spend a month debugging a bridge instead of learning what the robot does. What actually runs inside a humanoid maps the layers if the boundary between vendor code and your code is still unclear.

What computers are inside a humanoid, and does that change the answer?

A humanoid usually carries two or three computers, and that fact decides how much the messaging layer matters to you. There is a small controller close to the motors, running on timing hardware or a real-time-tuned kernel, which is the vendor's territory and not yours. There is a main computer, often a compact machine with a graphics processor, which is where your perception and decision code will live. Some designs add a third board for cameras. The reason this matters is that the arguments about middleware are mostly arguments about crossing boundaries. Messages that stay inside one computer can be passed cheaply. Messages that cross to another board, or worse over wireless, are where delays, dropped frames and the familiar complaints begin. So if all your code sits on the main computer, the messaging layer is a convenience question and you should pick for the ecosystem. If your design sprays work across boards and a laptop, the messaging layer becomes the thing that decides whether the robot behaves the same way twice.

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

Use the vendor's software development kit alone, and add nothing else until the demo is over. Short deadlines punish every layer you introduce, because each one adds a place where something can be misconfigured at the worst possible moment. A humanoid demo that has to work in front of people needs three things: a reliable stop, a behaviour rehearsed enough that the failure modes are known, and as few moving parts in the software as you can manage. The vendor's calls give you all of that with the fewest unknowns. If the demo requires something the kit does not do, such as recognising an object and walking to it, add exactly one piece rather than an ecosystem, which usually means a Python script beside the kit rather than a full ROS 2 graph. Teleoperation is also a legitimate answer for a deadline, and openly saying a person is driving is far better than a demo that collapses. What you are actually watching in robot demos is worth reading before you promise autonomy.

What skill level does running ROS 2 on a humanoid need?

More than a ROS 2 tutorial gives you, and less than a doctorate. The honest entry requirement is comfort in a Linux terminal, one language between Python and C++, and the patience to read error messages that describe a graph rather than a program. What makes a humanoid harder than the wheeled robot in the tutorials is not the ROS 2 part, it is that a humanoid can fall, so every mistake has a physical cost and the robot must be on a stand or a gantry until you trust your own code. The second difficulty is coordinate frames. A humanoid has many joints and several cameras, and getting confused about which frame a measurement is in is the classic beginner failure, producing a robot that reaches confidently towards a place the object is not. Budget months rather than weeks, and start in simulation, where a fall costs nothing and you can repeat the failure until you understand it. Nothing you learn there is wasted when the real machine arrives.

What goes wrong when a team puts the whole humanoid on ROS 2?

The robot works in the lab, becomes unpredictable in a real building, and nobody can say which layer caused it. The pattern is recognisable. Someone routes everything through the messaging layer because uniformity feels tidy, including things that should have stayed inside one program. Then the wireless link gets busy, or a camera process gets hungry, and messages start arriving late or out of order. The behaviour that emerges is not a crash, which would at least be honest; it is a robot that hesitates before a step, or reaches slightly behind a moving object, or does the right thing four times and something strange on the fifth. Every one of those looks like a bug in the code you wrote, which is where the team spends its month. The tell is that failures cluster when something unrelated is busy, and that the same code behaves perfectly on a quiet bench. The fix is boundaries: keep the fast loop inside one process, cross the messaging layer only where a genuine boundary exists, and stop putting anything safety-related on wireless.

What do you give up by choosing ROS 2 on a humanoid?

You give up simplicity, and you give up the ability to reason about timing without effort. A ROS 2 humanoid has many programs, launch files that start them, parameters that configure them, and a discovery step that has to find them all, so the number of things that can be wrong on a Tuesday morning goes up sharply. You also inherit the ROS 2 approach to time and delivery, which is designed for a network, so data that only ever moves between two programs on the same board still takes a path built for the general case. That is fine for camera frames feeding a planner and less fine for anything that must land before the next control step. The third cost is version discipline: your work is now tied to a ROS 2 release, and the packages you depend on have their own opinions about which one. What you buy in return is genuinely large, which is why most teams pay it: navigation, mapping, arm planning, visualisation, recording and a hiring pool that already knows the vocabulary.

When is ROS 2 the better choice?

ROS 2 is the better choice for almost every humanoid project that involves a robot you bought. If you need mapping, navigation, an arm planner, coordinate frame handling, or the ability to record a run and replay it while you argue about what went wrong, those exist today in the ROS 2 world and nowhere else in comparable depth. ROS 2 also wins when the team is more than a few people, because it is the only vocabulary a new hire is likely to arrive with, and it wins when the work must be published, reviewed or handed to a customer who expects a familiar structure. HORUS is not the answer in any of those cases, because a shared-memory layer for one machine gives you no perception packages, no planner and no vendor bridge, and pretending otherwise would waste your quarter. The narrow case where a different layer earns consideration is a single onboard computer running mixed-language programs that must hand each other data on a fixed rhythm, which is a real situation on humanoids but a small slice of the work.

Is ROS 2 the reason humanoid demos are teleoperated?

No, and here is why. Teleoperation appears in humanoid demonstrations because nobody has solved general autonomy in unfamiliar rooms, not because of anything in the messaging layer. A person wearing trackers handles the thing that defeats every autonomous system: a situation that was not in the training data, in a house nobody surveyed, with an object nobody labelled. That is a research gap, and it would remain a research gap if the middleware were replaced tomorrow. There is a second reason, which is that teleoperated runs are how the demonstration data for future learned policies gets collected, so operating the robot by hand is productive work rather than a cover story. What the software layer does affect is a narrower thing: how much lag an operator feels, and whether video and commands cross a network cleanly. That is worth engineering well, and it is not the reason the laundry-folding video needed a human in the loop. Whether home humanoids are actually autonomous goes through the evidence case by case.

Does a vendor's ROS 2 support mean you can command every joint?

Partly, but not the way you think. Vendor ROS 2 packages usually do expose joint-level commands, and you can send them, and the robot will move. What you cannot do is take over the layer that keeps the machine balanced, because that layer sits below the interface and keeps running whether you like it or not. In practice this means your joint commands are requests filtered through a controller that will override you the moment the robot's balance is at stake, which is the correct design and the reason the robot is not on the floor. Some platforms offer a lower-level mode that hands over more authority, and it is usually accompanied by a warning and a gantry, because a humanoid with its balance controller disabled is a heavy object with no plan. The practical consequence for you is scope: novel walking gaits and whole-body control research need a platform that explicitly supports that, while application work sits above the boundary and does not care. What works out of the box on a Unitree G1 is a concrete example of where the line falls.

How do you decide what to run on your humanoid?

Decide by asking which layer your actual work lives in, then pick the smallest thing that reaches it. If the work is application logic, so recognising something and deciding what the robot should do, start on the vendor kit and add ROS 2 when you want packages you did not write. If the work is perception and navigation, go to ROS 2 immediately, because rewriting mapping is a career, not a sprint. If the work is a new gait or whole-body control, your first question is not middleware at all, it is whether your platform gives you that authority, and most do not. Then check three practical things before committing. Check which ROS 2 release the vendor supports, because a mismatch there costs weeks. Check whether the robot's own computer will hold your code or whether you are planning to lean on a laptop over wireless, since that decision shapes everything downstream. And check the exit: task logic and learned policies move between platforms, while vendor-specific calls and launch files do not.

Where that leaves you, in five lines:

• If you bought a humanoid and want application work -> the vendor SDK first, ROS 2 second, because the bridge is only worth building once you need it.
• If you need mapping, navigation or arm planning -> ROS 2, because those packages exist there and nowhere else in that depth.
• If everything runs on one onboard computer in mixed languages -> a shared-memory layer, because crossing a network-shaped path buys you nothing there.
• If you are researching gaits or whole-body control -> a platform that grants low-level authority, because no middleware can hand you what the vendor withholds.
• If a demo is due next month -> the vendor SDK alone, because every extra layer is another thing to misconfigure on the day.

The HORUS Fit Framework is the compact version of that reasoning, and its five axes apply to humanoids as well as to anything else with motors: ecosystem size, setup effort, team size fit, deployment target and licence. Humanoid teams reliably underrate deployment target, then discover the whole design assumed a laptop nearby. If you want to try the layers apart from the hardware first, free simulators that run on a laptop is the cheapest place to start.

HORUS is open source under Apache-2.0 at github.com/softmata/horus. Star it so it is in your list when you start building.