ROS 2 in Production: Distro, Middleware and QoS Decisions

Q: Which ROS 2 distribution should a production robot fleet run in 2026?

A long-term support release, pinned across the whole fleet, with the migration to the next LTS planned before the current one reaches end of life. In 2026 the choice for a new fleet is between Jazzy Jalisco, released May 2024 and supported until May 2029, and Lyrical Luth, released on 22 May 2026 and supported until May 2031. Lyrical is the target when every third-party package the robot needs (sensor drivers, navigation, hardware interfaces) has a released binary for it, because the five-year runway matters; Jazzy is the safe fallback when two or three of those packages are still source-build-only. Humble Hawksbill reaches end of life in May 2027 and should not host new fleets, Kilted Kaiju is non-LTS and ends in December 2026, and Rolling Ridley is the development distribution where the next release is assembled and should never run on a shipped robot. The ROS 2 documentation does not guarantee communication between nodes built against different distributions, so a fleet is homogeneous per distro and migration is a staged fleet operation with rollback.

Q: Should a ROS 2 fleet use Fast DDS, Cyclone DDS, Connext or Zenoh?

For a single robot on a wired internal network, the default Fast DDS or Cyclone DDS is fine and the choice is unimportant. For anything that crosses Wi-Fi, a site network, a VPN or a cloud boundary, the choice is the architecture. DDS discovers participants by multicast on the local segment, and on a warehouse wireless network with dozens of robots each running dozens of nodes the announcement traffic degrades the access points and produces slow discovery, flapping topics and dropped sensor frames. Fast DDS's discovery-server mode replaces multicast with a known server and is the first fix within DDS. Zenoh, a Tier 1 middleware for ROS 2 since Kilted Kaiju in May 2025, removes the assumption: each robot's session connects to a router, routers peer across sites, the network sees unicast flows, and the ROS documentation notes Zenoh has essentially no incompatible QoS settings. Connext is the commercial option for teams buying support, with the caveat that the ROS binaries support only its standard desktop variant. Whatever is chosen, use one RMW implementation per graph, fixed in the robot image.

Q: Why does a ROS 2 subscriber sometimes receive nothing with no error?

Almost always because of incompatible quality-of-service profiles. QoS is negotiated per publisher and subscriber pair across policies such as reliability, durability, history depth, deadline, lifespan and liveliness, and the ROS 2 documentation states that when a requested profile and an offered profile are incompatible the connection is not made and messages are not delivered. The classic field case is a sensor driver publishing best-effort, which is correct for a lidar or camera stream, and a downstream node written against the default profile requesting reliable delivery. Nothing errors; the callback never fires, and the developer who tested against a bag file never saw it because the bag player used its own profile. The fixes are to use the sensor-data profile for sensor streams and reliable, transient-local durability for maps and commands, to subscribe to the incompatible-QoS event callbacks and log them at error level with the topic name, to define profiles in the interface package next to the message type, and to add a CI test that launches the real graph on the production RMW and fails if any topic has zero matched endpoints.

Q: How do executors and composition affect CPU and latency on a robot?

They are the process model, and the defaults are the most expensive combination: one process per node, a single-threaded executor and inter-process transport. The single-threaded executor spins one thread over all of a node's callbacks, so a slow callback delays everything behind it. The multi-threaded executor adds parallelism only as far as callback groups permit, and a reentrant group is a correctness decision rather than a performance one. The events-based executor processes events as they arrive instead of polling the wait set, and Lyrical Luth adds an asyncio-based node class in the Python client library whose release notes describe it as using significantly less CPU than the default executor. Composition loads nodes as components into a shared container process, enabling intra-process communication in which a published message is handed to the subscriber as a pointer; for camera frames of several megabytes at 30 frames per second, that is the difference between a saturated core and an idle one. Compose by data flow: nodes that exchange large messages share a process, nodes with different failure domains do not.

Q: What are ROS 2 lifecycle nodes and why do production fleets need them?

Lifecycle, or managed, nodes expose explicit states (unconfigured, inactive, active, finalised) and the transitions between them, so that a supervisor can configure every node in the graph, then activate them in dependency order, rather than letting every node start at once and retry until its inputs appear. Without lifecycle management, a fleet reboot is a race: the navigation stack may activate before the localisation node has a map, log a wall of warnings, and converge on some reboots and not on others, which is why the same robot behaves differently after every power cycle. With lifecycle management, the robot has a deterministic bring-up sequence that a fleet manager can drive, a health check can observe and a test can assert. Real-time control loops with actuation deadlines in single-digit milliseconds additionally need a real-time kernel, memory locking and no allocations in the control path, and should be isolated into their own composed process on their own cores rather than imposed on the whole graph.

Q: Is ROS 2 traffic encrypted, and how do you secure a robot fleet's communication?

By default it is not, and most deployed fleets run without it. SROS2 places DDS-Security underneath ROS 2: the tooling generates a keystore, creates an enclave for each node carrying its own key, certificate and permissions over which topics it may publish and subscribe, and runs in either enforce mode, which rejects unauthenticated participants, or permissive mode, which allows them while the configuration is validated, the right first step for a fleet migrating to security. Support varies by middleware vendor and distribution, so the RMW decision has a security consequence that should be confirmed before committing. Zenoh carries its own transport security and authentication at the router and session level rather than DDS-Security, making the router the control point. Where to start is a threat-model question: if robots share a network segment with anything the team does not control, the command and teleoperation topics need authentication before anything else, because a readable lidar stream is a privacy issue and a writable velocity topic is a safety one.

Q: What should ROS 2 not be used for in a production robotics system?

Three things. It is not a fleet-management protocol: fleet state, task assignment, telemetry to the cloud and software updates are request-response and event-stream problems over unreliable wide-area links with authentication, and the right tools are HTTP or gRPC APIs, MQTT and a signed, staged update pipeline; bridging a ROS graph across a VPN reproduces every discovery and QoS problem at continental latency. It is not a safety-rated controller: ROS 2 nodes, executors and middleware are not certified components, so the function that stops the robot when a person steps into its path runs on a certified controller with its own sensors and stop circuit, and the ROS graph is a client of that controller rather than its implementation. And it is not an observability platform on its own: a fleet needs a per-robot health model of named signals (topic rates, matched endpoints per topic, executor latency, CPU per composed process, discovery time at boot) exported off the robot and alerted on, or it is a fleet debugged by driving to it.

Q: What is a realistic maturity path for a ROS 2 fleet moving from lab defaults to production?

Five stages, each writing down one contract the lab left implicit. Stage 0 is lab defaults: Fast DDS multicast, default QoS, single-threaded executors, one process per node, whatever distro the laptop had. Stage 1 pins: an LTS distro with its end-of-life date on the roadmap, the RMW fixed in the robot image rather than the shell, and a dependency inventory listing every third-party package's release status for the next LTS. Stage 2 contracts: QoS profiles defined per topic in the interface packages, a CI graph test asserting matched endpoints on the production RMW, incompatible-QoS events logged at error level, and nodes composed by data flow with intra-process transport on the perception path. Stage 3 operates: lifecycle-managed bring-up, a per-robot health model exported off the robot, discovery servers or Zenoh routers per site with their own monitoring, and a staged, signed update pipeline with rollback for the distro migration. Stage 4 secures and isolates: enclaves or Zenoh authentication enforced, the robot's network interface as the architectural boundary with a curated API beyond it, and the safety function on a certified controller the graph talks to but does not implement.