The basic structure of a mission is composed by the events that may happen during the mission and must be managed (optional, lines 3-9), the actions that the robots will be asked to perform (optional, lines 10-15), the names of the robots used in the mission (mandatory, line 17), the locations that must be visited in the mission execution (optional, line 18), and finally the operators that compose the mission (mandatory, lines 10-43). The graphical syntax does not represent the first four elements, so they must be first detailed using the textual syntax (we provide a wizard to ease this step, as explained in one of our tutorials).

The root of our mission is the parallel operator (node 1 in this example), which decomposes the global mission into local, robot-specific missions that are executed in parallel. A robot is assigned to each branch associated with this operator, as indicated with labels in the edges between nodes 1 and 2 and between nodes 1 and 9. In the textual syntax, it is represented with the name of the assigned robot (lines 21 and 29).

The mission of r1. Node 2 represents an operator event handler. It has a default behavior; in our example, it forces the robot to sequentially patrol locations l1, l2, and l3 (node 3). This behavior is paused if one of the events that are assigned to the event handler (as gray circles in the graphical syntax and preceded by the keyword "except" in the textual one) is detected. In the example. if the event "intruder" is detected, the first delegate operator instantiated with the simple action pattern is executed (node 4). In this case, the robot must raise an alarm. If the event "found_object" is the one that is detected, node 5 is triggered, performing the action "request_help". Finally, the detection of the event ''r1_low_battery" triggers the operator sequence (node 6), which makes the robot go to its charging dock (node 7) and then perform the action "charge_battery" (node 8). The default robot's behavior, marked with 3, is resumed whenever any of the behaviors triggered by an event are finished (either succeeding or failing).

The mission of r2. Meanwhile, the event handler marked with 9 dictates that r2 must wait in l4 (node 10) by default. The detection of the event "help_requested" triggers a sequence of executions (node 11), starting from the visiting of l2 (node 12), followed by the action "grasp_object" (node 13). The operator fallback (node 14) encodes that r2 must try to reach office1 (node 15), and if it fails (e.g., the office's door is closed) it tries to reach office2 (node 16). Robot r2 then releases the object in the reached office (node 17). The child of node 9 triggered by the event "r2_low_battery" (node 18) is a replica of the event handler marked with node 6.

PROMISE's framework integrates a compiler that basides generating the mission to be sent to the robots, also generates a file for each robot containing a natural-English translation of the mission encoded by the user. The translations for each local mission (missions of r1 and r2) are listed below:

Robot r1 does by default patrol in sequence location(s) l1, l2, l3, and if event intruder occurs, it will perform action raise_alarm, and if event found_object occurs, it will perform action request_help, and if event r1_low_battery occurs, it will visit (without any specific order) location(s) chargingdock and then perform action charge_battery.

Robot r2 does by default wait in location l4, and if event help_requested occurs, it will visit (without any specific order) location(s) l2 and then perform action grasp_object and then visit (without any specific order) location(s) office1 if it fails, it tries to visit (without any specific order) location(s) office2 and then perform action release_object, and if event r2_low_battery occurs, it will visit (without any specific order) location(s) chargindock and then perform action charge_battery.