How Much Does It Cost to Get Started With a Humanoid?

Starting with a humanoid costs nothing in simulation, a hobby budget on a desktop machine, and roughly a car once you want legs. Almost every early lesson lives in software, and the layer your own programs talk through, ROS 2 or HORUS, costs nothing either. The verdict flips the moment your question is about weight, heat or grip, which only metal answers. The rest of this post is for a developer or a small team working out what to spend, in what order, over the next year.

You watched a launch video, then you opened a spreadsheet, and the spreadsheet is where the project stalled.

The prices are the first problem. Half the machines you want quote nothing at all and instead ask which company you represent. The ones that do publish a price publish a single figure, and you have no idea whether that figure includes a battery, a charger, a spare hand, shipping, or the import duty that arrives three weeks later with its own paperwork.

Then there is the suspicion that the robot is the small half. Somebody on a forum mentioned a gantry. Somebody else mentioned that their machine has been sitting on charge for two months because the person who knew how to start it changed jobs. A third said the robot was fine and the second computer was what broke the budget.

And underneath all of it, the question you cannot ask anyone without sounding like you are not serious: whether you need to buy anything at all this year, or whether the people making visible progress spent their money on time instead of hardware.

What does it actually cost to get started with a humanoid?

The honest answer spans from nothing to the price of a small car, and where you land is decided by one question: does your first year need legs.

Nothing is a real answer, not a rhetorical one. A laptop you already own, a free simulator, a published model of a real humanoid and that vendor's own kit let you write behaviour, drive joints and read sensors for as long as you like, and most of that code is the code that later runs on metal.

The middle tier runs from the price of a decent laptop up to a used motorbike, and buys either a knee-high education humanoid or a quadruped. Both teach legged movement, safety habits, and the feeling of watching a machine fall because of a line you wrote.

The top tier is car money for a full-size humanoid you can own and modify, and car money is only the deposit. Spares, a second computer, floor space, a harness and somebody's months all follow, and together they often match the machine over a first year.

What does getting started with a humanoid actually include?

Getting started includes five things, and the robot is only one of them.

The first is a body, real or simulated. The second is computers, plural: the robot has its own, running balance and joint control, and your code almost always needs another one, because a camera pipeline and a language model do not politely wait their turn behind the loop that keeps the machine upright.

The third is space and safety. A machine at chest height that topples does not topple gently, and the opening weeks of any humanoid project contain falls. Clear floor, a harness or gantry, and a person holding a stop switch are part of the purchase, and teams that skip them pay in repairs and then in caution, because a developer who is frightened of the robot stops experimenting.

The fourth is the software layer your own programs talk through, which is free in money and expensive in decisions.

The fifth is time, the line people leave off the spreadsheet. A humanoid absorbs somebody's months whether or not that somebody was budgeted for.

What are the real routes into humanoid development?

There are seven routes, and they sort by how much metal you buy in the first year. Simulation alone, on hardware you already own, is where most working developers start. A knee-high education humanoid teaches balance on a desk. A quadruped gives you legs, falls and a real vendor interface for less money and fewer repairs, which is why the quadruped-first argument keeps winning. A wheeled humanoid torso gives you two arms and skips balance. A full-size purchasable humanoid gives you the machine from the videos, plus its maintenance. An institutional research humanoid adds a support contract and a procurement process. And borrowed access, through a university, an employer or a hackerspace, costs scheduling rather than money.

The software layer is a separate decision and costs nothing either way: 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 walking controller and replaces no vendor kit.

How do the starting routes compare?

Read the last two columns first, because most people are eliminated into a route by floor space and by what the robot is actually for, long before money enters the conversation.

Nothing in that table is a price, because the price is the part that changes every quarter and the fit is the part that does not.

Which route fits a hobbyist, a student, a startup or a lab?

A hobbyist should stay simulated and buy small, a student should borrow, a startup should buy the closest thing to the eventual product, and a lab should buy what its collaborators already own.

For a hobbyist, the arithmetic is unforgiving. A full-size humanoid costs a car and breaks like a laptop, and one bad fall on a Saturday can end a project that was going well. Write behaviour in simulation, then spend on a small machine when you want to feel what balance means.

For a student, the cheapest metal is somebody else's. A university lab, a robotics society or an employer's spare quadruped gives you the physical lessons without the ownership, and the code you bring to that session was written at home for free.

For a startup, buy the closest thing to what the product will be and expect to replace it. If the plan is manipulation in a workshop, legs teach you less than you hope.

For a lab, comparability wins. A machine your collaborators also own is worth more than a better machine nobody else has, because shared platforms mean shared code and comparable results.

What else do you have to buy besides the robot?

A second computer, a second battery, floor space, a harness, spare parts and a stop switch, roughly in that order of certainty.

The second computer is the one that surprises people. The robot's own machine is busy keeping the thing upright, and your perception work, your language model and your behaviour code have to live somewhere. Teams who plan to run everything on the robot's computer find out in week three, when the machine starts hesitating and nothing has crashed.

The second battery turns a run window into a working day. One battery means a fraction of an afternoon, then charging, then waiting.

Floor space cannot be bought at all in most flats and small offices, which is why it deserves a line before the order goes in rather than after.

Spares are the item people find distasteful to budget and always need. A hand, a joint, a foot pad, a cable loom: order the obvious ones with the machine, because the version that ships next year may not fit.

How does your timeline change what you should spend?

A demo due within a month means spend nothing on hardware you do not already have, because nothing you order will arrive, be assembled and be trusted in time.

On that horizon, use a simulated humanoid and the vendor's own examples, and put the money into the one behaviour that has to work. Teams who order metal for a demo a month away spend the month unpacking, charging, chasing firmware and learning that a joint is on back order.

On a horizon of a quarter, buying starts to make sense, but buy the smallest machine that answers your actual question. A quadruped or a torso arrives, works and teaches, without consuming the quarter in maintenance the way a full-size humanoid can.

On a horizon of a year, buy properly and budget for the replacement. Humanoid hardware moves quickly, and the code that survives a hardware change is the code that treated the robot as an interface rather than an assumption. Teams who wrote against the vendor's structure everywhere find the next machine expensive. Teams who kept their own boundary find it merely tedious.

What skill level does each starting point assume?

Every route assumes Linux and one language you know properly, and after that they diverge sharply.

Simulation assumes the least: Python, a willingness to read documentation, and the patience to work on a machine that does not exist yet. It is the only starting point that forgives a beginner, which is why it is right for nearly every beginner.

An education humanoid assumes you can wire a servo, read a datasheet without panic and accept that the robot will fall on the desk. That is a different skill set from writing behaviour, and it is why some developers love these machines and others find them a distraction.

A full-size humanoid assumes something harder to buy: comfort when a program starts, nothing happens, and there is no error message. That is most of the first fortnight, and it separates teams who make progress from teams who stall. The failures worth debugging are never inside one file. A message stopped arriving, a process died quietly, two things wanted the same joint. If you have only ever debugged one program at a time, close that gap before the crate arrives.

What costs does nobody put in the budget?

The invisible costs are shipping, duty, insurance, floor space, the second computer, the person who becomes the only operator, and the quiet months spent on problems that are not your project.

Shipping and duty on a heavy machine crossing a border are not a rounding error, and neither is the freight forwarder you did not know you needed. Insurance becomes a real question the moment a machine that heavy shares a room with people.

The operator cost is the sneakiest. One person sets up the robot, learns its moods, keeps the launch procedure in their head, and from then on the project moves at their calendar. When they take leave, the robot sits still. The cure is boring and works: write the procedure down, make a second person run it, and record every session from the first day rather than the day after something interesting breaks.

Then there are the months lost to problems that have nothing to do with your idea. Firmware that changed, an example that no longer runs, a network that behaves differently in your building. Those are not exceptional. They are the job.

What do you give up by starting cheap?

You give up realism, and specifically the physical lessons that only arrive through a machine you can lift.

Simulation teaches interfaces, behaviour, message flow, failure handling and most of what your code will ever do. It will not teach you how heavy the robot is on the gantry, how a joint feels when the motor is warm, how quickly a battery goes from working to not, or how different a real room looks to a real camera. Those lessons arrive later than people expect.

You also give up credibility with certain audiences. An investor, a customer or a hiring manager watching a simulated demo will ask the obvious question, and having an answer ready matters.

And you give up the forcing function. Hardware creates deadlines that simulation does not, and some teams genuinely work better with a machine in the room glaring at them. That is a real argument for buying earlier than the strictly rational schedule, and it is worth being honest about which kind of team you are. The longer case is in developing for a humanoid without owning one.

When is ROS 2 the better choice?

ROS 2 is the better choice the moment your humanoid needs to do anything beyond standing up and moving its own joints, and that moment arrives sooner than most budgets assume.

Navigation around a building, motion planning for the arms, calibrating a camera against a gripper, recording and replaying a session, monitoring more than one machine: all of that exists in ROS 2, written and debugged by people who did it before you, and none of it is cheaper to rebuild than to adopt. Choose ROS 2 when the vendor ships bindings for it, which is common on humanoids and quadrupeds alike. Choose ROS 2 when the code will be handed to another team who will expect familiar conventions. Choose ROS 2 when you are a student, because employers ask for it by name.

HORUS is not the answer to any of those needs: no navigation stack, no planner, no calibration tooling and no package ecosystem. A humanoid project that needs those needs ROS 2. The narrower case arrives later, when several of your own programs share the robot's computer and the machine starts hesitating under its own software.

Do you have to own a humanoid to work on humanoid software?

No, and here is why: the machines worth developing for publish simulation models, and code written against a model is the code that runs on metal.

This is not a consolation prize. Walking and grasping policies are trained in simulation as standard practice, because no physical machine survives the number of attempts learning requires. A team that buys hardware first inverts the sequence, and the robot ends up on charge while somebody writes the code that will eventually use it.

The practical version looks like this. Download the simulator and the vendor's model. Write the behaviour you actually care about. Make it fail deliberately, in every way you can invent, and build the recording and restart machinery you will need later. Then, when a question appears that only metal answers, buy the smallest machine that answers it.

The developers who look furthest ahead a year from now are usually the ones who spent the first six months on software and the second six on hardware. Money spent early buys a robot. Money spent late buys a robot that already has something to run.

Will waiting for prices to fall save you money?

Partly, but not the way you think: humanoid prices are falling, and waiting saves money only if you spend the waiting period writing code.

The falling half is true. Machines that cost an institution's budget a few years ago are now sold to individuals, and the trend has not stopped. A team that waits will get more machine for the same money, and possibly better documentation, because vendors compete on that now.

The trap is treating waiting as a strategy rather than a schedule. A team that waits and writes nothing arrives at the cheaper machine with no code, no habits, no recording setup and no idea what to ask it to do. A team that waits and writes ships behaviour on day one of ownership.

There is a second cost to waiting that nobody mentions. Vendor interfaces change between generations, and a team that has never used one has no opinion about which vendor to trust. Working against a simulated machine gives you that opinion for free, and opinions are what make the eventual purchase a good one rather than a guess.

How do you decide what to spend first?

Decide by naming the one question that metal has to answer, and if you cannot name it, the correct spend this quarter is nothing.

That sounds severe, and it is the most useful test available. A team that can say it needs to know whether its grasp policy survives a real gripper has named a question, and the purchase follows directly. A team that says only that it needs a humanoid has named an ambition, and ambitions buy machines that sit on charge.

Two follow-up checks settle most cases. First, where does your code need to reach: if the answer is only high-level commands, a sealed machine may be enough and a simulated one is certainly enough for now. Second, who else owns this platform: a machine with other developers around it saves more hours than a better machine you are alone with, because you will be reading their code at two in the morning.

If neither check decides it, stay simulated one more quarter. The questions to put to a vendor when you do buy are in what to ask before buying a humanoid.

• If you are learning alone with no budget -> simulation plus the vendor's kit, because the code written there is the code that ships.
• If you want to feel a machine fall -> a knee-high education humanoid, because that lesson is cheap at desk height and expensive at chest height.
• If legs are the point and hands are not -> a quadruped first, because the interface lessons transfer and the repair bills do not.
• If arms, speech and behaviour are the project -> a wheeled humanoid torso, because balance is a year you did not budget for.
• If a customer is waiting and the machine must be full-size -> a purchasable humanoid plus spares and space, because the visible price is only the deposit.
• If your own programs already fight over one computer -> look at the software layer underneath, because that is not a hardware bill at all.

The HORUS Fit Framework reduces the software half of the budget to five things you can judge without a benchmark: ecosystem size, setup effort, team size fit, deployment target and licence. On a money question, setup effort and team size fit do most of the work, because both are paid in the months nobody put in the spreadsheet.

The week the budget clears and the crate arrives is a bad week to start reading about middleware. Put HORUS on the shelf now: star it so it is in your list when you start building.