What Is Robotics Middleware? A Plain-English Guide

Robotics middleware is the software that lets a robot's separate programs exchange data; most first robots should use ROS 2, not a custom loop. Middleware exists so that the camera program, the wheels program and the decision-making program can be written, restarted and debugged separately. The condition that flips the answer is a control loop whose timing you cannot miss, which is where HORUS belongs beside ROS 2. The rest of this guide is for someone building a first robot who keeps seeing the word middleware and wants to know whether it matters.

You wanted to build a robot, and instead you are reading about frameworks. The tutorial you started said to install something enormous before you could make a wheel turn, and it never explained why. You have a working script that reads a sensor and moves a motor, and it does the job, so the whole layer of vocabulary on top, nodes, topics, publishers, subscribers, message types, feels like ceremony invented by people with bigger robots and more time.

Then the script grows. You add a camera, and now the loop that used to run smoothly hesitates every time an image arrives. You add a second sensor and the timing gets stranger. You want to restart just the vision part without stopping the motors, and you cannot, because it is all one program and one crash takes everything down. A friend offers to write the planning part, and you realise you have nowhere for their code to plug in.

That is the moment the word middleware stops being ceremony and starts being the name of your actual problem. This guide explains what it is, when you need it, and when adding it is the wrong move.

Do you need robotics middleware at all?

You need it as soon as your robot does more than one thing at once. A robot that reads a distance sensor and stops the motors is one loop, and one loop needs no middleware. A robot that watches a camera, tracks its own position, decides where to go and drives the wheels is four jobs running at four different rhythms, and the moment you try to write those as one program you spend your evenings on plumbing instead of on the robot.

The honest test is not how big your robot is. It is whether you have two pieces of software that need to run at different speeds, restart independently, or be written by different people, possibly in different languages. If yes, you need something to carry data between them, and building that yourself means writing the same queues, timestamps and startup ordering everyone else has already written.

If your robot is a single loop on a single board and will stay that way, skip it. Adding middleware to a project that does not need it buys you setup effort and returns nothing you can point at.

What is robotics middleware in plain terms?

Robotics middleware is a postal service for the programs inside a robot. One program announces that it publishes camera images. Another announces that it wants camera images. The middleware makes the connection, moves the data, and neither program needs to know where the other one lives, when it started, or whether it is written in the same language.

That is the whole idea, and everything else is consequence. Because the programs do not know about each other, you can restart one without touching the rest. Because the messages have names and types, you can inspect what is flowing without adding print statements everywhere. Because the connection is made at runtime, you can replace the real camera with a recorded file or a simulator and the rest of the robot cannot tell the difference.

Middleware usually adds a few things around the postal service: a way to start a group of programs together, a way to set values without recompiling, a way to record everything and replay it later, and an agreed vocabulary for positions and orientations. Those extras are why people adopt a whole framework rather than writing a message queue.

What are the actual middleware options for a robot?

There are about six, and they are not really competing for the same robot. Writing everything in one program with no middleware is the honest starting point for a first project. ROS 2 is the default for almost everything after that, because ROS 2 brings message passing plus navigation, manipulation, visualisation, recording and drivers that other people already debugged. Your robot vendor's own library is often the fastest route on their hardware and a wall the day you add anything they did not sell you. A general message broker of the kind used in home automation is fine for slow status messages and wrong for a control loop.

The fifth option matters when timing is the problem rather than structure. HORUS is 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 never packed into bytes and unpacked again. Apache-2.0 licensed, validated in simulation. The sixth is a microcontroller client library, for boards too small to run a full framework.

Which middleware fits which kind of builder?

Read the table by elimination rather than by ranking. The rows are answers to different questions, and treating them as a league table is how people end up with an industrial framework on a robot that needed forty lines of Python, or a hand-rolled message queue on a robot that needed a navigation stack.

Are you a hobbyist, a student, or a company?

Hobbyists should start with no middleware and add it on the day a second program appears. There is nothing embarrassing about a single script that drives a rover, and you will understand every framework concept far better after you have felt the absence of it. The trigger to change is not ambition, it is the first time you want to restart one part without stopping the others.

Students should use whatever their course or lab uses, without arguing. The value of matching your environment to the person who can help you when the build fails is worth more than any technical difference between options, and a shared setup is what makes a lab's accumulated knowledge reachable.

Companies should assume ROS 2 unless they have a specific reason not to, because hiring, drivers, tooling and the ability to buy a component and find a working package for it all lean the same way. The reason to look further is narrow and usually about timing, which the section on failure modes below describes in more detail.

Does the computer on your robot limit your choice?

Yes, and this is the constraint that quietly decides for you. A full framework expects a real operating system, which in practice means Linux on a single-board computer or a small x86 machine. If your robot's brain is an eight-bit microcontroller, no framework is going anywhere near it, and the right architecture is a small board doing the fast, simple work and a larger computer doing everything else, with a slim client library joining the two.

Memory is the next limit. Message passing between separate programs costs memory for buffers and processes, and a board with very little of it will feel that. If the board is comfortable running a browser, it is comfortable running a framework.

The third limit is what the vendor supports. Board makers ship their own Linux images with their own graphics and camera drivers, and those images often lag behind the general releases, which constrains which version of a framework installs cleanly. If that sentence matters to you, the comparison of ROS 2 releases works through the version question properly.

How soon does your robot need to move?

If you need something moving this week, write one program and skip all of this. Learning a framework and getting a robot to move are two separate projects, and attempting them in the same week usually produces neither. Get the wheels turning with the simplest thing that works, so you have something real to reason about.

If you have a month, learn the framework deliberately, on a robot that already moves. Port one piece at a time: move the motor driver into its own program first, then the sensor reader, then the decision-making. Each step leaves you with a working robot, which is the only way to tell which change broke something.

If you have a term, a semester or a funded quarter, start with the framework from day one and accept a slow first fortnight. The structure pays back the moment a second person joins, because they can work on their part without needing to understand yours, and that handover is worth more than the fortnight cost.

How much programming do you need before middleware helps?

Enough to have written a program with a loop in it, and no more than that. You do not need threading, networking or memory management, because avoiding those is the point of the exercise. The concepts that actually gate you are small: a program that sends data, a program that receives it, a named channel between them, and an agreed shape for the messages.

What genuinely trips beginners is not the programming but the setup. Installing a framework, understanding why a program cannot see another program's messages, working out why the version of a library on your machine does not match the one in the tutorial: these are environment problems, not robotics problems, and they consume most of a first week for almost everyone. Expect that and it stops feeling like failure.

The good news is that this cost is paid once. After the first working setup, adding a new piece to a robot is genuinely quick, and that asymmetry is why people keep using frameworks even while complaining about them.

What does it look like when middleware is the thing that is wrong?

It looks like a robot that hesitates rather than one that crashes. The arm moves smoothly until the camera starts streaming, and then it stutters. The rover drives well in an empty corridor and jerks when there is enough around it to think about. Everything works when you test one part alone and behaves differently with the whole system running, which makes the problem impossible to pin down.

The tell is that your algorithm is not the thing at fault. The planner produces a correct answer; it just produces it after the wheels needed it, so the robot acts on a picture of the world that has already changed. Add a sensor and it gets worse in proportion to the data, not in proportion to the difficulty of the decision.

Most people meet this after the robot works, which is what makes it so confusing. The write-up on fusing IMU and odometry data walks through one version of this in detail, and the shape it describes recurs everywhere data has to arrive before a control cycle uses it.

What do you give up by adding middleware to a small robot?

You give up simplicity, and you should not pretend otherwise. One program that you can read top to bottom becomes several programs, a startup file to launch them together, message definitions, and a new class of bug where everything runs and nothing talks because two halves disagree about a name. Debugging changes character: instead of stepping through code, you are inspecting what is flowing between programs.

You also give up some directness. Data that used to be a variable is now a message that arrives when it arrives, so you have to think about what the robot should do when a message is late or missing. That is real work, though it is work the robot needed anyway; a single-program design just lets you ignore the question until a sensor stalls.

What you get in exchange is that the robot stops being one thing. Parts restart independently, a colleague can own a piece, and you can record a run and replay it at your desk. On a small robot that trade is not obviously worth it. On a growing one it always becomes worth it.

When is ROS 2 the better choice?

ROS 2 is the better choice for almost every reader of this guide, and anyone telling a beginner otherwise is selling something. Take ROS 2 when you want mapping and navigation you did not write, when you want drivers for a camera or a lidar you just bought, when you want to see what the robot believes about the world in a viewer, when you want to record a drive and replay it, when you want simulation before hardware, and when you want to ask a question and find that someone has answered it already. That covers the overwhelming majority of robots being built right now.

HORUS is not the answer for a first robot, or for a team that mainly needs the surrounding ecosystem, because a real-time middleware replaces how messages move and nothing else. The narrow case for it is a machine that already works, where one loop must finish before the next cycle needs the result and the cost of moving data between programs is what prevents that. If the robot has not been built yet, that is not your problem, and choosing for it now costs you everything the ecosystem provides.

Can you skip middleware and just write one big program?

Partly, but not the way you think. You can go a long way with one program, further than framework advocates usually admit, and for a single-purpose robot that is the correct engineering decision. The limit is not size and it is not sophistication. The limit arrives when two parts of the robot need different rhythms: a camera that produces frames in bursts and a motor loop that must run steadily, inside one program, means the slow part interrupts the fast part.

At that point people reach for threads, and threads are where the trouble starts. Now you own locks, shared state and race conditions, and you are debugging concurrency instead of robotics. What you have built by the end is a small, undocumented, personal middleware that only you can maintain.

So the honest answer is that you do not skip middleware. You either adopt one or write one. Writing one is a reasonable choice exactly once, for learning, and a poor one every time after that.

Is middleware only worth it for large research robots?

No, and here is why. The value comes from having more than one program, not from having a big budget. A hobby rover with a camera, a gamepad listener and a motor driver has the same structure as a warehouse robot with a hundred programs, and gets the same three benefits: parts that restart independently, one place to see what is flowing between them, and the ability to rewrite one piece without touching the others.

The size myth persists because the tutorials are written for the large case. Introductions open with a simulated industrial arm and thirty pages of configuration, which makes the whole idea look like something you graduate into rather than something you use on a desk robot on a Saturday.

The practical version is much smaller. Two programs, one message type, one launch file, and you have already got most of the benefit. A short walkthrough like the Python comparison piece shows the scale honestly. Judge the idea by that version, not by the industrial demo.

How do you choose your first middleware without regretting it?

Answer three questions in order and stop at the first clear answer. One: does your robot have more than one program, or will it within a month? If no, write one program and come back later, because you cannot evaluate a framework against a problem you do not have yet. Two: does your robot's computer run Linux? If no, your architecture is a small board talking to a bigger computer, and the question moves to that computer.

Three: do you need things other people have already built, mapping, drivers, a viewer, a simulator? If yes, and it usually is yes, take ROS 2 and stop shopping. Every hour spent comparing options is an hour not spent on the robot, and the comparison only becomes meaningful once you have a working machine to compare against.

The regret people actually report is not picking the wrong framework. It is spending three weeks choosing. Pick the default, build something that moves, and let the robot tell you if you were wrong.

If you are building a first robot with one job -> no middleware, because one program you understand beats a framework you do not.

If you are adding a camera to a working rover -> ROS 2, because someone has already written the driver you are about to write.

If you are a student in a lab -> whatever the lab runs, because help matters more than technical preference.

If your board is a microcontroller -> a slim client library plus a larger computer, because a framework will not fit.

If your robot works but stutters when everything runs together -> a real-time layer beside your existing stack, because the problem is data arriving late, not your code being wrong.

We rate these on this blog with the HORUS Fit Framework, which scores each option on five axes and no numbers: ecosystem size, setup effort, team size fit, deployment target, and licence. Beginners are usually deciding on the first two; teams with working robots are deciding on the last three.

If that last decision line is the one that described you, HORUS is open source under Apache-2.0 and validated in simulation. Star it so it is in your list when you start building, and leave it there until the day your loop starts arriving late.