What Developers Should Ask Before Buying a Humanoid

Ask what your own code is allowed to touch, because that answer separates a humanoid you can build on from a sealed appliance. Everything else follows: which computer runs your programs, whether ROS 2 or HORUS sits underneath, what a broken joint costs on a Friday. The verdict flips only if you are buying a finished machine to operate rather than a platform to program. The rest of this post is the list of questions to ask a vendor, a forum and yourself before the order goes in.

The quote is sitting in your inbox and it has been sitting there for a fortnight.

Not because of the money, exactly. Because every time you read the specification page you notice something that is not on it. Joint counts are there. Battery capacity is there. Nothing says whether you can send a joint command directly or only ask for a walk to a waypoint. Nothing says which computer your own programs are supposed to run on. Nothing says what happens when a hand breaks.

You have watched the demo video four times and you still cannot tell whether a person was driving. You have found two forum threads: one glowing, from somebody who unboxed it last week, and one furious, from somebody nine months in whose machine has been waiting on a part since spring.

And there is the version of the question you keep avoiding, which is whether you know enough yet to buy well. Everybody who has bought one of these says the same thing afterwards: they wish they had asked something different, and they will not say what.

What is the first question to ask before buying a humanoid?

Ask what your own code is allowed to touch, and insist on a specific answer before anything else is discussed.

There are three possible answers and they describe three completely different products. The most open answer is that you can send joint-level commands and read raw sensors, which means you can replace controllers and do real research. The middle answer is that you get a documented interface to the vendor's controllers: walk here, look there, grasp that, plus sensor streams. That is enough for most application work and not enough for locomotion research. The narrowest answer is a fixed list of approved behaviours, which makes the machine a product you operate rather than a platform you program.

None of the three is wrong. Buying the third while planning the first is what wrecks projects, and it happens constantly, because marketing pages for all three look identical. The word "developer" appears on all of them.

Get the answer in a form you can check. A published kit you can read before purchase is proof. A sales engineer saying it is fully open is not, and neither is a video.

What are you actually buying when you buy a humanoid?

You are buying a body, a sealed controller you did not write, a support relationship, and a maintenance commitment that outlives your interest.

The body is obvious and the least likely to disappoint. Modern humanoids walk, balance and recover better than most buyers expect, and that part usually works out of the box.

The sealed controller is the part people misjudge. Balance and joint control run on the robot's own computer, on a rhythm that cannot slip, and your code sits outside that boundary sending goals in and reading state out. That boundary is the product. Where the vendor drew it determines everything you can and cannot attempt.

The support relationship is what you buy instead of self-sufficiency. Some vendors sell a warranty, spares and an engineer who answers email. Others sell a machine and a community forum. Both are legitimate and the prices differ for exactly that reason.

The maintenance commitment is the one nobody signs for. A humanoid needs charging routines, firmware updates, calibration, cleaning and somebody's attention, permanently. What actually runs on the machine is covered in the software inside a humanoid robot.

What are the options once you have decided to buy something?

There are six kinds of purchase and one software decision, and confusing the two is the most common mistake buyers make.

The purchases are: an open, purchasable humanoid from a vendor selling to individuals; a research humanoid bought through an institution with a support contract; a wheeled humanoid torso with arms, which skips balance entirely; a knee-high education humanoid for learning; a quadruped instead, which teaches legged movement for less money and fewer repairs; and no machine at all this quarter, working against a published simulation model.

The software decision is separate and free in money. Your programs talk to each other through something: ROS 2, the vendor's own stack, 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, ships no drivers and replaces no vendor kit. Choosing hardware does not choose that layer for you, and the order of those two decisions is argued out in picking middleware before or after hardware.

How do the buying options compare?

Read the fourth column against your actual project, because the machine most buyers want is rarely the machine their project needs.

Note that two rows are not machines. That is deliberate, because two of the six worst purchases people describe afterwards were software problems bought as hardware.

Which questions matter most for your kind of team?

A solo developer should ask about community, a startup should ask about supply, a lab should ask about comparability, and a company deploying should ask about service.

If you are alone, the only question that really matters is who else owns this machine. You will be reading a stranger's repository at midnight, and a platform with people around it is worth more than a better platform with nobody. Ask how many public repositories target the machine, and check them yourself rather than believing a count.

If you are a startup, ask whether you can buy a second one next year, and a third the year after. Vendors change models, and a fleet of one-of-a-kind machines is a maintenance problem disguised as a purchase.

If you are a lab, ask what your collaborators own. Shared platforms mean shared code and results that can be compared, which is worth more than any individual capability.

If you are deploying into a workplace, ask about service level, spare availability and who is liable when the machine hurts something. Those answers are contractual, not technical, and they take longer to obtain than the quote did.

What should you ask about the computers and the interface?

Ask which computer your code is expected to run on, what else is already running there, and what happens when your programs and the vendor's compete.

This question sounds pedantic and it predicts the first month better than anything else on the list. The robot has an internal computer keeping it upright. If the vendor expects your perception, your language model and your behaviour code to share that computer, you need to know now, because the failure that follows is subtle: nothing crashes, no error appears, and the robot simply gets worse than it was on day one, hesitating in a way nobody can reproduce.

So ask three things. Is there a spare computer inside, or a documented way to add one. What is the physical and logical route between your machine and the robot's, and does it survive a busy network. And is there a supported way to run your own code alongside the controller without stealing the moment it needed.

Ask also what recording looks like. If you cannot capture what every program saw during a failure, you will not diagnose the failures worth diagnosing.

What should you ask if a demo is due soon?

Ask what runs out of the box, on video, with no modification, and plan your demo entirely inside that.

Vendors will tell you honestly if you ask precisely. The useful phrasing is: what can I show a room of people within two weeks of unboxing, using only your examples. The answer is usually walking, a scripted sequence, teleoperation and some sensor visualisation. That is a genuinely impressive demo and it is the one to build on.

The trap on a short timeline is the ambition to replace something. Humanoids punish this in a specific way: the hard parts, balancing and walking, already work, and the parts you add are the parts that break. A demo that keeps the vendor's walking and adds one clear behaviour lands. A demo that replaces the walking controller does not.

Also ask about lead time honestly, and then add to it. Between order and a robot you trust in front of people there is shipping, customs, assembly, firmware, a calibration you did not expect and a part that arrives damaged. Budget planning for that gap is covered in what it costs to get started with a humanoid.

What should you ask about your own team's skills?

Ask whether anybody on the team has debugged several programs talking to each other, because that skill, not kinematics, is what the first months demand.

Humanoid work is rarely blocked by mathematics. It is blocked by a message that stopped arriving, a process that died quietly, two programs that both wanted the same joint, and code that acted on information that was already stale. If nobody on the team has worked that way before, the machine will spend its first quarter as an expensive teaching aid.

Ask also who is comfortable near moving machinery. This is not a joke question. Somebody has to hold the stop switch, decide when a run is over, and refuse to let an excited colleague try one more thing at the end of a long day. That person is a role, not an afterthought.

And ask who will own the boring parts: charging, the launch procedure, session recording, firmware. Projects where one person absorbs all of that quietly are projects that stop when that person takes leave, and it happens more often than any vendor mentions.

What should you ask about repairs, spares and support?

Ask which parts you can buy directly, how long they take to arrive, and whether a repair means shipping the whole machine somewhere.

A humanoid will break. It will break in a way that is your fault, probably in the first month, probably in front of somebody. What matters is what happens next, and the answers vary enormously between vendors selling the same class of machine.

The specific questions worth asking: are hands, feet, joints and cable looms sold as parts. Is there a repair manual, or does opening the machine void something. What is the realistic wait for a common part in your country. Does the warranty survive you replacing controllers and running the robot until something breaks, which is what development actually is.

Then ask the question nobody thinks of: what happens when this model is discontinued. Vendors moving quickly retire generations quickly, and a machine whose parts stopped being made is a machine with a shelf life. Ask how long parts are supported after a model ends, and treat a vague answer as a short one.

What do you give up by buying the most open machine?

You give up support, polish and somebody to blame, and you accept that a broken robot on a Friday is your problem until Monday.

Vendors who sell to institutions include engineers who answer questions, parts that arrive under contract, and a warranty that survives an experiment going badly. The open, purchasable machines cost less for exactly that reason, and the difference shows up on the worst day rather than the average one.

You also give up documentation quality. Manuals written for procurement processes are thorough because a procurement process demanded it. Documentation aimed at developers is often a repository, a handful of examples and a community thread, and the part you need most is usually the part nobody wrote down.

And you give up stability. Firmware changes, interfaces shift between versions, an example from a video no longer runs. That is the tax on buying from a company moving quickly, paid in afternoons.

What you get back is a machine you own and can genuinely modify, which is the entire point, and for most developers it is the right trade. It is simply not a free one.

When is ROS 2 the better choice?

ROS 2 is the better choice for most humanoid projects, and a buyer should assume it is the answer unless something specific says otherwise.

Choose ROS 2 when the robot must navigate a building, when the arms need a motion planner, when a camera must be calibrated against a gripper, when sessions have to be recorded and replayed, or when more than one machine needs monitoring. All of that exists, written by people who solved it before you. Choose ROS 2 when the vendor ships bindings for it, which is common enough that it often settles the question at the point of purchase. Choose ROS 2 when the code will be handed to another team, or when your team is students who will be hired on the strength of knowing it.

HORUS is not the answer to those needs. There is no navigation, no planner, no calibration tooling, no driver library and no package ecosystem, and a humanoid project that needs those needs ROS 2. The narrower case comes later, once several of your own programs share the robot's computer and the machine starts hesitating under its own software.

Should you wait for the next machine before buying?

No, and here is why: there is always a better humanoid two quarters away, and the teams who wait well are the ones writing code while they wait.

The hardware genuinely is improving, and a buyer who waits will get more machine. But waiting only pays if the waiting period is productive. A team that waits and writes nothing arrives at the better machine with no behaviour code, no recording setup, no habits and no opinion about which vendor to trust. A team that waits and writes against a published simulation model ships something on the first day of ownership.

There is also a quieter reason not to wait indefinitely. Every generation you skip is a generation of interface experience you do not have, and interfaces are what you are actually buying. The team that has driven a simulated machine through a vendor's kit knows what a good kit feels like. The team that has only read specification pages is guessing.

So the honest advice is: do not wait for hardware, and do not buy before you have a question. Those are compatible, and the gap between them is where the code gets written.

Does the vendor's kit cover everything you will need?

Partly, but not the way you think: the kit covers the robot beautifully and covers your system not at all, and the gap is where projects stall.

Vendor kits are usually good at what they are for. Joint commands, sensor streams, walking goals, a simulation model, some examples. If your project is one program calling those functions, you will be happy.

The gap appears when your project becomes several programs. A camera pipeline, a model doing inference, a behaviour layer, a safety watchdog, a logger, and possibly a language interface. The kit says nothing about how those talk to each other, which one runs where, what happens when one is late, or how to record all of them together. That scaffolding is most of the code in every working humanoid, and every team writes it, whether deliberately or by accident.

Deciding whether to build that yourself or adopt something is a real fork, and it is argued out properly in building on a vendor SDK or your own stack. What matters at purchase time is knowing the gap exists, because the quote does not mention it.

How do you decide whether to sign the order?

Sign when you can name the question that only this machine answers, and when you know what happens the week it breaks.

Those two tests eliminate most regretted purchases. The first stops you buying an ambition: a team that needs to know whether its grasping approach survives a real hand has a reason, and a team that just wants a humanoid does not. The second stops you buying a machine you cannot keep running: if nobody can answer where the spare hand comes from and who fits it, the robot will spend more time broken than working.

Two smaller checks help. Can you read the software kit today, before paying. And has somebody outside the company published code for this machine that you can read and understand. Both are cheap to verify and both predict the next year better than any specification.

If the tests do not pass, the correct action is not to buy a different machine. It is to spend one more quarter in simulation and ask again, with better questions and a stronger idea of what you actually need.

• If you cannot name the question metal must answer -> buy nothing yet, because a robot on charge teaches nobody anything.
• If you need to replace controllers or do locomotion research -> an open, purchasable humanoid, because sealed machines will refuse at exactly the wrong moment.
• If arms, language and behaviour are the project -> a wheeled humanoid torso, because balance is a year you did not plan for.
• If a grant covers it and downtime is unacceptable -> a research humanoid with a support contract, because that is what the money is buying.
• If you are learning and the budget is your own -> a quadruped or an education humanoid, because the lessons transfer and the repairs do not hurt.
• If your own programs already fight over the robot's computer -> look underneath at the software layer, because no new machine will fix that.

The HORUS Fit Framework reduces the layer beneath your code to five things you can judge without a benchmark: ecosystem size, setup effort, team size fit, deployment target and licence. At purchase time, ecosystem size and deployment target usually decide it, and licence becomes urgent the first time a customer asks exactly what they are buying.

The week the crate arrives is a bad week to start researching middleware. Put HORUS on the shelf beforehand: star it so it is in your list when you start building.