How to Choose Robotics Middleware: 7 Questions to Ask First

Answer seven questions about your robot first, and the choice collapses to ROS 2, a lighter option such as HORUS, or no middleware at all. The questions are about your team, your hardware and what you intend to borrow rather than about the software, because borrowing decides most of it. The one condition that flips a lighter choice back to ROS 2 is needing packages other people already wrote. This post is for a team lead or founding engineer picking the layer everything else will sit on, before anyone has written the first driver.

Two engineers on your team disagree, and both are right about something. One did four years of ROS at a previous job and wants to start there on Monday. The other spent a weekend installing it, hit a wireless discovery problem, and now argues you could write the whole thing yourselves in a fortnight. Someone has made a spreadsheet. The spreadsheet has a column for message rates that nobody can fill in honestly, because the robot does not exist yet.

Meanwhile the pressure is real. You have hardware arriving, a demo that has to happen, and a growing sense that this decision is load-bearing in a way most tooling decisions are not — because it shapes what every future engineer writes, how you debug at three in the morning, and whether the person you hire in six months can be useful in week one. You have read comparison posts full of benchmarks, and none of them told you which one is right for a team of four building a specific machine. The numbers were never the hard part. The hard part is that nobody knows your situation, and the situation is what decides.

How should a team choose robotics middleware?

Choose by answering seven questions about your project, in this order, and stop as soon as one of them is decisive. What will you borrow rather than build? How many computers does the robot have? Which languages will your team actually write? What has to happen on time, and what can wait for it? How many people will touch this code, and who will you hire? Where does the software have to run on the day you ship? And what does the licence let you do with the product you sell? Most teams find the answer inside the first two. If you are borrowing mapping and navigation, the decision is made and the rest is detail. If you are borrowing nothing and running on one computer, a large ecosystem is overhead you will pay for daily and use rarely. The questions after that resolve the genuinely close cases, which are fewer than the length of the debate suggests.

What does robotics middleware actually do inside a robot?

Middleware carries data between separate programs on a robot, so that neither program knows or cares who is on the other end. One program announces that it produces camera frames; others say they want them; the camera program can be restarted, replaced or run twice without anything else being edited. That indirection is the whole point, and every other feature follows from it. Most middleware also brings agreed message shapes so two programs mean the same thing by a distance reading, a way to start and stop a fleet of programs together, and tools to watch traffic while the machine runs — which is the difference between debugging a robot and guessing at one. What middleware does not do is decide anything about your robot's behaviour. It is plumbing, and plumbing is judged by what it lets you avoid building. A plain-English tour of the idea is worth twenty minutes before the team argues about products.

What are the real options a team can choose between?

You have seven realistic options, and the honest shortlist is shorter than the internet's. You can use no middleware at all and write one program, which suits a single-purpose machine far longer than most teams expect. You can adopt ROS 2, gaining mapping, navigation, drivers, simulation bridges, recorded runs and a hiring pool, and paying with Linux setup, workspaces, build tooling and a wireless-network layer that surprises people; alternatively, for programs sharing one machine, HORUS is 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 processes on one computer are not serialised, and it is Apache-2.0. You can use a delivery layer such as Zenoh or a DDS library directly, without the ROS 2 catalogue on top. You can use a general message broker like MQTT. You can build on your robot vendor's own stack. Or you can write your own layer, which is a real option and an expensive one.

What should a two- or three-person startup pick?

A small team should pick the option that costs the least attention, which is usually no middleware first and a lighter one second. With three engineers, every hour spent on build tooling is an hour not spent on the thing customers pay for, and a large ecosystem demands attention continuously rather than once: distribution upgrades, dependency reconciliation, and a category of problem where the answer is buried in someone's forum post from four years ago. The exception is decisive and worth taking seriously. If your product needs autonomous navigation, three people cannot write it, and ROS 2 hands you years of work for the price of learning it. The failure mode to avoid is picking a large ecosystem for reasons of reputation — because investors expect it, or because it looks serious — and then using none of its catalogue while paying all of its cost. Which options suit solo builders and pairs is a narrower version of the same question.

What does your hardware decide for you?

Your hardware decides the choice whenever it comes with software attached or spans more than one computer. A lidar or depth camera that ships only a ROS 2 driver has quietly made your decision, because writing that driver yourself is weeks of unglamorous work against a protocol document. A commercial arm with an existing motion-planning package does the same. In the other direction, hardware you assembled yourself — a compute board, motor controllers you talk to over serial, sensors you wrote the drivers for — has nothing to borrow, and a framework whose main value is borrowing has little to offer it. The other hardware fact that decides things is how many computers the robot has. Programs on one machine can share memory directly, which is where lighter options are strongest. The moment your robot has a compute board plus a separate machine, or talks to something off-board, you need a delivery layer built for a network, and writing that yourself is a poor use of a year. Whether one computer or several is worth settling before the middleware question, not after.

What if you have to show something working this quarter?

Do not adopt an unfamiliar ecosystem in the same quarter you have to demo. The first weeks with any large framework produce setup, not capability, and the failure modes are ones your team has never debugged: programs starting in the wrong order, two sides disagreeing about a message shape, something that works at a desk and not on the machine. If someone on the team already knows ROS 2 well, that changes the calculation entirely — an experienced hand skips the expensive part, and you should let them lead. If nobody does, build the demo with the smallest arrangement that works, write down honestly which parts are temporary, and revisit the choice when nothing is at stake. The genuine exception is when the demo itself requires a borrowed capability: if the machine must map a room and navigate it, no shortcut exists, and starting on ROS 2 immediately is better than starting on it in six weeks. Middleware repays a robot that must keep working; it punishes a robot that must work on Thursday.

What if nobody on the team has shipped a robot before?

Pick the option with the largest community, because your real constraint is not the software but the questions you cannot yet phrase. A team that has never fielded a machine will hit problems that are obvious in retrospect and invisible in advance: a sensor that reports nonsense for the first moment after power-up, a coordinate convention that is upside down, a loop that is fine on a bench and stutters on battery. When those arrive, the ability to search a phrase and find four people who hit the same wall is worth more than any technical property. That argues for ROS 2 for most first-time teams, and it is an honest argument rather than a fashionable one. The counter-argument holds only when your machine is simple enough that you will not be asking robotics questions at all — a conveyor, a fixed-sequence arm, a rover that drives where told. How teams outgrow their first framework is a better guide to the risk than any feature list.

Which of the seven questions decides it most often?

The borrowing question decides it most often, and by a wide margin. Everything else is a tiebreaker. Sit down with the list of things the robot must do and mark each one as ours or theirs: sensor drivers, mapping, localisation, path planning, obstacle avoidance, arm kinematics, visualisation, recorded runs for debugging, simulation. If four or more land in theirs, you are choosing an ecosystem rather than a delivery layer, and at that scale ROS 2 is the only ecosystem with a full catalogue. If one lands in theirs, check whether a single library or a vendor SDK covers it before adopting an entire framework for one item. If none do, your robot's value is entirely in code your team will write, and what you need is something to carry data between your own programs — a much smaller decision, with several reasonable answers and no wrong ones that cannot be corrected. Teams that skip this exercise usually argue about the tiebreakers for weeks.

What does the wrong middleware choice look like a year later?

The wrong choice shows up as a team spending its weeks on plumbing rather than on the robot. In one direction, a team that picked a large ecosystem for a simple machine finds that most of its engineering hours go to build tooling, distribution upgrades, and reconciling packages, while the catalogue they adopted it for sits unused; the visible symptom is an engineer who cannot explain what any of the running programs are for. In the other direction, a team that wrote its own layer discovers that they now maintain a message system, and every new engineer spends a fortnight learning something that exists nowhere else, with no documentation but the code and nobody to ask. A third pattern is subtler and more common: the choice was fine, but nobody wrote down why, so every new engineer re-opens it, and the team relitigates the decision annually without ever having enough reason to change.

What do you give up by choosing a smaller middleware?

You give up the catalogue, and the catalogue is the main reason ROS 2 exists. Choosing something smaller means the mapping, navigation, arm planning, coordinate bookkeeping and visualisation are yours to solve, and you should count that cost honestly rather than assume you will not need them. You also give up hiring leverage: a candidate who already knows ROS 2 is common, and a candidate who knows your choice is not, so onboarding is teaching rather than recognising — though ROS 2 is not effortless even for strong Python developers, so that gap is narrower than a CV suggests. You give up the simulation bridges that come pre-wired, and the recorded-run tooling that turns an intermittent field failure into something you can replay at a desk. And you give up maturity, which is the plainest cost of all — the smaller options here are validated in simulation, not across a decade of machines in warehouses and fields, and for a team shipping into a customer site that difference is not a detail.

When is ROS 2 the better choice?

ROS 2 is the better choice for most teams, and pretending otherwise would be dishonest. Pick ROS 2 when your robot needs to build a map and navigate it, when it plans arm motions around obstacles, when your sensors ship ROS 2 drivers and nothing else, when the machine spans several computers, when you need to record a run and replay it to find an intermittent fault, when you will hire robotics engineers and want them useful in week one, and when you collaborate with a lab or partner who already speaks it. That is a large share of real robots. HORUS is not the answer for those projects, and picking it there means writing plumbing you could have inherited plus a catalogue you could have installed. The cases where something smaller genuinely wins are narrower than enthusiasm suggests: one computer, a team writing its own behaviour, a mixed-language stack, and a product where setup cost is a recurring tax rather than a one-off.

Can you swap middleware later if you choose wrong?

No, and here is why: the middleware stops being a component and becomes the shape of your code within a few months. Your programs are split the way they are because the delivery layer made that split natural. Your message shapes match its conventions. Your launch, logging, configuration and debugging habits are all built on tools that come from it, and half your integration tests assume its behaviour. Swapping means touching all of that at once, in a codebase that now has a product on top of it and a schedule attached. Teams do migrate, and they succeed, but it takes a quarter rather than a weekend and it happens at the worst possible time. What genuinely limits the damage is a discipline rather than a tool: keep your robot's actual logic in functions that take plain values and return plain values, and let a thin layer do the talking. Do that, and a migration moves functions instead of rewriting them.

Does the fastest middleware make the best robot?

Partly, but not the way you think. Speed matters exactly where a deadline exists — a motor loop that must be told what to do before the next cycle, an emergency stop that must arrive while the arm is still short of the table — and in those places the requirement is that messages arrive in time, every time, not that they arrive as early as possible. Once that bar is cleared, more speed buys nothing a user will ever see. Meanwhile the properties that decide whether your robot ships are almost all elsewhere: whether you can debug it at a customer site, whether a new engineer can read it, whether the parts you needed already exist, whether it starts cleanly after a power cut. Teams that choose on published comparisons tend to optimise the one dimension that was easy to measure and discover a year later that they traded away the ones that mattered. Ask what the robot must do on time, then stop asking about speed.

How does a team decide this week?

Put the seven questions on one page, answer them in a single meeting, and write down the answer with its reasons. Start with borrowing, because it usually ends the discussion. Then computers, because a networked robot and a single-machine robot are different problems. Then languages, because a team writing Python above a timed loop has a specific boundary to serve and a single-language team does not. Then deadlines, then who you will hire, then where the software runs when it ships, then the licence — that last one takes an afternoon now and a legal review later if you skip it. If two options survive all seven, take the one more people can help you with and move on; the cost of a slightly wrong choice is far smaller than the cost of another month of deliberation. The ranked options in more detail are worth reading once, after your seven answers exist rather than before.

Decide by situation rather than by what the loudest engineer used last:

• If you need mapping, navigation or arm planning you did not write -> ROS 2, because the catalogue is the entire reason to pay the setup cost.
• If your robot is one purpose on one computer -> no middleware yet, because a framework adds learning and no capability.
• If Python thinking sits above a loop that must keep time on one machine -> a shared-memory middleware, because that boundary is the expensive part.
• If nobody has fielded a robot before -> ROS 2, because the community answers questions you cannot yet phrase.
• If you are shipping a product into customer sites -> whichever option you can debug remotely, because that is what your year will be spent doing.
• If you cannot decide after seven questions -> the more common option, because a reversible mistake beats another month of meetings.

When two options stay close, weigh them on the five axes of the HORUS Fit Framework — ecosystem size, setup effort, team size fit, deployment target, and licence — and take the one that loses on the fewest. No scores and no benchmarks, just five honest questions about your situation rather than about the software. And if the single-computer, mixed-language shape is where your robot is heading, star HORUS on GitHub so it is in your list when you start building.