# Petri Net Toolbox for Multi-Robot Planning under Uncertainty
## 3 Materials and Methods
### Execution Manager  
The _execution manager module_ coordinates the multi-robot system and guarantees that the task is executed according to the designed GSPNR model and the provided policy. The GSPNR model alone is not enough to have an executable task plan since the GSPNR has non-determinism necessary for the action selection process. Applying a given policy to the GSPNR model resolves this non-determinism and enables the task plan execution. Figure 7 shows a flowchart that summarizes the _execution manager module_ algorithm. This module is able to coordinate real systems as it interfaces with ROS _actionlib_ through the MATLAB(r)_ROS Toolbox_. The coordination algorithm takes four inputs:  
1. GSPNR model \(G^{\prime}\);
2. policy \(\pi_{G^{\prime}}\);
3. mapping function \(Map_{p}^{\prime u}\) between each robot's identifier and its initial GSPNR place;
4. mapping function \(Map_{AS}^{p}\) between each action place and the respective ROS _ActionServer_. Figure 7: _Execution manager_ algorithm flowchart. The robot identifier must be the robot's ROS namespace. The algorithm assumes that the ROS packages of different robots are launched under different namespaces, and the packages of the same robot are launched under the same namespace. The \(Map_{AS}^{p}\) must specify the action server name, the package name, the action name and the message fields for each action place. This mapping can be inputed as a YAML configuration file or using a MATLAB(r) structure array. The algorithm runs until it reaches a terminal marking or until the process is killed, and is executed as follows. First it establishes the correspondence between each token in the \(G^{\prime}\) and each individual robot in the multi-robot system using \(Map_{P}^{\textit{it}}\). This ensures that the system knows in every marking which robot should be performing which action. Then it checks if the current marking of \(G^{\prime}\) is vanishing or tangible. A vanishing marking is an action selection state while a tangible marking is an action execution state. Thus when in a vanishing marking it applies the given policy \(\pi_{G^{\prime}}\) until it lands in a tangible marking. Applying \(\pi_{G^{\prime}}\) consists in firing the immediate transition prescribed by \(\pi_{G^{\prime}}\) for that given marking. This step takes a negligible amount of time when compared with action execution. When in a tangible marking it sends actions goals to all the robots that are not executing any action. To do this it gets the _ActionServer_ name from \(Map_{AS}^{p}\) according to the robot's current place. Then it sends the goal to that _ActionServer_ with the message fields also provided in \(Map_{AS}^{p}\). Once one robot finishes executing its action the algorithm fires the output timed transition that is connected to the place where the robot token currently is. This leads to a new marking and the process repeats again. The novel feature of the _execution manager_ algorithm is being able to provide an accurate mapping between robots as these are represented as indistinguishable tokens in the GSPNR. The algorithm first maps the actions each robot is executing to places in the Petri net. This is done by looking at the user provided configuration file that specifies, for each \(G^{\prime}\) action place, which action server should be executed. By doing this, the algorithm assigns to each robot one token according to the action that each robot is currently executing. If two or more robots are executing the same action, the algorithm randomly maps the tokens in that action place to those robots. In this case, it is not necessary to distinguish between those robots, since we assume that heterogeneous robots can never share the same action place. Once the current action being executed finishes, the marking evolves until a new action must be executed. During this, the algorithm tracks each token, ensuring the correct mapping to each robot.