Introducing Maps to the VDA 5050 in Version 2.1.0

[KIT-IFL]

Update from the VDA 5050 team on Maps

For some time now, the VDA and VDMA team has been planning to extend the VDA 5050 communication standard to include the topic of map exchange. In a joint workshop it was determined that it is not possible and not in the sense of VDA 5050 to define the format of the exchanged maps. It was decided to only include the process of downloading and updating maps in the standard. For the release of version 3.0 (TBD) the following changes are currently planned, which can already be seen in the development branch since pull request #155:

• Two new action definitions downloadMap and deleteMap have been added. Action states have also been defined for these two actions.
• The action initPosition has been adjusted and should be used to initialize vehicles on a new map. A description has also been added.
• In the order message the corresponding information about maps has been added (e.g. optional parameter mapVersion).
• In the state of a vehicle, the maps[map] field, consisting of map JSON elements, contains information about all maps available on a vehicle.

Each map is uniquely identified by its mapId. In addition, a map may optionally contain information about its version number in mapVersion.

Questions about maps can be discussed in this topic. We will also keep you informed about further developments of the VDA 5050 team.

[nv-delliott]

This is a very good extension to the standard to replace & unify bespoke mapping implementations. Some comments below:

• mapAddress is mispelled as mapAdress

• mapDescription is present in the object structure, but not the download parameters. Should that be?

• mapHash - will the spec be specific on how this is to be used: eg sha1 of binary map data, or open to interpretation?

• One aspect to consider is larger facilities have complex maps that are too memory intensive for a single AMR/AGV. A common way to work around this is by splitting their map into smaller tiles. eg, mapId == "facility A", mapVersion == 2 , but also N tiles which the master control can selectively distribute. Suggest adding: **tileId** string optional. This will avoid the practice of overloading mapId with a complex struct.

• A performance optimization can be for downloadMap action and deleteMap actions to accept maps[map].

[srijan]

One more suggestion for larger maps (that we needed to use in our implementation to make map propagation faster) is to send a compressed map.

For this, I suggest adding a mapCompression parameter to the downloadMap instant action so that the AGV knows how to decompress the map after downloading.

[AntonDueck]

One more suggestion for larger maps (that we needed to use in our implementation to make map propagation faster) is to send a compressed map.

For this, I suggest adding a mapCompression parameter to the downloadMap instant action so that the AGV knows how to decompress the map after downloading.

I think, as there will be not a MapsServer providing a map to every Vehicle Type exits. You are free to Provide Compress Maps, as your vehicle knows your provide a compressed map, so there is no need of an extra parameter mapCompression

[ConstantinUp]

The changes are incorporated in the release candidate dev/2.1.0 and can be viewed in the PR #285.