What to Look For in Robotics Middleware If You've Never Chosen One

What to look for first is ecosystem, not speed: pick ROS 2 if your robot needs packages other people wrote, a lighter middleware if not. Everything else you will read about, including languages, setup and licence, matters, but it matters less than whether you will be borrowing navigation and drivers or writing your own. If you are writing your own, an option such as HORUS costs far less to live with. The rest of this post is for someone choosing middleware for the first time, with no strong opinion to defend and a robot they want to finish.

You have a robot that half works, and the half that works is one program you understand completely. Then the camera arrived, and now the wheels hesitate every time a frame comes in. Someone told you that you need middleware, so you searched for it, and now you have five answers. Three said use ROS, one said ROS is dying and you should look at something newer, and one said just use sockets and stop overthinking. The ROS tutorial opened with workspaces and build tools and you closed it after twenty minutes because nothing had moved yet. Every comparison page you find is a wall of numbers, and you have no idea whether any of those numbers describe a robot like yours. You are also aware, uncomfortably, that this feels like the sort of decision that is annoying to change later, and you do not want to spend a month learning something and then find out it was the wrong month. What you actually want is someone to tell you which questions matter.

What should you actually look for in robotics middleware?

Look at four things, in this order: what other people have already built that you would want to use, how much you must learn before anything moves, whether the languages you write are properly supported rather than technically supported, and what the licence lets you do with the result. That order is deliberate. Ecosystem comes first because it is the only item you cannot produce yourself; everything else is work you could do, but borrowed mapping and navigation are years you cannot make up. Setup effort comes second because it decides whether you finish anything at all in the next month. Language support comes third, and the word properly is doing real work there: a language that exists as a thin wrapper somebody maintains in their spare time will not feel the same as one the project treats as central. The licence comes fourth and takes ten minutes to check. Speed is not on the list, and the section further down explains why that is not carelessness.

What is robotics middleware, in plain terms?

Middleware is the part of a robot that carries data between separate programs so that none of them has to know the others exist. The camera program says here is an image, and the middleware delivers it to whoever asked for images. The motor program says give me steering commands, and it gets them without knowing what produced them. That indifference is the whole point, and everything useful follows from it: you can add a recorder later without touching the camera, replace the thing that decides where to drive, or restart one part of the robot without stopping the rest. Most middleware brings a little more with it, usually a way to start a set of programs together, agreed shapes for common messages so that two programs mean the same thing by a distance reading, and a way to watch messages going past while the machine runs. That last one matters more than beginners expect, because it turns why did it do that into something you can look at. A longer plain-English tour of the idea is worth an evening.

What middleware options actually exist for a first robot?

There are six realistic options, and the first is the right answer more often than the internet suggests. You can use no middleware at all and keep one program, which is what most working first robots are. You can adopt ROS 2, which brings mapping, navigation, drivers, simulation and the largest community in robotics, along with workspaces, build tooling and vocabulary to learn before anything moves. You can use a lighter middleware meant for programs sharing one computer: 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 machine are not serialised, which suits a Python program working beside a Rust or C++ loop. You can stay inside the toolkit that came with your kit or arm, which usually handles everything the vendor sold you and nothing beyond it. You can use a general message broker such as MQTT, familiar from web and home-automation work. Or you can connect programs with your own sockets, which teaches you a great deal and costs you evenings.

What should you look for if you are building alone at home?

Look for the option with the least to learn before your robot does something new, because alone at home your scarcest resource is momentum. That usually means no middleware at all for as long as the machine allows it, and then the smallest thing that solves the specific problem you hit. A solo builder gets no benefit from the parts of a large framework designed for coordinating teams, and pays the full learning cost of them anyway. There is one situation where the calculation changes: if the robot you want exists only because of a package somebody else wrote, such as a map-and-navigate rover, then the framework that hosts that package is worth the entire learning curve, because without it the project is not a weekend harder, it is impossible. So be honest about which robot you are building. A robot that follows a line, avoids things, drives an arm through a sequence or answers your phone needs no framework. A robot that maps your flat needs somebody else's mapping.

What should you look for if your robot runs on a Raspberry Pi or a Jetson?

Look at what the middleware leaves behind for your actual code, because on a small board everything competes for the same modest resources. A heavier framework will run on these boards, and plenty of people run it there, but you notice the cost in a way you would not on a desktop: the machine takes longer to come up, the build is slow enough to discourage experiments, and there is less room left for the camera work that is the point of the robot. The second thing to look for is whether messages stay on the board. If all your programs live on one computer, a layer that moves data between them without packing and unpacking it every time leaves more room for everything else. The third thing is memory card wear and cold-boot behaviour, unglamorous and the actual cause of most field failures on small boards. If your robot fits on one board and you write most of the code yourself, a lighter layer is the natural fit.

What if you want the robot moving within a month?

Choose the option that puts something on the floor this week, and treat the architecture as a later question. A month is enough to build a working robot with one program, and not enough to learn a large framework and build a working robot. That is not a criticism of the framework; it is arithmetic. So start with the single program, get the machine driving, discover that your sensor lies near shiny surfaces and that one motor pulls harder than the other, and let those discoveries happen early where they are cheap. If the loop stutters when the camera reads, take the smallest step that helps: process fewer frames, move the camera read onto its own thread, or ask less of it. Write down that you did it, so the patch is not mistaken for a design. Then, when nothing is at stake, look at middleware with a real problem in hand rather than an imagined one. Choosing with a concrete symptom is enormously easier than choosing from a comparison table.

What if Python is the only language you know well?

Check how the middleware treats Python before you check anything else, because there is a large difference between supported and central. In some projects Python is a first-class citizen with examples and documentation that assume it. In others it is a wrapper around a C++ core, maintained with less attention, where the error messages come from a layer you cannot read and the examples quietly stop at the interesting part. You will meet that difference on your first confusing evening rather than in the feature list. The second thing to check is what happens later, when the Python part is doing something heavy while another part has to keep time. That is the wall every growing robot meets, and the usual answer is to move the timekeeping into a faster language and leave the thinking in Python. A layer that makes that boundary comfortable saves you a rewrite. The bill for getting this choice wrong arrives mostly at that boundary, months after the decision.

How can you tell whether a middleware project will still be here next year?

Read the repository rather than the website, and look at four things that take ten minutes together. First, the commit history: is work happening across the last several months, or was there a burst two years ago and silence since? Second, the issues: are questions from outsiders answered, and answered by more than one person, or is there a single maintainer heroically holding everything up? Third, the releases: do they come out at all, and does the changelog read like maintenance rather than only new features? Fourth, the licence and who owns the project, because a permissive licence means the code survives the organisation even if the organisation loses interest. What you are trying to avoid is not an unpopular project, which can be excellent, but an abandoned one, which will eventually make you the maintainer of something you only wanted to use. A small active project is a much safer bet than a large dormant one.

What do first-time choosers usually get wrong?

The commonest mistake is choosing middleware before having the problem it solves, and the second commonest is choosing on numbers that describe somebody else's robot. Both come from the same anxiety, which is a suspicion that everyone else knows a correct answer you have not been told. The third mistake is subtler and more expensive: writing all your logic against whatever you chose, so that the sensor handling, the decisions and the motor commands are tangled up with the middleware's own vocabulary. Do that and changing your mind means rewriting the robot rather than the plumbing. The fourth is picking based on a comparison written by whoever built one of the options, without noticing. And the fifth is the opposite of all of these, which is deliberating so long that no robot gets built at all. If you have been reading comparisons for more than a week, stop reading and build the smallest version of your robot, because the machine will tell you more than the articles will. Beginners frequently need no middleware yet.

What do you give up by choosing a smaller middleware?

You give up other people's work, and for a beginner that is the largest single item on the bill. The big ecosystem means a sensor you buy often arrives with a driver already written, a mapping system exists that you could never build alone, there is a simulation setup that people have already made work, and when you get stuck at midnight somebody has asked your exact question in public and been answered. Choosing something smaller means each of those becomes yours to solve. You also give up a shared vocabulary: when you ask for help, you will spend the first paragraph explaining your setup instead of naming it. What you get back is far less to learn before your robot does something, a layer whose behaviour you can hold in your head, and fewer moving parts to debug at the exact moment you are least able to debug anything. For a robot that is mostly your own code on one computer, that trade is usually worth taking.

When is ROS 2 the better choice?

ROS 2 is the better choice the moment your robot depends on something other people have already built. A machine that must map a room and drive to a chosen point is a ROS 2 project, because mapping and navigation represent years of work nobody reproduces in evenings. If the sensor or arm you bought ships only a ROS 2 driver, that decides it. ROS 2 also wins when the robot spans more than one computer, when you want to record a run and replay it later to work out what happened, when you are aiming at a job or a research group where ROS 2 is what everyone speaks, and when you want a large public body of answers to search when you are stuck. HORUS is not the right answer for those projects, and picking it there means rebuilding things you could have inherited. The honest cost of ROS 2 is a serious amount of learning before your robot does anything new, and a strong preference for Linux.

Should you choose middleware by comparing speed claims?

No, and here is why: the numbers in those comparisons describe a test somebody designed, and your robot is not that test. Message-passing measurements are taken with particular message sizes, particular machines, particular numbers of programs and a system doing nothing else, and any of those differing from your setup can change the result entirely. Worse, the figure is almost never what limits your robot. A first robot is limited by a sensor that lies, a motor that pulls, a camera that takes its time and a loop that does too much, none of which appears in any comparison. There is a real question underneath the numbers, and it is worth asking in plain words: will messages arrive before the next thing that needs them, on my hardware, with my robot running? That question is answered by building the nastiest part of your robot and watching whether the arm stops before it hits the table. Everything else is somebody else's benchmark.

Are you stuck with the first middleware you choose?

Partly, but not the way you think. The plumbing itself is not the expensive part to change; rewiring how programs pass data between them is mechanical work. What gets expensive is everything that accumulates around the plumbing: the startup order that took a fortnight to get right, the calibration values that live in a configuration file, the tuning that makes the gripper close firmly enough without crushing anything, and the tools you have learned to debug with. That knowledge is the valuable thing you have built, and it moves badly when it is entangled with a specific middleware's vocabulary. So protect yourself with habits rather than by choosing perfectly. Keep hardware access in one place. Keep the code that decides things free of middleware types, taking plain values in and returning plain values out. Do that and switching later is an afternoon of moving functions, which means the choice you are agonising over is genuinely less permanent than it feels right now.

How do you decide which middleware to start with?

Write down the jobs your robot does, then write next to each one how long it can be made to wait before something visible goes wrong, and the answer usually falls out of the page. If everything can wait for everything else, you need no middleware and you should enjoy that for as long as it lasts. If one job cannot wait while another takes its time, you need separate programs, and the only remaining question is what carries data between them. If most of what the robot does will come from packages other people wrote, that answer is the large ecosystem and the learning is the price. If the robot is your own code on one computer, a lighter layer costs less to set up and less to understand.

• If this is your first robot and it does one thing -> one program, no middleware, because a framework adds learning and no capability.
• If you need mapping, navigation or a specific vendor's driver -> ROS 2, because those packages are the project.
• If your robot is Python thinking above a loop that must keep time, on one computer -> a shared-memory middleware, because that boundary is where the trouble is.
• If you bought a complete kit and are staying inside it -> the vendor's toolkit, because leaving early buys work rather than capability.
• If you want the robot moving this month -> the option with the least to learn, because momentum is the thing you cannot buy back.

When two options still look close, weigh them on the five axes of the HORUS Fit Framework: ecosystem size, setup effort, team size fit, deployment target, and licence. No scores and no numbers, just five honest questions about your own situation rather than about the software, and take whichever option loses on the fewest. And if your robot is heading towards several programs on one computer, star HORUS on GitHub so it is in your list when you start building.