Is ROS 2 Still the Default Choice in 2026?

Yes, ROS 2 is still the default in 2026, and alternatives like HORUS or a vendor SDK are exceptions you must justify. The default earns that status through drivers, navigation, simulation and a hiring pool, none of which a leaner stack replaces. The verdict flips when one computer runs everything, deadlines are tight, and you need almost none of that catalogue. The rest of this post is for anyone choosing a stack for a real machine this quarter and tired of forum arguments.

You have probably read two threads this week that contradict each other. One says the default is bloated, that it drags in a build system nobody asked for, that half the tutorials no longer apply, and that any competent engineer would write the twenty files they actually need. The other says every alternative is a toy, that the people rewriting from scratch are quietly rebuilding the same thing badly, and that they will discover why coordinate frames are hard the week before their demo. Both are written with complete confidence and neither knows what you are building.

Meanwhile the practical questions pile up. Your camera vendor ships a wrapper for one version and you are on another. Your first install pulled down more than expected and you cannot say what most of it does. Somebody wants to write everything in Rust and somebody else has a working Python prototype they refuse to throw away. Underneath all of it sits the question nobody says out loud: if you pick wrong, how much of the next year do you lose? That is answerable, but not with a feature list.

Should I start my next robot on ROS 2?

Start on ROS 2 unless you can name the parts of the catalogue you would never touch. That is the whole test and it takes ten minutes. Write down every piece of your robot you were not planning to write yourself: the driver for the depth camera, the thing that turns a map into a path around the furniture, the arm planner, the bookkeeping that says where the gripper sits relative to the base, the recorder that replays this morning's failure at your desk, the viewer where you watch what the robot thought it saw. If that list has five entries, the default is doing five jobs for you and you should take it and stop reading comparisons. If the list is empty because your kinematics are unusual, your sensors are custom and everything runs on one board, the default is asking you to carry a warehouse to move one box. Notice what the test is not. It is not about which layer moves messages more cleverly, because both work fine on a bench. It is about how much of your robot already exists, and whether you would use it.

What is a robotics framework, in plain terms?

A robotics framework is two products sharing one name: a way for separate programs to swap data by name, and a library of robot behaviour that someone already got working. The first half is small. Programs run independently, publish under a topic name, and subscribe to names they care about, so the camera process can crash and restart without the controller knowing anything happened. You could write that half yourself in a fortnight and many people have. The second half is why frameworks dominate. It holds the driver that speaks to your particular lidar, the bookkeeping that tracks where every part of the robot sits relative to every other, a clock everyone agrees on, a recorder that captures a whole run for replay, a viewer that draws what the robot believed, and a navigation stack that crosses a building without hitting the furniture. Arguments about frameworks are almost always conducted about the first half and decided by the second. If the vocabulary is still fuzzy, the plain-English tour of what middleware does is the right place to start.

What are the real options besides ROS 2 in 2026?

There are about seven realistic families, and most robots that actually ship use two of them together rather than one. You can take ROS 2 on its default transport, which is right whenever your machines share a switch and you want the catalogue. You can take ROS 2 and change the layer underneath it, which is the Zenoh and DDS question and matters when your graph crosses a network you do not administer. You can put the timing-critical part of the robot on its own computer with a shared-memory middleware, which is what HORUS is for, since Rust, Python and C++ processes there read and write the same ring buffers rather than serialising to each other, and it pairs with ROS 2 rather than displacing it. You can take the SDK your robot's manufacturer ships. You can write plain firmware on a microcontroller and skip the category. You can assemble your own stack on a message library. Or you can stay in simulation, a legitimate answer when the deliverable is a result rather than a machine.

Which option fits the robot I am actually building?

The option that fits is decided by two things: how many computers are involved, and how much of the catalogue you would use. Before you read a row, draw your robot as boxes and lines, mark every line crossing from one computer to another, and circle every box you were hoping not to write. Most people are surprised twice: fewer crossing lines than they assumed, more circled boxes than they admitted. Those two counts decide more of the table than any feature comparison does.

Two rows is the usual honest answer: one for what runs on the robot's own computer, one for everything else.

What should I use if I am one person or a two-person team?

Take the default, unless your robot is one computer running one loop, in which case take the lean path and actually finish it. The failure mode for small teams is never picking the wrong framework. It is spending four months building infrastructure that a framework already had, arriving at something almost as good, and having no robot to show for it. A solo builder's scarcest resource is unfinished work, and every layer you write yourself is a layer you also debug at midnight, document for nobody, and maintain forever. So the honest rule is this: if you would use the navigation stack, the driver set or the viewer, take them and accept the setup afternoon as the price. If your machine is a custom mechanism with custom sensors and a loop you wrote yourself, the catalogue has nothing you want. There is a fuller treatment in the guide for solo builders and two-person teams, but the short version is that both mistakes are expensive and only one leaves you with a moving robot.

What if my robot is one small computer driving motors and a camera?

On one small computer, the default costs you setup time rather than motion, and that is usually a price worth paying. The fear people arrive with is that the framework will make the robot sluggish. That is mostly the wrong fear. What single-board builders run into is duller: the install is large, the build takes long enough that you stop rebuilding casually, the distribution wants a Linux version your board's vendor image is not, and the graphical tools want a screen the robot does not have. None of that makes the arm miss the table. All of it makes your Saturday disappear. The real timing question on a small board is how many times a camera frame gets copied between the process that captured it and the process deciding what to do about it, which is a different problem with a different answer. So budget a weekend for setup, not a rewrite. If that weekend becomes a month because nothing matches your board, that is a legitimate signal to look at the lean path.

What if I have to show something working in a month?

Use the default, because a month is not enough time to write the parts you would be replacing. A demo needs a robot that moves, a way to see what it is thinking when it does something stupid, a way to record the run so you can work out what happened afterwards, and a driver for every piece of hardware on the machine. The catalogue has all four, today, written by people who already hit the edge cases. Building your own versions of those four things is a genuinely interesting engineering project and it is not a month. The trap in the other direction is treating a month-long demo as a permanent commitment. It is not. Plenty of teams demo on the default, learn which part of the robot cannot tolerate the framework's habits, and carve that part out afterwards knowing exactly why. Choosing the default early does not lock the door. Choosing a hand-rolled stack early, with a deadline, usually does.

What if I have never shipped robot software before?

Start on the default and budget the first fortnight for Linux rather than robotics. This is the single most useful thing to know before you begin, because almost every beginner who concludes the framework is impossible is actually meeting an operating system, a build tool and a package manager for the first time simultaneously. Environment variables, file permissions, a service that refuses to start, a package that installed but cannot be found: none of that is robotics and all of it arrives on day one. Expect it and it stops feeling like a personal failure. The second thing worth knowing is that the concepts are not framework trivia. Topics, message types, timestamps, coordinate frames and queue behaviour appear under different names in every stack you will touch, including one you write yourself, so the hours are not stranded if you later ship on something leaner. The realistic timeline for learning ROS 2 is longer than the tutorials imply and shorter than the forums suggest, and knowing which weeks hurt makes them easier to sit through.

What does it look like when ROS 2 turns out to be the wrong default?

It never looks like a crash. It looks like a slowly growing pile of workarounds, each of which was reasonable on its own. Someone merges two programs into one because passing the camera frames between them was costing too much, and then merges a third. Someone adds a queue setting nobody can explain but which stops the stalling. The start-up sequence acquires a wait because a node was not ready and nobody found a cleaner fix. The team stops using half the tooling because it does not work with the merged programs. Six months in, the system runs on the framework but no longer benefits from it, and every new person must be taught the local rules first. That is the shape of outgrowing a default, and it is worth reading about why projects outgrow their first framework before you are inside it. The trigger is almost always the same: a control loop that shares a machine with something bulky, like vision.

What do I give up by choosing ROS 2?

You give up control over your start-up, your update schedule and the shape of your process graph. Start-up first: your robot comes alive when a discovery process has found everyone, which is fine on a workbench and genuinely annoying on a machine that must simply work when someone flips the switch in a warehouse aisle. Updates second: you are on someone else's distribution calendar, tied to a particular Linux version, and a dependency you did not choose can change under you. Shape third: the framework has opinions about what a program is, and if your natural design is four things that must never be separated, you will spend energy persuading the tooling to agree. There is a quieter cost too: you no longer understand every layer of your own robot, so when something misbehaves in a way the documentation does not cover, the search space is enormous. For most projects the trade is not close, because what you buy is years of other people's work. But it is a trade, and pretending otherwise leads to surprises.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever more than one computer is involved, whenever you want software someone else already wrote, and whenever you expect to hire. Concretely: you have a mobile base that needs to cross a building without hitting people, and the navigation stack is a decade of work you cannot reproduce. You have an arm and you need collision-aware motion planning, which is genuinely hard and already solved. You have three sensors from three vendors and each ships a wrapper. You are hiring, and the candidates already speak the vocabulary. You are reproducing published research, which arrives as packages. You have a fleet, and fleet tooling assumes the default. In all of those cases HORUS is not the answer, and neither is a hand-rolled stack, because both leave you writing what the catalogue already contains. The strongest version of this argument is about your calendar, not your code: the default lets a small team spend its months on the part of the robot that is actually theirs.

Is ROS 2 too heavy for a small robot?

Partly, but not the way you think. The weight people complain about is mostly weight in the developer's day rather than weight on the robot's processor. A large install, a long first build, a distribution tied to a Linux version, tools that assume a desktop: all real, all annoying, all paid once. People then assume the same heaviness slows the machine down at runtime, and that is where the reasoning goes wrong. What actually costs a robot at runtime is identifiable: how many times a large message is copied and converted while crossing between two programs on one computer, how much traffic discovery generates on a busy network, and whether the program acting on a deadline competes with something bulky for the processor. Those are architecture questions, not bloat questions, and you can answer them inside the framework by keeping deadline-critical work in one place. Calling it bloat hides the real problem, which is that the same message can cross a process boundary several times before anything looks at it.

Do serious companies quietly replace ROS 2 before they ship?

No, and here is why. The pattern in shipped machines is not replacement, it is carving. A company keeps the framework for everything that benefits from it, which is most of the robot, and moves the innermost part somewhere else, which is usually a microcontroller or a dedicated process on the main computer that speaks to the rest through a narrow, well-defined boundary. The drive motors get commanded by something small and predictable, while mapping, planning, logging and the operator interface stay in the framework where the tooling lives. Full replacements happen for a narrow set of reasons: a certification regime demanding an auditable stack, a processor too small to host the framework, or a product whose entire value is a control law nothing off the shelf resembles. If none of those describe you, the story you occasionally hear about a team ripping the whole thing out is a story about a different company. Whether the default scales to a commercial product is a fairer framing than whether it gets thrown away.

How do I decide this week?

Decide by writing two lists and one sentence, then spending four days trying to prove the choice wrong. The first list is everything in your robot you were not planning to write yourself. The second is every place a message crosses from one computer to another. The sentence names the one thing that must never be late, in plain words: the wheels stop before the robot reaches the edge of the dock, or the arm stops before it hits the table. Then install the default, get your hardware talking to it, and see which of the three you struggle with. Most teams find the struggle is the sentence rather than either list, which is useful: it says the problem is where your deadline-critical code runs, not which framework surrounds it.

Take the line that matches you:

• If you are one engineer with a machine that must not be late -> a lean single-machine stack, because you would use almost none of the catalogue anyway.
• If you are new to robotics -> the default, because the tutorials, the simulators and the answers to your questions already exist.
• If you are a startup shipping hardware this year -> the default everywhere except the innermost loop, because rewriting drivers is not your product.
• If your robot spans several computers or a building -> the default, because multi-machine plumbing is exactly what it already solved.
• If you bought a finished platform -> the vendor's own stack, because their support stops where your changes begin.

The HORUS Fit Framework is the checklist behind those lines, and none of its five axes is a number: ecosystem size, setup effort, team size fit, deployment target, and licence. Score every option you are weighing on all five, and the axis you cannot compromise on decides it.

Defaults deserve to be taken. When you meet the machine that needs a leaner layer underneath, where Rust, Python and C++ share the same ring buffers on one computer and nothing gets serialised between them, HORUS is open source under Apache-2.0. Star it so it is in your list when you start building.