Petri Net Machines for Human-Agent Interaction

Petri Net Machines for Human-Agent Interaction

Christian Dondrup, Ioannis Papaioannou, Oliver Lemon
School of Mathematical and Computer Sciences, Heriot-Watt University
Edinburgh Campus, Edinburgh, EH14 4AS
{c.dondrup, i.papaioannou, o.lemon}

Smart speakers and robots become ever more prevalent in our daily lives. These agents are able to execute a wide range of tasks and actions and, therefore, need systems to control their execution. Current state-of-the-art such as (deep) reinforcement learning, however, requires vast amounts of data for training which is often hard to come by when interacting with humans. To overcome this issue, most systems still rely on Finite State Machines. We introduce Petri Net Machines which present a formal definition for state machines based on Petri Nets that are able to execute concurrent actions reliably, execute and interleave several plans at the same time, and provide an easy to use modelling language. We show their workings based on the example of Human-Robot Interaction in a shopping mall.


kbKBKnowledge-Base \newacronymdfsmDFSMDeterministic Finite State Machine \newacronymfsmFSMFinite State Machine \newacronympnPNPetri-Net \newacronympnmPNMPetri-Net Machine \newacronymrosROSRobot Operating System \newacronymhaiHAIHuman-Agent Interaction \newacronymhriHRIHuman-Robot Interaction \newacronymsdsSDSSpoken Dialogue Systems \newacronymdqnDQNDeep Q-Network \newacronymrlRLReinforcement Learning \newacronympddlPDDLPlanning Domain Definition Language \newacronymsmachSMACHState MACHine \newacronympnpPNPPetri Net Plan \newacronymyamlYAMLYet Another Markup Language \nocopyright


Smart devices such as the Google Home or Amazon Echo, and even social robots such as Anki’s Cozmo and SoftBank’s Pepper have moved from the lab into private homes. All of these agents seek to interact with humans in their vicinity in one way or the other. Hence, all of them need a way to manage this interaction and a lot of approaches to solve this problem have been proposed over the years. On the one hand, deep reinforcement learning such as \glspldqn have been used for many applications with one of them being behaviour generation via the learning of control policies, e.g. playing games [Mnih et al.2015]. This, however, requires access to large amounts of meaningful raw sensor data which is difficult to come by when looking at the domain of \glshai in general or \glshri in particular. Traditional reinforcement learning approaches such as Q-Learning have similar problems or require a long time exploring the state space to create a suitable policy. Exploration, however, can rarely be done in \glshai scenarios and is, therefore, often scaffolded by simulating user interactions. This is particularly prevalent in \glssds, see surveys by e.g. [Schatzmann et al.2006, Pietquin and Hastie2013]. Using a \glsfsm on the other hand allows to model interaction using expert knowledge and creating behaviours for interaction without needing to collect data a-priori and/or to first create a user simulation. For this reason, many interactive systems in \glshri and for dialogue management for smart speakers still rely on \glsplfsm. Examples for this are \glssmach [Bohren and Cousins2010] for the \glsros or [Thomson and Young2010, Curry et al.2018] in the wider sense in case of \glssds.

Figure 1: One of the experimenters interacting with the system embodied by the robot. Shot on location in a Finnish shopping mall.

Another challenge when it comes to \glshai and \glshri is that a myriad of actions might have to happen at the same time. An example for this in \glshri would be a robot giving a route description to an interaction partner. In this case the robot has to verbalise the description, point to the target, look at the human or the direction pointed to, etc. Modelling these concurrent actions correctly in a \glsfsm presents problems of managing these actions and the general flow of the interaction due to its exploding complexity. In this paper, we present an approach to building \glspldfsm automatically. These \glspldfsm are based on \glsplpn which are able to handle concurrency and guarantee that there are no unreachable states. This approach was inspired by work by [Ziparo et al.2011] but we believe that it improves not only the implementation and usage but also the conceptual realisation of the \glspn making this approach even more versatile and powerful. Moreover, the approach presented here also allows to execute several \glsplpn concurrently to allow to interleave tasks or execute them at the same time.

In this paper we present our execution system based on \glsplpn developed with the \acrfullros in mind. It natively supports \glsros action servers and presents an alternative to \glssmach [Bohren and Cousins2010]. It’s current application is to create a unified plan modelling and execution framework combining dialogue and physical actions on a robot. Most current dialogue systems apart from the one this execution system is part of are either task or social chat based but not both. Therefore, in previous work, we argued why it would be beneficial to combine the two [Papaioannou et al.2017b]. While this was the main initial motivation, the resulting execution system is more generally applicable and can be used for all tasks one would use a \glsfsm for. However, it comes with all the benefits of a \glspn such as concurrent execution, modelling complex structures, and in addition to that as we believe an easy to use description language to create state machines without having to do much programming. We tested the system in a deployment of the robot in a Finnish shopping mall (see Figure 1) where it gave directions to customers.

Related Work

There are many approaches when it comes to selecting and executing actions on robots. Some of the more notable ones are [Ingrand et al.1996, Kim, Williams, and Abramson2001, Verma et al.2005, Lesire and Pommereau2018, Colledanchise and Natale2018, Xu et al.2002, King, Pretty, and Gosine2003]. All of these approaches have in common that they are designed for the planning and execution of sequences of actions which are disjoint meaning that the output of one action is not used by a different action further down the sequence. This, however, is possible using the approach presented here. Additionally, the system we propose also offers communication with an external \glskb which can even be a user of a dialogue system to fill gaps before or during execution of an action. Moreover, the presented system automatically generates checks and recovery behaviours based on preconditions and effects of each action to make execution more stable.

In the following, we present more detail on the two concepts most closely related to the work presented here, i.e. \glsplfsm and \glsplpn. Another popular approach, i.e. \glsrl, has the draw back of either having to explore the state space or needing vast amounts of data collected a-priori. Hence, we will not go into detail about approaches using \glsrl for agent control.

Finite State Machines

One can implement a \glsfsm in any programming language. There are some examples where these \glsplfsm have been specialised for robot control. An early example of using \glsplfsm for robot control is the work by [Brooks1986] to control a mobile robot and give it some degree of autonomy. The system was divided into several smaller modules which were implemented as \glsplfsm and communicated with each other via a network. As mentioned earlier, the most notable due to the widely used \glsros is \glssmach [Bohren and Cousins2010]. It was created for rapid development and provides convenient introspection tools. Instead of creating \glsplfsm by hand, others aim to create them automatically such as ROSPlan [Cashmore et al.2015]. Here, the authors of the paper use a \glspddl based planner to create a sequence of actions to be executed to reach a given goal state from the current start state. ROSPlan also provides a \glsros interface to execute those actions in the order given by the planner. This sequence of actions itself can also be regarded as a \glsfsm in the wider sense.

The vast majority of \glsfsm based approaches suffer from the same short comings, i.e. the need to model the flow manually and the probability of introducing errors during modelling, the difficulty modelling concurrent states on one or multiple agents, and the problem of not being able to deal with environment states that have not been modelled. Our approach presented in this paper aims to deal with some of these issues by using \glsplpn to model concurrency and guarantee that all states are reachable, and by using a simple modelling language. It also provides checks and recovery behaviours to deal with unexpected environment states.

Petri Nets for robot control

In the past, there has already been work on modelling robot behaviour as \glsplpn. Some examples of modelling (multi-agent) robotic systems are [Milutinovic and Lima2002, Sheng and Yang2005, Costelha and Lima2007], where [Costelha and Lima2007] also explicitly include a model of the environment. Most of the systems that used \glsplpn in robotics, however, are either modelling ad-hoc solutions to specific problems or used 3rd-party methods for task execution. The first approach of defining a language for so-called \glsplpnp was presented in [Ziparo et al.2011]. This approach has later on been used in different scenarios of \glshri such as the generation of social-plans, i.e. plans that include both actions of robot and human  [Nardi and Iocchi2014], and the explicit inclusion of social norms in \glsplpnp [Carlucci et al.2015]. For this reason, the work presented here builds on \glsplpnp. In previous work [Dondrup et al.2017], we already extended \glsplpnp to work in combination with ROSPlan [Cashmore et al.2015] to automatically translate the plan created into a \glspnp for execution using the defined preconditions and effects to automatically generate checks and recovery behaviours. A similar system without the use of recovery behaviours generated based on the plan has also been presented by [Sanelli et al.2017].

The work presented in the following builds on the concepts by [Ziparo et al.2011] and our previous work [Dondrup et al.2017] and extends its functionality to more closely resemble that of a \glspn. Moreover, it defines a modelling language, supports automated \glspn generation, has tight \glsros integration, allows the concurrent execution of multiple \glsplpn, and provides an improved implementation.

Petri Nets

Figure 2: Example of concurrent states in a \glspn. The initial marking is shown by dots, squares show , the diamonds show , and the triangle shows . All arcs have a weight of which according to convention has been omitted. is referred to as a fork and as a join.
Figure 3: Simple \glspn example. (top) shows a \glspn with marking and weights . (bottom) shows the \glspn after transition occurred where the marking changes to .

Based on work by Petri [Petri1962], the theory, notation, and representation of \glsplpn and how they could be applied to modelling and analysing systems of concurrent processes was first introduced by Holt et al. [Holt et al.1968, Holt and Commoner1970]. In short, \glsplpn are state-transition systems which allow to model automata with concurrent and asynchronous states. In order to define a Petri Net , we first have to define a net where and are disjoint finite sets of places and transitions and is a set of arcs such that . Given a net , we define a configuration such that . Both and form a so-called elementary net . The resulting definition of a \glspn is


where is a multiset of places and the so-called marking of the net which replaces the configuration . is the multiset of arcs so that the count of each arc is a measure of its weight.

Figure 3 shows an example \glspn. The tokens (black dots) represent the current marking of the net. shows the \glspn before transition occurs and shows the same \glspn after the transition. The weight of the arc symbolises the number of tokens required in for transition to occur. The weight of arc shows the number of tokens placed in after transition occurred. Hence, one can think of arcs pointing to transitions as consuming an amount of tokens equal to their weight and arcs pointing to places generate an amount of tokens equal to their weight. These two processes are disjoint, meaning that the amount of tokens generated does not correspond to the amount of tokens consumed and vice-versa. Transitions ‘fire’ as often as the amount of tokens allows, meaning that if the marking of is a multiple of the weight of , fires times.

The process of changing the marking of can easily be calculated using simple matrices [Chen2003]. Firstly, we define the two matrices with if transition has input from place for outgoing arcs and with if place has input from transition for incoming arcs. The composite change matrix is then defined as . The new marking for in Figure 3 can then be calculated from marking in as follows


where is a matrix with representing the number of times each transition should fire.

From these definitions follows that whereas . This fact allows for the modelling of concurrent states mentioned earlier by creating forks and joins using transitions. Figure 2 shows the most simple example of concurrency in \glsplpn. The fork could theoretically split the execution token into any number of places followed by any number of transitions and places. The join could similarly join any number of execution tokens. This mechanism allows to start concurrent processes using the fork and wait for their completion using the join.

Petri Net Machines

It is easy to see the similarities between \glsplpn and \glspldfsm. Looking at the definition of with being a finite non-empty alphabet of input symbols, being the set of states, the start state , representing the state-transition function , and being the final or goal state, we can clearly see the similarities. States relate to places and markings, transitions relate to , and the initial marking being . Only the input alphabet and the goal states are missing. This similarity is not surprising and \glsplpn have been used to model and analyse all kinds of automata including \glsplfsm.

In this work, we present an approach to not only model \glspldfsm using \glsplpn but also present a solution and software framework that incorporates external input to create a transition function


which allows us to create our new marking using Equation 2. Since \glsplpn are a simple but powerful model to describe automata that also deal with concurrency, others have presented similar work, e.g. [Ziparo et al.2011]. The approach presented here, however, uses the full capabilities of the \glspn model to automatically create and execute \glspldfsm and not just an elementary net such as in prior approaches. To this end we define \glsplpnm where is a Petri Net and is the initial marking of the net. similar to the of \glspldfsm represents goal states. Reaching a goal state in a \glspnm translates into a goal place being included in the current marking . Hence, the execution has reached its goal if .

ROS Petri Net Machines

The \acrfullros is a popular choice for a large number of research institutes and the industry when it comes to controlling their robots111While \glsros is popular in academic research, industrial robotics, and self-driving vehicles, it is almost never used for social robots in real-world products and deployments with the exception of the experiment described blow.. It has a very modular structure and allows to easily port one’s work from one robot to another. Moreover, it is supported by a vast community and offers a great number of state-of-the-art, open-source, and off-the-shelve software components readily available. \glsros also comes with its very own implementation of a state machine, i.e. SMACH [Bohren and Cousins2010]. \glssmach is a python framework for creating \glspldfsm but as mentioned earlier suffers from the same short-coming as most implementations of DFSMs. For this reason, we chose to base our implementation of a \glsdfsm on \glsplpnm. Similar to [Ziparo et al.2011], we use \glsros action servers which are triggered whenever a transition occurs, but we also allow to generate the \glsplpnm on-the-fly based on prior work [Dondrup et al.2017].

The system presented in the following is based on \glsplpnp by [Ziparo et al.2011] but extends on their idea and improves the implementation to support automatic generation of \glsplpnm, handle concurrent execution of multiple \glsplpnm, speed up the execution, and to better exploit the native \glsros infrastructure. The latter is achieved by using \glsros action servers identified via their signature as described below. This aims at making its use easier while increasing its capacity for automation and allow the use of the full modelling prowess of \glsplpn. In addition, we also provide a modelling language that makes it easy to define \glsplpnm without much programming. The code is open source and freely available.222˙net/tree/ros

Action Servers

Figure 4: Example of a \glsros action with the 3 outcomes of a typical \glsros action server. When is triggered, the action server is started. depends on the reported outcome of the server and only allows the corresponding transition to fire.

Action Servers333 are one of the most used principles in \glsros to execute behaviours on robots. They allow to start, monitor, and interrupt processes remotely. Most actions or behaviours robots can execute are implemented as such action servers. One example being move_base444˙base which has the robot navigate to a given goal. For this reason it makes sense to support this programming principle in any state machine for \glsros. \glssmach [Bohren and Cousins2010] for example, offers functionality to use (3rd-party) stand-alone action servers as states directly. We also followed this example and allow to use action servers as places directly which is a novel concepts using \glspn-based execution. These actions are triggered by a transition and while they are executing, the marking reflects this by having a token in the place after the transition that started the server. Once the server has finished, the transitions following the place will become active. Which of these transitions are active depends on how the server finished (see Figure 4), thereby, creating our transition function from Equation 2.

Sometimes, it is necessary for an action to be able to communicate with the process that has started it. For this reason, we implemented a dedicated version of the \glsros action server that is able to query the underlying \glskb. It inherits the same functionality as an action server but also offers query and inform methods (see Listing 1). Both types of servers can be used interchangeably.

1update_kb(RPNActionServer.UPDATE_LOCAL, ”spam”, ”eggs”)
2query_kb(RPNActionServer.QUERY_ALL, ”spam”)
Listing 1: Methods to interact with the \glskb. Both QUERY and UPDATE provide the functionality of specifying the LOCAL, GLOBAL, or ALL \glsplkb. The letter first querying LOCAL and if no value is returned the GLOBAL \glskb.


One of the problems of state machines is the passing of knowledge between states. While action servers have goal messages that contain data and result messages that contain produced data, planning and execution systems such as ROSPlan [Cashmore et al.2015] use a database to pass information between states that is not part of the planning domain. Hence, it relies on action to put information in that can subsequently be queried by action . This requires both actions to be specifically designed to be executed in sequence. For our execution framework, we use a local \acrfullkb that fills all data fields in the goal of the action to be sent to the server automatically and is updated by the resulting data produced by an action server after its execution finished. These fields to be filled are identified by their name. So if action produces data for variable , it will automatically be used to fill variable in any followup action. If the two variables do not have the same name, a simple \glskb operation can be included in the plan to save the data under the required name before is executed555\glskb operations do not require an action server to be implemented but are executed by the \glspnm directly operating on the \glskb.. This allows the user to use off-the-shelve (3rd-party) action servers without having to change the names of goal or result parameters and recompile them. Moreover, by creating a disjoint instance of the local \glskb for each \glspnm that is executed, we allow the concurrent execution of several plans (see the Concurrent Multi-threaded Execution section) each having their own \glskb making it thread safe.

The framework can also be interfaced with a number of global \glskb like a data centre to query information or a dialogue system [Papaioannou et al.2017a, Curry et al.2018] such as introduced in [Dondrup et al.2017]. This can be used to query information from something like an ontology which is not in the local \glskb or to direct questions to the user of a dialogue system for clarification. Imagine, for example, a system for route guidance that was asked to give directions to a restaurant. There might be several restaurants close by so the \glspnm, after finding all possible instances of restaurants, can query the global \glskb (in this case the user) which restaurant they want to go to before the action of generating a route is executed.

Recovery Behaviours

As presented in previous work [Dondrup et al.2017], before executing an action and after its execution, certain behaviours are automatically inserted to check conditions and recover from execution errors. Before the start of an action, the local database is queried to check if the variables required to fill the goal message are present. If not, the \glspnm reports a failure. After the execution of an action, as can be seen in Figure 4, sever outcomes are checked. If the execution reported success the \glspnm continues as expected. If the action failed, the \glspnm reports a failure and if the action is interrupted (i.e. preempted in \glsros terminology), followup recoveries can be defined manually or the \glspnm continues regardless. Hence, all these recovery behaviours for action, checks, and recovery behaviours for checks, can be used as is but can also be defined manually. This ranges from simple predefined commands such a retrying an action to defining a whole chain of alternative actions.

3 dummy_server:
4  <<: *rpn_action
5  params:
6   - value
7  effects:
8   and:
9    - Comparison: [”eq”, [Query: time”, Query: value”]]
10    - not:
11     Comparison: [”ne”, [Query: time”, Query: value”]]
12 wait:
13  <<: *ros_action
14  params:
15   - time
16  preconditions:
17   Exists: [Query: time”]
Listing 2: Example domain excerpt following a \glspddl inspired syntax including params, preconditions, and effects. The super types rpn_action and ros_action define which specific python source files to use and have been omitted.

Planning Interactions

In order to plan interactions, the user can define domains and plans manually. These are then translated into action servers themselves which when started execute the plan as a \glspnm. An example domain can be seen in Listing 2. The markup language used is \glsyaml and the layout for the domain file is based on \glspddl. Actions are defined with a name, a list of parameters, preconditions, and effects. Preconditions and effects can use logical operations as can be seen from the example in lines 9 – 11, 17. Query takes a single argument, queries first the local and if the value is not found, the global \glskb for the required information, and returns the value. Comparison takes two arguments: i) the comparison operation, e.g. eq for equals, and ii) a list of arguments to execute the comparison on. Exists checks if the given query returned a result or not.

An example plan can be seen in Listing 3. It defines initial knowledge to populate the local \glskb on start-up and the list of actions. The actions are executed in order and can be given arguments for the parameters they expect. If any of the parameters is omitted, it is filled from the \glskb automatically. dummy_action takes “value” as a parameter and returns a “time”. This “time” is then used by the wait actions on lines 6 and 7. concurrent_actions defines a list of actions that should be executed concurrently. These can also be nested. dummy_server is defined as a \glsros \glspn action or rpn_action (see Listing 2). This means that it is able to communicate with the \glspn execution server to query or update information at runtime (see Listing 1).

Figure 5: The conceptual structure of the \glspnm resulting from Listing 3. Each box contains several places and transitions for precondition and effect checks, and for the execution of the action (see Figure 4).
2 value: 3
4 - dummy_server: {}
5 - concurrent_actions:
6  - wait: {}
7  - wait: {}
8  - concurrent_actions:
9   - wait: {time: 5}
10   - wait: {time: 6}
Listing 3: Example plan. This plan defines initial knowledge that is used to populate the \glskb on start. The plan itself lists (concurrent) actions in order of execution. Line 9 and 10 show how to pass explicit values for parameters where as lines 5 and 6 have the wait function use whatever value is found in the local \glskb. Figure 5 shows the resulting conceptual representation of a \glspnm.

As can be seen in Figure 5, the resulting net executes first the dummy_server and then 4 instances of the wait action concurrently. In addition to concurrent interactions, these plans also allow to create loops and thanks to the mentioned recovery behaviours if-then-else constructs. Neither of these have been shown here due to the limitation of space. The full documentation can be found online22footnotemark: 2. Once a plan has been loaded, it becomes a \glsros action server itself for ease of use.

Figure 6: Hypothetical multi-threaded example interaction. Conversation between the User (U) and the System (S). The colours and numbers of the nodes in the tree correspond to the colours and numbers of the text. Each node in the tree represents one turn, i.e. one user utterance + one system utterance. The green root is created at the start of the interaction. Only the red branch has finished. The black text comes from the persona chatbot for social interaction.

Concurrent Multi-threaded Execution

In addition to being able to concurrently execute actions within a \glspnm, the system also allows to concurrently execute several \glsplpnm which is a novel contribution compared to other \glspn-based systems. Thinking of the example of dialogue, this might happen if the user asks the system to fulfil a specific task. Within that task, a rpn_action requires feedback from the user and asks a question. The user however does not answer the question but starts a different task or the same task with other parameters. This means that both plans are executed at the same time. This requires a system that keeps track of the running \glsplpnm and assign the answer to a question to the correct rpn_action. This arbitration system has been introduced in our previous work [Dondrup et al.2017] (see Experiment section and Figure 6).


The work presented in this paper is part of the MuMMER project666 with the aim of putting an entertaining and helpful robot in a shopping mall. Hence, we conducted preliminary tests with the system described here in a shopping mall in Finland777 As mentioned in the Introduction section, the main purpose of the described system is to act as an action manager that is able to combine dialogue actions and physical actions in the same planning domain. We previously argued why it would be beneficial to combine the two [Papaioannou et al.2017b] and, create a system able of social interaction via chat and the execution of physical tasks on a robot. Hence, the hypotheses of the experiment were i) we are able to combine both dialogue and physical actions in the same plan and domain and ii) the system is able to interleave strands of conversation by pausing tasks while preserving the ability to resume the task where it was left off (see Figure 6).

The social component or ‘social-chat’ of the dialogue comes from the system described in [Papaioannou et al.2017a, Curry et al.2018] and the physical task execution is handled by the \glspnm described here. The physical tasks provided were direction giving, making the robot dance, and taking a selfie with the robot. For the direction giving the \glspnm coordinated several actions that created the route description, clarified abilities of the user, e.g. if they are able to take stairs or see certain landmarks, and confirmed if the descriptions have been understood. If they were not, it offered to repeat them or directed them to a human for more information. For the other two tasks, the \glspnm triggers built in behaviours of the robot.

The robot was deployed in the shopping mall for 5 days during which we tested several different scenarios that were all using \glspnm based execution. These tests included interactions with experimenters but also with customers of the shopping mall (see Figure 1 and 7). We tested scenarios such as interleaving several tasks and interleaving tasks with social chat (see below).

Figure 7: Visitor of the shopping mall interacting with the system embodied by a pepper robot.

Method and Results

In order to test our hypotheses, we gave participants a script to follow which does not state what they are supposed to say but rather gives them a list of actions and in which order they should be executed, i.e. you want to find shop_0, interrupt the robot and ask for shop_1, interrupt the robot and talk about an unrelated topic such as your favourite artist, film, or book. This interaction was meant to test both hypotheses i) by triggering the guiding task that combines physical (e.g. pointing) and dialogue actions (e.g. describing the route and confirming it has been understood), and ii) that a task can be paused via interrupting its execution with chat or a new task and resume it when being re-prompted by the system because the task has not finished yet. A possible example can be seen in Figure 6. This was tested amongst the developers and with 5 customers of the mall who agreed to take part in the experiment. No participation reward was offered.

During these experiments, the customers were rating the system based on the quality of the conversation and the given route descriptions. Since these ratings only mildly reflect the workings of the execution framework, these results have been omitted here. However, through observation we found that in 100% of the test cases the system triggered the right task, was able to pause it to be interleaved with chat or another task, and finally resumed it when the user was re-prompted with a previous question regarding the task.


The \glspnm presented here allows developers to automatically create state machines form a simple mark up text file. It uses the modelling powers of \glsplpn to handle concurrency and also allows to implement constructs such as loops. In comparison to previous approaches using \glsplpn for similar tasks, the \glspnm presented here implements the full functionality of the Petri Net, allows for concurrent execution of several \glsplpn, and natively supports \glsros action servers while also allowing to create actions that can interact with a common \glskb during execution. The mark up language used and the underlying implementation gives the user more freedom than previous implementations of this concept as it is more explicit and versatile than a semi-colon separated list of actions (as used in e.g. [Ziparo et al.2011]) by building on familiar concepts known from languages such as \glspddl. \glspddl style syntax is used for the domain file of the \glspnm while the plan file follows its own unique syntax. However, in comparison to \glspddl, the mark up language of choice, i.e. \glsyaml, can be parsed by a wide variety of languages without any programming overhead.

The system was tested in a shopping mall in Finland as part of a greater dialogue system. In this paper we present observational and anecdotal evidence for the \glspnm working as intended. This evidence stems from user tests in the shopping mall that evaluated different parts of a greater system but all used \glsplpnm as the underlying execution system.

In conclusion, we have presented a system that is able to generate \glspldfsm as \glsplpnm, execute tasks successfully even if concurrent and also execute several \glsplpnm concurrently. It presents an alternative to other approaches such as \glssmach [Bohren and Cousins2010] or \glspnp [Ziparo et al.2011] and provides benefits over each of them.

Future work will investigate the ease of use of the developed modelling language, and the framework itself and its modelling capabilities.


The research leading to these results has received funding from the European Commission’s H2020 programme under grant agreement No. 688147, MuMMER project.


  • [Bohren and Cousins2010] Bohren, J., and Cousins, S. 2010. The smach high-level executive [ros news]. IEEE Robotics & Automation Magazine 17(4):18–20.
  • [Brooks1986] Brooks, R. 1986. A robust layered control system for a mobile robot. IEEE journal on robotics and automation 2(1):14–23.
  • [Carlucci et al.2015] Carlucci, F. M.; Nardi, L.; Iocchi, L.; and Nardi, D. 2015. Explicit representation of social norms for social robots. In 2015 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), 4191–4196. IEEE.
  • [Cashmore et al.2015] Cashmore, M.; Fox, M.; Long, D.; Magazzeni, D.; Ridder, B.; Carrera, A.; Palomeras, N.; Hurtós, N.; and Carreras, M. 2015. Rosplan: Planning in the robot operating system. In ICAPS, 333–341.
  • [Chen2003] Chen, M. 2003. Matrix Representation of Petri Nets. Available at
  • [Colledanchise and Natale2018] Colledanchise, M., and Natale, L. 2018. Improving the parallel execution of behavior trees. In 2018 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), 7103–7110. IEEE.
  • [Costelha and Lima2007] Costelha, H., and Lima, P. 2007. Modelling, analysis and execution of robotic tasks using petri nets. In 2007 IEEE/RSJ International Conference on Intelligent Robots and Systems, 1449–1454. IEEE.
  • [Curry et al.2018] Curry, A. C.; Papaioannou, I.; Suglia, A.; Agarwal, S.; Shalyminov, I.; Xu, X.; Dušek, O.; Eshghi, A.; Konstas, I.; Rieser, V.; et al. 2018. Alana v2: Entertaining and informative open-domain social dialogue using ontologies and entity linking. Alexa Prize Proceedings.
  • [Dondrup et al.2017] Dondrup, C.; Papaioannou, I.; Novikova, J.; and Lemon, O. 2017. Introducing a ros based planning and execution framework for human-robot interaction. In Proceedings of the 1st ACM SIGCHI International Workshop on Investigating Social Interactions with Artificial Agents, 27–28. ACM.
  • [Holt and Commoner1970] Holt, A., and Commoner, F. 1970. Events and conditions: system description. In Record of the Project MAC conference on concurrent systems and parallel computation, 7–24. ACM.
  • [Holt et al.1968] Holt, A. W.; Saint, H.; Shapiro, R.; and Warshall, S. 1968. Final report of the information systems theory project. Applied Data Research, Inc., Princeton, NJ.
  • [Ingrand et al.1996] Ingrand, F. F.; Chatila, R.; Alami, R.; and Robert, F. 1996. Prs: A high level supervision and control language for autonomous mobile robots. In Proceedings of IEEE International Conference on Robotics and Automation, volume 1, 43–49. IEEE.
  • [Kim, Williams, and Abramson2001] Kim, P.; Williams, B. C.; and Abramson, M. 2001. Executing reactive, model-based programs through graph-based temporal planning. In IJCAI, 487–493.
  • [King, Pretty, and Gosine2003] King, J.; Pretty, R. K.; and Gosine, R. G. 2003. Coordinated execution of tasks in a multiagent environment. IEEE Transactions on Systems, Man, and Cybernetics-Part A: Systems and Humans 33(5):615–619.
  • [Lesire and Pommereau2018] Lesire, C., and Pommereau, F. 2018. Aspic: an acting system based on skill petri net composition. In 2018 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), 6952–6958. IEEE.
  • [Milutinovic and Lima2002] Milutinovic, D., and Lima, P. 2002. Petri net models of robotic tasks. In Proceedings 2002 IEEE International Conference on Robotics and Automation (Cat. No. 02CH37292), volume 4, 4059–4064. IEEE.
  • [Mnih et al.2015] Mnih, V.; Kavukcuoglu, K.; Silver, D.; Rusu, A. A.; Veness, J.; Bellemare, M. G.; Graves, A.; Riedmiller, M.; Fidjeland, A. K.; Ostrovski, G.; et al. 2015. Human-level control through deep reinforcement learning. Nature 518(7540):529.
  • [Nardi and Iocchi2014] Nardi, L., and Iocchi, L. 2014. Representation and execution of social plans through human-robot collaboration. In International Conference on Social Robotics, 266–275. Springer.
  • [Papaioannou et al.2017a] Papaioannou, I.; Curry, A. C.; Part, J. L.; Shalyminov, I.; Xu, X.; Yu, Y.; Dušek, O.; Rieser, V.; and Lemon, O. 2017a. Alana: Social dialogue using an ensemble model and a ranker trained on user feedback. Alexa Prize Proceedings.
  • [Papaioannou et al.2017b] Papaioannou, I.; Dondrup, C.; Novikova, J.; and Lemon, O. 2017b. Hybrid chat and task dialogue for more engaging hri using reinforcement learning. In 2017 26th IEEE International Symposium on Robot and Human Interactive Communication (RO-MAN), 593–598. IEEE.
  • [Petri1962] Petri, C. A. 1962. Kommunikation mit automaten.
  • [Pietquin and Hastie2013] Pietquin, O., and Hastie, H. 2013. A survey on metrics for the evaluation of user simulations. The knowledge engineering review 28(1):59–73.
  • [Sanelli et al.2017] Sanelli, V.; Cashmore, M.; Magazzeni, D.; and Iocchi, L. 2017. Short-term human-robot interaction through conditional planning and execution. In Twenty-Seventh International Conference on Automated Planning and Scheduling.
  • [Schatzmann et al.2006] Schatzmann, J.; Weilhammer, K.; Stuttle, M.; and Young, S. 2006. A survey of statistical user simulation techniques for reinforcement-learning of dialogue management strategies. The knowledge engineering review 21(2):97–126.
  • [Sheng and Yang2005] Sheng, W., and Yang, Q. 2005. Peer-to-peer multi-robot coordination algorithms: petri net based analysis and design. In Proceedings, 2005 IEEE/ASME International Conference on Advanced Intelligent Mechatronics., 1407–1412. IEEE.
  • [Thomson and Young2010] Thomson, B., and Young, S. 2010. Bayesian update of dialogue state: A pomdp framework for spoken dialogue systems. Computer Speech & Language 24(4):562–588.
  • [Verma et al.2005] Verma, V.; Estlin, T.; Jónsson, A.; Pasareanu, C.; Simmons, R.; and Tso, K. 2005. Plan execution interchange language (plexil) for executable plans and command sequences. In International symposium on artificial intelligence, robotics and automation in space (iSAIRAS).
  • [Xu et al.2002] Xu, D.; Volz, R.; Ioerger, T.; and Yen, J. 2002. Modeling and verifying multi-agent behaviors using predicate/transition nets. In Proceedings of the 14th international conference on Software engineering and knowledge engineering, 193–200. ACM.
  • [Ziparo et al.2011] Ziparo, V. A.; Iocchi, L.; Lima, P. U.; Nardi, D.; and Palamara, P. F. 2011. Petri net plans. Autonomous Agents and Multi-Agent Systems 23(3):344–383.
Comments 0
Request Comment
You are adding the first comment!
How to quickly get a good reply:
  • Give credit where it’s due by listing out the positive aspects of a paper before getting into which changes should be made.
  • Be specific in your critique, and provide supporting evidence with appropriate references to substantiate general statements.
  • Your comment should inspire ideas to flow and help the author improves the paper.

The better we are at sharing our knowledge with each other, the faster we move forward.
The feedback must be of minimum 40 characters and the title a minimum of 5 characters
Add comment
Loading ...
This is a comment super asjknd jkasnjk adsnkj
The feedback must be of minumum 40 characters
The feedback must be of minumum 40 characters

You are asking your first question!
How to quickly get a good answer:
  • Keep your question short and to the point
  • Check for grammar or spelling errors.
  • Phrase it like a question
Test description