The definition of "instant action" is misleading. It is stated that these actions have to be activated "immediately". The meaning of "immediately" is missing. Adittionally we experienced in our applications that so called "Actions" also need to be sent as instant actions in specific situations (see example below).

Proposal: Definition of "instant action" as actions which are not bound to a node or an edge. In general all standardized actions of the standard can be used bound to node/edge or been sent directly to the AGV e.g. when the AGV is not moving. The AGV may deny actions being sent as instant actions when the local AGV state does not allow the execution of an action (e.g. when the AGV is moving, when AGV has not enough energy etc.).

Example: Pick/Drop is used to load/unload a parcel onto the AGV and according to the standard only allowed bound to node/edge. In our applications AGVs are located at a station and waiting for orders. If at this station where the AGV is waiting a parcel arrives it would not be possible to pick this parcel with PICK action without moving the AGV. In our application we defined now PICK also as instant action. The standard should allow all actions arbitrarily been selected as action or instant action. The distinction between those two use cases is misleading.

Original change request:

• The idea of DS was to add a field agvType (string) to the topic state
• The information of this field can be used by a supervisor to identify the type/capabilities of a new/unknown AGV and compare it with an internal database => The orders and instantActions can be created accordingly.
• As the field is in the topic state it can change during runtime and therefore can be used to cover changes of the AGV load handling capabilities (e.g. a forklift AGV picks up a conveyor-unit => it is still not loaded; it can handle now a different type of loads)

Summary of GoTo-Meeting discussion on 2021.01.14:

• The information planned to transport with the one field will be covered by two separate fields.
• The field agvType should be static and therefore transferred to the topic connection.
• The information on the current load-handling capabilities of the AGV will be covered by additional fields in the load-handling-section (TODO: separate GitHub-Issue)

Hello!

Consider the following Order:

Actions A1 and A2 are attached to N0, A3 is attached to E1

VDA5050 states, that A3 has to finish (either failure or success) as soon as the AGV enters N2.

Does this also hold for A1 and A2, or may they run beyond
N2?

What is the difference between actions in Chapter 6.8.1 and 6.8.2

Proposal: Delete chapter header 6.8.2

test

Currently, VDA5050 uses numbers for both, node names and node sequence numbers:

This leads to an ambiguity, when one says “the AGV goes from 6 to 8”, does it mean “node6 to node8” or “seq6 through seq8”? In the example following example I used letters to name nodes, so if I say “from B to D” it is unambiguous, and so is “from 2 to 6”:

This will make it a bit easier to cooperate with other people, say, when you're debugging something together and you need to make references to certain parts of the map.

The info data structure references an infoReference data structure (page 36), however it is not defined anywhere.

In #23 was a (very) short side discussion if is it allowed that two (or more) identical nodes (identical nodeId and position) are in a row. I didn't found anything in the norm, which forbids such an order (but maybe I read over the crucial part?).
I think if it is allowed there are some open topics how to interpret such an order. Beside that some vehicle cannot deal with edges of zero length, how should a vehicle behave if e.g. the nodes differs in the allowed deviation range?
If such an order isn't allowed I think this should be explicitly mentioned.

For an holistic traffic management it would be great to incorporate also location data of other moving objects (pallets, forklifts, people) in the scheduling | planing process

Add two additional fields in topic order:

• order->source: The source of the order (string). Information on where the order started (e.g. station name)
• order->destination: The current destination of the active order (string). Information on where the order ends (e.g. station name). This field can change during runtime.

Usage of the fields:

• The only purpose of these fields is to visualize the information on the AGVs display and support the AGV maintenance personal.

Why do not use node-description for this purpose?

• Can already send the AGV the name of the final destination of the order, even if some nodes still have to be sent with future order-updates.

7.1 Error reference

If an error occurs due to an erroneous order, the AGV should return a meaningful error reference in the fields errorReference (see 5.6.2 Implementation). This can include the following information:

The reference 5.6.2 does not exist.

It is not obvious whether order updates can only extend the horizon, or deviate from a previously declared horizon (e.g. by changing it completely or partially).

• the flowchart on page 17 shows “clear horizon” as one of the steps, which implies that the horizon can be replaced altogether (unless in this case “clear” means “permit to travel”, i.e. “mark the horizon as released=True, effectively turning it into the base)
• however, the specification also says “Once a sequenceId is assigned, it does not change with order updates (see Figure 7).”

To illustrate this question graphically - is such a situation possible? (note that sequence number 8 used to be node E, now it is F - which seems like a violation of rule 2 above).

Ideally, the specification should include an explicit statement about such cases, rather than leave it open to interpretation.

Hallo,

mir ist aufgefallen, dass das Enum für den connectionStatus folgendermaßen definiert wird:
Enum {ONLINE, OFFLINE, CONNECTIONBROKEN}
Stelle im Dokument:
https://github.com/KIT-IFL/VDA5050/blame/new_addendum/VDA5050_EN_V1.md#L1132

Hier wird die Nachricht allerdings so angegeben:
„connectionState“ = „connectionBroken“
https://github.com/KIT-IFL/VDA5050/blame/new_addendum/VDA5050_EN_V1.md#L1144

Ich habe bereits eine entsprechende Änderung geschrieben und einen Pull Request gestellt:
#1

Currently it is not possible to command AGVs in a specific tangential edge-orientation related to a physical trajectory.

The only existing way to command AGVs in a edge specific orientation is the value "orientation" [rad, Float64], which only relates to the project specific map origin. As a result, all commanded orientation values are global interpreted orientations. A simple "move backwards" command along a trajectory, which can include curves, is currently not possible.

Therefore, we suggest to integrate a new value for a tangential command. Two options are possible:

1. The new value specifies, in how to interpretate the "orientation" value - ENUM [GLOBAL, TANGENTIAL]
2. A new orientation value gets integrated, e. g. "orientationTangential", and the existing value "orientation" is renamed to "orientationGlobal".

Context

The definition of the startPause action [6.8.1] states: "... Actions can continue...", whereas the definition of the stopPause action states: "... Movement and all other actions will be resumed (if any)..."
The "finished" column in the table in [6.8.2] suggests that actions should be paused (startPause: "... All actions will be paused..." and stopPause: "... All paused actions will be resumed...").

Questions

1. Is it safe to assume that actions should be paused and that the first quote is a mistake?
2. If used in a preemptive fashion as described in Issue #8 (which makes perfect sense to me - if I want to pause something, I must preempt it), do we maybe need some additional flag indicating whether or not to resume any preempted actions?

We suggest to extend the AGV state message (5.6. Topic: State) by adding a an array maps and a JSON-object map that maps consists of.
This array should contain the list of maps available on the AGV consisting of mapId and information if a map is currently used.

Usage of the field:

Some AGVs are already able to keep more than one map at once.
Master control therefore needs to know

• what maps are present on the AGV
• which of the maps present is currently being active / used on the AGV
• if no map exists (yet) on the AGV

Structure:

Example:

{
…,
    "maps": [
        {
            "mapId": "1619becf-90f1-4152-b0f7-9b88893fb0ca",
            "active": true
        },
        {
            "mapId": "13467deb-f89a-5561-f96e-11bbfe3cad2b",
            "active": false
        }
    ]
}

In the specification we currently use different approaches to declare the datatype of specific fields. E.g. compare 6.7 orderUpdateId: Integer and 6.10.6 orderUpdateId: Uint32. This can cause confusions and might be even hindering in the communication between AGV and MC.

Currently this mainly applies to Integer vs uint32.

The work groups should decide which notation for the datatype should be used.

I hope this is the right place for this:
In the AGV_factsheet.md document the word visualization is spelled in 2 instances with its UK spelling of visualisation.

Hello,

the change we propose consists of two parts:

• The field order->node->nodePosition->mapId should be optional and not elementary.
• Edge should have an optional field mapId as well (order->edge->mapId).

Arguments for this changes:

• A node, placed exactly between two maps, should not have the mapId of the first map and also not the mapId of the second map. In this case the mapId field should not exist.
• For an edge it is interesting as well which map it is connected to. Is the edge placed on top of multiple maps this optional field should not exist.

Chapter 6.1.3 (page 10) states that enumerations have be in upper case. Still the following enumerations are in lower case:

• state->actionState->actionStatus (page 39)
• state->error->errorLevel (page 40)
• state->safetyState->eStop (page 40)

In Figure 8, when following the highlighted path, the last action is “append state…”. It is not stated explicitly whether
(a) the sequence numbers of the nodes and edges are automatically adjusted by the AGV (i.e. sequence numbers in the order will begin with 0 and the AGV will figure out the rest, e.g., by adding the last used sequence number)
(b) the MC is supposed to send a new order that continues the sequence numbers from the value last used in the previous order.

• Consolidate duplicate branches
• Vertical orientation

Flowcharts could be simplified by refactoring, because some of the branches are nearly identical, here is an example:

The second point is about the fact that I have to either turn my head around or rotate the document multiple times whenever I'm dealing with some of the more complex figures of the specification.

If the flowchart is simplified and does not contain redundant elements, it can fit nicely into a vertical layout. I'm attaching my "from scratch" drawing of the same flowchart, you can open it in software like yED (free), which can also “prettify” the flowchart using various automatic layout algorithms.

since edge.orientation and controlPoint.orientation is in world coordinates,but orientation of every piont on 'S' line is not same when agv move backward(hold 180 degree relative angle to line) on 'S' line. and i am confuse why controlPoint has orientation field,conrolPoint is not on the line if the line is curved line.
in some since,we need agv hold 30degree relative angle to 'S' line,in a special case 180 degree means move backward on line.

In Vda5050 spec V1.1 chapter 7.2 a line says

Der Grund für die Verwendung des vorgeschlagenen Schemas “key”: “actualKey”, “value”: “actualValue”
besteht darin, die Implementierung durchgängig zu halten. Dies ist in mehreren Sitzungen gründlich und
kontrovers diskutiert worden.

in my opinion it means, that "value" has to be a string (“actualValue” is surrounded by ").

The current discussions on the AGV-factsheet suggest for valueDataType

data type of Value, possible data types are 
BOOL, NUMBER, INTEGER, FLOAT, STRING, OBJECT, ARRAY 

Can this be interpreted in the way that valueDataType describes the format of the value string or should this be 'fixed' in one of the two documents?

Suppose you send an order like this:

• the base only covers the first 3 nodes, up to node 90
• the rest is the horizon

Then you send an order update, to extend the base further up to 107:

• note that although the base is extended, the horizon has been removed

This looks like a special case of horizon modification #15, where the horizon is simply removed altogether.

The specification does not say this explicitly, so it is better to double-check - is the horizon set in stone, and can it be only extended? Or are such modifications as depicted here, or in issue #15, also valid?

Not all the branches of the flowchart in fig. 8 are labeled, so one is forced to spend extra time to figure out which is which:

It would be great if there were a community wiki or something like it, where resources relevant to this standard could be shared. For example, so far during my work with the specification I've got several things that might come in handy to others:

• a stricter JSON schema
• a VDA 5050 payload visualizer, for easier debugging and replicating scenarios

NOTE: This question concerns only instant actions which correspond
to AGV actions (not special actions like cancelOrder)

Example scenario

Let's say the AGV is currently running a NONE-blocking action A1. Then a HARD-blocking instant action A2 was received.

I can think of the following behaviors:

• A1 is paused, the AGV stops, A2 is executed, the AGV resumes driving, A1 is resumed
• The AGV stops, A1 is finished, A2 is executed, the AGV resumes driving
• A1 is finished, The AGV stops, A2 is executed, the AGV resumes driving

Those difficulties also appear with other combinations of
blocking types.

Questions

Is there meant to be a standard way of scheduling actions
(e.g. by first come, first serve or some kind of blocking type priority)?

Are instant actions allowed to preempt running actions?

We suggest to change the MQTT quality of service level of the connection-topic from 0 to 1

Arguments for the change (example):

• The AGV connects to the broker (including the configuration of the last-will) and then sends a connection-telegram ONLINE which is lost.
• In this case a supervisors waiting for this connection-ONLINE-telegram it will get stuck.

As the connection telegram is only sent when the AGV connects to or disconnects from the broker the impact on the network traffic should be hardly noticeable.

In the ControlPoint data structure weight should be written in italics, because it has a default value of 1.0, hence it can be omitted.

Currently the existing edge/node connections between source and target need to be teached to the AGV (supplier specific SW) and manualy recreated in the VDA5050 fleet manager.
To avoid this double work, it would be great if an exchange possibility for edge/node connection would be created.
Initial upload of all existing connections and on demand/push (or e.g. on every AGV restart), the AGV downloads the available pathes from the high level fleet manager

In our opinion, the instant action waitForTrigger is defined to thight. In practise the trigger must not necessarily be executed from the vehicle but can be resolved by the Master Control (or systems connected to MC). For this use case it would be useful to have the option to send the trigger action from MC to vehicle. The vehicle then confirms it resolved the trigger by setting waitForTrigger Actions exec status to "finished".

This is just a minor request for a cosmetic change regarding the PDF format: Would it be possible to publish the PDF output with a TOC usable for navigation? While it is not a big problem to generate a version with a TOC by oneself, it leads to multiple customized copies of the standard in different places.

Inside the state message the objects nodeState and edgeState contain the field released, which suggests that the state message contains both the base of the current order and the current horizon. Right?
How to deal with actions attached to nodes/edges inside the horizon? Is the object actionState inside the state message also containing the state of these actions? And what is the state of these actions if the order is canceled or an order update modify the horizon, so these actions do not longer exists inside the order, neither in the base nor in the new horizon?

The following German strings are still present in the English text:

• sofern automatisiert
• Praktische Beispiele (in the doc chapter 7 is titled "Best practice")

What is the normative meaning of column "Wichtig" ("Important") in terms of standardization?

On the one hand, the actions-arrays are named actions in the topic order for both the node-actions as well as the edge-actions. On the other hand, the actions-array is named 'instantActions' in the topic 'instantActions'. => Rename for consistency reasons?

A new/unknown vehicle connect to the MQTT Brocker and Publisches the first VDA5050 State. As an reaction on this the Master Control sends an Instant Action RequestFactSheet with the Parameter {"key": "URI" , "value": "https://myserver/facksheetEndpoint" }

the vehicle gets the Action and and starts an POST transfer to the URI with the payload (factsheet.json)
after the HTTP_OK(OK) is finish, the action marked as successful in the vehicle state.

actionType inside the actionState definition is marked as mandatory (not written in italic), but the accompanying text says it is optional.

Enums are currently mixed up written in their specification. So as a change request we would like to have strict specification for all enumerations along the VDA5050 document.

We suggest to write all enums in CAPITAL letters.

Examples of different specifications:

To stick to the general specification of the VDA5050, not possible, required or existing data is optional and therefore not mandatory to send, we suggest to make the JSON object 'informations[Info]' optional, instead of sending empty JSON objects.

This would also reduce the general primary data content of each telegram.

Sometimes there are several actions that should be executed on one node. Is there a best practice of guaranteing the order of actions? Would it make sense to add an action sequenceId?

The connection status message is supposed to be retained and transmitted as a last will. When the will is delivered in case of a connection outage, its timestamp and headerId will be outdated.

Perhaps the specification could explicitly say that developers should watch out for this aspect, emphasizing that this would be the timestamp and headerId from the time the message was originally sent by the AGV, so the fact that they're "in the past" is expected.

It would be great if we had a standard format to define the nodes, edges and their attributes - otherwise everyone will come up with their own format.

In 6.6.1:

The first node of an order must be trivially reachable for the AGV. This means either that the AGV is already standing on the node, or that the AGV is in the nodes deviation range.

Is there an expected behavior, how AGVs respond to non-reachable first nodes?

In the context of section 6.6.1 it sounds like AGVs have to reject the whole order in this scenario.
If so, I would propose to let the AGV accept the order and set an appropriate error in the state, once
it recognizes the first node is not reachable. This would be more straight forward to implement, because
the navigation stack of the AGV would not have to preprocess the route before accepting the order.

We had several discussions with different customers related to actions and instantActions and their differentation. For some customers, the difference between actions and instantActions was not clear enough by only reading the VDA5050 document.

E. g.: some of them thought, that a normal pre-defined action, listed in chapter 6.8.1 & 6.8.2, can't be a instantAction in the same way, as the list belongs to the chapter "Actions" and not to "instantActions".

Therefore, to avoid this discussions with new customers, we suggest to add a new sentence to the specification, which explains the difference between actions and instantActions in more detail.

In general: instantActions are actions, which are sent over a different MQTT channel regardless of order telegrams and needs to be directly executed.

For autonomous driving vehicle a reduced message set would be usefull.
E.g. it finds the path from source to sink dynamically, there is no need to send a list of nodes/edges to it, a simplified order with start and end node should be enough.

In order to handle the behaviour of autonomous vehicle additional instant messages, are usefull:

• set speed (t.b.d. how to avoid a hart break from 2m/s to 0.3m/s by the AGV. Idea via 2 parameters: target_speed, delay steps +/- 0.2m/s)
• start/stop (already available)
• go to x/y position

The specification says this about sequence numbers: "This sequenceId runs over the nodes and edges (first node of an order receives a 0, the first edge then gets the 1, the second node then gets the 2, and so on). This allows for easier tracking
of the order progress."

This leaves room for interpretation, for example - are gaps in the sequence allowed? i.e., would this be OK 10 20 30 34? This becomes a sensitive issue in cases such as #15, where an order update diverges from the previously defined horizon, forcing either a reuse of previously assigned sequence numbers, or the introduction of such gaps.

The current version of the VDA5050 interface does not contain any option to shut down the whole AGV fleet at once or one by one after the charging.
Therefore it would be desirable to integrate the InstantAction “shoutdown” or “sleepmode”.
To ensure that every AGV has enough battery capacity to get over the time without operation, a concept for battery management must be set up specifically to the conditions.
Of course, it is required to wake up the fleet after weekend or business interruptions. As there are different possibilities, how each AGV fleet (depending on the manufacturer) can be awoken, the communication concerning “wake up” should be defined individually.

Another possibility would be to separate the sleepmode into two different stages:

• 1st stage: InstantAction “sleepmode: all non-vital functions of the AGVs will be shut down. The communication over VDA5050 is still possible. In this case, an InstantAction “wakeup” must be integrated, too.
• 2nd stage: InstantAction “shutdown”: every functionality in the AGV is shut down. In this case, the wakeup must be defined individually (e. g. via UDP-Protocol, etc.) -> see description above.

In chapter 6.8. it is noted that AGV shall use the actions of this list if possible. Additional it is written that if neccessary additional parameters may be added.

When pre-defined standardized actions have additional parameters they are no longer standardized and need to be named differently. Otherwise the Fleetmanager can not distinguish between actions with same name but different parameters (or even return values).

Proposal: Actions defined in the specification shall be taken as proposals for actions. None of the actions have been proven intensive in customer applications till now. E.g. Pick/Drop needs additional parameters in our application which makes them no longer a standardized action.