Can You Develop for a Humanoid Without Owning One?

Yes, simulation carries most of a humanoid's software, but the last stretch of the work needs the real machine or somebody else's. Perception, planning and the whole structure of the software can be developed against a simulated robot, which is how many teams work anyway. What flips the verdict is balance: a machine that must not fall teaches things no simulator will, and neither ROS 2 nor HORUS changes that. The rest of this post is for someone drawn to humanoids who cannot spend the price of a car to find out whether they like the work.

You have watched the videos. You have watched the one where the robot gets shoved and recovers, and the one where it folds a shirt badly but folds it. You looked up what a developer unit costs, sat with that number for a moment, and closed the tab.

Since then you have been told two contradictory things by people who both sound confident. One says everything is simulation now and you can be useful without touching a robot. The other says simulation is a toy, the real work starts when the machine is in front of you, and anything else is a hobby.

What neither of them tells you is which parts of the job actually change when the robot is physical. So you are stuck between spending money you would rather not spend on hardware you might outgrow, and spending six months on something that turns out not to count. Meanwhile the tutorials you find are either a walking policy paper you cannot follow or a video of somebody dragging a robot model around a scene, and neither one resembles a job.

Can you develop for a humanoid without owning one?

Yes, and most humanoid software is written this way, including inside companies that own dozens of machines.

The reason is practical rather than philosophical. A humanoid is expensive, fragile in the particular way a falling machine is fragile, and wanted by more people than can use it at once. A robot that falls badly is a robot in the workshop for a week. So even a team surrounded by hardware does most of the work against a simulated model and books time on the real machine with questions prepared in advance.

What that buys you is nearly everything above the joints. How the robot decides what to do, how it interprets what it sees, how behaviours are sequenced, how the software is structured, how it is tested: none of that needs a physical body to be written, or to be wrong in ways that teach you something.

What it does not buy you is the last stretch, where the machine's own weight, the play in its joints and the lag in its sensing decide whether it stays upright. That stretch needs a real robot. It is also shorter than most people fear.

What does developing for a humanoid actually involve?

Humanoid development is four jobs stacked on each other, and only the bottom one genuinely demands the machine.

At the bottom is whole-body control: keeping the thing upright, correcting every joint far more often than a person could notice, catching a stumble before it becomes a fall. Above that is perception: turning cameras and depth sensors into a belief about where the table is and which object is the mug. Above that is behaviour: sequencing an action into steps, deciding what to do when a step fails. At the top is the plumbing that carries data between all of it without anything arriving too late to be useful.

Most job adverts, most open-source projects and most of the interesting unsolved problems live in the top three layers. The bottom layer is where the manufacturer has usually done the hard part already, because a humanoid that cannot stand up is not a product. If you want the full tour of the pieces, the software inside a humanoid divides along these lines.

What are your actual options without hardware?

There are four honest routes: a physics simulator on its own, a simulator wired to a full software stack, a smaller robot standing in for the humanoid, and borrowed time on someone else's machine.

A simulator on its own means MuJoCo or Isaac Lab and a Python program. You get contact, gravity and joints, and you write everything else. This is the research route and the quickest way to study one question about walking or grasping.

A simulator wired to a stack means you build the thing a real robot would run, and point it at a simulated body instead of a physical one. That is the route that most resembles the job, because the stack is the deliverable.

Underneath that route sits the middleware question. ROS 2 is the default, brings drivers, visualisation and packages, and is what most humanoid platforms document. HORUS is an open-source real-time middleware for Rust, Python and C++ where those three languages share the same shared-memory ring buffers, so messages between programs on one machine are not serialised; the licence is Apache-2.0, and the project is validated in simulation, though the connection to your simulator is yours to write.

Which route should you take?

Here are the routes side by side, with the situation each one is genuinely for.

The last row is the one most people accidentally choose by not choosing.

Which route fits a student, a solo builder, or a funded team?

A student should take the simulator plus stack route, a solo builder should add a small physical robot, and a funded team should buy hardware early and keep simulating anyway.

A student's constraint is proof. Nobody can see your understanding, so it has to be visible in a repository somebody can run. A simulated humanoid doing a task end to end, with the code structured the way a real system is structured, reads as competence. A half-trained policy in a notebook does not.

A solo builder's constraint is motivation, which is a real engineering constraint and not a soft one. Simulation is a lonely medium and it is easy to drift. A cheap legged robot or a desk arm gives you a machine that surprises you, and surprises are what keep people going.

A funded team's constraint is the calendar. Hardware has lead times, and the first physical robot always exposes something structural that costs weeks. Buy early, discover the surprise early, and keep the simulation as the place where daily work happens, because the machine cannot be everybody's test rig.

What computer do you need to do this at home?

An ordinary laptop is enough to simulate a humanoid's physics, and it is not enough to train a policy or render convincing camera images.

That split decides more than people expect. MuJoCo will happily simulate a humanoid model on a machine with integrated graphics, because contact and rigid-body dynamics are arithmetic rather than pictures. You can study a gait, write a controller and watch a robot fall over hundreds of times on the computer you already own.

Training a walking policy is a different workload. That means many copies of a scene running at once for a long time, which wants a strong NVIDIA card, and it is the one part of this that is genuinely cheaper to rent by the hour than to buy.

Photographic rendering is the third workload, and the one people misjudge. If your project needs images good enough to fool a neural network rather than a person, you are in the same hardware territory as policy training. If your project needs images good enough to check that a perception program receives frames and does not crash, a plain simulator is fine and always was.

How long can you go before you need a real robot?

You can go about as far as the first question that has a physical answer, and for most people that is several months of useful work.

The honest markers look like this. Writing perception, behaviour and the structure of the stack: no hardware needed. Getting a task to work end to end in a simulated kitchen: no hardware needed. Making that task work when the mug is slightly translucent and the light comes from a window: hardware, or at least real recorded data. Tuning a controller so the robot does not wobble on a soft floor: hardware, definitely.

The trap is the middle. There is a long stretch where simulation still answers your questions but stops teaching you anything new, and it is easy to keep polishing because the loop is comfortable and nothing breaks. That is the point to seek out a borrowed machine, a lab, a hackspace or a job. Knowing when to stop simulating and build the real thing is a skill in itself, and it is mostly about noticing that your questions have changed shape.

What do you already need to know to start?

You need Python, patience with maths you will not fully derive, and the ability to read documentation written for somebody else. That is the entry price, and it is lower than the field's reputation suggests.

Python is the working language of humanoid simulation. Nearly every example, every learning framework and every quick experiment is Python, and you can go a long way before the language becomes the limitation.

The maths matters but not in the way school implies. You need to be comfortable with rotations, coordinate frames and the idea that a robot's state is a list of numbers with meaning attached. You do not need to derive the dynamics of a floating-base system to write useful software above the controller.

The third requirement is the one that stops people. Humanoid documentation is thin, aimed at people already inside the field, and often out of date. Getting a robot model loaded and moving is the first real test, and it is a test of stubbornness rather than talent. If you are starting from further back, there is a route into robotics that needs no robot at all.

What does hitting the hardware wall look like?

Hitting the wall feels like your simulation becoming a pet rather than a tool, and it usually happens gradually enough that nobody names it.

The early signs are pleasant, which is why they are missed. Everything works. The robot completes the task every time. You start adding scenes because the existing ones are all solved, and you begin tuning things that were never wrong. The improvements stop teaching you anything, because every question you ask now has the answer you designed in.

The clearer sign is that your bug reports change character. Instead of "the arm goes through the table", you get "the arm stops just short of the mug and I cannot tell whether that is right". You have exhausted the questions the model can answer, and the remaining ones are about a physical world that the model was never a faithful account of.

The last sign is social. You cannot describe your work to a person with hardware without a string of qualifications. That is a signal to go find a machine, not a signal that the months were wasted.

What do you give up by developing without the robot?

You give up calibration of your own judgement, which is subtler than giving up a skill and harder to recover later.

Concretely, you give up the feel for what breaks. Somebody who has watched a real humanoid fall knows that the interesting failures are boring: a cable that pulls at a joint limit, a sensor reading that goes stale for a moment, a foot on a floor slightly more slippery than the last one. In simulation those failures do not exist unless you deliberately model them, and nobody models the ones they have not seen.

You also give up timing intuition. In simulation, the physics politely waits for your program. On a real machine nothing waits, and a program that arrives late produces a stumble rather than a slightly delayed result. That difference is invisible until it is expensive.

Lastly you give up the confidence that comes from having done it. That is not nothing in an interview, and it is why a weekend on a borrowed machine is worth more than another month of scenes.

When is ROS 2 the better choice?

ROS 2 is the better choice for anyone who wants to work on humanoids professionally rather than study one narrow question, and that covers most readers here.

The reasons are concrete. Several humanoid platforms document a ROS 2 interface directly, so the path from your simulated stack to a borrowed machine is a path somebody has walked. The visualisation tool everyone uses is a ROS 2 tool, and being able to show a colleague what your robot believes is half of debugging. Job adverts name ROS 2 by name. Existing packages for navigation, mapping and manipulation exist there and nowhere else.

HORUS is not the answer for that reader. If your goal is employability, or getting a specific commercial humanoid to do something, a different middleware costs you the tutorials, the drivers, the community answers and the interview vocabulary, in exchange for solving a problem you have not encountered yet. Learn ROS 2 first. The moment to consider anything else is when your own programs start missing each other on one machine, and not before. If you want the shortlist of machines that are open to outside developers, the developer-facing humanoid platforms differ sharply.

Is buying a small humanoid kit the fastest way to learn?

No, and here is why: a small hobby humanoid teaches you servo control and mechanical patience, and almost nothing about the software problems that full-size humanoids actually have.

The little machines are position-controlled. You tell each joint an angle, the servo goes there, and balance comes from a low centre of mass and a wide foot rather than from any control the robot is doing. That is a legitimate and enjoyable hobby, but the skill it builds does not transfer upward, because the hard part of a real humanoid is precisely the part the toy skips.

There is a version of this that does work. A small legged robot with torque-controlled joints, or a desk arm you actually program, gives you real contact, real delay and real failures. So does a wheeled robot with an arm on it, which teaches perception and manipulation without balance in the way.

Spend the money on the machine that has the property you want to learn from, not the machine that has the shape you want to build. Shape is the least transferable thing about a robot.

Does simulation experience count with employers?

Partly, but not the way you think. Nobody is impressed that you used a simulator, and everybody is interested in what you built inside one.

The distinction that matters to a hiring manager is between a tutorial completed and a system built. A repository showing a simulated humanoid picking up an object because you followed a guide reads as a course. A repository showing a stack you structured, with the perception separated from the behaviour, tests that run without hardware, and a written account of what failed and why, reads as engineering.

The second thing they look for is honesty about the gap. A candidate who says their controller works in simulation and lists the three reasons it would probably not survive contact with a real floor is more credible than one who claims it is finished.

And the layer matters. For perception, behaviour, tooling and infrastructure roles, simulation work counts fully. For whole-body control and hardware bring-up, it counts as preparation, and the team will expect you to learn the rest with a machine in front of you.

How should you decide what to do this month?

Pick the layer of the robot you want to work on, then choose the cheapest setup that lets you fail at that layer repeatedly, and ignore everything aimed at a different layer.

• If you want a robotics job -> a simulator plus a full stack, because the stack is what the job actually is.
• If you are studying one gait, grasp or policy -> MuJoCo or Isaac Lab alone, because the framework would only be in the way.
• If you need something physical to stay motivated -> a small torque-controlled legged robot or a desk arm, because surprises keep people building.
• If you have access to a lab or hackspace -> prepare in simulation and book the machine, because a prepared hour beats an idle week.
• If your programs already trip over each other on one computer -> look at the layer underneath before buying more hardware.
• If you are waiting until you can afford a humanoid -> start this weekend anyway, because the waiting is the only route that teaches nothing.

The HORUS Fit Framework keeps the stack decision to five things you can judge without running a benchmark: ecosystem size, setup effort, team size fit, deployment target and licence. Working without hardware, setup effort and deployment target usually decide it, and licence matters the day you publish the repository. Which simulator you point that stack at is a separate decision with its own logic.

The day your simulated robot behaves and the borrowed machine hesitates is a poor day 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.