E · System design challenge 6

Challenge 6: Multi-Robot Fleet Deployment

Ten robots share one building. What happens when the Wi-Fi drops, a robot dies, or an update goes wrong?

Uses modules 13, 18, 19, 20
ROS 2 Jazzy

1. Problem statement

A site runs a fleet of autonomous mobile robots sharing aisles, doors and chargers. The deliverable is an architecture (what lives on the robot and what on the server), a network design, task allocation and traffic rules, monitoring and update procedures, and evidence from tests (including failures) that the fleet meets a stated throughput and availability.

2. Constraints

Safety and local avoidance work without the server and without the network.
The network design handles roaming and loss: ROS 2 domain and discovery settings, QoS and message sizes are chosen deliberately.
Task allocation is global (not first come first served) with battery and capability constraints.
Shared resources (doors, lifts, corridors, chargers) have reservations and deadlock handling.
Updates are staged and reversible; maps, configuration and software are version-compatible.
Telemetry is buffered and defines availability and success metrics with owners for every alert.

3. Architecture

WMS / operators ─▶ fleet server (tasks, traffic, monitoring, updates) ─Wi-Fi─▶ robots (navigation, safety, local autonomy)
robots ─ buffered telemetry ─▶ metrics, outlier detection, alerts

Item	Decision to make
Architecture	Centralised, decentralised or hybrid; what works offline
Network	Domain IDs, discovery range, QoS, bandwidth, coverage
Allocation	Global assignment with costs and constraints
Traffic	Reservations, passing places, deadlock handling
Operations	Monitoring, updates, rollback, incident analysis

4. Implementation stages

Architecture. Decide what lives where and what happens when the server is down (fleet architecture and task allocation).
Networking. Configure domains and discovery, tune for large messages, and diagnose cross-computer problems (troubleshooting page, ros 2 qos intra process communication and executors).
Navigation and safety. Nav2 configuration and safeguards on every robot (configuring nav2, operational safeguards vs safety rated functions).
Traffic. Reservations and conflict resolution (traffic management and conflict prevention).
Monitoring. Health metrics and outlier detection (remote monitoring and health metrics).
Updates. OTA, configuration and staged rollout (ota updates and configuration management, production deployment and rollback).
Failure analysis. Fleet-wide diagnosis (diagnosing fleet wide failures).
Validation. Throughput and availability with intervals, plus failure drills (trials and intervals, benchmarking the complete system).

5. Validation criteria

With the server and the network cut, every robot stops or continues safely for the defined time and no collision occurs.
Throughput and task success meet the requirement with a 95 % lower bound over a multi-day run.
A staged update with an injected fault rolls back automatically and the fleet is restored within the target time.
Incident analysis normalised per robot identifies a seeded common factor (version or site) correctly.

6. Engineering trade-offs

Centralised planning vs robot-side negotiation: optimality against resilience.
Single vendor vs vendor-neutral fleet platform: integration effort against lock-in (see Open-RMF).
Dense fleet vs delays: utilisation against congestion.
Fast rollout vs safe rollout.

References

Tools and guides for this challenge are linked in the stages. Sources used by those guides include the Open-RMF README, the ROS 2 Jazzy domain, discovery and QoS documentation and the Nav2 documentation, read 2026-11-06. This challenge is a design task.