Do Beginners Need Robotics Middleware at All?

No — your first robot does not need middleware, and a single program beats ROS 2 or any other framework until the machine outgrows one loop. Middleware earns its place when separate programs must exchange data while the robot is moving, which is when a slow camera read starts costing you a stop. If that is already happening, ROS 2 or a lighter option such as HORUS is worth the setup. The rest of this post is for someone building a first or second robot and wondering whether they skipped a step everyone else took.

Your robot is one file. It reads the distance sensor, decides whether to turn, sets the motors, and for a fortnight that felt like magic. Then you added a camera, and now the loop pauses every time a frame arrives, and the machine rolls a little further than it should before it turns away from the wall. You added some logging and it got slightly worse. You wanted to try a new vision idea without stopping the wheels, and you could not, because stopping one thing stops everything. A friend offered to help and asked which part they could take, and the honest answer was the file.

So you go looking for advice, and everyone says ROS. You open a tutorial and it is a long stretch of workspaces, build tools and vocabulary before a single message goes anywhere, and none of it looks like your robot. Now you are stuck between a program that has started to fight you and a framework that seems to belong to a much bigger project than yours.

Do beginners need robotics middleware at all?

No, not for a first robot, and yes the moment two parts of the machine have to run at their own pace. A first robot is almost always one loop: read, decide, act, repeat. That loop needs a hardware library and nothing else, and adding a framework on top of it buys you concepts to learn and gives you nothing the machine can do. What changes the answer is a specific structural fact: something on the robot now takes a while to finish, and something else cannot wait for it. A camera that thinks for a moment while the wheels are still turning. A planner working out a route while a motor loop holds the arm steady. Once that is true, the single loop becomes a series of compromises — skipping frames, checking the clock, wrapping things in threads — and every one of those compromises is a small piece of middleware you are now maintaining yourself, badly, at the same time as building a robot.

What is robotics middleware in plain terms?

Middleware is the postal system inside a robot: one program hands over a piece of data, and the middleware delivers it to whichever programs asked for that kind of data, without either side knowing anything about the other. That is the whole idea, and the rest is consequences. Because the camera program does not know who reads its images, you can add a recorder later without touching it. Because the motor program only asks for steering commands, you can replace whatever produces them. Middleware usually brings a few other things with it: a way to start and stop a set of programs together, agreed shapes for common messages so two programs mean the same thing by a distance reading, and tools to watch messages going past while the robot 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 reading once your robot has two programs.

What are your actual options when you are starting out?

You have seven realistic options, and the first one is the right answer more often than the internet suggests. You can write one program with no middleware at all. You can keep one program but move the slow part onto its own thread. You can split into separate programs and connect them with sockets or files you wrote yourself. You can lean on the software toolkit that came with your kit or arm, which usually handles everything the vendor sold you and nothing else. You can adopt ROS 2, which brings mapping, navigation, drivers, simulation and a large community, along with workspaces, build tooling and vocabulary to learn first. You can use a lighter middleware built 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. Or you can use a general message broker such as MQTT, familiar from web and home-automation work.

What should you pick if you are learning alone with a small kit?

Write one program with no middleware and keep going until the robot itself tells you to stop. This is not beginner advice you graduate from; it is what an experienced person does with a new machine, because the first weeks are about discovering that your sensor lies near shiny surfaces and your motors do not turn at the same rate. Every layer between you and the hardware makes those discoveries slower to make. So keep the loop in one file, keep the decisions in small functions with plain inputs and outputs, and resist the urge to design an architecture for a robot that does not exist yet. What you should do is leave a seam: read the sensor in one function, decide in another, drive the motors in a third, and never let the deciding function reach out and touch hardware. That habit costs nothing today and means the day you split the program into pieces, you are moving functions rather than untangling them.

What robot hardware makes middleware worth it sooner?

Hardware that produces data continuously, and hardware that must not be kept waiting, both bring the decision forward. A camera or a depth sensor delivers frames whether or not you are ready, and the moment your loop pauses to handle one, everything else on the robot pauses too. Several motors under closed-loop control pull the other way: they need attention on a rhythm, and a hesitation shows up as a jolt you can see and often hear. Put those two together — a camera feeding decisions while motors hold a rhythm — and one program is already the wrong shape, because the two jobs want incompatible things from the same loop. By contrast, a robot driven by a distance sensor and two wheels, or an arm running a fixed sequence, has none of this tension and can happily stay a single file for years. The question is never how impressive the robot looks. It is whether two things on it need to happen without waiting for each other.

What if you have a demo in two weeks?

Do not introduce middleware two weeks before a demo. Whatever is fragile in your robot today, a new layer of plumbing will not fix it in the time available, and it will add a category of problem you have never debugged before: programs that start in the wrong order, messages that go nowhere because two sides disagree about a name, a machine that works on your laptop and not on the robot. Spend the fortnight on the demo instead. If the loop stutters when the camera reads, take the smallest step that helps — process every other frame, move the camera read to its own thread, lower what you ask of it — and write down that you did it, so nobody mistakes the patch for a design. After the demo, when nothing is at stake, is exactly the right moment to restructure. Middleware repays a robot that has to keep working; it punishes a robot that has to work on Thursday.

What if Python is the only language you know?

You can build a genuinely useful robot in Python alone, and the wall you eventually hit is not the language but the shape of the loop. Python is comfortable for reading sensors, making decisions and driving motors, and enormous amounts of real robot work happens in it. What Python is less comfortable with is holding a steady rhythm while also doing something heavy, because the heavy work and the rhythm are competing inside one program. The usual first fix is threads, which helps for a while. The usual second fix is a separate process for the heavy part, and that is the point where you have arrived at middleware whether you call it that or not. Many robots settle at exactly that arrangement: the thinking in Python where it is pleasant to change, the steady loop in a language that keeps time, and something carrying data between them. Whether the framework is needed at all is a separate question from which language you write in.

How do you know your single program has stopped being enough?

Four symptoms, and one of them is enough. First, the loop hesitates: the robot overshoots or reacts late whenever a particular step runs, and you find yourself adding conditions to skip work. Second, one failure takes the whole machine down — a camera hiccup stops the motors, and the arm stops holding position because unrelated code raised an error. Third, you cannot restart part of the robot; trying a new vision idea means shutting down the wheels, so you experiment less than you would like. Fourth, a second person cannot work on the robot without editing the same file you are editing. Notice that none of these is about size or elegance. A long file is not a problem in itself, and plenty of good robots are one long file. The problem is always the same underneath: two things that need to happen independently are sharing one thread of execution, and the robot is showing you the consequence.

What do beginners usually build first, and why does it stop working?

Almost everyone builds one loop that does everything in order, and it stops working when one step takes longer than the others can wait. The loop reads a sensor, works something out, moves the motors and goes round again, which is the right place to start. Then the robot gets a camera, or a network connection, or a log file, and one of those steps starts to take its time. The first repair is to do the slow thing less often. The second is a thread, plus a shared variable, plus a lock, plus a bug that only happens when the robot is moving. The third is a separate program and a socket, which works until you want a third program and discover you are now designing a protocol. Every step in that sequence is reasonable in isolation. The pattern to notice is that you are gradually building your own middleware while believing you are avoiding one, and building a robot without a framework works best when that is a deliberate choice rather than an accident.

What do you give up by adding middleware early?

You give up the ability to hold the entire robot in your head, which is worth more at the start than almost anything a framework provides. In one program, you can read every line that runs between a sensor reading and a motor command, and when the robot does something strange you can find the cause by looking. With separate programs and messages between them, the same investigation involves checking whether a message was sent, whether anyone was listening, whether the two sides agreed about its shape and whether the timing worked out. You also give up setup time, which is the real cost for a beginner: hours spent on installation, workspaces and configuration are hours not spent finding out that your robot drifts left. And you give up a little independence, because you are now inside somebody's conventions for how programs should be arranged. None of these are arguments against middleware for a robot that needs it. They are arguments against adopting one before that.

When is ROS 2 the better choice?

ROS 2 is the better choice as soon as your robot needs something other people have already solved. A machine that must build a map of a room and drive to a chosen spot is a ROS 2 project, because mapping and navigation packages represent years of work that nobody reproduces in evenings. If the sensor you bought ships only a ROS 2 driver, that decides it too. ROS 2 also wins when the robot spans more than one computer, when you want to record a run and replay it later, and when you are heading for a job or a lab where ROS 2 is what everyone speaks. HORUS is not the answer for those projects, and choosing it there means rebuilding plumbing you could have inherited for free. The cost of ROS 2 is real and worth stating plainly: it is a substantial amount of learning before your robot does anything new, and it is easiest on Linux.

Is middleware just complexity a beginner should avoid?

No, and here is why: the complexity middleware handles is already inside your robot, and the only choice is whether it lives somewhere you can see. The moment a camera and a motor loop have to run without waiting for each other, something must carry data between them and decide what happens when one side is slower than the other. Write it yourself and you own that decision in the form of threads, locks, queues and a subtle bug that shows up once a week. Adopt a middleware and you own a dependency and some vocabulary instead. Neither choice is free, and a beginner who avoids the question entirely is choosing the first option by default. What is genuinely a bad idea is adopting a framework as ceremony, because a video said serious robots use it, before the robot has two programs. The advice is not avoid middleware. The advice is do not buy the answer before you have the question.

Will skipping middleware mean rewriting your robot later?

Partly, but not the way you think. What gets rewritten is the plumbing, and the plumbing was never the valuable part. The valuable part is the knowledge accumulated in your code: this sensor reports nonsense for the first moment after power-up, the left motor needs a little more push to match the right one, the gripper must close before the arm lifts. That knowledge survives any restructuring, provided you kept it in functions that take inputs and return outputs rather than reaching into hardware from wherever they feel like. The rewrite that genuinely hurts is the one where deciding, reading and driving are tangled together across hundreds of lines, because separating them is where the work is. So protect yourself with habits rather than with frameworks. Keep hardware access in one place, keep decisions pure, and pass data as plain values with obvious names. Do that and moving to middleware is an afternoon of moving functions into separate programs, not a rebuild.

How do you decide whether you need middleware yet?

Count the things on your robot that must happen without waiting for each other, and if the answer is one, you do not need middleware. That is the whole test, and it is worth doing on paper rather than in an argument. Write down each job the robot performs: reading a distance sensor, processing a frame, holding a wheel speed, logging, listening for a command from your phone. Next to each, write how long it can be made to wait before something visible goes wrong. If everything can wait for everything else, keep one program and enjoy it. 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 borrowed packages are what you need most, that answer is ROS 2. If it is your own programs on one computer, a lighter middleware costs less to set up.

Decide by situation rather than by what looks professional:

• If this is your first robot and it does one thing -> one program, no middleware, because a framework adds learning and no capability.
• If one slow job is making another job wait -> separate programs with something carrying data between them, because the loop is the problem.
• If you need mapping, navigation or a vendor's driver -> ROS 2, because those packages are the project and rebuilding them is not.
• If your robot is Python thinking above a loop that must keep time -> a shared-memory middleware, because that boundary is the expensive part.
• If a demo is close -> change nothing structural, because new plumbing brings new failures at the worst moment.

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 numbers, just five honest questions about your situation rather than about the software. And when your robot does grow past one program, star HORUS on GitHub so it is in your list when you start building.