Is ROS 2 Too Heavy for a Small Single-Board Computer?

No, ROS 2 is not too heavy for most small single-board computers, and HORUS only wins on the narrow slice where timing slips. A modern board handles the ecosystem fine; what hurts is a busy board where perception, logging and control compete, plus a boot you notice every power cycle. The verdict flips when the board is a microcontroller rather than a small Linux computer. The rest of this post is for someone whose robot already runs on a small board and who suspects the software layer is the reason it stutters.

The robot works on your laptop. On the board it hesitates. Not always, and never while you are watching for it, but the arm stops a beat late, or the wheels twitch when the camera is running, or a loop that felt smooth on the desk feels rubbery on the machine. You have already run the obvious checks and the board is not out of memory, so the numbers on your screen say everything is fine and your eyes say otherwise.

Meanwhile the small annoyances stack up. The card image is bigger than the card you bought. Building anything on the board takes long enough that you now build on the laptop and copy files across. Powering the robot on and waiting for it to be ready has become a coffee-length ritual, and once in a while something comes up in the wrong order and nothing works until you restart it by hand. Somebody on a forum has told you the framework is bloated and you should write your own. Somebody else has told you to buy a bigger board. Neither answer explains why the same code behaved differently on your laptop, and that is the question actually worth answering before you spend either money or a weekend.

Is ROS 2 too heavy for a small single-board computer?

No, not for the class of board most people mean, which is a credit-card Linux computer with a handful of cores and a real operating system. Weight turns up in three separate places and only one of them is about raw capability. The first is storage and start-up: a full install is large and a machine that takes its time coming up is irritating on a bench and a genuine problem in a product that power-cycles in the field. The second is idle overhead, where discovery, background threads and per-message bookkeeping take a slice of a small board before your own code does anything at all. The third is what happens when the board is busy, with camera decoding, a network stack, writes to a memory card and a control loop all wanting the same cores in the same instant. On a desktop that contention hides behind spare capacity. On a small board it becomes something you can see in the machine's movement. Anyone asking whether the framework is too heavy is usually describing the third case and blaming the first.

What is a robot's middleware doing on a small board?

Middleware carries values between the separate programs that make up a robot, and decides what happens when one of those programs falls behind. On a small board that job has a felt cost, because every message that crosses between two programs is packed into a portable shape, handed to the operating system, and unpacked again on the other side. A camera frame is large, and doing that work several times a second while a control loop is also asking for cores is where a small computer starts to make choices you did not ask it to make. Middleware also handles discovery, meaning the business of programs finding each other without you listing addresses by hand, and that machinery keeps running in the background whether or not anything interesting is happening. None of this is waste in principle. It is what buys you the ability to restart one program without restarting the robot, to attach a tool to a running machine and watch values go past, and to swap a sensor for a different one without editing the code that consumes the readings.

What are the real options for a small single-board computer?

There are seven options builders actually choose between, and the honest starting point is that the first two cover most robots. You can run ROS 2 as it comes, on a mainstream Linux install, accepting the size and the start-up cost in exchange for drivers and navigation packages that already exist. You can run a trimmed ROS 2, installing only what your robot uses rather than a full desktop bundle, which removes most of the storage complaint and none of the contention one. You can keep the ecosystem above and put the timing-critical processes on HORUS, an 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 serialised; the licence is Apache-2.0, the project is validated in simulation rather than proven across fleets, and it is not a full ROS replacement, which is exactly why it belongs beside ROS 2 rather than instead of it. You can collapse everything into one program with no middleware at all. You can move the loop onto a microcontroller. You can pass messages through a small broker. Or you can write your own plumbing.

How do the options compare on a small board?

Read the table by finding the row whose "when not to" column describes your robot, then crossing that row out. Most builders are left holding two, and the tiebreaker is which one you can still debug at midnight without asking anybody.

Two surviving rows is the normal outcome rather than a failure of the table, because most small-board robots want the ecosystem for sensing and something calmer underneath the motion. Combining is allowed and common: keep the packages that see and plan, and let the loop live where less is going on around it, whether that is a second chip or a transport that skips the copying. What is rarely wise is picking a row because of how it sounded in a forum argument. Cross rows out on evidence you have watched on your own robot, and the list gets short fast.

Are you a hobbyist, a student, or an early product team?

The three should decide this differently, and copying the wrong one is the usual mistake. A hobbyist optimises for finishing, and a finished robot on a slightly slow board beats an unfinished one on a perfect foundation; take the ecosystem, take the drivers, accept the start-up wait and get the machine moving. A student optimises for what transfers, which means the vocabulary and tooling that a lab or an employer already uses, and there the largest ecosystem wins almost regardless of how it feels on the hardware. An early product team optimises for what the machine does in a customer's building, which changes the question entirely: start-up ordering after a power cut, configuration drift between two units, and whether anyone can see inside a robot they cannot reach. That team should still prototype on the ecosystem and should only move a layer when a customer-visible symptom names the layer. If you are that team, the commercial version of this decision is a different post, because the constraints that bite are procurement and support rather than card space.

Which board are you actually running?

The board decides more of this than any preference, and the categories behave nothing alike. A small Linux computer with several cores runs the ecosystem comfortably, and any trouble you have is about contention rather than capability. A cheaper or older Linux board with fewer cores and less memory runs it too, but with much less room to absorb a camera and logging at the same time, so the same code feels different. A board with an accelerator on it changes the shape again, because the heavy work moves off the general cores and the remaining question is how the results travel back to the code that uses them. And a microcontroller is not the same conversation at all: there is no Linux underneath, ROS 2 as normally installed does not run there, and the honest options are firmware, a small real-time operating system, or a cut-down bridge designed for that class of chip. Before reading any advice about weight, check which of those four you are holding, because guidance written for one of them is often actively wrong for another.

What if you only have a few weekends?

Use the ecosystem your board already has packages for, and treat every unfamiliar layer as time you are not spending on the robot. A few weekends sounds generous until a motor driver arrives with the wrong connector, a camera needs a kernel option you have never heard of, and an afternoon disappears into a power supply that browns out under load. Nothing in that list is middleware, and swapping middleware makes all of it slower to solve, because you also lose the ability to search for your exact error message and find somebody who hit it first. Take the existing drivers. Take the visualisation tool. Accept the boot wait. If the machine ends up hesitating, note when it hesitates and carry on, because a hesitation you can describe precisely is worth more later than a rewrite you did on suspicion. The exception is a robot whose entire point is a fast loop and nothing else, with no camera and no map; that robot has almost no ecosystem to lose and can start somewhere smaller without regret.

What does your team already know how to debug?

Whatever your team can debug at midnight is the correct answer, and that is usually a stronger constraint than any property of the software. Debugging on a small board is harder than on a laptop in ways people underestimate: there is no comfortable editor, builds are slow enough to break concentration, and the failure often only appears when the machine is powered from its own battery and moving. In that setting the value of a large community is not ideology, it is that your exact error message has been seen before and written up by somebody. A smaller foundation asks you to be the person who reads the layer underneath when it misbehaves, in whichever language it is written in. Some builders enjoy exactly that, and for them a narrow stack is a pleasure rather than a risk. If nobody on your side wants that job, choose the option with the most existing answers and accept its ceremony as the price of never being alone with a problem. Skill level here means appetite for owning plumbing, not years of experience.

What do people try first when the board struggles, and why does that stop helping?

People turn things off first, and it works until the robot has to leave the bench. Logging goes, then the visualisation tool, then a camera stream drops to a smaller size, then a background service is disabled, and each step buys back a little smoothness. The trouble is that everything switched off was doing a job. Logs are the only witness when the machine misbehaves somewhere you are not standing. The camera stream you shrank is the one that made the robot see far enough. Six months later nobody remembers which of the disabled things is safe to turn back on, so nothing gets turned back on, and the robot ships in a permanently reduced state that everyone quietly works around. The second thing people try is a bigger board, which genuinely helps and also raises the cost of every unit forever, and which hides the contention rather than removing it. Both moves are reasonable diagnostics and poor destinations. The useful version is to notice which switch made the difference, because that switch is naming the actual problem.

What do you give up by leaving ROS 2 on a small board?

You give up the drivers, and that is the real bill. A working camera pipeline, a lidar that publishes without you reading a protocol document, a navigation stack that somebody else tuned, a tool that shows the robot's frames while it moves, and the recording format that lets you replay a failure at your desk instead of chasing it around the room. You also give up the ability to search for your problem in the words a stranger used. You give up conventions, which sounds abstract until two people on the same project disagree about what a message means and there is no standard to point at. And you give up hireability, in the small sense that the next person to touch your robot will already know the ecosystem and will not already know your plumbing. Against that you get back card space, a shorter start-up, fewer background threads, and a machine whose behaviour under load is easier to reason about because there is less of it. That trade is genuinely worth making for some robots and clearly wrong for most.

When is ROS 2 the better choice?

ROS 2 is the better choice for the majority of small-board robots, and the cases are easy to state without hedging. If your robot needs to see, map, or plan a path, the packages are the robot and no amount of saved overhead compensates for writing them yourself. If you are learning, the ecosystem is the thing worth learning, because it is the vocabulary the field speaks and the reason your questions have answers. If your sensor's only maintained driver is a package, the decision was made for you when you bought the sensor. If several people will touch the code, standard message definitions are the cheapest agreement you will ever get. And if the robot spends most of its time talking to another computer over a network, the ecosystem was built for that world. HORUS is not the answer in any of those cases, and choosing it there trades a decade of other people's work for plumbing you would then have to maintain alone. For a hobby machine specifically, the overkill question is worth reading before you switch anything.

Is ROS 2 simply too bloated to run on small hardware?

No, and here is why: the bloat complaint is mostly about the desktop bundle rather than the framework, and it dissolves once you install what your robot uses instead of everything the project publishes. Most of the size people quote comes from simulation assets, visualisation tools, example packages and documentation that never need to be on the machine. A robot that runs a camera, a motor driver and a controller can be assembled from a much smaller set, and builders do exactly that routinely. What is true, and what the complaint is groping towards, is that the framework was designed for computers with room to spare, so its defaults are generous where a small board would prefer them to be mean. Discovery chatters. Message types are copied more than they strictly need to be. Nothing here is a scandal and none of it is fixed by writing your own transport, which is how a weekend complaint becomes a year-long maintenance commitment. Trim the install first. Measure what changed by watching the robot rather than by reading forum opinions.

Will a lighter middleware rescue a board that is already struggling?

Partly, but not the way you think. Moving messages between programs without serialising them removes real work from a loaded board, and on a machine where several processes exchange sensor data on one computer that is a genuine reduction rather than a trick. What it does not do is create cores. If your camera decoding, your model and your controller together want more of the board than the board has, a lighter transport moves the shortage rather than curing it, and the robot still hesitates. The tell is straightforward and worth running before you commit: quieten everything except the loop and see whether the misbehaviour survives. If motion is clean once the rest of the system is idle, you have contention and the transport is a fair target. If the loop still misbehaves alone, the cause is your control tuning, your calibration, or the mechanics, and no foundation change touches any of those. Builders who skip that test frequently rewrite a working layer and discover the stutter waiting for them on the other side, unchanged.

How do you decide what to run on your board?

Decide by naming the symptom out loud, because each symptom points somewhere different and only one of them is about middleware. "The image does not fit on my card" is a packaging problem and trimming the install solves it. "The robot takes ages to be ready" is a start-up problem, solved by starting fewer things and fixing the order in which they come up, not by changing what carries the messages. "I cannot find a driver for my sensor" is an argument for staying exactly where you are. "The arm stops late when the camera is running, and it stops on time when the camera is off" is the one symptom that genuinely implicates the layer underneath, and it is worth acting on. If more than one of those is true, fix them in that order, because the cheap ones are also the ones that make the expensive diagnosis clearer. And if none of them is true and the robot simply works, the board is not too small and the framework is not too heavy, whatever the internet told you.

Decide by situation rather than by reputation:

• If you are learning robotics -> ROS 2 on a mainstream Linux board, because the ecosystem is the thing worth learning.
• If your card is full or your boot is slow -> a trimmed ROS 2 install, because the complaint is packaging rather than architecture.
• If motion degrades only when the board is busy -> keep the ecosystem above and move the loop to a shared-memory transport, because contention is the actual problem.
• If your board is a microcontroller -> firmware or a small real-time operating system, because there is no Linux underneath to run any of this.
• If one person owns the whole robot and it is small -> one program and no middleware, because the coordination you are paying for does not exist yet.

When two rows survive, 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 questions about your project rather than about the software, and you keep whichever option loses on fewer of them. If your robot keeps landing on one board, more than one language, and a loop that slips when the rest of the machine gets busy, star HORUS on GitHub so it is in your list when you start building. If you are still weighing the wider field, the alternatives for a small robot covers the neighbouring choices.