Building a Robot Dog: The Software Choices That Save Months

Buy a quadruped that already walks and start on its vendor SDK; move to ROS 2 or a smaller stack when the SDK blocks you. Most of the months a dog project eats go to locomotion and hardware, not to whether messages move through ROS 2, through HORUS, or through the vendor's own library. That flips when legged control is the research itself. The rest of this post is for someone about to spend real money on a dog and wanting to know which decisions are reversible.

You saw the video. A quadruped trotting over gravel, recovering from a shove, climbing a stair it had never seen. You bought the parts, or you bought the dog, and now there is a machine on your bench that either lies flat or stands up and shakes until you catch it. Six weeks in, your notes read like a list of unrelated emergencies: a motor that reports a different angle after every power cycle, a leg that works on the left and not the right, a gait that walks beautifully on lino and falls on carpet. You have rewritten the gait three times. You have also, somewhere in there, spent two weekends on the plumbing — the part that carries joint positions up from the motors and commands back down — and you cannot tell anyone what those two weekends bought. When you ask for help, people answer with framework names, and none of the answers explain why your dog is on its side. The question underneath all of it is which of these problems is the one actually costing you months.

Which software decisions on a robot dog are worth agonising over?

Three decisions cost months if you get them wrong, and the choice of message layer is rarely one of them. The first is whether you write the walking controller or take one that already works, because balancing on four legs has consumed careers, and a version written in a spare month falls over in ways nobody can diagnose. The second is where the fast loop runs: the code keeping the dog upright must run without interruption, and sharing its computer with a vision model that occasionally stalls is a decision you pay for on a floor somewhere. The third is whether you can reproduce a failure without the dog: if the only way to see a bug again is to walk the machine down the corridor and hope, every fix costs a day. Everything else is recoverable. You can swap a planner, change a language, or rewrite the behaviour logic over a weekend. What you cannot cheaply undo is a design where the thing keeping the dog upright shares a queue with the thing looking at pictures, which is why the timing of that loop is the part to protect from the first week.

What does the software on a robot dog actually consist of?

The software on a legged robot is four layers stacked, plus the plumbing that runs between them. At the bottom sit the motor controllers, usually firmware on the joints themselves, which take a target angle or torque and hold it. Above that is the balance and gait layer, the part that decides on a strict cadence where each foot should be so the body stays over its feet. Above that is state estimation, which merges joint angles with an inertial sensor to answer a question the dog cannot observe directly: which way is up, and how fast am I moving. Above that sits everything you think of as the robot's job — seeing, mapping, deciding where to go, being told what to do by a person. Running through all of it is the plumbing, which carries joint states up, carries commands down, and decides what happens when one part is late or dead. Newcomers assume the top layer is the hard one because it is the visible one. On a dog the middle two are where the months disappear, and the plumbing is where the inexplicable failures come from.

What are the real software options for a legged robot?

A robot dog project chooses between five families, and most projects end up using two of them together. The first is the vendor SDK that came with a bought quadruped, which already contains a walking controller and exposes it as commands you send. The second is ROS 2, which brings a message layer, a build system, a catalogue of drivers and planners, and simulation that speaks the same message types as the hardware. The third is a single-machine message layer such as HORUS, where Rust, Python and C++ share the same shared-memory ring buffers so messages are not serialised between processes on one computer — an Apache-2.0 project aimed at robots where sensing, control and actuation live on one board, which describes almost every dog. The fourth is a learning stack: a physics simulator plus a training framework, used to produce a walking policy you then run on the machine. That is not a middleware and does not replace one. The fifth is no middleware at all — one program, one language, threads and queues — which is where many dog projects honestly start and where a few should stay.

Which of these fits which kind of dog project?

The fit depends mostly on how much of the dog you intend to build rather than assemble.

Most working dogs are two rows at once: a vendor SDK or a firmware layer holding the legs up, and something above doing the job.

What should I use if I am one person doing this in evenings?

Buy the dog, use its SDK, and spend your evenings on what the dog does rather than on how the dog walks. That is the largest month-saving decision available to a solo builder, and almost everyone resists it, because building the legs feels like the real work. Building legs is real work; it is also the better part of two years, most of it mechanical and electrical rather than software, ending in a machine that walks worse than one you could have bought. If the budget is not there, the honest alternative is not a cheaper dog but a smaller problem: a single leg on a test rig, a two-legged hopper, an arm. Those teach the same control ideas and fit on a desk. If you do build anyway, keep the software as small as you can defend — one program, one language, threads and queues — until you hit a boundary that forces something bigger, such as a vendor library that exists only in C++. The test worth applying every few weeks is whether you could rebuild your whole setup from a blank machine in one evening.

What if I bought a quadruped rather than building the legs?

Your first job is finding out exactly how much of the dog the vendor will let you touch, because that boundary shapes every later decision. Vendors differ enormously here. Some expose a high-level command — walk this way at this pace — and nothing underneath, which is fine when your work is navigation or carrying something and fatal when your work is the gait. Some expose joint-level control, but only through their own library, in their own language, on their own release schedule. Some ship a ROS 2 bridge, which is convenient and usually adds a hop your commands and readings must pass through. Find the boundary in week one by writing the smallest program that reads joint states and sends a single command, then noting everything you had to install to make that work. Whatever sits on the far side of that line is not yours and will not become yours. If your project's contribution lives on the far side, you bought the wrong dog, and learning that early is worth more than any comparison of a vendor SDK against your own stack.

What if something has to walk in three months?

Buy the dog, use the vendor's walking controller, and freeze every decision that is not about the demo. Three months is enough to make a bought quadruped do one specific useful thing, and nowhere near enough to produce a gait, adopt a stack nobody has used, or absorb a hardware order that slips. The failure pattern is consistent: six weeks evaluating, four weeks integrating, and a discovery in the final fortnight that the dog falls over on the actual floor of the actual venue, which is the problem nobody scheduled. Work backwards instead. Decide what must happen on the day, get the dog doing a bad version of it inside the first fortnight, and spend the remaining time making the bad version survive the real place — the real floor, the real lighting, the real crowd standing too close. Along the way, protect two things above all: a way to stop the dog instantly that does not run through the software you are debugging, and a recording of every run, so a failure at the venue is something you can study rather than something you remember.

What if Python is the only language I am fluent in?

Python is enough to build the interesting parts of a robot dog and not enough to hold one upright. That is not a criticism of the language; it is simply where the boundary falls. The layer keeping four feet under a body must run on a strict cadence with no pauses, and a language with a garbage collector will occasionally pause at the wrong moment. On a wheeled robot a pause means a jerky line. On legs a pause means the machine is on its side and something is bent. The practical answer is to let somebody else own that layer — the vendor's controller, firmware on the joints, or a compiled component you obtained rather than wrote — and do everything above it in Python. Perception, behaviour, mission logic, the interface a human operator uses: all fine in Python, and all where your hours are best spent. The trap to avoid is a design where a Python process sits inside the balance loop, because that design works on your desk, works in the first demo, and fails on the day there is an audience.

What changes when the dog has to leave the lab?

Everything the lab was quietly providing disappears, and almost none of it was in anyone's plan. Indoors, on flat floor, with a full battery and a good network, a dog looks solved. Outdoors the floor is uneven and sometimes wet, the battery sags under load, the joints behave differently as they warm, and the network you were streaming video over is now a phone hotspot behind a hedge. Three consequences follow. The dog must keep walking when the link drops, which means the balance loop and the emergency stop cannot live at the far end of a wireless connection. Logs become your only witness, because nobody watches a terminal while chasing a machine across a field. And starting the robot has to be one action performed by a tired person, in the rain, with no laptop. Teams that defer all this rediscover it in public, usually while being filmed. The cheap preparation is to run one full untethered session outdoors on your first outdoor day, long before the dog is asked to do anything clever there.

What do I give up by not building the dog on the standard stack?

You give up the catalogue, the shared vocabulary, and the ability to hand the problem to somebody else. The catalogue is the concrete loss: lidar drivers, a mapping stack, a navigation stack, a viewer that shows what the dog believes the world looks like, and a simulator speaking the same message types as the robot. If your dog must build a map of a building and walk through it without hitting people, that is a multi-year project you would be starting from nothing. The vocabulary is the quieter loss. When you ask a question, the standard stack is what people answer in. When a student joins, the standard stack is what they already learned. When a contractor quotes, the standard stack is what they quote for. There is also a staffing version: on a smaller stack, the only person who understands the plumbing is on your team, permanently. Whether any of that matters is a function of your parts list and your plans, so write both down before deciding. The answer is usually obvious once the lists are on paper.

When is ROS 2 the better choice?

ROS 2 is the better choice for any dog whose value comes from what it does with a map. If the machine must explore a building, come back, avoid a person who steps in front of it, and be checked in a simulator that speaks the same message types as the hardware, ROS 2 is the answer and nothing else comes close, because that stack exists today and writing it from nothing does not fit in any schedule. ROS 2 is also the answer when the dog spans machines by design, with a workstation doing perception and the robot carrying only the fast loop, since HORUS is single-machine middleware and shared memory stops at the edge of the computer. ROS 2 is the answer when students, collaborators or contractors will touch the code, because the standard stack is the one they already know. And ROS 2 is the answer when your vendor's only supported integration is a ROS 2 bridge, because fighting that becomes a project of its own. In all those cases the ecosystem decides, and a smaller stack buys a property you did not need.

Is a robot dog just a wheeled robot with extra motors?

No, and here is why: a wheeled robot that stops computing stays where it is, and a legged one falls over. That single difference propagates into every software decision on the machine. On wheels, a late message means a jerk or a slightly wrong path. On legs, a late message during the balance loop means the body is already committed to a foot placement that never arrived. On wheels you can pause the stack, think, and resume. On legs a pause is damage. On wheels a crash in an unrelated component is an annoyance; on legs, anything sharing a computer with the balance controller is a hazard until proven otherwise. The practical consequences are specific. The dog needs a way to sit down safely that does not depend on the code you are currently breaking. The fast loop needs isolation from everything that can stall, including your own vision model. And testing has to include being shoved, standing on something that moves, and losing power mid-stride, none of which a wheeled robot forces you to think about early.

Will a trained walking policy make the software stack irrelevant?

Partly, but not the way you think. A learned policy genuinely can replace a hand-tuned gait, and on some machines it walks better than anything a small team would write by hand. What a policy does not replace is any of the plumbing around it. The policy still needs joint states arriving on time, still needs its commands reaching the motors without a stall in between, still needs a safety layer able to override it, and still needs something recording what it did on the run where it failed. In practice the stack around a learned policy looks like the stack around a written controller, with one extra worry: the policy came out of a simulator, the physical dog is not that simulator, and you now need a way to compare what the policy expected against what it got. That is a data problem, solved with recordings and replay rather than with a better network, and it is the whole subject of getting a robot from simulation to reality.

How do I make this decision before the parts arrive?

Answer three questions on paper, in order, and the choice makes itself. First: is locomotion your contribution or your prerequisite? If locomotion is the prerequisite, you are buying a dog and never writing a gait, which removes most of the hard software from the project before it starts. Second: how many computers will run your code when the dog works — one board on its back, or a board plus a workstation? One board removes a whole category of network problems and makes single-machine options sensible, while two computers change the shape of the answer. Third: write the list of things you will not write yourself. If that list contains mapping, navigation, a lidar driver and a simulator, take the ecosystem that already has them and accept the upkeep. If the list is short and vague, take the smallest thing that moves messages between your parts and spend the saved months on the dog. When the three answers disagree, the third wins, because a catalogue takes years to replace and a message layer takes a fortnight.

A short version, by situation:

• If you are one person who wants a dog doing a job -> buy the quadruped and use its SDK, because writing a gait is the two years you do not have.
• If your dog must map a building and navigate it -> ROS 2, because that stack already exists and rewriting it fits in no schedule.
• If the whole dog runs on one board and mixes a compiled control loop with Python -> a single-machine message layer, because there is no network to design around.
• If legged control is your actual research -> a physics simulator and a training framework first, and the plumbing decision can wait a while.
• If you have a demo in three months -> whatever is already running, frozen today, because changing foundations under a deadline is how demos are lost.

When you want to compare options rather than symptoms, 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 a dog, deployment target does most of the work, because a machine that carries its own computer and falls over when something is late is a narrower target than anything on wheels.

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.