Which Robotics Stack Survives Contact With Real Hardware?

Most robots survive contact with real hardware on ROS 2, because the drivers already exist; HORUS wins only when same-machine timing is what breaks. Real hardware punishes whatever your stack is worst at: it arrives late, floods the network, and never stops. The condition that flips this is a robot whose programs all live on one board and pass heavy sensor data between themselves. The rest of this post is for a team whose demo already works and who now have to make it work every morning, on the actual robot.

The demo was fine. That is what makes this confusing. In simulation the arm reached, the base drove where it was told, and the whole thing ran for an hour while somebody filmed it.

Then it went onto the robot, and now it is a different machine every day. Monday it works. Tuesday it works until the second camera comes up, and then the arm gets jerky in a way nobody can reproduce. Wednesday somebody plugs in a laptop to watch what is happening and the behaviour changes, which is the most annoying kind of bug there is, because the act of looking is the thing that broke it.

Nobody can say which layer is at fault. The control code looks right. The motors are fine on the bench. The sensor publishes at the rate on its datasheet. And yet the robot stutters, and the person who wrote the planner and the person who wrote the driver each have a plausible story about why it is the other one's problem.

Somewhere in that week, someone says out loud that maybe the whole foundation was the wrong choice.

Which robotics stack survives contact with real hardware?

The stack that survives is the one whose failure modes you can already recognise, which for most teams means ROS 2, because a decade of other people's field problems has already been paid for and written down. Survival on hardware is not mostly a property of message passing. It is a property of how quickly you can tell what went wrong at four in the afternoon with a customer watching, and that depends on tooling, on shared vocabulary, and on whether the error you are staring at has ever been seen before by anyone.

There is one specific case where the foundation itself is the thing that fails, and it is narrow. A robot with several programs on one computer, passing large sensor data between them, on a board with no headroom to spare, will spend its capacity copying that data rather than acting on it. That failure looks exactly like sloppy code, which is why teams chase it in the wrong place for months.

Everything else that hurts in the first hardware month, and there is a lot of it, is unaffected by which foundation you picked.

What is a robotics stack, in plain terms?

A robotics stack is everything your robot runs that is not the clever part you were hired to write. It is the layer that lets separate programs find each other and exchange data, plus the conventions around that: how messages are described so two programs agree on their meaning, how a set of programs is started and supervised together, how time and coordinate frames are handled, and how you record a run so you can watch it again afterwards.

Most people picture the messaging and stop there. In practice the rest of that bundle is what you touch daily. The launch and configuration system becomes your deployment story. The recording format becomes your dataset. The coordinate conventions become assumptions buried in geometry code nobody has reread since the day it started working.

The stack also decides what a failure feels like. When a sensor stops, one foundation gives you a program that blocks forever and another gives you stale data that looks fresh. If those words are new, the plain-English guide to robotics middleware is the better place to start than this post.

What are the real options once actual hardware is in the room?

There are about seven, and only two of them are what people mean by choosing a stack. The common answer is ROS 2 with its default transport, which brings navigation, mapping, motion planning, a visualiser and drivers for hardware you can actually buy. The variant that solves most transport complaints is ROS 2 with something different underneath, because ROS 2 speaks to the wire through an abstraction layer and swapping the layer costs far less than swapping ROS 2. HORUS sits beside ROS 2 as a different answer to the same question: an open-source real-time robotics middleware for Rust, Python and C++ where all three languages share the same shared-memory ring buffers, so messages between processes on one machine are not serialised, published under Apache-2.0, validated in simulation, and shipping no navigation or mapping of its own.

The other five are narrower. A hardware vendor's SDK, if you have committed to one robot from one supplier. Moving the tight loop onto a microcontroller and leaving Linux for perception. Collapsing everything into a single program with no middleware at all. Or writing your own transport for one path that matters and nothing else.

How do these options compare side by side?

Read the last column first, because most teams can eliminate four rows in a minute and the real argument is between the two that survive.

What do teams try first when hardware exposes the stack, and why does that stop working?

The first move is almost always to turn things down, and it works for about a fortnight. Someone lowers the camera resolution, drops the publish rate on the stream nobody is watching, closes the visualiser during runs, and the stutter goes away. This is a legitimate fix and it buys real time. It stops working the moment the product needs the thing that was turned down.

The second move is to buy a bigger computer. That also works, and also stops working, because a faster board makes the same amount of copying take less wall-clock time without changing the shape of the problem. Add one more consumer of the camera stream and the ceiling reappears at the new level.

The third move is a workaround with a nickname. Every team that has outgrown its foundation has one piece of software whose entire job is to compensate for the foundation, usually maintained by whoever was least able to refuse. When that program exists and somebody is afraid to touch it, the stack has stopped being a tool and started being a constraint. Why robots slow down as you add features is the longer version of this arc.

Are you a hobbyist, a startup, or a company shipping units?

A hobbyist should pick the option with the most people to ask, which is ROS 2, and should not spend an evening on this decision. A first robot fails on connectors, power, coordinate conventions and a driver that only works on one kernel version. None of those are messaging problems, and an uncommon foundation turns one solvable project into two unsolved ones.

A startup of roughly two to ten engineers is where the decision actually bites. The codebase is already larger than one person's head, the hardware is real, and a foundation change eats a quarter that the runway may not have. This is the group that should test the specific failure before choosing, because the difference between a transport problem and a badly split set of processes is invisible from the outside and expensive to guess wrong.

A company with units in the field is past the technical question. Field robots run the current build, paperwork names the current stack, and the honest move is a boundary rather than a switch, drawn so the next product line can be built differently. What to check before betting a product on an open-source stack is the checklist for that call.

What hardware are you actually putting this on?

The hardware decides more of this than any architectural preference, and the deciding factor is usually a driver. A depth camera with a vendor-supplied package for one stack and nothing for the other has already made the choice, and no amount of design taste outvotes a sensor you have already bought and cannot return. Write down every device on the robot and, beside each one, the name of whoever supplies its driver.

The compute layout matters next. A robot with one board running everything is a robot where every message is a same-machine message, and that is precisely where a shared-memory foundation behaves differently from a network-shaped one. A robot split between an onboard computer and an operator laptop has a real network in the middle that no shared-memory arrangement touches, so the network-shaped foundation is the honest fit.

Then there is the split that dissolves the argument. Put the deadline-critical motor loop on a microcontroller, leave Linux for perception and planning, and the messaging layer is no longer on the critical path. Whether your robot needs one computer or several is worth settling before the stack question.

How long until the robot has to work in front of someone?

With a demo inside a month, do not change the foundation, and treat that as a decision rather than an avoidance. Reduce what the busiest stream carries, close the tools nobody needs while the robot is running, pin the process that matters to a core of its own, and cut scope. Each is reversible in an afternoon and none can break the demo the night before.

With a quarter, you have room to find out where the time actually goes and to try the cheap structural fixes: change what sits under the existing stack, merge two programs that already live and die together, move one heavy consumer off the hot path. Most teams find something surprising in the first fortnight, and the surprise is usually not the transport.

With a year, decide by where the robot is going rather than where it is today. A product that will gain more sensors, more consumers of a single stream and tighter timing is a product whose foundation is under steadily increasing load, and that is the case where changing early costs less than changing late. Why projects stall after the prototype covers what the late version looks like.

What does your team already know how to do?

Your team's existing knowledge is worth more than any property of the foundations being compared, and teams routinely value it at nothing. A group fluent in one stack recognises a strange failure in an afternoon because somebody has seen its shape before. The same group on an unfamiliar foundation spends a week on the same failure, because recognition is exactly the thing being rebuilt from scratch.

Language matters more than most comparisons admit. A team that writes only Python and has never had to think about who owns a piece of memory will find that a shared-memory foundation asks a question nobody has asked them before, and the answer takes weeks to become instinct. A team already writing C++ or Rust finds the vocabulary familiar, and the cost becomes configuration rather than education.

Hiring outlasts the decision by years. A widely known foundation means candidates arrive already speaking the language and are useful in their second week. A less common one means you train everyone, which is affordable while the team is small and becomes a permanent tax once it is not.

What do you give up by picking a stack for hardware reasons first?

You give up the packages, and that is a much bigger bill than it sounds. Choosing a foundation because it handles same-machine data well means writing or porting the things a mature ecosystem hands you: the mapping, the path planning, the arm motion planning, the calibration tools, the visualiser, and the driver for every device you buy. Teams consistently underestimate this because those pieces are invisible until they are missing.

You also give up the crowd. When your question is unusual, fewer people have answered it before you, search results run out faster, and the coding assistant you ask has read far less material about your problem than about the common alternative. That is a daily cost even when the technical choice was correct.

And you give up a shared vocabulary with the rest of the field. Conference talks, tutorials, university courses and job candidates all speak one dialect. Choosing another means translating constantly, and it means that the engineer who leaves takes knowledge with them that the next hire does not arrive with. Why teams outgrow their first framework is the other side of the same trade.

When is ROS 2 the better choice?

ROS 2 is the better choice for most robots being built right now, and HORUS is simply the wrong answer for a project whose real need is everything except messaging. If you want mapping, autonomous navigation, arm motion planning, a way to see what the robot believes about the world, or a driver for hardware already sitting on your bench, use ROS 2 and use the packages. They represent an enormous amount of accumulated work that no sensible team reproduces for a first product.

Use ROS 2 when the robot spans more than one machine, because a network-shaped foundation is the correct shape for a network-shaped robot. Use ROS 2 when you are hiring, because candidates arrive fluent. Use ROS 2 when your team is large enough that a common standard beats any individual technical win, which happens sooner than founders expect.

And use ROS 2 when you have not yet proven where the time goes. Changing a foundation on a hunch is how teams spend a quarter and arrive at the same symptom with unfamiliar tools. The direct comparison of the two walks through where each one wins.

Is your messaging layer the reason the robot stutters on real hardware?

No, and here is why: most hardware stutter comes from four causes that sit above and below the messaging layer, and they all present identically. The first is a control loop doing work that does not belong in it, such as allocating memory, writing a log line to disk, or waiting on a device that occasionally takes its time. The second is process scheduling, where the loop and a heavy vision program compete for the same core and the operating system arbitrates in a way nobody asked for.

The third is the device itself. Sensors deliver data on their own schedule, some of them buffer, some of them hand you a timestamp from a clock that disagrees with the computer's, and code written against the simulator's tidy delivery encodes assumptions that hardware violates.

The fourth is thermal. A board that throttles when it warms up produces a robot that behaves differently after twenty minutes, which is the exact shape of bug that gets blamed on software. What to do when simulation and hardware disagree is a better first stop than a foundation change.

Does a faster computer fix a stack that struggles on hardware?

Partly, but not the way you think: more compute raises the ceiling without changing the slope, so you buy time rather than headroom. If the trouble is that a large camera frame is copied several times on its way to three consumers, a quicker board performs the same copies faster and the robot behaves better for a while. Add a second camera, or a fourth consumer of the first one, and the ceiling comes back at the new level, having cost you money and a hardware revision.

There is also a version of this that makes things worse. A more capable board invites more ambitious software, so the team adds the vision model they were putting off, and the margin the upgrade bought is spent within a month by the people who asked for it.

The upgrade genuinely fixes one case: when the machine simply lacks the capacity for the work, with no structural waste involved. Tell them apart by adding one more consumer of your busiest stream and watching whether the robot degrades gently or falls off a cliff.

How do you decide which stack to build on?

Decide by writing down the specific thing your robot must do that the current arrangement cannot, in one sentence containing a product requirement rather than a feeling. If the sentence names a requirement and you have shown the failure by experiment rather than argued it in a meeting, a foundation change may be worth paying for. If the sentence says the team finds the stack unpleasant, that is real and it is not a reason, because no migration has ever fixed a morale problem.

Then run the experiment that actually separates the cases. Put every program on the real board with real sensors attached and let it run far longer than a demo. Unplug something. Kill a process mid-motion. Start the programs in the wrong order. Let the machine get hot. The failures that show up in that hour are the ones that will define your next year, and almost none of them will be the ones you were arguing about.

Here is the whole decision in five lines.

• If you are building your first robot -> ROS 2, because your problems will be drivers and wiring, not messaging.
• If the robot spans a computer and a laptop -> ROS 2, because the network is real and a shared-memory trick does not cross it.
• If several programs on one board pass heavy sensor data and the loop is late -> a shared-memory foundation, because that is the exact problem it exists to solve.
• If the motion loop must never be interrupted -> put the loop on a microcontroller, because then the stack choice stops being on the critical path.
• If you cannot name what the current stack is blocking -> stay put and instrument, because a change on a hunch costs a quarter and answers nothing.

The HORUS Fit Framework compresses this into five axes you can score any option against: ecosystem size, setup effort, team size fit, deployment target, and licence. On a hardware decision, deployment target and ecosystem size carry most of the weight, because they decide what drivers exist and who can help you at four in the afternoon.

The cheapest time to have an alternative on the shelf is before the week you need it. Put HORUS there now: star it so it is in your list when you start building.