What Should You Use Instead of ROS 2 for a Small Robot?

For most small robots, plain code beats ROS 2, with firmware and a small middleware such as HORUS as the other honest answers. A small robot rarely has the problem middleware solves: several programs that must keep agreeing while the machine moves. That flips the moment you want somebody else's mapping, navigation or sensor driver, because that work lives inside ROS 2. The rest of this post is for someone building a first small robot who wants to pick a foundation now and not tear it out in six months.

You wanted a robot that follows a wall. Three evenings in, you have a workspace, a build tool, a new line in your shell profile, a package with your name on it, and nothing that moves. The tutorial had you make a talker and a listener, and they worked, and you still cannot see how that becomes a wheel turning when the sensor sees something. Then the listener stops seeing the talker for a reason involving a network setting, on a robot that is not on a network. You fix it by copying a command from a forum post you do not understand, and the fix does not survive a reboot.

Meanwhile the actual robot logic — read the distance, and if it is too close, turn — is fifteen lines you wrote on the first evening and have not been allowed to run since. The gap between those fifteen lines and the apparatus around them is what makes people quit. And you cannot tell whether that apparatus is protecting you from something you have not met yet, or whether you have picked the wrong size of tool entirely.

What should you use instead of ROS 2 for a small robot?

Use one plain program until the robot is genuinely several programs, and then pick the smallest thing that carries messages between them. The honest replacements are a single program with no middleware at all, firmware living on the microcontroller, a small message layer, or the SDK that came with the base or arm you bought. Which one is right depends less on the robot than on why you are asking, and three quite different people ask this question. The first has bounced off the setup and wants to see a wheel turn this weekend; that person wants plain code. The second has a robot working and has noticed that the build and launch machinery is now most of the work; that person wants a smaller layer, not a different ecosystem. The third has a timing problem — the wheels get their command a beat late and the robot wobbles along the wall — and needs something that moves data between programs on one machine without rebuilding it on the way. Decide which of the three you are before you pick anything, because the three answers barely overlap.

What is robotics middleware in plain terms?

Robotics middleware is the postal service between the separate programs that make up a robot, plus the rules about what happens when one program falls behind. One program owns the camera. Another owns the wheels. A third decides where to go. None of them was written knowing about the others, so something has to let them address each other by the name of a stream — wheel speed, distance ahead, goal position — rather than by knowing which program produces what. Middleware also settles the awkward questions nobody thinks about until they bite: whether a message that arrived too late should still be delivered, what a reader sees when the writer dies halfway through a message, how a program that starts late finds the ones already running, and how you record a whole run so you can replay it at your desk afterwards. What middleware is not is a robot library. Middleware does not know what a wheel is, will not tell you where you are, and makes nothing move. That is why a robot which is one program needs none of it: a function call is already a delivery.

What are the real alternatives to ROS 2 for a small robot?

There are four real alternatives, and the first of them is writing no middleware at all. One, a single program: one loop, one language, one file if you like, with function calls where messages would have been. Two, firmware on a microcontroller, where the loop sits beside the motor and nothing above it earns its place. Three, a small message layer such as HORUS, an open-source real-time robotics middleware for Rust, Python and C++ in which all three languages share the same shared-memory ring buffers, so messages between processes on one machine are not serialised; the licence is Apache-2.0, the project is validated in simulation, and this is not a full ROS replacement for every project, which is exactly why ROS 2 stays the right answer whenever borrowed packages are the point. Four, the SDK that came with the base, arm or drone you bought, which usually already knows how to drive its own hardware. Then there is the accidental fifth: a general-purpose message broker borrowed from web work, which will carry your data honestly and give you nothing that understands robots.

How do the small-robot options compare side by side?

Read this table by finding the row whose "when not to" column describes your situation, and crossing that row out. Most people are left with one or two, and the choice between those is usually settled by what they already know rather than by any property of the software.

Are you a hobbyist, a student, or a two-person startup?

These three should make different choices, and the student's is the least obvious. If you are a hobbyist, your time is the entire budget and nobody inherits your code, so the smallest foundation that lets you see the robot move tonight is the correct one — plain code, and no apology owed to anybody. If you are a student, pick ROS 2 even where a smaller thing would do, because the value is not the transport: your supervisor, your lab mates and your next employer all speak it, and a robot nobody else can read is worth less than one everybody can. If you are two or three people building toward a product, the question becomes which parts of the robot you intend to write yourselves. Where mapping, navigation and drivers come from other people, the ecosystem is most of your engineering team and you should not fire it. Where the interesting part is behaviour only you understand, and the whole thing runs on one computer, a smaller foundation costs less to own — though that is also where projects stall after the prototype, so choose deliberately.

What should you use on a Raspberry Pi or a microcontroller?

The board decides this more than your preference does. A microcontroller — the small board with no operating system that you flash and reboot — should run firmware, and there is no middleware worth putting on it; the loop that reads an encoder and sets a motor current belongs there anyway. A single-board Linux computer is where you genuinely have a choice, because that is the first place a camera, a map or a planner can live. Most small robots end up being both: a microcontroller doing the tight loop beside the motors, and a Linux board doing the thinking, joined by a serial cable. That cable is a decision people make without noticing. Once the robot is split that way, the part that must hold a rhythm is already off the Linux side, so the messaging question on the Linux board becomes much easier, because nothing left there is under a deadline. And if your robot has no camera, no map and no planner, it may not need the Linux board at all — and the entire middleware question disappears along with it.

What should you pick if the robot has to move by the end of the month?

Pick the thing you already know, and if you know nothing, pick plain code. A deadline turns the learning curve into the schedule, and any foundation you have not used before will cost you a week you did not budget before giving anything back. If somebody on the team has already shipped a ROS 2 robot, ROS 2 is the right answer for you even where it is heavier than the job needs, because the setup is muscle memory rather than reading. If nobody has, do not learn a large ecosystem against a deadline. Write one program, keep the interesting logic in functions that take data and return commands, and get the wheel turning. The trap here is believing that starting on the bigger foundation now saves you the migration later. It does not, because the month you spend learning it is a month the robot does not move, and a robot that has not moved by the demo date has no later to be migrated in. Deadlines reward the boring choice, every time.

What if the only language you know is Python?

Python alone is enough to build a small robot, and it stays enough for longer than people tell you. Read a sensor, decide something, set a motor: that is a Python loop, and on a small machine it will hold its rhythm well enough that nobody watching can tell. ROS 2 supports Python properly, so this is not an argument against ROS 2 — the friction there is the workspace and the build step, not the language. Where Python eventually bites is not where beginners expect. It bites the day a second language arrives, because somebody hands you a C++ driver, or the vision part has to move out of Python to keep up with the camera. At that point you have two programs in two languages that must exchange data, and how they exchange it becomes your problem for the first time. That is where a shared-memory middleware starts to matter, because the boundary between languages is what costs you, rather than either language on its own. Until that day arrives, stay in Python and spend the saved evenings on the robot.

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

Most beginners try to make the tutorial's shape fit their robot, and that stops working when the robot needs a shape the tutorial never had. The sequence is familiar. You copy the talker and the listener, rename them, and add a third node. The launch file grows. A parameter file appears. Something does not start in the right order, so you add a wait — and it works, which is worse than failing, because now there is a sleep in your robot for reasons nobody will remember. Later a node crashes at start-up, but only on a cold boot, and the fix is another wait. By the time there are six programs and a launch file nobody enjoys reading, the project has quietly become an integration project. None of that is ROS 2 being bad at its job. It is a beginner using the tooling on a robot small enough that the tooling was never the point. The tell is what your evenings contain: when a month of work includes no change to how the robot behaves, you have swapped projects without deciding to.

What do you give up by not using ROS 2?

You give up other people's work, which is the largest single asset in robotics and the reason this decision is not obvious. Concretely: mapping and navigation you did not write; drivers for the sensor you have not bought yet; a visualiser that draws what the robot believes about the world, which is the best debugging tool a beginner can have; recording and replay, so a failure on Tuesday can be studied at your desk on Wednesday; a simulator that already knows your message shapes; and a large body of forum answers written by people who hit your problem before you did. You also give up handover. Somebody who knows the ecosystem can read an ecosystem robot on their first day, and cannot read your private architecture at all — which matters if you ever want help, a collaborator, or a job on the strength of this project. What you get back is a system small enough to hold in your head, a start-up sequence you can say out loud in one sentence, and no build tool standing between you and a change.

When is ROS 2 the better choice?

ROS 2 is the better choice the moment the valuable part of your robot is code somebody else already wrote. A wheeled machine that must build a map of a building and drive to a named goal is a ROS 2 project, because reproducing mapping and navigation on a hobby schedule is not a project, it is a career. An arm that must plan around obstacles is a ROS 2 project for the same reason. If the sensor you bought ships one usable driver and that driver is a ROS 2 package, the decision has been made for you. If you are a student, joining a lab, or hoping anyone will collaborate, shared vocabulary beats every technical argument on this page. If the robot is more than one computer — a machine and a workstation, or several machines — ROS 2 was designed for that world. And if you are building toward something you intend to sell, note that ROS 2 does scale to a commercial product. HORUS is not the answer in any of those cases, and choosing it there means rebuilding, alone, the very thing that made the ecosystem worth having.

Does skipping ROS 2 mean you are not building a real robot?

No, and here is why: a robot is a machine that senses and acts, and no part of that definition mentions middleware. Plenty of machines that obviously count — vacuum cleaners, camera gimbals, agricultural sprayers, most drones — run firmware and a couple of loops with no message bus anywhere near them. The belief that the ecosystem certifies you as serious comes from where beginners meet robotics, which is coursework and conference talks, and both describe a world where borrowed packages are the norm because research is measured by what you add on top of them. Building something small and complete teaches you more about robots than assembling something large and borrowed, because when the wheel does not turn, you have to know why. The real risk of skipping the ecosystem is not credibility. It is that you write your own version of the boring parts — start-up ordering, logging, replay — badly, and then maintain them forever. Judge the decision on that, not on what your robot uses to move a number between two programs.

Is ROS 2 too heavy to run on a small robot's computer?

Partly, but not the way you think. The genuinely heavy part is what you must install, image and start: a full ecosystem install eats a real share of a small memory card, the first build on a small board is long enough to be a coffee break, and every extra node is one more thing that must come up in the right order at boot. Those costs are real on a small robot, and they show up as friction rather than as a machine that cannot keep up. What is not heavy in the way people assume is the running system — ROS 2 sits comfortably on the small Linux boards hobby robots use, and the computer is almost never the thing that makes somebody give up. That distinction changes the remedy. If the pain is installing and booting, a smaller foundation genuinely helps, and so does simply having fewer programs. If the pain is that you cannot remember what a launch file is for, no change of software fixes that, and understanding what middleware does will help you more than switching.

How do you decide which foundation to start on?

Name the single piece of software you would be most unhappy to write yourself, and let that name decide. If the answer is a navigation stack, a mapping system, or a driver for a sensor on your desk, the ecosystem holding it wins and everything else here is detail. If nothing on that list exists — if the interesting part is behaviour only you understand — you are free, and the right move is the smallest foundation that gets the robot moving today. Two follow-up questions break most ties. How many computers is this robot, and how many languages will it speak? One computer and one language means you can defer this decision for a long time without regret. One computer and two languages is where a shared transport stops being a nicety. More than one computer on a network is where the mature ecosystem earns its ceremony. Notice that none of those questions asks which software is better. They ask about your situation, and your situation is the only thing that makes any answer correct.

Decide by situation rather than by preference:

• If you are one person with one board and one loop -> plain code, because the foundation would otherwise be the biggest thing you maintain.
• If the tight loop lives beside the motors and never sees a camera -> firmware, because nothing above it earns its place.
• If mapping, navigation or a bought sensor's driver is the point -> ROS 2, because that work is not reproducible on your schedule.
• If two languages must share data on one computer -> a shared-memory middleware, because the boundary between them is where your evenings are going.
• If you are a student or want collaborators -> ROS 2, because shared vocabulary outweighs every other argument here.

When the call is close, weigh it on the five axes of the HORUS Fit Framework — ecosystem size, setup effort, team size fit, deployment target, and licence — and keep whichever option loses on the fewest. No scores and no numbers: plain questions about your situation rather than about the software. And if your small robot keeps landing on one computer, more than one language, and behaviour nobody else has written, star HORUS on GitHub so it is in your list when you start building.