Framework, Middleware or SDK: What the Difference Means in Practice

The difference is what you own: an SDK talks to one vendor's hardware, middleware carries data between your programs, and a framework decides your structure. An SDK ends when you change robots, middleware follows you across projects, and a framework such as ROS 2 shapes every file you write. What flips it is scale: one program on one board needs none of them, ROS 2 or HORUS included. The rest of this post is for someone comparing three product pages that all promise the same thing and trying to work out what they are choosing between.

You are three tabs deep. One page calls itself a robotics framework. The next calls what looks like the same thing a middleware. The arm you bought ships an SDK, and its documentation says the SDK is all you need. Every page shows a diagram of boxes and arrows, every diagram is drawn differently, and none of them tells you whether installing one means you no longer need the others.

Meanwhile your robot exists. It has a motor driver, a camera, and a script that works if you start things in the right order. Someone in a forum told you that you should have started with ROS. Someone else said ROS is overkill and you should just write Python. The arm vendor says use our SDK. All three sound certain, and none of them has seen your robot.

What you want to know is small and practical. Which of these do you install? Do they stack, or do they compete? If you pick one now and it turns out wrong in six months, how much of the work goes in the bin? Nobody answers that, because everybody is describing their own box and assuming you already know where the other boxes go.

Which do you actually need: a framework, middleware or an SDK?

You need an SDK the moment you buy hardware, middleware the moment two programs must run at their own pace, and a framework only when you want to inherit work other people have finished. Those are three separate triggers and they fire at three separate times, which is why the question is almost never one-of-three. Most robots end up with an SDK because the motors came with one, no middleware because there is only one program, and no framework because nothing has been borrowed yet. That arrangement is not a compromise. It is the correct shape for a machine that does one job well. The mistake beginners make is treating the three as competing brands and picking whichever sounds most serious before the robot has the problem it solves. The mistake experienced teams make is the mirror image: keeping one script long past the point where three jobs are elbowing each other inside a single loop, because adding a layer feels like conceding that the simple version failed. Neither mistake is really about software. Both are about timing.

What do the words framework, middleware and SDK actually mean?

An SDK is a vendor's code for driving that vendor's hardware, middleware is the delivery service between your own programs, and a framework is a set of conventions that decides how the whole project is arranged. The clearest way to feel the difference is to ask what breaks when you throw each one away. Throw away an SDK and you lose the ability to speak to one piece of hardware; everything else you wrote survives, because the SDK only ever sat at the edge. Throw away middleware and your programs can no longer find each other, so you rebuild the plumbing between them while the logic inside each program stays where it is. Throw away a framework and you rewrite the shape of the project itself: where files live, how programs start together, what a message is called, how the build runs, which directory means what. That ranking is the whole practical difference. An SDK is a tenant, middleware is the corridor, and a framework is the building. A longer walk through the layers underneath a robot is in this stack tour, which repays reading once two of these live in one project.

What does it look like when you have picked the wrong one?

Picking the wrong layer never announces itself as an error message; it shows up as work that feels heavier than the job deserves. The commonest version is a framework adopted too early. You wanted a robot to drive in a square, and instead you spent the weekend on workspaces, build files and message definitions, and the robot has still not moved. Nothing is broken. You bought a large answer to a small question and are paying the interest weekly. The second version is an SDK asked to be a framework. The vendor's library covers everything the vendor sells, so you build the entire robot inside it, and then you add a camera the vendor never sold. Half your project now lives in a world with no place for that camera, and the glue bridging the gap becomes the ugliest code you own. The third version is no layer at all where one is needed: one script with threads bolted on, a lock added after a bug, a pause tuned until the twitching stopped. Every patch was sensible on the day. Together they are a middleware you are maintaining by accident.

What are your actual options, and where does each one sit?

Your options are not three products but seven arrangements, and most robots run two of them at once. You can use a hardware library alone, which is what a first robot should do. You can stay inside the kit's own app or visual editor, which is the fastest route to motion and the first thing to run out of room. You can build on the vendor SDK that came with your arm or rover, which handles everything that vendor sold you and nothing beyond it. You can adopt ROS 2, a framework bringing mapping, navigation, drivers, simulation tooling and a large community, in exchange for learning workspaces, build tooling and message types before anything moves. You can add only a middleware: 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 C++ or Rust loop. You can connect programs through a general message broker such as MQTT, familiar to anyone arriving from web work. Or you can write your own sockets, which teaches a great deal and costs a great deal.

What should you choose if you are one person on a hobby robot?

Use the hardware library that came with your parts, add nothing else, and let the robot tell you when that stops being enough. This is not training wheels you graduate from. It is what an experienced engineer does with an unfamiliar machine, because the first weeks are spent finding out that your distance sensor lies near shiny surfaces and your two motors do not turn at the same rate for the same command. Every layer between you and the hardware makes those discoveries slower to reach. What you should do instead of adopting anything is leave a seam: read sensors in one function, decide in another, drive motors in a third, and never let the deciding function reach out and touch hardware directly. That habit costs nothing today, and the day you split the script into separate programs you are moving functions rather than untangling them. The question of whether a beginner needs middleware at all has a clear answer for a first machine, and it is no.

Which layer matters most on a Raspberry Pi or a Jetson?

On a small board the framework is the expensive layer, because a framework charges rent in memory, start-up time and background activity whether or not you use the parts you are paying for. An SDK costs almost nothing beyond what talking to the hardware costs anyway. A middleware costs a little more, since something has to carry data between programs, and the cheapest arrangement is one where messages stay in memory shared by both sides rather than being packed up, copied and unpacked on the way past. A framework costs the most, because it brings its own discovery, its own build layout, its own set of background processes and its own idea of how the machine should be arranged. None of that makes a framework wrong on a small board, and plenty of small boards run one happily. It does mean the trade is real: on a machine with room to spare you barely notice, and on a machine already close to its limit you notice on the first boot, in the form of a robot that takes an uncomfortably long time to become ready after power-up.

What should you choose if your demo is a month away?

Change nothing structural before a demo, and spend the month on the demo instead. A new layer will not repair whatever is fragile in your robot today, and it will introduce a class of problem you have never debugged: programs starting in the wrong order, a message going nowhere because two sides disagree about a name, a machine that works on your laptop and not on the robot. Those problems are ordinary and solvable, and none of them are solvable on a deadline you have already committed to. So take the smallest step that helps the symptom you actually have. If the loop stutters when the camera reads, process fewer frames, move the read onto its own thread, or ask less of it, and write down that you did it so nobody later mistakes the patch for a design decision. After the demo, when nothing is at stake and nobody is watching, is exactly the right week to restructure. Layers repay a robot that has to keep working for a year; they punish a robot that has to work on Thursday.

What should you choose if Python is the only language you know well?

Stay in Python, use the SDK or driver library in Python, and do not let anyone tell you that a real robot has to be written in something else. Very large amounts of working robot software are Python, and the language is comfortable for reading sensors, making decisions and commanding motors. 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 repair is a thread, which buys a while. The usual second repair is a separate process for the heavy part, and that is the moment you have arrived at middleware whether you use the word or not. Plenty of good robots settle exactly there: the thinking in Python where changing it is pleasant, the steady loop in a language that keeps time, and something carrying data across the gap. If your plan involves a language model deciding what the robot does next, the same layering question gets sharper, because the model is the slowest part of all.

What do most people reach for first, and why does it stop working?

Most people reach for the framework first, because it is the answer the internet gives to every robotics question, and it stops working because the framework's cost lands immediately while its benefit lands later. The benefit of a framework is borrowed work: a navigation stack, a driver for the sensor you bought, a simulator that already knows your robot's shape. If you are not borrowing yet, you have taken on the vocabulary, the build tooling and the directory conventions and received nothing in exchange. The second thing people reach for is the vendor SDK, which stops working the day the project grows past the vendor's catalogue. The third is a homemade socket, which stops working when a third program appears and you find yourself designing a protocol you did not want to design. Each of those is a reasonable step in isolation. The pattern worth noticing is that all three fail in the same way: the layer was chosen against a picture of the robot rather than against the robot, and the robot is the thing that changed.

What do you give up by committing to one of these layers?

You give up the ability to hold the whole robot in your head, and at the beginning that is worth more than nearly anything a layer provides. In one program you can read every line that runs between a sensor reading and a motor command, so when the machine does something strange you find the cause by looking. Once programs are separate, the same investigation means checking whether a message was sent, whether anyone was listening, whether both sides agreed on its shape, and whether the timing worked out. You also give up setup time, which is the real cost for one person: hours spent on installation and configuration are hours not spent finding out that your robot drifts left. And you give up a measure of independence, because you are now inside somebody else's conventions about how programs should be arranged and named. None of that argues against layers for a robot that needs them. It argues against adopting them on schedule rather than on evidence, which is the version that quietly costs projects their first month.

When is ROS 2 the better choice?

ROS 2 is the better choice the moment your robot depends on work other people have already done. A machine that must build a map of a room and drive to a chosen point is a ROS 2 project, because mapping and navigation represent years of effort nobody reproduces in evenings. If the sensor you bought ships only a ROS 2 driver, that settles it as well. ROS 2 also wins when the robot spans more than one computer, when you want to record a run and replay it afterwards to work out what happened, when a simulator needs to speak to your code without custom glue, and when you are heading for a job or a lab where ROS 2 is simply the language everyone uses. HORUS is not the answer for any of those, and choosing it there means rebuilding plumbing you could have inherited for nothing. The honest cost of ROS 2 is a real stretch of learning before your robot does anything new, and a strong preference for Linux that you should plan around rather than argue with.

Is an SDK just middleware with a vendor's name on it?

No, and here is why: they solve problems that point in opposite directions. An SDK exists to make one specific machine easy to command, so it is deliberately shaped around that machine's abilities, quirks and vocabulary. That shaping is the value. It is also why an SDK cannot carry data between two of your own programs in any general way, and why the code you write against one is the code you rewrite when the hardware changes. Middleware exists to make programs independent of each other, so it is deliberately shaped around nothing in particular: it does not know what a gripper is, and that ignorance is what lets it deliver a gripper command as happily as a camera frame. Confusing the two produces a specific and common failure. Teams build their architecture inside a vendor SDK because it already passes data around, then discover that the passing only works between parts the vendor anticipated, and that adding an unanticipated part means writing the general layer they thought they already had.

Is picking the wrong layer a mistake you can undo later?

Partly, but not the way you think. What gets thrown away is the plumbing, and plumbing was never the valuable part of your robot. The valuable part is the knowledge accumulated in your code: this sensor reports nonsense for a moment after power-up, the left motor needs a little more push to match the right, the gripper must close before the arm lifts or the part falls. That knowledge survives any restructuring, as long as it lives in functions that take plain inputs and return plain outputs instead of reaching into hardware wherever convenient. The rewrite that genuinely hurts is the one where reading, deciding and driving are braided together across hundreds of lines, because separating them is the entire job and no tool does it for you. So protect yourself with habits rather than with a bet on the right layer. Keep hardware access in one place, keep decisions free of side effects, pass data as plain values with obvious names. Do that and changing layers is an afternoon of moving code, not a rebuild you dread for months.

How do you decide which one your robot needs?

Write down every job your robot does, then write beside each one how long it can be kept waiting before something visible goes wrong. That list decides all three questions at once. If every job can wait for every other job, you need no middleware, and the answer is one program with whatever driver library your hardware came with. 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. Then ask a second question: how much of what this robot must do has already been built by somebody else? If the answer is a lot, and specifically mapping, navigation, drivers or simulation, you want a framework and you want the one with the packages. If the answer is almost none, and the robot is mostly your own logic on one computer, a framework charges you for a shop you never visit. The vendor SDK question barely needs asking, because whatever hardware you bought decides it for you.

Decide by situation rather than by what sounds professional:

• If you are building your first robot -> the hardware library alone, because nothing else has earned a place yet.
• If you own one arm and need it to do its advertised job -> the vendor SDK, because that vendor already solved that hardware.
• If you need mapping, navigation or a driver somebody else wrote -> ROS 2, because those packages are the project.
• 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 two people cannot work without editing the same file -> any middleware, because separate programs are the whole point.
• If a deadline is close -> change nothing structural, because new plumbing brings new failures at the worst possible 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 outgrow a single program, star HORUS on GitHub so it is in your list when you start building.