Should You Build on a Humanoid Vendor's SDK or Your Own Stack?

Build on the humanoid vendor's SDK and add your own stack above it, rather than replacing the SDK, unless the vendor actively blocks you. The SDK owns balance, joint limits and the stop path, which nobody sane rewrites in a first year. The verdict flips when the SDK's own plumbing becomes the thing that stutters, and then ROS 2 or HORUS goes above the SDK, not instead of it. The rest of this post is for a team that has a humanoid, or an order for one, and is deciding how much of the software to own.

Right now there is a folder on your machine called something like sdk_examples, and it has a script in it that makes the robot wave. You have run that script maybe forty times.

The trouble started when you tried to make the robot do two things at once. Watch for a person, and walk somewhere. Both need the cameras. Both need to know where the robot is. The example script assumed it was the only thing running, and now you have two copies of it, arguing.

So you look at the vendor's documentation again and find that it stops exactly where your questions start. It tells you how to send a walking goal. It says nothing about what happens when your perception code is slow, or how to run a logger without stealing camera frames, or what to do when the behaviour program and the safety program disagree about whether to stop.

The forum threads are not encouraging. Half say use ROS 2 because everyone does. Half say the vendor stack is fine and ROS 2 is a tax. A few people insist they rewrote everything from the joints up and it was worth it, and you cannot tell whether those people shipped anything.

Should you build on the humanoid vendor's SDK or your own stack?

Build on the vendor SDK, and treat your own stack as the layer above it rather than a replacement for it.

The reason is ownership of the parts you cannot inspect. A humanoid SDK carries the balance controller, the joint limits, the thermal cutouts and the emergency stop path, all tuned against hardware and safety testing you cannot repeat in your workshop. Rewriting that is not ambition. It is a year spent arriving back where you started, with a machine that now falls in ways the vendor had already fixed.

What you should own is everything above the joints: perception, behaviour, logging, the state machine that decides what the robot is doing and why, and the plumbing that carries data between those programs. That is where your product lives, and it is also where vendor SDKs are thinnest, because the vendor cannot guess what you are building.

So the decision is not either-or. It is a line drawn through the stack, and the entire question is where you draw it and how much you let creep below the line.

What does a humanoid vendor's SDK actually give you?

A vendor SDK is the machine's driver layer plus a set of commands the machine is willing to accept, and very little above that.

Four things come in the box. Drivers, meaning the code that talks to motors, encoders, cameras and battery, which nobody outside the company could write. Controllers, meaning the loops that keep the robot standing and move a limb to a pose without shaking it. An interface, usually C++ with a Python binding, through which your programs send goals and read state. And often a simulation model of the same robot, which turns out to be the most valuable item of the four.

What does not come in the box is a way to organise your own programs. The SDK assumes one program talking to one robot. The moment you have a perception program, a behaviour program, a logger and a watchdog all wanting the same camera frames, you are past the edge of the documentation.

Every humanoid team fills that gap. The only variable is whether they fill it deliberately or by accident, one socket at a time.

What are your real options for the layer above the SDK?

Four, and teams usually try them in this order: the SDK alone, a hand-rolled layer, ROS 2, or a middleware built for a single machine.

The SDK alone means one program that does everything, calling vendor functions in a loop. That is correct for a first month and stops being correct quietly. A hand-rolled layer means you add sockets, files or a queue library yourself when the single program gets too big to reason about. ROS 2 means adopting the standard robotics ecosystem: nodes, topics, tooling, and a large body of existing packages that already speak a common language. A single-machine middleware means something like 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 computer are not serialised; that project is Apache-2.0 and validated in simulation, and it ships no drivers, no balance controller and no replacement for what the vendor gives you.

Most teams end up combining two of these rather than picking one.

How do the options above the SDK compare?

Read the last two columns first, because most teams are eliminated by what they already know and by how soon somebody wants a demonstration.

For what sits above and below each of these, the layer-by-layer view of a humanoid's software is the companion piece.

Which side of the line is right for a two-person team?

Stay on the vendor SDK longer than feels comfortable, and add exactly one layer when a specific symptom forces you to.

Two people cannot maintain a stack and a product at the same time. Every hour spent on your own messaging layer is an hour not spent on the thing that makes your robot worth showing to somebody. The teams that get furthest with two people are ruthless about this: they use the vendor's examples as scaffolding, keep everything in one process for as long as it holds, and split only when the single process stops being debuggable.

The symptom that justifies a split is not size. It is interference. When the logger writing to disk makes the arm hesitate, or the vision model's slow frame delays a stop command, one program has become two whether you like it or not.

At that point pick the smallest thing that fixes it. A small team adopting a large ecosystem to solve a plumbing problem usually inherits more maintenance than the problem was worth, and teams that rewrite their humanoid stack repeatedly almost always started with a decision like that one.

What if the robot only has one small computer on board?

Then everything you add above the SDK is competing with the vendor's own software for the same processor, and that changes the answer.

Humanoids are tight machines. The balance controller has to run whatever else is happening, and it already has a claim on the computer. Vision models want the accelerator. Your behaviour code, your logging and your messaging all queue behind those. On a machine with one board, an ecosystem that spawns many processes and copies data between them will be felt, and it will be felt as the robot moving less smoothly rather than as a number on a dashboard.

The practical rule is to keep data that is heavy and frequent, meaning camera frames and point clouds, from being copied between programs on that board. Whether you achieve that by keeping perception in one process, by using shared memory, or by moving the model onto a second computer is a design decision, not a religious one.

If the machine has two computers, this question mostly disappears, and the interesting question becomes which programs live where.

What if you have to show something working next quarter?

Then use the vendor SDK and the vendor's simulation model, write one program, and do not adopt anything.

Demonstrations are won by narrowness. A robot that does one thing convincingly beats a robot with an elegant architecture and a task that half works. The stack decisions that matter for a demonstration are the ones that let you change behaviour in an afternoon, which means scripting language, fast restarts, and a simulator where you can try something twenty times before touching hardware.

The trap is adopting a framework because the demonstration is important. Adoption costs its own weeks: environment setup, build systems, message definitions, launch configuration, and the debugging of problems that belong to the framework rather than to your robot. Those weeks come out of the demonstration, not out of some other budget.

Write the throwaway version. Then, if the demonstration goes well and the project continues, you will know exactly which parts hurt, and you will be choosing a layer against evidence instead of against forum advice. Deciding when to leave simulation is part of that same plan.

What if your team writes Python and has never shipped C++?

Then start in Python against the vendor's binding, and expect to move one or two pieces into a compiled language later rather than all of it.

Humanoid SDKs are built for exactly this. The vendor's real interface is usually C++, with a Python binding on top for research and scripting, so a Python-only team can drive the machine on day one. Perception glue, behaviour logic, data collection and experiments all live comfortably in Python and stay readable while three people change them.

What eventually moves is the small set of things that must react while the robot is in motion, and cannot pause. A safety watchdog. A hand controller closing a loop on force. Those pieces are small, and rewriting a small piece in C++ or Rust is a week, not a rewrite of the project.

The mistake is deciding in advance that a Python codebase is unserious and starting in C++ with a team that has never debugged a build system. That choice costs a quarter before the robot moves at all.

What does it look like when the vendor SDK stops being enough?

It looks like timing problems that move around, not like a missing feature you can name.

The first sign is usually a robot that behaves differently on different runs with unchanged code. It walks the route cleanly, then hesitates halfway, then does it cleanly again. The second sign is a logger or a recording tool that makes the machine worse whenever it is running. The third is a stop command that works on the bench and arrives late when the vision model is loaded.

Underneath all three is the same thing: programs on one computer competing for the processor and copying large data between themselves, with no rule about who gets served first. The SDK never promised to arbitrate that, because the SDK expected one program.

Teams misread these signs constantly. They retrain the model, add filters to the controller, or blame the hardware, and the behaviour persists because the fault was never in any single program. The diagnosis to reach for is why a robot behaves differently every run, which is a plumbing question wearing a control theory costume.

What do you give up by owning the layer above the SDK?

You give up simplicity, vendor support for anything you touched, and the ability to blame somebody else.

Simplicity goes first. One program is easy to reason about. Once there are five, you own the questions of what starts in what order, what happens when one dies, how they agree about time, and how you watch all of them at once. Those are real problems with real solutions, and none of the solutions are free.

Support goes next, in a specific way. Vendors will help with their own interface. The moment the report says the robot hesitates while our messaging layer is running, you are on your own, and rightly so. Keeping a reproducible case that uses only vendor code is the difference between a support ticket and a shrug.

The subtler cost is that your layer becomes a thing you maintain forever, including on the day the vendor changes their interface. That is affordable if the layer is small and boring. It becomes the project itself if you let it grow features nobody asked for.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever you need what the ecosystem already contains, and that is more often than middleware enthusiasts admit.

Three cases are clear. First, when your humanoid has to navigate an environment: mapping, path planning, costmaps and the tooling around them exist in ROS 2, are used daily by thousands of people, and would take you a year to approximate. Second, when the robot spans several computers, or an operator station, because the ROS 2 model was designed for exactly that and handles it without special effort. Third, when you are hiring, teaching, or handing the project to a university partner, since ROS 2 skills are what the market actually has.

There is also the vendor's own hand: many humanoid vendors publish ROS 2 bindings first, which means the well-trodden path through their documentation is the ROS 2 path.

HORUS is not the answer in those cases. A single-machine middleware gives you no planners, no visualisation, no drivers and a far smaller community, and none of that is a fair trade when what you needed was navigation and colleagues.

Does building your own stack mean rewriting the walking controller?

No, and here is why: the walking controller is the one part of a humanoid that outside teams almost never touch, and the vendors have arranged things so that you do not have to.

Balance is a closed-loop problem tuned against a specific machine, with specific masses, specific joints and specific failure modes, tested in ways that involve breaking robots. What the vendor exposes to you is the layer above that: go here, adopt this pose, hold this stance, stop. Your stack sends those goals and reads the machine's state back. It does not compute torques.

This is why owning your stack is more affordable than it sounds. The frightening part of humanoid software, the part with the physics and the safety consequences, is not the part you are being asked to write.

The exception is research whose subject is locomotion itself, where teams need lower access and often negotiate it explicitly with the vendor, or buy a machine chosen for that openness. If that is your project, choose hardware on that basis before writing anything.

Will the vendor eventually lock you out of your own robot?

Partly, but not the way you think: the usual lockout is not a legal one, it is a support one, and it happens gradually.

The dramatic version people fear, where a firmware update disables a machine you own, is rare and would be commercially suicidal for a vendor selling to developers. What actually happens is quieter. The interface changes between releases and your code needs work. A feature you depend on is deprecated in favour of a newer path. The examples are rewritten around a stack you did not choose. The vendor's attention moves to a newer model, and questions about your robot get slower answers.

The defence is not paranoia, it is a boundary. Keep the vendor's interface behind a thin layer of your own, so that when the interface changes you edit one file rather than fifty. Keep your perception, behaviour and messaging free of vendor types. Teams that do this survive a vendor change with a bruise; teams that scattered SDK calls through their whole codebase rewrite the project.

How do you decide where to draw the line this quarter?

Draw the line at the first place the vendor SDK gave you a symptom you can describe in one sentence, and nowhere higher.

Most bad stack decisions are made before any symptom exists, out of a feeling that the SDK is not serious enough. That feeling is not evidence. Evidence is: the arm hesitates when the logger runs. Two programs need the same camera and one is starving. The stop command arrives late under load. A colleague cannot get a second program running at all.

Write the symptom down. Then ask which of the four options addresses precisely that symptom and nothing else, and take the cheapest one. If no symptom exists yet, the correct action this quarter is to build more of your product on the SDK and revisit later, with the robot doing more than it does today.

The second question is who else needs to work in this codebase within a year. A stack nobody else can start is a liability regardless of how well it performs when you are the one running it.

• If you are in your first weeks with the robot -> the vendor SDK alone, because you do not yet know which problems are real.
• If you need mapping, navigation or a second computer -> ROS 2 above the SDK, because those parts already exist and are maintained.
• If several programs on one board are tripping over each other -> a single-machine middleware, because the fault is copying and scheduling rather than logic.
• If a demonstration is due next quarter -> one program against the SDK and the simulator, because adoption costs weeks you do not have.
• If your subject is locomotion itself -> a machine chosen for low-level access, because no software decision recovers a sealed controller.
• If the vendor's interface is scattered through your codebase -> a thin boundary layer first, because that is what makes every later decision reversible.

The HORUS Fit Framework reduces the choice to five things you can judge without a benchmark: ecosystem size, setup effort, team size fit, deployment target and licence. On humanoids, deployment target and team size fit usually decide it, and licence becomes urgent the day a customer asks what exactly they are buying.

The week your robot starts hesitating under its own software is a bad week to begin researching middleware. Put HORUS on the shelf before then: star it so it is in your list when you start building.