ROS 2 in Production: What Changes When You Move From Research Lab to Robot Fleet

What actually changes when ROS 2 goes into production?

The short answer: almost nothing changes in the code, and almost everything changes in the assumptions around it. A research build of ROS 2 optimizes for iteration speed — one robot, one operator, a Wi-Fi network you control, and a human ready to Ctrl+C a broken node. Production robotics optimizes for the opposite: dozens or hundreds of robots, no operator standing next to any of them, unreliable RF environments, and a requirement that failures degrade gracefully instead of hanging the whole stack. The middleware layer — DDS by default — is where most of that tension shows up first, because DDS was designed for flexible discovery and quality-of-service tuning in trusted networks, not for silent, self-healing behavior across a warehouse full of overlapping radios.

Everything below is about the gap between those two worlds, and the specific decisions teams have to make to close it.

Why does DDS behave differently in a lab than on a fleet?

DDS (Data Distribution Service) is the default middleware that ROS 2 nodes use to discover each other and exchange messages, and it was inherited more or less intact from industrial and defense systems that assumed a stable, segmented network. In a single-robot lab setup, DDS discovery — where every node broadcasts itself and builds a mesh of publishers and subscribers — is nearly invisible. You launch a few nodes, they find each other in milliseconds, and you move on.

Put twenty robots on the same subnet, or run several robots through the same warehouse Wi-Fi access points, and the picture changes. DDS discovery traffic scales in a way that punishes dense deployments: every participant is, by default, trying to discover every other participant, which means multicast storms, discovery timeouts, and nodes on Robot A occasionally picking up traffic meant for Robot B if network segmentation isn’t airtight. Quality-of-service settings that were left at their defaults in the lab — reliability, history depth, deadline — start to matter enormously once bandwidth is shared and radios roam between access points.

This is precisely the pressure that has pushed the ROS 2 ecosystem to treat middleware as a real architectural choice rather than a fixed default. Open Robotics introduced rmw_zenoh, a Zenoh-based middleware implementation, as an officially supported alternative to DDS-based middlewares starting with the Jazzy Jalisco release, with its first full release targeted for Kilted Kaiju in May 2025. Zenoh was built from the ground up for the kind of constrained, large-scale, sometimes-disconnected networking that fleets actually operate under — which is exactly the profile DDS struggles with at scale. It’s worth being precise here: DDS remains the default middleware for ROS 2, and rmw_zenoh is an alternative you opt into, not a replacement that has taken over. But the fact that a fleet-oriented option now exists as a first-class citizen in the ROS 2 ecosystem is itself a signal of where the pain points are.

Which ROS 2 release should a production fleet actually run?

This is less obvious than it sounds, because ROS 2 ships new distributions on a predictable cadence and not all of them are meant for long-term deployment. The distinction that matters for a fleet is LTS (Long Term Support) versus standard release.

Distribution	Release date	Type	Supported until
Jazzy Jalisco	May 23, 2024	LTS	End of May 2029
Kilted Kaiju	May 23, 2025 (11th distribution)	Standard	November 2026
Lyrical Luth	May 2026 (12th distribution)	LTS	May 2031

Jazzy Jalisco’s Tier 1 platform support includes Ubuntu 24.04 Noble Numbat on both arm64 and amd64, plus Windows 10 — a combination that matters for fleets running mixed compute, from onboard arm64 SBCs to amd64 edge servers. Kilted Kaiju, by contrast, is a standard release with a much shorter support window, ending in November 2026, which makes it a reasonable choice for teams that want to track newer features (including the maturing rmw_zenoh support) but a risky one for a fleet you intend to leave running for years without a forced upgrade cycle.

For a robot fleet specifically, the practical rule is simple: default to the LTS distribution unless there’s a concrete feature in a standard release you need now, and budget the migration to the next LTS well before support runs out — five-year windows sound long until you’re mid-fleet-rollout and the clock is at eighteen months.

What breaks first when you scale from one robot to a fleet?

A few failure modes show up almost every time, and they show up in roughly this order.

Network discovery collapses under density. As described above, DDS discovery traffic doesn’t stay flat as robot count grows — it grows with it, and on shared Wi-Fi it can start competing with the bandwidth robots need for telemetry, video, and control. Teams typically respond with network segmentation (separate SSIDs or VLANs per robot or per zone), tuned discovery ranges, or a move to a middleware built for this pattern.

Logging and diagnostics stop being something you can tail -f. In the lab, a crashed node means reading a terminal. In the field, it means a robot two buildings away silently degraded three hours ago, and the first anyone hears of it is a missed pick or a stalled route. Fleets need centralized log aggregation, structured diagnostics, and health telemetry that’s designed to be queried after the fact, not watched live.

Configuration drift becomes a real problem. One robot with a hand-tuned parameter file is fine. Fifty robots, each with slightly different parameter overrides accumulated over months of field tweaks, is how fleets end up with behavior nobody can fully explain. This is one of the core reasons fleet operators lean on version-controlled, declarative configuration and staged rollouts rather than SSHing into machines — the discipline that RobotOps exists to formalize.

Time synchronization and QoS mismatches cause intermittent, hard-to-reproduce bugs. A subscriber with a different reliability or history setting than its publisher will silently drop messages instead of throwing an error, and that kind of mismatch is far more likely to surface only under field network conditions than on a lab bench.

How do real fleets actually handle this?

Dexory, a warehouse robotics company, offers a concrete example of ROS 2 running at fleet scale rather than as a lab demo. Its autonomous warehouse-scanning robots are built on ROS 2 together with the Nav2 navigation stack, developed under Dr. Marcus Schuenemann, who as Head of Autonomy oversees scalable autonomy development. The exact current size of Dexory’s deployed fleet is reported inconsistently across sources — one account puts it at more than 200 units in production globally, while an earlier company statement described scaling “from zero to 90 robots” around the time of its Series B — and the discrepancy likely reflects different points in time rather than a contradiction, but it hasn’t been independently confirmed at the higher figure, so it’s worth treating as a range rather than a fixed number.

What is well documented is the company’s momentum: Dexory raised $165 million in a round announced October 14, 2025, structured as $100 million in equity led by Eurazeo’s Growth team, with participation from LTS Growth, Endeavor Catalyst, and existing investors Atomico, Lakestar, Elaia, and Latitude Ventures, plus $65 million in debt financing from Bootstrap Europe. CEO Andrei Danescu has framed the raise around scaling an AI-powered warehouse intelligence platform — the kind of expansion that only works if the underlying robotics stack, ROS 2 and Nav2 included, can absorb fleet growth without a rewrite. That’s the practical test of “production-ready”: can the same software stack that ran three robots in a pilot run three hundred without falling over.

What should a team building toward production actually prioritize?

Treat middleware as a decision, not a default. Know whether you’re running DDS or rmw_zenoh, know why, and understand the network topology your robots will actually operate in before you assume the lab configuration will hold. If robots roam across access points or operate with intermittent connectivity, this decision deserves real evaluation time, not an assumption inherited from the demo.

Pin an LTS distribution and plan the upgrade path before you need it. Jazzy Jalisco’s support through May 2029 or Lyrical Luth’s through May 2031 gives a fleet years of runway, but only if the upgrade from whichever distribution comes next is planned rather than forced by an end-of-support deadline arriving mid-deployment.

Build observability for absent humans. Centralized logging, health dashboards, and automated alerting aren’t nice-to-haves for a fleet — they’re the only way anyone finds out a robot is misbehaving before it becomes a support ticket or a safety incident.

Validate in simulation before every field rollout. The gap between “works on the bench” and “works in the warehouse” is exactly what pushes teams toward heavier investment in simulation and digital twin environments — testing network conditions, edge cases, and multi-robot interactions before they hit real hardware.

Instrument for the data you’ll actually need later. Fleets generate far more operational and sensor data than any single lab robot, and decisions about what to log, how to structure it, and how to feed it back into model improvement are tied closely to how a team approaches teleoperation and data collection at scale.

None of this replaces the fundamentals covered in the broader Physical AI stack — perception, planning, and control still have to work. What production adds is a second, parallel job: keeping that stack alive, observable, and consistent across every robot running it, all day, without anyone standing next to the hardware.

Seen through an agent lens, this same DDS/ROS 2 middleware layer is doing double duty as a safety-critical harness — the thing standing between a planning decision and an actuator actually moving. Agentic engineering for physical AI covers that role in more depth, and why it doesn’t reduce to the harness patterns teams already use for software-only agents.