ROS 2 in production: what a robot fleet taught us

The context

Robotics is one of our four areas of expertise, on the same level as web, data, and cloud. We talk about it less because it’s seen less. Yet it’s where code meets the physical world, and where an error can’t be fixed with a rollback.

On an autonomous navigation project for a fleet of industrial robots (Tokyo hub, ROS 2 and vision), we drew lessons that hold beyond that specific project.

Six lessons from the field

1. ROS 2 is not ROS 1 with a higher number. The move to DDS for communication changes everything about reliability and network configuration. Underestimating it is costly.
2. Real-time is designed in, not retrofitted. Real-time constraints must guide the architecture from day one. You don’t “make a system real-time” when it was designed without it.
3. Simulation is not reality. A behavior validated in simulation fails in the field for trivial reasons: light, dust, uneven ground. Physical testing remains irreplaceable.
4. A fleet is not one robot multiplied. Coordinating several robots introduces its own problems: path conflicts, zone sharing, recovery after one unit fails.
5. Observability applies to robots too. You want to know what a robot “saw” and “decided” at a given moment. Without usable logs, debugging becomes an investigation.
6. Edge and cloud, each its role. The critical decision stays on the edge, close to the sensor. The cloud is for analysis, training, supervision. Mixing the two creates latency where you can’t afford it.

The anti-patterns

Designing without real-time constraints and adding them later. Validating everything in simulation. Treating a fleet like an isolated robot. Putting the critical decision in the cloud. We’ve encountered them all — sometimes on our own side, before fixing them.