Software patterns and data structures for the runtime coordination of robots, with a focus on real-time execution performance

This paper introduces software patterns (registration, acquire-release, and cache awareness) and data structures (Petri net, finite state machine, and protocol flag array) to support the coordinated execution of software activities (also called “components” or “agents”). Moreover, it presents and tests an implementation for Petri nets that supports real-time execution in shared memory for deployment inside one individual robot and separates event firing and handling, enabling distributed deployment between multiple robots. Experimental validation of the introduced patterns and data structures is performed within the context of activities for task execution, control and perception, and decision making for an application on coordinated navigation.

• Create: allocation of memory for the Petri net; • Configure resources: initialization of Petri net and protocol arrays; registration of coordinated activities; • Configure capabilities: switch places to skip and places to process; • Running: consisting on executing communication and computation; • Delete: de-registration of coordinated activities; deletion of Petri net and de-allocation of memory; Moreover, the following design invariants are taken into account for the Petri net execution : • there are no enabled transitions when the computations are started, and when they end.
• the order in which places and transitions are processed does not matter.
• the data structures are big enough to store the maximum number of entries that can occur.
For each protocol event that comes in, the event loop in the Running state of the coordinating activity executes the operations described in Algorithms 1, 2, and 3, in that order: 1) first a communicate() step where the incoming events are mapped to places, 2) the computation() as execution of the Petri net and 3) communicate() the events triggered by the newly processed sink places.The coordinating activity executes these operations in a synchronous manner.
The communication of events with external processes has to be conveyed by other activities within the same process.Therefore, the communication with external processes is handled asynchronously.

Event connection to places in the Petri net
Figure 1 shows the data structures for the communication in the configuration and running states of the Life Cycle State Machine of the Petri net coordination.That is, the basis for the handling of the events involved in the coordination.The data structures relevant for the configuration state of the coordination are: • event to source pointer, event to source number: these are part of a map event to source, similar to place to transitions.to find the status data structure of a source place with a given ID, when an event with a given ID arrives through shared memory.This is needed in the protocol to convert external events to a source place with a given ID.
• sink to events: similar to the map event to source, to find the event(s) to fire when a sink place with a given ID is filled by the Petri net.
• sink index: mapping from the place ID in the place transition map to the corresponding ID in the sink to events data structure.If the place is not a sink, the respective ID is NULL.
The data structures relevant for the running state are:

Frontiers
• sinks to events counter: similar to marking history.Contains a counter on the number of times a sink place has been processed per execution of the Petri net.
• sink todo list: circular buffer with the sink places whose markings have been updated.The IDs of the sink places refer to the sinks to events map.From this information, the triggering of connected outgoing events starts.
• events to process, events to communicate: circular buffer with the incoming and outgoing events from and to other activities.

Frontiers
Figure 1.Data structures for the processing of events between asynchronously running coordinated activities, and the synchronous context of processing of events, places and transitions inside the Petri net's coordinating activity.
Algorithm 1 First Communicate(): get events to process from other activities while ID event ← read next(events to process) ̸ = N U LL do places ← get event places(ID event , event to sources map) for ID place in places do set marking(ID place , marking of places) add new(ID place , places to process, place buf f er states) end for end while