Should Your AI Startup Adopt ROS 2 or Something Lighter?

Most AI startups should start on ROS 2 and switch to a lighter middleware only when the robot shows the heavier stack is hurting. The ecosystem is what a small team is really buying — drivers, navigation, tools someone else debugged — and that outweighs any saving in how data moves. The verdict flips when one computer runs both a model and the loop commanding motors, which is where HORUS fits. The rest of this post is for founders and early engineers choosing a stack before the robot exists, on a runway that punishes a wrong turn.

You have money for about eighteen months, four engineers, and a demo that made somebody write a cheque. Now one of you has to decide what the robot software is built on, and the decision has the wrong shape. It feels enormous, it is being settled by whoever holds the strongest opinion, and nobody can point at evidence.

One engineer spent a week with ROS 2 and describes it as a second job. Another says every serious robotics company runs it and that arguing about this is a waste of runway. A third wants to write something small, because the robot only has to do one thing and the frameworks look like they were designed for a different problem. The advisor who has actually shipped a machine says the choice matters less than you think, then says something that quietly contradicts that.

What you can see from outside is that everybody who chose is defending their choice, and nobody who chose is describing what it cost them. You want the version with the cost in it, because four months spent discovering which of them was right is four months you do not have.

Should an AI startup build on ROS 2 or something lighter?

Build on ROS 2 unless your robot puts a model and a control loop on the same computer with large data moving between them, which is the one case where a lighter stack pays for itself. The reason is that a startup's scarce resource is engineer-months, not machine time. ROS 2 arrives with drivers for hardware you have not bought yet, a navigation stack shaped by a decade of other people's mistakes, recording tools that let you understand a failure nobody witnessed, and a hiring pool that already speaks the vocabulary. A lighter middleware supplies none of that and expects you to bring it, which is cheap only if you genuinely need very little of it. The trap is deciding from taste. Engineers who dislike ROS 2 are usually describing the first week, which is a real cost but a one-time one, while engineers who defend it are often defending parts of it you will never use. Decide from the machine instead: what runs where, how large the messages are, and which loop is never allowed to wait.

What does robotics middleware actually give a startup?

Middleware is the part of a robot's software that lets separate programs exchange data without knowing about each other. A robot is never one program. The camera driver is one, perception is another, planning is a third, and the thing commanding motors is a fourth, each running at its own pace and each obliged to survive the others being slow or dead. Middleware handles the introductions and the delivery, so perception asks for camera frames without knowing which process produces them. Most middleware brings a second thing, and this is where founders get confused about what they are choosing. Along with the plumbing come conventions — message shapes, a build layout, a launch system, a way of naming coordinate frames — and around those conventions grows an ecosystem of drivers and tools that exists only because everyone agreed to them. When a team says it uses ROS 2, the plumbing is the smallest part of what that sentence means. What middleware actually does in a robot walks through the mechanics without assuming you have used any of it.

What are the actual options for an early robotics team?

There are roughly seven realistic options, and they line up on a single axis: how much existing work you inherit against how directly your programs share data. ROS 2 with its default transport is the baseline and the answer for most teams, because everything else in robotics assumes it. ROS 2 with Zenoh underneath keeps that inheritance while behaving better across several computers and unreliable networks. 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 are not serialised between processes on one machine, which suits a startup whose Python model and Rust or C++ controller sit on the same board and need the same data without copies between them; like ROS 2, it is Apache-2.0. Below those sit the pragmatic choices: one Python process and no middleware at all, a message broker for a robot that mostly reports and receives instructions, the robot vendor's own SDK, or a small in-house layer you own completely.

What should you use if the founders came from machine learning?

Use ROS 2, because the half of the problem you have not solved is the half ROS 2 has written down. A team arriving from machine learning normally has a working model and no robot, and the gaps are not where they expect them to be. Coordinate frames will take a week and feel insulting. Matching a camera frame to the joint positions at the instant it was captured will take another, and getting it wrong looks exactly like a model that has degraded. Deciding what the machine should do when perception stops arriving is a design question nobody in machine learning has been asked before. All of it has established answers in ROS 2 and none at all in a layer you wrote last month. The habit worth importing immediately is separation: never put a model call inside the loop that commands the machine, even when one process would work today. Splitting them later means rewriting the part your team understands least, when you have the least time. What changes when an AI model is driving the robot covers the rest of that shift.

What should you use if the robot is one on-board computer?

If the whole robot runs on one computer, the question becomes how many copies of your largest messages get made before they reach the thing that acts on them, and that is where a shared-memory middleware becomes worth the trade. A single board has a fixed amount of memory bandwidth and a fixed power budget, and passing camera frames between programs consumes both. ROS 2 runs perfectly well on this class of hardware for a robot whose model advises rather than steers, and the inheritance stays worth more than anything you would save by rolling your own. The pressure appears when a camera feeds a model, the model feeds a planner, and the planner feeds a controller, all on one board, with copies at every hop. It shows up as a machine that runs hot, empties its battery earlier than the spreadsheet promised, and responds late under load rather than failing outright. Middleware for Raspberry Pi and Jetson robots covers what small boards actually tolerate, including moving perception to a second computer.

What should you use if you need a working robot before the next raise?

Use whatever your team already knows, which for most teams means ROS 2 or a single Python program. A few months is not enough time to learn a framework, a robot and a deployment target simultaneously, and the failure that kills a fundraising demo is never that the plumbing was suboptimal. It is that the model was never wired to the arm at all, or that the arm reached for a stale position and swept a cup off the table in front of the room. Two decisions protect a short timeline regardless of what you pick. Split the model and the controller into separate programs on the first day, so a slow inference call cannot freeze the machine mid-motion. Then define what the robot does when a result does not arrive: hold position, finish the current motion, or stop. Demos survive on that definition, because what ruins a demo is a robot doing something surprising rather than a robot doing something slowly. Change the foundation afterwards, when you know which part actually hurt.

What if nobody on the team has shipped robot software before?

Then pick the option with the most written down, and that is ROS 2 by a distance nothing else approaches. A first robot is a sequence of problems that look like bugs and are actually missing knowledge: the arm moves to a position that is right in one frame of reference and wrong in another, a message arrives but nothing reacts to it, the machine behaves differently on the bench and on the floor. Every one of those has a public thread with somebody explaining the answer patiently. With a smaller stack, or one you wrote, you get the same problems and an empty search page, and you burn a week each time on something that was never your product. The counter-argument you will hear is that ROS 2 hides too much from beginners and teaches nothing. There is something to that, but a team with a runway is not optimising for education. Why so many people quit ROS 2 in the first week describes the specific walls, which is useful to read before you hit them.

What does the wrong middleware choice look like a year later?

It looks like a team that is busy every week and shipping nothing new. The symptoms are consistent enough to be diagnostic. Every new feature requires touching the messaging layer, so estimates keep doubling. One engineer has become the only person who can deploy, because deployment lives in their head. Bugs are reproduced by running the robot and waiting, since nothing recorded what happened the last time. New hires take a month to make a first change, and half of that month is spent on the parts you wrote yourselves. Nobody wants to upgrade anything, so the versions drift further behind and the upgrade grows more frightening. Notice that none of these are about how fast data moves. A wrong middleware choice hurts a startup through the tax it puts on ordinary work, not through the machine being late by some measurable amount. That is also why the wrong choice takes so long to notice: nothing breaks, everything just costs slightly more than it should, forever.

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

Almost every team starts with one Python program that does everything, and it stops working the first time the robot has to move and think at the same time. The first version is honest and correct: read a sensor, run the model, decide, command the motor, repeat. It works on a bench, it works in a slow demo, and it fails as soon as the machine has momentum, because the world does not pause while a model runs. The second attempt is threads inside the same program, which helps a little and introduces a class of bug that only appears under load and never during the demo you scheduled to check. The third attempt is separate programs with a queue between them, which is the right shape, and the point at which a hidden question surfaces: when the slow side falls behind, do you process every stale item in order or skip to the newest? For a robot acting on the present, the newest is almost always correct, and a queue that quietly prefers the oldest produces a machine that seems to be reacting to the recent past.

What do you give up by choosing something lighter than ROS 2?

You give up the largest collection of ready-made robot software in existence, and for a small team that is usually a bigger loss than anything gained. The sensor drivers go first: somebody has already made your camera, your lidar and your arm work with ROS 2, and reproducing that is unpaid work with no upside for your product. Navigation and mapping represent years of accumulated fixes for situations you have not met yet. The recording and visualisation tools are how you understand a failure that happened in a customer's warehouse while nobody was watching. Hiring changes too, because ROS 2 on a résumé is a signal you can filter for and anything smaller is something you must teach on your own time. Community answers matter more than teams admit: at eleven at night the real question is whether somebody has already been stuck this way in public. Leaving the ecosystem is defensible when the machine demands it, and it costs you in exactly these ways rather than in any way a benchmark would reveal.

When is ROS 2 the better choice?

ROS 2 is the better choice for most AI startups, and that is not a diplomatic hedge. If your robot has to navigate a space, build a map, or plan around obstacles, those stacks exist there and nowhere else in comparable shape, and writing your own is a company-ending detour. If your model advises rather than steers — labelling, detecting, choosing a destination while a conventional controller handles motion — the ecosystem outweighs every other consideration. If your programs are spread across several computers, ROS 2 with a transport suited to that spread is the right structure, and shared memory does nothing for you across a network. If you plan to hire quickly, ROS 2 is the vocabulary your candidates already have. HORUS is not the answer for a team that needs navigation off the shelf, drivers for unusual hardware, or a stack their next four hires will recognise on sight. The narrower case is specific: one computer, large messages, a model and a controller that must see the same data without copies passing between them.

Will a lighter middleware get your robot out the door sooner?

No, and here is why: nothing about your product's schedule is decided by how programs pass data. Startup timelines are consumed by hardware that arrives late, a gripper that cannot hold the thing customers actually hold, a model that fails on surfaces nobody thought to photograph, and the long tail of behaviour at the edges of the task. A lighter middleware removes a layer of setup and hands you the work that layer was doing. Sometimes that trade is right, because a small robot with three programs and one job genuinely does not need a navigation stack. Often it is a way of converting an uncomfortable learning curve into a comfortable building project, which feels productive and moves no closer to a customer. The honest test is whether you can name the specific thing the heavier stack is preventing you from doing. If the answer is a feeling about complexity rather than a described problem on your robot, the switch will cost weeks and return nothing you can show anyone.

Is ROS 2 too heavy for a four-person team?

Partly, but not the way you think. The weight people complain about is mostly front-loaded: the build system, the workspace layout, the launch files, the first week where nothing works and no error explains why. That is genuinely expensive and it is paid once. The weight that actually persists is different and quieter. Somebody has to own the build and deployment setup. Somebody has to plan the upgrade when a distribution reaches end of life, and a four-person team will feel that week. Somebody has to know why the robot behaves one way on a desk and another on a factory network. None of that appears in the tutorial, and all of it is ongoing. So the real question is not whether four people can learn ROS 2 — they can — but whether four people can carry a maintenance obligation on top of building the product. Teams that answer yes usually have one engineer who enjoys that work. Teams with nobody in that role feel the weight most in month nine, not week one.

How do you decide without spending a month on it?

Answer three questions about your machine and the decision mostly makes itself. Does the robot need to navigate, map, or use hardware other people have already integrated? Does everything run on one computer, or are programs spread across several? Is the traffic between programs mostly large sensor data feeding something that must act immediately, or mostly small commands and status? Navigation, several computers, or small messages all point at ROS 2, and you should take it without further debate. One computer, large data, and a model sitting inside the loop that moves the machine point at shared memory. If you cannot answer the questions yet, you do not have a middleware problem — you have a robot you have not specified, and the honest next step is describing the machine rather than shopping for a framework. What happens when you outgrow your middleware is worth reading before you commit, because the exit cost is the part nobody quotes you.

Decide by situation, not by preference:

• If your robot must navigate or map -> ROS 2, because rebuilding those stacks would consume your runway.
• If your model advises a conventional controller -> ROS 2, because the ecosystem is worth more than anything else on offer.
• If programs run on several computers -> ROS 2 with a transport built for that, because shared memory stops at the edge of one machine.
• If a Python model and a faster controller share one board -> a shared-memory middleware, because copies are what you are losing.
• If you are three people with a demo in eight weeks -> whatever you already know, with the model and the controller as separate programs from day one.
• If nobody can name the problem the switch would fix -> stay where you are and revisit after the next milestone.

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. Take whichever loses on fewest — five plain questions about your situation rather than about the software, with no scores attached. And if your robot is heading towards a model and a control loop sharing one on-board computer, star HORUS on GitHub so it is in your list when you start building.