“Where does the map actually live?” is the question that almost never appears in a tender and almost always during commissioning. Yet one of the most elegant ideas behind VDA 5050 was exactly that: making the map on the robot unnecessary. The master control holds all the information, and the robot receives its route along with the order. In practice, we have barely seen anyone implement it that way. This post looks at why the map stayed, how many maps a mixed fleet carries, since when the standard governs them, and what happens when a robot stops. The fundamentals are in our guide to VDA 5050.
The founding idea: trajectory instead of map
VDA 5050 transfers an order as a sequence of nodes and edges, and an edge can carry a trajectory. A robot can therefore reach its destination without knowing the overall layout. The logic moves from the bottom upwards: the master control knows what the hall looks like, the robot knows what to do next.
Anyone who has commissioned 50 mobile robots knows why that is appealing. Without an automated distribution path, a maintained map per robot is not a detail but a commissioning problem.
Spelled out like this, it appears nowhere in the standard, which only assigns responsibilities. It is our reading of the early versions, backed by seeing individual manufacturers implement exactly that.
Why the map stayed anyway
In most of the projects we know, both are present: a map on the robot and a path specification from above. There are four understandable reasons for that.
- The robot needs more than the interface carries. Switching safety fields, the reference between a node and physical markers on the floor such as QR or grid codes, speed zones covering whole areas instead of edge by edge. The protocol had no place for any of it.
- A map update is manual work. Connect, find the directory, copy the map over, restart the software: one to two minutes per robot, for every node that gets moved. Across larger fleets that adds up to hours per layout change.
- That is why the map usually comes from the robot manufacturer. It can then be edited and swapped on site during fine-tuning instead of routing through the master control.
- A map rarely belongs to exactly one robot. Robots of the same type from the same manufacturer tend to work on the same map, while a forklift next to them brings its own.
A mixed fleet carries several map worlds side by side, each with its own format and update path. Maintenance happens per map world, distribution robot by robot.
This is explicitly not a failing on the manufacturers’ part. The map is not a legacy artefact but a functional necessity: it carries what the interface did not. That field knowledge flowed back into the standard through the working groups.
In short: The real question is not whether the robot has a map, but who maintains it, and by which route it stays current.
The map has been official since version 2.1
The standard caught up, and earlier than most assume. With version 2.1.0, released on 19 August 2024, the map became an object of its own in the protocol: the robot reports its maps in state with mapId, mapVersion and mapStatus, and the master control manages them via the actions downloadMap, enableMap and deleteMap (specification 2.1.0). The same version brought corridors, within which a robot may deviate from its path.
Two details matter in practice. Alongside the mapId, downloadMap carries a mapDownloadLink: the map sits on a map server and is fetched from there rather than travelling through MQTT. That is precisely the automated distribution path missing above. And only the master control may delete. The robot reports when its memory runs out, but the specification does not permit it to remove a map itself.
What gets standardised is the lifecycle: transfer, activation and deletion. The content stays out of it, and the standard defines no file format. That is distinct from the Layout Interchange Format (LIF), which the standard names as the import path for route networks. Both usually come from the same source at the robot manufacturer but go to different recipients. LIF is what the master control needs to send a robot from A to B: nodes, edges, stations, permitted speeds, orientations. The map is the robot’s own world model. LIF travels upwards, the map stays down.
Version 3.0.0 of 18 March 2026 then moves in a different direction: zones for freely navigating robots, and path sharing, where the robot plans its own path and shares it upwards (release 3.0.0). That inverts the founding idea. To us it is not a step backwards but an architectural question: keep both sides synchronised automatically and you get both advantages. Robustness when the fleet manager is offline, and still the change that applies to 30 robots at once.
When a robot stops: the fallback layer
If a robot leaves the permitted navigation space, the standard requires it to stop and report an error of type OUTSIDE_OF_CORRIDOR with level CRITICAL. How it finds its way back into the order is not governed.
That is where the gap to expectations opens up: the standard assumes the master control can compute a way back. In practice the robot has to be close enough to a node before it can accept an order, so it gets pushed or driven there. In MANUAL mode it moves under direct human control, steered with a controller.
Except that this controller almost always sits with the robot manufacturer. So the logic did not fully move upwards after all: the fallback layer stayed at the bottom. In one project we used an off-the-shelf game controller for it, and honestly, it was not safe. On connection loss it kept sending, and an automatic stop had to be retrofitted.
What this means for planning
Three questions follow, and hardly any tender contains them: where does the map live, and who maintains it? How does a layout change reach 30 robots without someone walking up to a device 30 times? And with several manufacturers: how many map worlds appear, and who keeps them apart? All three can be settled before the award and written as acceptance criteria.
The more expensive question is untouched: does this layout carry this fleet under peak load? Simulation answers it before a single robot is ordered. Ours is graph-based: nodes, edges, corridors and zones as LIF and VDA 5050 describe them, not the robot’s internal path planning. For structured intralogistics that is the right modelling depth. Dispatching in live operation stays with fleet management. We complement it, we do not replace it.
Conclusion: the map is an architectural decision
- The founding idea is strong, but we have barely seen it implemented. The map carries safety fields, marker references and zones the protocol did not transfer.
- A mixed fleet does not have one map but several map worlds side by side. The second manufacturer brings its own.
- Version 2.1 acknowledged this and has governed the lifecycle of the map since August 2024, not its content. Distribution runs via a map server, deletion only via the master control.
- Path sharing in version 3.0 inverts the founding idea. Keep both sides in sync and you gain robustness and speed of change.
- The fallback layer in a fault case sits with the robot, almost without exception. Not planning for it means not planning for the most expensive day of the project.
Planning a fleet of mobile robots, or extending an existing one with a second manufacturer? In a free initial call we work out which of these questions are still open for your layout. Get in touch.
About the author
Tim Nowak
Tim Nowak is co-founder and Managing Director of ScaliRo GmbH. He supports operators, manufacturers and integrators with vendor-independent planning and simulation of mobile robot fleets.
LinkedIn
