Petri Net Machines for Human-Agent Interaction

09/13/2019 ∙ by Christian Dondrup, et al. ∙ Heriot-Watt University 13

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.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 7

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

Introduction

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 dqn 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 hai in general or hri 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 hai scenarios and is, therefore, often scaffolded by simulating user interactions. This is particularly prevalent in sds, see surveys by e.g. [Schatzmann et al.2006, Pietquin and Hastie2013]. Using a fsm 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 hri and for dialogue management for smart speakers still rely on fsm. Examples for this are smach [Bohren and Cousins2010] for the ros or [Thomson and Young2010, Curry et al.2018] in the wider sense in case of sds.

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 hai and hri is that a myriad of actions might have to happen at the same time. An example for this in hri 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 fsm 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 dfsm automatically. These dfsm are based on pn 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 pn making this approach even more versatile and powerful. Moreover, the approach presented here also allows to execute several pn concurrently to allow to interleave tasks or execute them at the same time.

In this paper we present our execution system based on pn developed with the ros in mind. It natively supports ros action servers and presents an alternative to smach [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 fsm for. However, it comes with all the benefits of a pn 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 kb 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. fsm and pn. Another popular approach, i.e. rl, 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 rl for agent control.

Finite State Machines

One can implement a fsm in any programming language. There are some examples where these fsm have been specialised for robot control. An early example of using fsm 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 fsm and communicated with each other via a network. As mentioned earlier, the most notable due to the widely used ros is smach [Bohren and Cousins2010]. It was created for rapid development and provides convenient introspection tools. Instead of creating fsm by hand, others aim to create them automatically such as ROSPlan [Cashmore et al.2015]. Here, the authors of the paper use a pddl 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 ros interface to execute those actions in the order given by the planner. This sequence of actions itself can also be regarded as a fsm in the wider sense.

The vast majority of fsm 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 pn 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 pn. 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 pn 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 pnp was presented in [Ziparo et al.2011]. This approach has later on been used in different scenarios of hri 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 pnp [Carlucci et al.2015]. For this reason, the work presented here builds on pnp. In previous work [Dondrup et al.2017], we already extended pnp to work in combination with ROSPlan [Cashmore et al.2015] to automatically translate the plan created into a pnp 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 pn. Moreover, it defines a modelling language, supports automated pn generation, has tight ros integration, allows the concurrent execution of multiple pn, and provides an improved implementation.

Petri Nets

Figure 2: Example of concurrent states in a pn. 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 pn example. (top) shows a pn with marking and weights . (bottom) shows the pn after transition occurred where the marking changes to .

Based on work by Petri [Petri1962], the theory, notation, and representation of pn 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, pn 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 pn is

(1)

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 pn. The tokens (black dots) represent the current marking of the net. shows the pn before transition occurs and shows the same pn 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

(2)

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 pn. 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 pn and dfsm. 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 pn have been used to model and analyse all kinds of automata including fsm.

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

(3)

which allows us to create our new marking using Equation 2. Since pn 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 pn model to automatically create and execute dfsm and not just an elementary net such as in prior approaches. To this end we define pnm where is a Petri Net and is the initial marking of the net. similar to the of dfsm represents goal states. Reaching a goal state in a pnm translates into a goal place being included in the current marking . Hence, the execution has reached its goal if .

ROS Petri Net Machines

The ros is a popular choice for a large number of research institutes and the industry when it comes to controlling their robots111While ros 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. ros also comes with its very own implementation of a state machine, i.e. SMACH [Bohren and Cousins2010]. smach is a python framework for creating dfsm 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 dfsm on pnm. Similar to [Ziparo et al.2011], we use ros action servers which are triggered whenever a transition occurs, but we also allow to generate the pnm on-the-fly based on prior work [Dondrup et al.2017].

The system presented in the following is based on pnp by [Ziparo et al.2011] but extends on their idea and improves the implementation to support automatic generation of pnm, handle concurrent execution of multiple pnm, speed up the execution, and to better exploit the native ros infrastructure. The latter is achieved by using ros 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 pn. In addition, we also provide a modelling language that makes it easy to define pnm without much programming. The code is open source and freely available.222https://github.com/cdondrup/petri˙net/tree/ros

Action Servers

Figure 4: Example of a ros action with the 3 outcomes of a typical ros 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 Servers333http://wiki.ros.org/actionlib are one of the most used principles in ros 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_base444http://wiki.ros.org/move˙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 ros. smach [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 pn-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 ros action server that is able to query the underlying kb. 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 kb. Both QUERY and UPDATE provide the functionality of specifying the LOCAL, GLOBAL, or ALL kb. The letter first querying LOCAL and if no value is returned the GLOBAL kb.

Knowledge-Base

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 kb 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 kb operation can be included in the plan to save the data under the required name before is executed555kb operations do not require an action server to be implemented but are executed by the pnm directly operating on the kb.. 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 kb for each pnm that is executed, we allow the concurrent execution of several plans (see the Concurrent Multi-threaded Execution section) each having their own kb making it thread safe.

The framework can also be interfaced with a number of global kb 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 kb 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 pnm, after finding all possible instances of restaurants, can query the global kb (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 pnm 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 pnm continues as expected. If the action failed, the pnm reports a failure and if the action is interrupted (i.e. preempted in ros terminology), followup recoveries can be defined manually or the pnm 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.

1
2actions:
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”]
18
Listing 2: Example domain excerpt following a pddl 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 pnm. An example domain can be seen in Listing 2. The markup language used is yaml and the layout for the domain file is based on pddl. 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 kb 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 kb 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 kb 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 ros pn action or rpn_action (see Listing 2). This means that it is able to communicate with the pn execution server to query or update information at runtime (see Listing 1).

Figure 5: The conceptual structure of the pnm 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).
1initial_knowledge:
2 value: 3
3plan:
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 kb 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 kb. Figure 5 shows the resulting conceptual representation of a pnm.

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 ros 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 pnm, the system also allows to concurrently execute several pnm which is a novel contribution compared to other pn-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 pnm 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).

Experiment

The work presented in this paper is part of the MuMMER project666http://www.mummer-project.eu/ 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 Finland777https://lempaala.ideapark.fi. 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 pnm 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 pnm 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 pnm 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 pnm 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.

Conclusion

The pnm presented here allows developers to automatically create state machines form a simple mark up text file. It uses the modelling powers of pn to handle concurrency and also allows to implement constructs such as loops. In comparison to previous approaches using pn for similar tasks, the pnm presented here implements the full functionality of the Petri Net, allows for concurrent execution of several pn, and natively supports ros action servers while also allowing to create actions that can interact with a common kb 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 pddl. pddl style syntax is used for the domain file of the pnm while the plan file follows its own unique syntax. However, in comparison to pddl, the mark up language of choice, i.e. yaml, 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 pnm working as intended. This evidence stems from user tests in the shopping mall that evaluated different parts of a greater system but all used pnm as the underlying execution system.

In conclusion, we have presented a system that is able to generate dfsm as pnm, execute tasks successfully even if concurrent and also execute several pnm concurrently. It presents an alternative to other approaches such as smach [Bohren and Cousins2010] or pnp [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.

Acknowledgments

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

References

  • [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 https://www.techfak.uni-bielefeld.de/~mchen/BioPNML/Intro/MRPN.html.
  • [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.