ROS 2 and Robotics Middleware Explained

What middleware is for

A robot is many programs that must agree about the world. A camera driver, a detector, a planner, a controller and a safety monitor all run concurrently, often on different machines, and all need to exchange data with known timing and known failure behaviour. Middleware is the plumbing that lets those programs find each other and pass messages without each pair inventing its own protocol.

Without it, every integration is bespoke. That was the state of robotics before common middleware existed, and it is the reason the field spent years rewriting the same drivers.

How ROS 2 is structured

ROS 2 is the dominant robotics middleware and much more than middleware in practice: a communication layer, a build system, a package ecosystem, and a large body of community components.

Nodes are the logical participants in the graph — one reads a sensor, one runs a detector, one drives a controller. A node is not the same thing as an operating-system process: components can be composed so that several nodes run inside one container process, which is a deployment choice made for lower overhead and more efficient communication rather than a property of the node itself. See the ROS 2 composition documentation.
Topics carry streaming data on a publish-subscribe basis. Publishers do not know who is listening, which decouples components and also makes it possible to be unaware that nobody is.
Services are request-response calls for things that need an answer.
Actions handle long-running goals with feedback and cancellation, which is the right shape for "move to this pose" where the answer takes seconds and may fail halfway.
Parameters hold runtime configuration.
Transforms maintain the relationships between coordinate frames over time, which sounds administrative and is where a large share of real bugs live.

What changed from ROS 1

ROS 1 had a central master process that brokered discovery; if it died, the system lost its ability to connect. ROS 2 removed it in favour of distributed discovery built on DDS, a middleware standard from aerospace and defence. That brought real-time-friendly behaviour, configurable quality of service, security hooks, and multi-platform support — and it brought DDS's configuration surface along with it.

Quality of service is the part that most often surprises people coming from ROS 1. Reliability, durability, history depth and deadline are now per-topic settings, and a publisher and subscriber with incompatible settings will simply not communicate, silently. That is correct behaviour and a frequent source of lost hours.

Fast DDS has been the default implementation for over a decade, with alternatives available where licensing or performance characteristics call for them.

Releases and support

ROS 2 ships a new distribution each May, named alphabetically. Even-year releases get long support, odd-year releases get a shorter window.

Humble Hawksbill — May 2022, supported to May 2027. Still widely deployed in production precisely because of that window.
Iron Irwini — May 2023, ended November 2024.
Jazzy Jalisco — May 2024, supported to May 2029.
Kilted Kaiju — released 23 May 2025, support ending November 2026.
Lyrical Luth — May 2026, the current distribution.
Rolling Ridley — continuously updated development line, where breaking changes land first.

The practical advice is boring and correct: build production systems on a long-support release, because the cost of a forced migration mid-deployment exceeds whatever the newer distribution offered. Check docs.ros.org for the live list — a static page cannot stay current against an annual cadence, and this one will go stale.

What ROS 2 solved

Coordination. Components from different authors can exchange data without bilateral agreements.
Reuse. Drivers, planners, localisation, visualisation and simulation bridges exist and are shared rather than rewritten.
A common vocabulary. Standard message types mean "a point cloud" means the same thing between teams.
Tooling. Recording and replaying data, introspecting a live graph, and visualising state are solved problems rather than per-project work.
Training. A large number of engineers already know it, which is a genuine commercial advantage.

What it was never designed to solve

This is the part that matters for anyone assuming middleware answers more than it does.

It is not safety. A ROS 2 topic is not a safety function. Safety-rated behaviour lives in independent, rated paths — not in application code that publishes a stop message and hopes.
It does not make capability portable. Two robots can both speak ROS 2 and share nothing about what a capability assumes. Message compatibility is not behavioural compatibility.
It does not make reliability comparable. There is no standard way to state how well a component works, under what conditions, with what failure behaviour.
It does not answer responsibility. When a composed system does the wrong thing, nothing in the middleware establishes who owns the consequence.
It is not an operations platform. Versioning across a fleet, staged rollout, rollback, and knowing precisely what is running on which machine are outside its scope.
Determinism is not free. Real-time behaviour requires deliberate work on executors, scheduling, memory and the underlying operating system. Using ROS 2 does not confer it.

Why that distinction matters

Common middleware solved a coordination problem thoroughly enough that it stopped being the bottleneck, and the field moved on to the problems above. Those are harder, because they are about assurance and accountability rather than about message passing, and they do not have an obvious technical fix.

Anyone proposing a shared software layer for robotics now is proposing to address that second set. Pointing at ROS 2 and saying the problem is solved mistakes the plumbing for the building.

Is ROS 2 the right choice for production?

The question usually arrives framed as ROS 2 versus a proprietary stack, and the honest answer is that the trade is about where you want your engineering to go.

The case for it: a very large body of existing components, engineers who already know it, excellent debugging and data-recording tooling, no licence cost, simulation integration, and no vendor whose commercial direction can strand you.

The case against it: the surface area is enormous, quality across community packages is uneven, you own the integration and the long-term maintenance, real-time behaviour requires deliberate work rather than arriving by default, and nobody is contractually responsible when something misbehaves.

What most serious deployments actually do is neither extreme: ROS 2 for perception, planning, orchestration and tooling, with the safety-rated and hard-real-time paths implemented outside it on the manufacturer's own controller. That split follows the responsibility boundaries rather than fighting them, and it is why the question of "which middleware" matters less than the question of which layer owns which guarantee.

Practical notes

Match quality of service settings explicitly rather than relying on defaults, and check them first when two nodes are not talking.
Keep the transform tree shallow and its publishers authoritative. Most localisation confusion is a transform problem.
Record data from day one. A system without recorded sessions cannot be debugged after the fact.
Treat the DDS layer as a real dependency with real configuration, not as an implementation detail.
Pin the distribution and the dependency versions. "It worked on my machine" in robotics usually means a different ROS version.

Sources

Putting this into practice on a real robot: the integration requirements checklist asks for the distribution, driver and interface details by name.

ROS 2 and robotics middleware