Are Home Humanoids Really Autonomous?

No. Home humanoids today are mostly driven by a person or running a rehearsed routine, with real autonomy limited to a few practised tasks. Walking and balancing genuinely run onboard; deciding what to do next in an unfamiliar kitchen does not, and editing hides the difference. That flips for one repeated task in a fixed spot, where the stack underneath, whether ROS 2, a vendor kit or HORUS, starts to matter. The rest of this post is for someone deciding whether to buy one, work on one, or write software for one in the coming year.

You watched the video where the robot folds a shirt, and it did not look faked. Then you watched it again and noticed the shirt was already flat on the table, the lighting was studio lighting, and the cut happens the moment the second sleeve goes over. Somebody in the comments says there is a person in a motion capture suit off camera. Somebody else says that is a lie and the model is doing it end to end. Neither of them offers a way to tell.

Meanwhile there is a waiting list you can join and a price that would buy a car, and the page says the machine learns new tasks. You cannot work out whether that means it learns them in your house or whether a team of engineers spends a month teaching it in theirs.

And if you are the kind of person who might work on this, there is a second worry underneath the first. If the impressive part is a human being in a headset, then the interesting engineering problem is not the one the videos are advertising, and you would rather know that before you rearrange a career around it.

Are home humanoids autonomous today, or are people driving them?

People are driving them for most of what you see, and the robot is genuinely on its own for the rest. Both halves of that sentence are true at once, which is exactly why the argument never resolves in a comment thread.

The autonomous half is real and it is not small. A modern humanoid keeps its own balance, walks across an uneven floor, catches itself when pushed, and stands back up after falling, all from computers bolted inside its own body with nothing remote involved. That was a research problem for decades and it is now something you can buy.

The driven half is the half you find interesting. Loading a dishwasher, folding laundry, tidying a worktop with objects nobody arranged in advance: those are usually teleoperated in demonstrations, or run as a policy trained for that specific setup, in that specific room, with that specific set of objects. Move the bin two feet, add a dog, change the lighting, and the success rate drops in a way the video never shows.

So the correct answer to a friend who asks is: it walks by itself, and it tidies by imitation.

What does autonomy actually mean for a robot in a house?

Autonomy is not one property, and treating it as one is what makes the whole conversation confusing. It comes in at least four layers, and a home humanoid today passes the first two, struggles with the third and fails the fourth.

The first layer is keeping itself alive: balance, joint control, not falling down stairs. Solved, onboard, unglamorous.

The second layer is executing a known task in a known place. Pick the cup from the spot where the cup is, put it where cups go. Achievable now, sometimes impressively, and it is the layer demonstrations are filmed at.

The third layer is handling the world as it actually is. The cup has coffee in it. There is a tea towel over the handle. A child moved the shelf. Success here falls off a cliff, and the honest description is that the robot manages it sometimes and asks for help or freezes the rest of the time.

The fourth layer is deciding what is worth doing. Nobody has this. A humanoid that notices the kitchen is a mess and starts on it without being asked does not exist outside of narration over a video.

What are the real options if you want to build or buy a humanoid?

There are five paths, and only two of them are sensible for most people. You can buy a consumer preview unit and join an early access programme, which mostly buys you a place in a queue and a support relationship. You can buy a research humanoid of the class that legged robotics labs use, which is expensive but real, comes with a software kit, and expects you to be the engineer. You can buy arms and hands and skip the legs, which is what most manipulation groups quietly do because legs consume the budget and contribute nothing to the problem they care about. You can work entirely in simulation until the hardware market settles, which is genuinely productive now. Or you can build the software layer for somebody else's machine.

That last path is where the stack question lives. What runs inside is a control loop talking to sensors and motors, and the layer carrying those messages is ROS 2, a manufacturer's own kit, or a middleware such as HORUS, an open-source real-time robotics middleware for Rust, Python and C++ where 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 not a robot, not a model and not a product you can put in a kitchen. A fuller tour of the layers sits in what software runs inside a humanoid robot.

How do the humanoid software options compare side by side?

Read the last column first, because almost everyone is eliminated into a path rather than argued into one. Budget, whether you have somewhere to safely run a walking machine, and how much of your week is genuinely free will cross out most of this table before taste matters.

No column ranks how humanlike anything looks, because appearance predicts nothing about whether a machine is useful in a house.

Which kind of buyer or builder are you?

The right answer changes completely depending on which of four sentences describes you, and people go wrong by reading advice written for a different sentence. Find yours before reading anything else about humanoids.

If you want a machine that reduces your housework, you are a customer, and the honest answer is that the product you want does not exist yet. Nothing on the market removes a chore from your week without supervision, and buying now means owning a project.

If you want to work on humanoid software as a career, you are an engineer, and hardware is optional for the first year. Everything you need to learn about control, perception and manipulation can be learned against a simulated robot on a laptop, and the people hiring care whether you understand the problems rather than whether you own the metal.

If you are a researcher, you already know that legs and hands are separate fields, and the humanoid form is a constraint you accept for a reason rather than a starting point.

If you are a founder, the question is whether your customer wants a humanoid or wants a task done, and those two answers lead to very different machines.

What hardware is actually inside a home humanoid?

Several computers, not one, and knowing that explains most of what goes wrong. There is a small, deeply unfashionable controller close to the motors that runs the balance loop and must never be late, a larger onboard computer running perception and planning, and increasingly a graphics-capable module for the neural network that turns camera images into motion.

Around them sit joints with force sensing, cameras in the head and often in the wrists, an inertial sensor for orientation, and a battery whose life dominates every design decision the manufacturer made. The battery is why the robot in the video works for the length of the video.

The part that surprises newcomers is how much of the difficulty lives between those computers rather than inside any of them. The balance loop needs a fresh estimate of where the body is before it decides what the legs do next, and if that estimate arrives after the moment has passed, the machine wobbles even though every individual program is correct.

That is a software plumbing problem wearing a hardware costume, and it is the subject of why humanoids are hard on the software side.

How long before a home humanoid is worth buying?

Longer than the marketing implies and shorter than the sceptics say, and the useful way to think about it is by task rather than by year. A humanoid becomes worth buying for you on the day it does one specific thing you care about, unattended, in your actual home, without a person in a headset.

The order those tasks fall in is fairly predictable. Fetching and carrying in a tidy space comes first, because the objects are large and the tolerance is generous. Loading a dishwasher comes later, because plates are slippery and the rack is unforgiving. Folding laundry is much later than the videos suggest, because cloth changes shape as you touch it and no model of it stays true.

Anything involving a child, a pet or a staircase in a house with people moving around it is a different category, because the machine has to be trusted rather than merely capable.

If you want a date, watch for the first company that sells a humanoid with an uptime guarantee rather than a demonstration. That is the moment the technology stopped being a video.

What skills do you need to work on humanoid software?

Three, and only one of them is machine learning. The first is ordinary systems programming: processes, timing, memory, what happens when one program is slow and another is waiting. Most humanoid bugs are of this kind, and they are the ones that make a machine that worked yesterday hesitate today.

The second is classical robotics, which people skip because it is old and then rediscover painfully. Coordinate frames, kinematics, filtering a noisy sensor, understanding why an estimate lags. A learned policy sits on top of all of this and cannot repair a frame that is defined wrongly.

The third is machine learning, specifically the kind that turns recorded human demonstrations into motion. That is the layer producing the impressive manipulation results, and it is genuinely where the field is moving.

Notice what is not on the list: mechanical design. Unless you are building the machine, you will be handed one. The gap between people who can make a humanoid do something new and people who cannot is usually the first two skills, not the third, and that is the opposite of what the job adverts suggest.

What do you give up when you buy a humanoid today?

Money, floor space and a considerable amount of your own time, in exchange for a machine that is a project rather than an appliance. That trade is worth making for some people and terrible for most, and the mistake is not knowing which one you are before the crate arrives.

You give up the ability to leave it alone. Current machines want a person nearby, both because they can fall and because they get stuck in ways that need a human to intervene. A robot you must supervise does not save you time on the task you bought it for.

You give up predictability. Software updates change behaviour, sometimes for the better and sometimes not, and a machine that learned your kitchen may need to relearn parts of it.

You also give up a certain kind of privacy, quietly. A humanoid that reasons about your rooms usually sends images or descriptions of them somewhere else to do that reasoning, and you should read what the manufacturer says about it rather than assume.

What you get is early access to a field that will matter, and for some people that is the whole point.

When is ROS 2 the better choice?

ROS 2 is the better choice for almost anyone building software on a humanoid platform they did not design, which is the situation nearly every reader is in. Nothing else gives you drivers for the sensors already bolted to the robot, a coordinate frame system that keeps the head, hands and feet in a consistent story, motion planning that keeps an arm out of the robot's own chest, and a decade of people who hit your bug first.

If you are integrating a bought humanoid, ROS 2 is the answer, and most research platforms in this class ship with support for it. If you are hiring, ROS 2 is the answer, because you can hire for it. If you are handing the machine to a different team next year, ROS 2 is the answer, because they will recognise what they are looking at.

HORUS is not the answer to any of that. A middleware carries messages between programs on one machine, so it is the wrong thing to reach for when what you actually need is drivers, planners, a simulator bridge and community answers, and choosing it for those reasons would cost a reader months.

Is teleoperation cheating?

No, and here is why: teleoperation is how the training data gets made, so a teleoperated demonstration is a step in building autonomy rather than a substitute for it. Every session in which a person wears a headset and drives the robot through folding a towel produces exactly the recorded example that a manipulation model learns from later.

The dishonesty is not in the teleoperation. It is in the presentation. A clip that shows a driven session while the narration talks about the robot understanding your home is describing a capability the machine does not yet have, and viewers reasonably feel misled when they find out.

There is a practical reason to care beyond fairness. Teleoperated capability does not scale, because each robot needs a person. Learned capability scales, because a policy copies to every machine at once. So the question worth asking about any humanoid company is not whether they teleoperate, but what fraction of their demonstrations they can now run without a driver, and whether that fraction is growing.

Ask that question and the field sorts itself out quickly.

Will a large language model make a humanoid autonomous?

Partly, but not the way you think. A language model gives a robot the ability to interpret an instruction and break it into steps, which is genuinely useful and was genuinely missing, and it gives almost nothing to the part that actually fails.

What fails is contact. Knowing that tidying the table means moving the mug to the sink is the easy half. Getting fingers around a mug with a wet handle, at an angle that does not spill it, and noticing that it slipped, is the hard half, and no amount of language ability contributes to it. That gap is the subject of why a model that writes code cannot pick up a cup.

The models that are moving the field are the ones trained on motion rather than on text, taking camera images and an instruction and producing joint commands directly. Language is a component inside them rather than the trick.

So a humanoid with a language model attached talks about your kitchen well and handles it no better. Treat fluency as a user interface improvement, which it is, and not as evidence of competence.

How should you decide whether to buy, build or wait?

Decide by naming the one outcome you want, then asking whether any machine on sale delivers that outcome unattended today. If the answer is no, you are not buying a product, you are joining a project, and that is a fine thing to do deliberately and a miserable thing to discover afterwards.

• If you want your chores done -> wait, because no machine on sale removes a chore without a person nearby.
• If you want a career in this field -> a simulator and a laptop, because the skills transfer and the hardware will be different by the time you need it.
• If you research manipulation -> arms and hands rather than legs, because legs consume the budget and answer a different question.
• If you automate one repeated task in a business -> a purpose-built machine, because a humanoid pays a tax for generality you do not need.
• If you are building software for somebody else's humanoid -> ROS 2, because the drivers, planners and community already exist.
• If your demonstration works and the machine hesitates in a real room -> look at the plumbing between your programs, because the fault is rarely the model.

The HORUS Fit Framework reduces that stack choice to five things you can judge without a benchmark: ecosystem size, setup effort, team size fit, deployment target and licence. For humanoids, deployment target and licence decide it most often, since the machine ships to a customer and somebody will eventually ask what you are allowed to sell.

The week your humanoid demonstration works and the real machine hesitates is a bad week to start reading about the layer underneath. Put HORUS on the shelf before then: star it so it is in your list when you start building.