Is ROS 2 Used in Industry, or Just in Research Labs?

ROS 2 genuinely ships inside commercial robots, not only research demos, and teams needing tighter timing pair it with a shared-memory layer such as HORUS. The ecosystem is the reason: drivers, navigation, transforms and recording tools already exist, and rewriting them rarely pays for itself. That changes when the robot keeps missing deadlines and the delay sits in message delivery rather than in your own code. The rest of this post is for engineers choosing what a first commercial robot runs on, and for teams deciding whether to keep what they already have.

Most of the ROS 2 you have seen was filmed in a university corridor. A student pushes a cart, a robot follows it politely, everyone claps, and the code never leaves the building. So when your manager asks what the product will actually run on, the worry underneath the question is fair: is this a teaching tool that happens to work, or something a company can put behind a warranty?

You have probably heard both stories from people you trust. One says every serious robotics company runs ROS 2 and you would be mad to write your own. The other says the shipping teams they know quietly rewrote most of it, kept the message definitions, and never mention it publicly. Both are told with confidence, both are partly true, and you end up no wiser.

Meanwhile the practical questions pile up. Who fixes it when a dependency breaks a month before launch? What happens on a machine with no internet? Will the safety auditor accept it? Can two engineers maintain this, or does it quietly need six?

Is ROS 2 actually running on robots that customers pay for?

Yes, ROS 2 runs inside warehouse fleets, farm machinery, inspection drones, laboratory automation and delivery robots that customers buy and depend on daily. The adoption is real and it is not confined to startups. Established manufacturers use ROS 2 for the parts of the machine that change often, such as perception and navigation, while keeping their existing controllers for the parts that must never change.

What ships, though, rarely looks like the tutorial. Production teams pin one distribution and stay on it far longer than the release calendar suggests. They freeze the dependency list, delete packages they do not use, write their own drivers because the community ones assume a slightly different sensor, and push anything safety-related into firmware where a crashed process cannot reach it. The message graph ends up as the coordination and tooling layer rather than the thing standing between a sensor reading and a motor command.

Industry uses ROS 2 roughly the way industry uses Linux: widely, seriously, and with local modification that never makes it into a conference talk.

What does robotics middleware actually do for a product team?

Middleware is the post office between the programs running on your robot. One program reads a camera, another decides where to go, a third talks to the motors, and the middleware decides how a message leaves one program and arrives at another: who is listening, what the message looks like, what happens when the reader falls behind, and what happens when a program dies and comes back.

That sounds like plumbing, and it is, but it quietly shapes the whole system. Because messages are cheap to send, you split work into small programs that can be tested and swapped independently. Because there is a standard message for a laser scan, somebody else's mapping code accepts your sensor. Because the traffic is observable, you can record a bad run on site and replay it at your desk on Monday instead of driving back out.

The price is that every message now crosses a boundary, and boundaries have timing. A product team feels the middleware choice most sharply on the day a boundary stops being free.

What are the real options under a commercial robot?

There are roughly five families, and most companies run two of them at once. ROS 2 offers the largest ecosystem and the most hireable skill set, which is why it anchors so many products. HORUS is an open-source real-time robotics middleware for Rust, Python and C++ where all three languages read and write the same shared-memory ring buffers, so messages between processes on one machine are not serialised; it is Apache-2.0, so shipping a product on it raises no licence argument. In-house middleware is what teams build when their needs are narrow and their timeline is generous. A vendor platform hands you a finished robot behind a closed interface. And plenty of respectable machines run no middleware at all: one process, a few threads, firmware underneath.

Mixing is normal rather than shameful: the ecosystem above for tooling and community code, something tighter underneath for the loop that must not slip.

What does it look like when a lab stack goes into production badly?

A lab stack sent to production looks like a robot that behaves perfectly on the bench and misbehaves only when everything runs at once. Alone, the arm places the part correctly every time. Turn on the camera pipeline, the logger and the fleet uplink together, and the same arm starts overshooting slightly, then occasionally badly, and nobody can reproduce it in the morning when the office is quiet.

The other signatures are familiar to anyone who has shipped. The robot pauses at the same corner of the same aisle and nowhere else. Startup order suddenly matters, so somebody adds a sleep to a launch file and nobody dares remove it. A node dies at night and the machine keeps driving on the last message it received, which was still perfectly valid, just old. Recording data changes the behaviour you were trying to record.

Teams usually respond by buying a larger computer, and it helps for a while. Then they lower sensor rates, which also helps, and the robot becomes a slightly worse robot that fails less often. That trade is the symptom worth paying attention to.

Who are you, and does that change the answer?

Your role changes the answer more than the technical arguments do. A student or hobbyist should start with ROS 2 because help exists: when something breaks at midnight, somebody has already asked your question and been answered. A two-person startup chasing a pilot should also start there, because the calendar, not the architecture, is what kills a first product.

An established manufacturer with an electronics team is in a different position. The motor controllers, safety relays and field bus already work and are already certified. The sensible shape is ROS 2 above for perception, navigation and tooling, the existing controllers untouched below, and a boundary nobody may blur.

An integrator automating a known task rarely benefits from any of this and should buy the vendor platform. A research group publishing code should stay firmly in the ecosystem, because a paper nobody can run is a paper nobody cites. If you are early enough to still be counting how long this takes to learn, the honest timeline for learning ROS 2 is worth reading before you commit a roadmap.

What hardware are you shipping on?

The number of computers on the robot matters more than how powerful each one is. If everything runs on a single board, then every message between your programs is a message between processes on one machine, and packing data up only to unpack it again buys you nothing. That is the situation where a shared-memory approach earns its place, because the copying was pure overhead from the start.

If the robot spans several boards, or several machines on a vehicle network, then the networking that ROS 2 provides is doing real work and replacing it is a genuine loss. The same holds for a fleet where machines talk to a supervisor.

Microcontrollers change the question again. A small board driving motors will not run a full distribution; it runs firmware, or a cut-down bridge, and talks to the main computer over a serial link. Accelerator modules add a wrinkle: memory bandwidth is often the scarce resource, and a pipeline copying every camera frame twice before inference feels it long before the processor looks busy.

How much time do you have before the robot must work?

A near deadline argues strongly for ROS 2, and a distant one is what opens the other options up. If a customer demo is weeks away, the winning move is to assemble the robot from parts that already exist and accept whatever timing you get, because a robot that stutters and exists beats an elegant one that does not.

If you have a season or more before anything must ship, the calculation inverts. You have time to find where the timing actually hurts, and time to fix it in the right place rather than the convenient one. Teams that do this well spend part of that runway building a deliberately unfair test: run the control loop while the camera pipeline, the logger and a file copy all compete, and watch what happens to the arm.

The dangerous middle case is a deadline close enough to force shortcuts but far enough to tempt you into rewriting infrastructure. Teams in that band do both, leave the rewrite half-built, and ship something harder to maintain than either path alone.

What skill level does your team actually have?

The skill that decides this is Linux and build systems, not robotics theory. Engineers comfortable with package managers, cross-compilation, service units and reading a stack trace will be productive in the ecosystem quickly, whatever their background in kinematics. Engineers who are strong at control theory but have never packaged software will spend their first weeks fighting the tooling rather than the robot.

Language matters less than people argue about it. A team fluent in Python can go a long way, provided the parts with hard timing constraints are not written in Python; there is a reason a short Python example can outrun a carefully built node graph in simple cases. C++ is where most of the ecosystem lives. Rust adoption is growing and suits teams who would rather argue with a compiler than with a debugger.

The most useful question in a planning meeting is blunter: if the person who set up the build leaves, can anybody else rebuild the robot image from scratch? If the answer is no, that is the risk to fix first.

What changes as the robot gets more demanding?

Demands arrive in a predictable order, and knowing the order lets you prepare rather than react. First comes more data: another camera, a better lidar, a second arm. Nothing breaks, but the machine runs warmer and the logs grow large enough that you start deleting them.

Second comes tighter control. The robot moves quicker, or handles something fragile, or must stop within a distance that no longer allows a lazy reaction. Here message timing stops being an academic concern, because a state estimate that arrives after the decision was made is not part of the decision. Teams doing sensor fusion across several sources usually meet this wall first.

Third comes the fleet, which brings updates, rollback, remote diagnosis and versioning of message definitions, and the organisational problem overtakes the technical one. Fourth comes certification, which asks a question none of the earlier stages did: can you prove what the machine will do? That is answered by making the safety path small and boring, not by making the software clever.

What do you give up by building a product on ROS 2?

You give up direct control over when things happen, and you take on a large surface of code you did not write and cannot fully audit. Message delivery passes through discovery, configuration, transport and callback dispatch, and each layer has settings that interact in ways which only show up under load, on the customer site, on a Friday.

You also inherit an upgrade treadmill. Distributions age out, packages you depend on get abandoned, and the fix for one bug arrives bundled with changes you did not want. Most shipping teams respond by pinning everything and effectively forking their own snapshot of the world, a reasonable answer that quietly makes them responsible for maintaining it.

The third cost is conceptual. The ecosystem encourages splitting a system into many small programs, which is good for testing and awkward for the one loop that must never slip, because that loop now depends on the scheduling of programs it does not control. None of these costs are shameful. They are the bill that arrives with the ecosystem's benefits.

When is ROS 2 the better choice?

ROS 2 is the better choice for most first robots, for anything whose hard part is perception, navigation or manipulation, and for any team that needs to hire. If your robot must map a building, plan a path around a forklift, calibrate a camera against an arm, or interpret a point cloud, that work already exists and is better than what you would write in the time available. HORUS is not the answer to those problems: it is not a simulator, not an inference engine, and not a replacement for a navigation stack.

ROS 2 also wins whenever the ecosystem is the deliverable. Research groups sharing code, universities teaching classes, companies whose customers extend the robot themselves, and teams buying parts from several vendors benefit more from a shared vocabulary than from tight timing.

And it wins on people. You can hire engineers who already know it, buy training, and find an answer to almost any question without waiting for one. For a team of two shipping in a quarter, that is worth more than any architectural argument on this page.

Does industrial adoption mean ROS 2 works out of the box?

No, and here is why: the version that industry ships is not the version you install. Product teams repeat the same sequence. They start with the full distribution, discover it works impressively well, then spend months turning it into something they can support. Community drivers get replaced with ones matching their sensor's actual firmware. Discovery gets confined to the machine so a busy site network cannot disturb it. Launch files get replaced with service units that restart properly.

The out-of-the-box experience is optimised for getting something moving quickly, which is right for its purpose and not the same as being ready to sell. A robot running unattended in a customer's building needs answers to questions the tutorial never raises: what happens when the disk fills, when the clock jumps, when a sensor returns garbage instead of failing cleanly, when the machine is power-cycled mid-write.

Industrial adoption proves the foundation is sound. It does not prove the default configuration is a product.

Is a stuttering robot always a middleware problem?

Partly, but not the way you think. Most stutter in the field is contention, not transport. The control loop shares a processor with a camera pipeline that allocates memory aggressively, or a logger writing to a slow disk, or a Python program that pauses to tidy up at exactly the wrong moment. Change nothing about your messages, pin the loop to its own core, and many of these robots stop stuttering.

Telling the two apart is straightforward once you know to look. Run the loop alone with everything else disabled: if it is smooth, you have a contention problem and no middleware will save you from it. If it still hitches, check whether the data arriving is old rather than the computation being slow, because those failures look identical from outside and have opposite fixes.

The genuine middleware cases have a signature. Your program finishes its work with room to spare, yet acts on a reading that was already stale when it arrived, and the staleness worsens as you add publishers. That is when moving the data path is the real fix.

How do you decide what to build the product on?

Decide by naming the one thing the robot must never do, then working outward from there. Write it plainly: this arm must not swing while a person is inside the cell; this vehicle must stop before the dock. Find where that rule is enforced today. If it is enforced by a message arriving on time, you have found your risk, and it belongs somewhere smaller and more predictable than a general message graph, usually firmware or a dedicated controller.

Everything else can be chosen for boring reasons, which is a compliment. Pick the layer with the drivers you need, the community you can ask, and the skills you can hire. Then build one deliberately hostile test early: run the loop while the machine does everything it will really do, and watch whether the robot still behaves. Do that in the first month, not the last.

The teams who get this right are rarely the ones with the strongest opinions about middleware. They are the ones who found out early which part of their system was actually fragile.

• If you are a two-person team with a demo deadline -> ROS 2, because the drivers and navigation you would otherwise write already exist.
• If you are an established manufacturer with certified controllers -> ROS 2 above and existing controllers below, because the safety path should not move.
• If you are automating a known task with a known robot -> the vendor platform, because certification and support arrive with it.
• If you are a research group publishing code -> ROS 2, because your readers need to be able to run what you wrote.
• If your robot misses deadlines and the data is late rather than the compute -> a shared-memory route under the loop, because the copying was the part you can remove.

When you compare candidates, score them on the HORUS Fit Framework: ecosystem size, setup effort, team size fit, deployment target, and licence. Those five axes settle more real projects than any argument about architecture does.

If the shared-memory route is where your robot seems headed, HORUS is open source under Apache-2.0 on GitHub. Star it so it is in your list when you start building.