Quadrupeds vs Humanoids: Which Should You Develop For First?

Develop for a quadruped first, because a four-legged robot stays standing while your code is still wrong and a humanoid falls over. The stack you write, on ROS 2 or on a real-time layer like HORUS, carries across nearly unchanged, so the legs you learn on cost you little. That flips when the project is specifically about two hands at human height. The rest of this post is for someone who wants to work on legged robots, has a budget and a deadline, and has to pick one body to start against.

You have watched the videos. The humanoid ones are the ones that make you want to build something, and the four-legged ones look like a solved problem somebody already shipped. So the plan forms on its own: get a humanoid, or get access to one, and start writing. Then the practical questions arrive and none of them are about code. How much does the machine cost, and what happens the first time it falls. Whether you can even buy one where you live, or whether you are waiting on a shipment and an export form. Whether the thing you are allowed to write is real code or a scripting interface over the vendor's demo. Whether you need a second person in the room every time the robot is powered. Whether the work you do for the next six months will still be worth anything if you switch machines. Meanwhile there is a four-legged robot on a shelf at a fraction of the price that will walk across your floor this afternoon, and you cannot tell whether picking that one is being sensible or being timid.

Should you develop for a quadruped or a humanoid first?

Pick the quadruped, and pick it for stability rather than for simplicity. A four-legged robot has a base of support wide enough to survive a bad command: give it a nonsense velocity and it stumbles, plants a foot, and stands there waiting for the next instruction. Give a humanoid the same nonsense and it goes to the floor, and now your afternoon is a repair, a recalibration and a careful power-up rather than the next experiment. That difference compounds. Development is a loop of writing something, running it, watching it fail in an interesting way, and changing it, and the speed of that loop is the single thing that decides how much you learn per week. A machine that punishes each iteration with twenty minutes of recovery cuts the number of iterations you will ever run. The quadruped keeps the loop tight. Everything else — price, availability, spares, whether you need a second person in the room — points the same direction, which is unusual enough to be worth trusting. The exception is real and comes later in this post: if the work is arms and hands at human height, four legs teach you the wrong half.

What does developing for a legged robot actually involve?

Developing for a legged robot means writing three layers, and you will almost certainly only write two of them. The bottom layer keeps the machine upright: it decides how the joints move to place a foot, absorbs a shove, and recovers from a slip. That layer arrives with the robot, either as the vendor's controller or as a policy trained in simulation, and on a commercial platform you are usually not permitted to replace it. The middle layer decides where the robot should go and why: reading cameras and range sensors, building a picture of the room, choosing a route, noticing the stairs. The top layer is the plumbing — messages moving between the parts, timing, logging, a way to stop everything at once. Nearly all robot software jobs live in the middle and the top, and both of those are almost identical on four legs and on two. That is the fact that makes this decision less frightening than it looks. You are not choosing between two careers. You are choosing which body your middle and top layers will practise against, and that body's main effect on you is how expensive your mistakes are.

What are the real options for a first legged robot project?

There are six realistic starting points and two software layers underneath them. The starting points: a simulated quadruped, which costs nothing and runs on the laptop you already own; a hobby-class quadruped you can actually own outright; a research-grade quadruped with a proper sensor suite and a documented interface; a simulated humanoid, which is how most people genuinely begin humanoid work; a humanoid platform you buy, borrow or share access to; and the option people forget, a wheeled base or a fixed arm, which removes legs from the problem while leaving the interesting software intact. Underneath any of them sits the layer your own code is written against. ROS 2 is the default, with the largest package set in robotics, drivers for most sensors and a bridge shipped by nearly every legged vendor. HORUS is the smaller alternative: an open-source real-time middleware under Apache-2.0 where Rust, Python and C++ share the same shared-memory ring buffers, so messages between processes on one machine are never serialised, and a control loop written once behaves the same in simulation and on the robot's own board.

How do the legged options compare?

The comparison only makes sense once you separate the body you practise on from the layer you write against, because those are independent choices.

Most teams end up with two rows: one body, one layer, and a simulator alongside whichever body they picked.

What goes wrong first when people start with a humanoid?

The first thing that goes wrong is that the robot stops being available to you. Not broken, exactly — waiting. Waiting for a joint to be re-zeroed after a fall, for a battery to charge because a humanoid drains one faster than a machine that can simply stand still, for the one colleague who is allowed to power it up, for a part on order from another continent. Meanwhile the code you wanted to test sits in a branch. The second thing that goes wrong is that falls stop being free, so you stop taking risks, and a developer who has stopped taking risks with a robot has stopped learning from it. The third is social rather than technical: a humanoid attracts attention, so people start asking for demos, and demo work is not the same as making a robot work. Two weeks disappear into a video. None of these are arguments that humanoids are bad. They are arguments that a humanoid is a poor place to learn, because learning requires cheap failure and a humanoid makes every failure expensive.

Which should a solo builder learning at home pick?

Start in simulation with a quadruped, then buy a hobby-class quadruped once simulation stops surprising you. As one person you have two constraints that dominate everything else: nobody catches the robot when it falls, and nobody covers for you when a part takes a fortnight to arrive. Both constraints point at a machine you can pick up with one arm, reset by hand, and run on the kitchen floor without clearing the room. The simulated stage matters more than people expect, because that is where you find out whether you actually enjoy the work: reading sensor data, arguing with coordinate frames, watching a plan fail for reasons you cannot see. If that part bores you, no hardware will rescue it. If it grips you, the hardware then teaches you the other half, which is the half simulation cannot: connectors that work loose, a board that throttles when the sun hits it, a run that behaves differently every time. That second half is the subject of what to do when simulation and hardware disagree, and it starts the day the machine arrives.

Which should you pick given the hardware you can actually get?

Pick whichever legged machine you can have in the room within a month, and treat everything else as unavailable regardless of how good it looks. Availability decides more first projects than capability does. Quadrupeds ship in far greater numbers, from more vendors, at prices a single person or a small team can approve without a meeting, and spares exist. Humanoid platforms cluster around a handful of models, most with waiting lists, export paperwork, and a support relationship you have to build before anything goes wrong. There is a second availability question underneath the first, which is what the vendor lets you write. Some machines give you a documented interface and a bridge into a standard middleware; others give you a scripting layer over a fixed set of demonstrations and call it an SDK. That difference matters far more than the leg count, and it is the thing to establish before any money moves. Which humanoid platforms are genuinely open to developers is a shorter list than the marketing suggests, and the same question is worth asking of every quadruped vendor too.

Which should you pick if you need something working in three months?

Pick a quadruped, and pick a narrower goal than the one in your head. Three months is enough to make a four-legged robot do one useful thing reliably — walk a route, follow a person, inspect a fixed set of points, map a floor — provided the walking itself is the vendor's problem and not yours. Three months on a humanoid buys you a machine that stands up, a stack that talks to it, and a demo that works when the room is arranged correctly, which is a real achievement and not a working robot. The trap in a short timeline is the assumption that the hard part is the interesting part. It is not. The hard part is the last stretch: making the thing survive a floor that is shinier than the test floor, a person who walks in front of it, a battery at the end of its charge. Budget most of the time for that stretch, choose the body that lets you iterate quickly through it, and defer anything involving hands until the walking version has been boring for a fortnight.

Which should you pick if you have never written control code?

Pick a quadruped in simulation, and take comfort in the fact that you probably never need to write control code at all. The word "control" covers two very different jobs. One is the tight loop that decides how much current goes to a motor so that a foot lands where it should — that is written by the vendor or trained as a policy, and on a commercial legged platform you are usually not allowed near it. The other is the outer behaviour: where the robot should go, what it should do when the route is blocked, when to stop. That second job is ordinary software with a hard deadline attached, and it is what almost every legged robotics role actually involves. Start there. Learn to read a sensor stream, to reason about a message arriving later than expected, and to make a loop that runs on a steady cadence rather than whenever the previous work finished. A quadruped forgives you while you learn all three; the reasons a humanoid does not are laid out in why humanoid robots are so hard to build on the software side.

What do you give up by starting with a quadruped?

You give up the upper body, and the upper body is where the unsolved problems live. A quadruped teaches you legs, perception, planning and plumbing, and it teaches none of the following: two arms whose motions interfere with each other, a hand closing on an object that is not quite where the camera said, a torso that has to lean to counterbalance a reach, a machine whose whole balance changes the moment it picks something up. Those are exactly the problems humanoid teams are being funded to solve, and no amount of four-legged work substitutes. There is a second thing you give up, which shows up later. A quadruped stops teaching you at a certain point — usually the moment you bolt an arm onto it and discover that whole-body coordination is a different discipline from navigation. That is the natural moment to move up, and teams that read it correctly move then. Teams that read it as a failure of ambition either move too early, onto a machine they cannot yet debug, or stay too long, polishing a walking demo nobody needed.

When is ROS 2 the better choice?

ROS 2 is the better choice for nearly every legged robot bought from a vendor, and pretending otherwise wastes your first month. Every serious quadruped and most humanoid platforms ship a ROS 2 bridge, which means the sensors, the joint states and the command interface appear in a format that mapping, navigation and visualisation packages already understand. Choosing anything else on such a machine means writing that bridge yourself before you write anything of your own. ROS 2 is also the answer when the robot's computing is split — an onboard board driving the legs and a workstation running perception is a standing arrangement in legged robotics, and HORUS is single-machine middleware validated in simulation, so shared memory stops at the edge of one computer and the multi-machine case is not the case it serves. And ROS 2 is the answer when students, collaborators or future hires are involved, because a legged project already contains enough novelty without the message layer being novel too. The smaller layer earns its place on a single board you own end to end, and nowhere else on this page.

Is a humanoid just a quadruped with a torso bolted on?

No, and here is why: the two machines fail in different directions, and the difference is not the number of limbs. A quadruped that loses its balance ends up standing awkwardly. A humanoid that loses its balance ends up on the floor, and getting off the floor is its own research problem that many platforms simply cannot do unaided. That single asymmetry changes everything downstream. It changes how you test, because a humanoid test needs a gantry, a harness or a person ready to catch. It changes how you write code, because every behaviour needs a safe exit that a quadruped can skip. It changes how long a session lasts and how many people it takes. There is a second difference that gets less attention: a humanoid's purpose is usually to do something with its hands, which means the legs are infrastructure rather than the product. On a quadruped the legs are the product. So the two machines are not two points on one scale of difficulty — they are two different projects that happen to share a walking problem.

Does time on a quadruped go to waste if humanoids are the goal?

Partly, but not the way you think. What is genuinely wasted is small: some gait-specific intuition, some familiarity with a vendor's particular interface, a few weeks of tuning that will not transfer. What carries over is nearly all of it — the perception stack, the planning, the message plumbing, the logging discipline, the habit of bringing up one joint at a time, the reflex of recording every run because the strangest failures happen once and never again. The part people actually mean when they ask this question is the résumé, and there the answer is more favourable than expected: hiring managers at humanoid companies read quadruped work as legged-robot work, and most of their open roles are perception, planning, tooling and infrastructure rather than whole-body control. Where the waste becomes real is if you stay on four legs for years while intending to work on two. The upper body is a genuinely separate discipline, and the only way in is to work on arms and hands, whether attached to a humanoid, an arm on a wheeled base, or a fixed manipulator on a bench.

How do you decide which body to start against?

Answer three questions and the choice usually makes itself. First: is the thing you want to build about getting somewhere, or about doing something with hands? Getting somewhere is a quadruped question, and a wheeled base may serve even better. Hands are a humanoid question, and no four-legged detour prepares you for them. Second: when this robot falls over or breaks, how long until you can run the next experiment? If the honest answer is longer than an afternoon, you have chosen a machine that will slow your learning to a crawl, whatever its specification. Third: who is in the room? One person means a machine one person can lift, reset and carry. A funded team with space, spares and a second pair of hands can absorb a humanoid's overheads. When the three answers disagree, follow the second, because iteration speed is what determines how much you actually learn, and it is the one factor people consistently discount when the videos are impressive. A related trade-off, on a smaller machine, is covered in whether humanoids or robot arms are easier to develop for.

A short version, by situation:

• If you are one person learning on evenings -> a quadruped, simulated first, because you are the only one who can pick the robot up.
• If your project is about hands doing work at human height -> a humanoid, in simulation until the hardware is justified, because nothing four-legged teaches the upper body.
• If you need a working demonstration inside a quarter -> a quadruped with a narrow goal, because the vendor already solved the walking.
• If you have funding, floor space and a second pair of hands -> a humanoid platform is now affordable in the only currency that matters, which is recovery time.
• If what you actually care about is autonomy rather than legs -> a wheeled base, because wheels delete the balance problem and keep everything interesting.

When you want to compare the software layers rather than the bodies, the HORUS Fit Framework lines them up on five things that are not numbers: ecosystem size, setup effort, team size fit, deployment target, and licence. On legged hardware, ecosystem size and deployment target carry the decision, because the vendor's bridge and the number of computers on the robot settle it before anything else does.

HORUS is open source under Apache-2.0 and the repository is linked below. Star it so it is in your list when you start building.