Running Many Robots as One System: Multi-Robot Fleet Orchestration with Open-RMF and VDA 5050

With one or two robots in a warehouse or hospital, the vendor’s management screen is enough. Once robots from different vendors share aisles and lifts, you need a fleet layer that decides which robot takes which job and who goes first. This article explains the two most common building blocks for that layer, VDA 5050 and Open-RMF, from their official documentation, and calculates how control traffic grows with fleet size.

Three jobs a multi-robot fleet layer does

With a single vendor, that vendor’s fleet manager does all three. The trouble starts with mixed brands. MiR’s own explanation notes that mixed-vendor fleets can create complex traffic situations and that a common control source simplifies operating them.

The data loop that keeps improving models in the field is covered in our article on robot fleet MLOps. This article sits one layer below: coordinating robots that are moving right now.

VDA 5050: a common language between robots and fleet control

VDA 5050 is the interface defined by the German Association of the Automotive Industry (VDA) for communication between mobile robots and a fleet control. The latest published version in the GitHub repository is 3.0.0. Transport is MQTT, with MQTT 3.1.1 as the minimum version, and messages are JSON.

Source: VDA 5050 specification v3.0.0

An order carries two lists, nodes and edges, and the number of edges must equal the number of nodes minus one. Released nodes and edges form the base; unreleased ones form the horizon. Fleet control can show a robot its horizon while extending the base step by step, which is one way to sequence robots through a junction. A trimmed example:

{
  "orderId": "pick-0412",
  "orderUpdateId": 0,
  "nodes": [
    {"nodeId": "dock-A", "sequenceId": 0, "released": true},
    {"nodeId": "aisle-3", "sequenceId": 2, "released": true},
    {"nodeId": "shelf-17", "sequenceId": 4, "released": false}
  ],
  "edges": [
    {"edgeId": "dock-A_aisle-3", "sequenceId": 1, "released": true},
    {"edgeId": "aisle-3_shelf-17", "sequenceId": 3, "released": false}
  ]
}

Fields are trimmed to show the structure; the required fields and schemas live in the repository’s json_schemas folder. Per the spec, a robot’s state message is published when relevant events occur or at least every 30 seconds.

Open-RMF: a coordination layer over several fleets

Open-RMF is an open-source platform for managing multiple fleets together. It is built on ROS 2, supports the Humble, Jazzy, Kilted and Rolling distributions, and is licensed under Apache-2.0. A number of commercial robots, building systems and workcells have already been integrated, and a new fleet connects through an adapter started from fleet_adapter_template.

If VDA 5050 defines what one robot and its fleet control say to each other, Open-RMF sits above that, coordinating paths and shared infrastructure across different fleets. The ROS 2 multi-robot guide describes adapter integration levels:

• Full Control: RMF specifies the explicit paths robots follow and can interrupt and replace them; robot positions update live.
• Traffic Light Control: RMF can only pause and resume each robot; the vendor system chooses the path.

The lower the integration level, the coarser traffic management becomes. With many pause/resume-only robots, RMF has to stop robots earlier and more often to avoid conflicts.

The two work at different layers rather than competing. A site can run VDA 5050 robots under a VDA 5050 fleet control while a separate layer handles building infrastructure and coordination with other robot families.

Calculating control message load by fleet size

Load on the fleet server and MQTT broker can be estimated from robot count, message rate and message size. Using only the spec’s minimum rate badly understates it, so calculate an operating assumption alongside it.

robots = 50

# 1) Spec minimum: state at least every 30 s (VDA 5050 v3.0.0)
min_msgs_per_s = robots / 30
print(round(min_msgs_per_s, 2))          # 1.67 msg/s

# 2) Operating assumption: state 1 Hz (2 KB), visualization 10 Hz (0.5 KB)
state_hz, state_kb = 1, 2.0
vis_hz, vis_kb = 10, 0.5
msgs_per_s = robots * (state_hz + vis_hz)
mbit_per_s = robots * (state_hz * state_kb + vis_hz * vis_kb) * 1024 * 8 / 1e6
print(msgs_per_s, round(mbit_per_s, 2))  # 550 msg/s, 2.87 Mbit/s

For the same 50 robots, the spec minimum (about 1.7 messages per second) and the operating assumption (550 per second) differ by more than 300×. Message sizes and rates depend on the robot vendor and fleet software settings, so replace these assumed values with the message counts and sizes your broker actually records during a pilot.

Two practical consequences follow. First, the broker and network should be sized from the operating case, with headroom for robots reconnecting after a Wi-Fi drop, when many connection and state messages arrive at once. Second, the visualization stream is optional in the spec; if a dashboard only needs a refresh every second, lowering its rate is the cheapest way to cut load.

Five things to confirm with robot and fleet-software vendors

1. Supported VDA 5050 version and actions: fields and behavior differ between versions.
2. Integration level: whether paths can be set (Full Control) or only pause/resume (Traffic Light).
3. Shared infrastructure: whether the fleet layer can control doors, lifts and chargers.
4. Message rates and sizes: how many Hz state and visualization run at, and how many KB each message is.
5. Behavior when control is lost: whether robots stop immediately or finish the current task.

The fleet size and operating conditions you settle here feed directly into our warehouse and factory robot TCO and ROI model. For the order in which humanoids are entering real sites, see humanoid first deployments.