What ROS 2 Gets Right That People Rarely Mention

ROS 2 gets the boring parts right — time, coordinates, recorded runs and shared vocabulary — and lighter options like HORUS or Zenoh replace none of them. Those four are the parts nobody advertises and everybody depends on, which is why teams tend to notice them only after leaving. The verdict flips when your robot is one machine, one language boundary and one loop that must not be late. The rest of this post is for someone who already uses ROS 2 and is quietly wondering whether something else would be simpler.

You know the complaints because you have made most of them yourself. The first build took an afternoon. The tutorial assumed a version you did not have. Two programs on the same computer refused to see each other until somebody pasted an environment variable into the team chat. You have explained to a new starter, more than once, that the error about a missing package is not really about that package.

So when somebody posts that they got the same robot behaviour out of a page of plain Python, it lands. Of course it does. Most of what you did last month was not robotics.

There is a second experience that never gets posted, though. Somebody pulls up the recording of yesterday's failed run, scrubs back to the moment the arm swung wide, and sees on screen exactly what the robot believed about the table at that instant. The bug is obvious inside a minute. Nobody writes that afternoon up, because nothing went wrong and nothing felt heavy. That missing half is why the public account of this framework is so lopsided.

What does ROS 2 get right that people rarely mention?

ROS 2 gets four unglamorous things right, and none of them show up in the arguments about it. The first is geometry bookkeeping: a standing answer to where every part of the robot sits relative to every other part, kept honest across time, so a camera measurement taken while the head was turning can still be compared with a wheel position from a moment earlier. The second is time itself, because every message carries a stamp and the whole ecosystem agrees on what that stamp means, which is the difference between a sensor disagreement you can explain and one you argue about for a week. The third is recorded runs: capture everything, replay it into the same programs at your desk, and watch the failure again without the robot present. The fourth is vocabulary — thousands of people using the same words for the same things, so a stranger can answer your question without a tour of your architecture first.

What is a robotics middleware actually responsible for?

A robotics middleware is responsible for three jobs, and public comparisons weigh only the first. Job one is transport: getting bytes from the program that produced them to the programs that need them, on time and in order. Job two is convention: deciding how messages are named and shaped, how time is recorded, how positions relate to each other, how a program is configured and started, and what happens when a listener is slower than a talker. Job three is observation: the ability to see what is flowing without rebuilding anything, to record it, to replay it, and to draw it. Transport is the part that is easy to measure and the part every project starts with. Convention is the part that decides whether two teams can work on the same robot without a meeting. Observation is the part that decides how long a bad afternoon lasts. A middleware judged only on job one will always look overweight next to something that does job one alone.

What are your actual options if you want those quiet strengths?

Seven routes exist and only one of them hands you all four strengths in the box. First is ROS 2 with its standard tooling, which is the only option where geometry bookkeeping, stamped time, recorded runs and shared vocabulary all arrive together and already work with each other. Second is ROS 2 with a different transport underneath, which keeps every one of those and changes only how bytes move. Third is a smaller middleware such as HORUS, an open-source real-time layer for Rust, Python and C++ where 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 it deliberately carries none of the tooling above the message path, which is why teams often keep ROS 2 alongside it for sensors and recording. Fourth is a vendor SDK. Fifth is a network transport such as Zenoh for machines spread across a site. Sixth is a general message broker for telemetry. Seventh is your own layer plus borrowed libraries.

How do the options compare on the parts nobody advertises?

Compare the last two columns and treat the first as background. Every row is somebody's right answer, so read down the final column and cross out each row that describes your project this year. The habit worth forming is to ask, for each row you are tempted by, where the four quiet strengths would come from if you picked it — because the answer is often "from me, later, badly, at the worst possible moment". Rows can also be combined rather than chosen between, and the arrangements that survive contact with a real robot usually are combined: a vendor SDK underneath, ROS 2 for sensors and recorded runs, something smaller carrying the one path that must not be late. When two rows survive elimination, prefer the one your team can still debug on a bad night without the person who originally set it up, since that is the situation the choice will actually be tested in.

What breaks first when a team drops ROS 2 for something smaller?

Geometry bookkeeping breaks first, and it breaks quietly. Week one feels wonderful: fewer moving parts, a start-up you can describe in a sentence, no build system arguing with you. Then a second sensor arrives and something has to say where that sensor sits relative to the first one, and relative to the arm, and what that relationship was at the instant a measurement was taken rather than now. Teams write that themselves, and the first version ignores time, and the robot starts placing obstacles slightly wrong when it is moving. The second casualty is debugging an event nobody witnessed, because without recorded runs the only way to study a rare failure is to reproduce it on the hardware, which means standing in a lab waiting for a robot to misbehave. The third is introspection: with no way to list what is flowing and peek at it, every question needs a code change and a rebuild. None of the three is impossible to rebuild. All three are months, and none of them are what you meant to work on.

Do these strengths matter to a solo builder as much as to a team?

Two of the four matter on day one for a solo builder, and two only start mattering when a second person appears. Recorded runs matter immediately, because a person alone has nobody to hold the robot while they watch the terminal, and replaying a captured failure at a desk is the difference between an evening of progress and an evening of chasing. Geometry bookkeeping matters as soon as there are two sensors or two joints, whether there is one builder or ten. The other two are social. Shared vocabulary pays when you ask a stranger a question, when you hire, or when you return to your own robot after eight months away and read code written by a person you no longer are. Message conventions pay when somebody else has to add a component without a meeting. A solo builder can rationally skip the social half for a while — and the moment a collaborator, a client or a future self arrives, that half stops being optional.

Does ROS 2 still earn its place on a small single-board computer?

Sometimes, and the honest answer depends on which half you need. The full installation is heavy on a small board: it costs disk, memory and boot time, and the discovery machinery does work that is pointless when every program lives on the same chip. If your robot is one loop reading one sensor and driving one motor, that weight buys you very little and the small-board complaint is fair. But the parts described above are not the heavy parts. Stamped time is a convention. Geometry bookkeeping is arithmetic and a small library. Recorded runs need disk, and a modest recording of the messages that matter is affordable on almost anything. Teams on constrained hardware often keep the conventions and the recording discipline and drop the rest, which is a legitimate outcome rather than a compromise. Before deciding, separate the two questions: is the install too big for this board, and are the ideas too big for this robot? They usually have different answers, and only the first is about the board.

When in a project do these strengths start paying back?

Not in the first week, which is exactly why they get under-rated. In week one every one of them is a cost: another concept to learn, another file to write, another reason the build fails. The first payback usually arrives the first time the robot does something wrong that nobody saw and nobody can reproduce — that is the day recorded runs stop being bureaucracy. The second arrives with the second sensor, when geometry bookkeeping stops being an abstraction and starts being the reason two measurements agree. The third arrives with the second engineer, when shared vocabulary means an explanation takes ten minutes rather than a morning. The fourth arrives in month nine, when somebody asks why the arm swung wide in March and you can go and look. Anyone judging this framework on their first weekend is measuring only the cost side and has genuinely not seen the other one yet, which is why beginner reviews and three-year reviews disagree so completely.

How much do you need to know before ROS 2 gives any of this back?

Less than the folklore says, and the list is specific. You need the idea of separate programs exchanging named messages, which is one paragraph. You need to know that positions are tracked in a tree of named frames and that asking for a relationship at a particular time is normal, which is one afternoon. You need enough of the delivery settings to know the difference between wanting only the newest reading and wanting none dropped, which is another afternoon and prevents a whole family of confusing bugs. You need to start a set of programs together from one file and pass them settings. And you need to record a run and play it back, which is two commands and pays for itself the same week. That is the working set. Everything else — build systems, packaging, the layer underneath the messages — can wait until something forces it. Most people who bounce off did not bounce off these ideas. They bounced off the installation and the tooling around it, which is a separate complaint with separate fixes.

What do you give up by staying on ROS 2 for these strengths?

You give up simplicity and a certain kind of control. The install is large, the first day is slow, and a new starter meets the build system before they meet the robot. Upgrades arrive on someone else's schedule, and each release eventually reaches the end of its supported life, so you are committing to a maintenance rhythm rather than a fixed target. You give up being able to hold the whole start-up sequence in your head, because a running robot is many processes with a discovery mechanism between them. You take on dependency weight you did not choose, and packages whose maintainers may drift away. And on one machine you pay for message copying between processes that would not exist if those processes shared memory directly, which is precisely the cost that matters to a tight control path and does not matter at all to a camera feed going to a dashboard. Whether that trade is good depends entirely on which of your paths is the demanding one.

When is ROS 2 the better choice?

ROS 2 is the better choice for most robots that have to leave a workbench. If the machine must map a building and navigate it, ROS 2 wins outright, because mapping and planning are years of specialist work and no message layer substitutes for them. If several machines coordinate over a network, ROS 2 has lived in that world for years and its failure modes are written down. If you are teaching, hiring, or want your engineers employable next year, ROS 2 is the vocabulary in the job adverts and the textbooks. If your sensor's only working driver ships as a ROS 2 package, that decides it on its own. And if you are one person on a first robot who wants to spend evenings on behaviour rather than plumbing, borrowed code beats owned code every time. HORUS is not the answer in any of those cases, and the honest complaint list is worth reading alongside this post so the decision is made with both halves visible.

Is ROS 2 only still here because everyone already uses it?

No, and here is why: inertia explains why something stays installed, not why people who could leave keep choosing it for new robots. Teams start fresh projects on ROS 2 every month with no legacy to protect, and they do it for the boring reasons above — the borrowed drivers, the recorded runs, the geometry bookkeeping, the fact that a question posted at midnight has an answer by morning. Inertia does explain part of the picture, and pretending otherwise is silly: some of the tooling stays in use because replacing it is nobody's promotion, and some packages survive on habit rather than merit. But the strongest evidence against the pure-inertia story is what happens to teams that leave. Many come back for a subset, keeping their own message path for the demanding loop while running the standard tools for sensors and debugging. People do not return to something merely familiar once they have paid to escape it. They return because they miss something specific, and they can usually name it.

Do the tools make up for how long ROS 2 takes to set up?

Partly, but not the way you think. The trade is not one bad week bought back by good tools later, because the setup cost is not one week — it recurs at every upgrade, every new machine, every new starter, and every time a dependency moves under you. Anyone who tells you the pain is a one-time payment has forgotten their own last upgrade. What is true is that the costs and the benefits land on different people and at different times. The setup pain lands on whoever is new, on their first day, alone. The benefit lands on whoever is debugging a rare failure in month nine, usually with somebody waiting. That mismatch, not the total, is why the same framework gets described as unbearable and indispensable by people on the same team. The practical response is to move the pain: make installation somebody's owned job, write down the working setup, and stop paying it individually on every laptop.

How do you decide which of these strengths your robot actually needs?

Go through the four and mark each as needed now, needed later, or never. Do you have more than one sensor or more than one moving joint that must agree about where things are? That is geometry bookkeeping, and if the answer is yes today, you need it today. Will anything ever fail when nobody is watching? That is recorded runs, and the answer is always yes for a robot that leaves a bench. Will a second person touch this code, including you in a year? That is vocabulary and message conventions. Does a stranger need to add a component without asking you first? Same answer. Then ask the separate question about the message path: does any part of your robot have a deadline that a copy between processes could threaten, and can you point at that part? If the four are mostly "needed later" and the message path answer is a confident yes, you are the case for something smaller — and the switching checklist is the next thing to read.

Decide by situation rather than by principle:

• If your robot maps a building or plans an arm path -> ROS 2, because that work is years deep and cannot be borrowed elsewhere.
• If failures happen when nobody is watching -> keep recorded runs whatever else you change, because reproducing on hardware is the slowest way to debug.
• If a second person will touch the code -> keep the shared vocabulary, because an explanation is cheaper than a tour.
• If one box mixes Rust, Python and C++ on a path that must not be late -> a shared-memory middleware for that path only, because copies between processes are what charge you there.
• If the robot is several machines on a patchy link -> a network transport, because that is a different problem with different answers.

Where two lines describe you, weigh them on the five axes of the HORUS Fit Framework — ecosystem size, setup effort, team size fit, deployment target, and licence — and keep whichever loses on fewest axes. No scores, just five honest questions about your project rather than about the software. If your answers keep landing on one machine, several languages and a loop that cannot afford to wait, star HORUS on GitHub so it is in your list when you start building, and keep the tools above, because nothing smaller replaces them.