Methodology of Designing Multi-agent Robot Control Systems Utilising Hierarchical Petri Nets

TL;DR

This paper introduces a hierarchical Petri net-based methodology for designing multi-agent robot control systems, enabling systematic development and automatic code generation to accelerate implementation.

Contribution

It presents a novel hierarchical Petri net approach for modeling robot systems and a tool for automatic controller code generation, improving development efficiency.

Findings

Hierarchical Petri nets effectively model concurrent subsystem activities.

The developed tool accelerates robot controller implementation.

Successful demonstration on a rudimentary robot task.

Abstract

A robot system is designed as a set of embodied agents. An embodied agent is decomposed into cooperating subsystems. In our previous work activities of subsystems were defined by hierarchical finite state machines. With their states, activities were associated. In that approach communication between subsystems was treated as an implementation issue. This paper represents the activities of a robot system using hierarchical Petri nets with conditions. Such net is created by specifying consecutive layers: multi-agent robot system layer, agent layer, subsystem layer, behaviour layer and communication layer. This decomposition not only organizes in a systematic manner the development of a robot system but also introduces a comprehensive description of concurrently acting subsystems. Based on those theoretical considerations, a tool was created for producing hierarchical Petri nets defining the model of a robotic system and enabling automatic generation of the robot controller code, resulting in a significant acceleration of the implementation phase. The capabilities of the tool are presented by the development of a robot controller performing a rudimentary task.

Figures

Equations

$$\left(\text{prescript}s{s}_{j,v}^{i+1},\text{prescript}y{s}_{j,v}^{i+1}\right):=\text{prescript}s{f}_{j,v,\omega }(\text{prescript}s{s}_{j,v}^i,\text{prescript}x{s}_{j,v}^i),$$

$$\begin{array}[]{l}\prescript{c,e\!}{}{f}_{1,\rm control}\triangleq\\[5.69054pt] \left\{\begin{array}[]{lcl}\left.\begin{array}[]{l}\prescript{e}{y}{c}_{1,\rm motor}^{i+1}[{\rm v_{lin}}]={\rm v}\\ \prescript{e}{y}{c}_{1,\rm motor}^{i+1}[{\rm v_{ang}}]={\rm 0}\end{array}\right\}&\mbox{for }&\mathcal{L}\land\mathcal{M}\land\mathcal{R}\\ \left.\begin{array}[]{l}\prescript{e}{y}{c}_{1,\rm motor}^{i+1}[{\rm v_{lin}}]={\rm v}\\ \prescript{e}{y}{c}_{1,\rm motor}^{i+1}[{\rm v_{ang}}]={\rm-\omega/15}\end{array}\right\}&\mbox{for }&\mathcal{L}\land\mathcal{M}\land\lnot\mathcal{R}\\ \left.\begin{array}[]{l}\prescript{e}{y}{c}_{1,\rm motor}^{i+1}[{\rm v_{lin}}]={\rm v}\\ \prescript{e}{y}{c}_{1,\rm motor}^{i+1}[{\rm v_{ang}}]={\rm-\omega}\end{array}\right\}&\mbox{for }&\mathcal{L}\land\lnot\mathcal{M}\land\lnot\mathcal{R}\\ \left.\begin{array}[]{l}\prescript{e}{y}{c}_{1,\rm motor}^{i+1}[{\rm v_{lin}}]={\rm v}\\ \prescript{e}{y}{c}_{1,\rm motor}^{i+1}[{\rm v_{ang}}]={\rm\omega/15}\end{array}\right\}&\mbox{for }&\lnot\mathcal{L}\land\mathcal{M}\land\mathcal{R}\\ \left.\begin{array}[]{l}\prescript{e}{y}{c}_{1,\rm motor}^{i+1}[{\rm v_{lin}}]={\rm v}\\ \prescript{e}{y}{c}_{1,\rm motor}^{i+1}[{\rm v_{ang}}]={\rm\omega}\end{array}\right\}&\mbox{for }&\lnot\mathcal{L}\land\lnot\mathcal{M}\land\mathcal{R}\\ \left.\begin{array}[]{l}\prescript{e}{y}{c}_{1,\rm motor}^{i+1}[{\rm v_{lin}}]={\rm-v}\\ \prescript{e}{y}{c}_{1,\rm motor}^{i+1}[{\rm v_{ang}}]={\rm-\omega/2}\end{array}\right\}&&{\rm otherwise}\\ \end{array}\right.\end{array}$$

Full text

I INTRODUCTION

Specification of a robotic system requires the determination of its architecture, i.e. structure and style [11]. Structure pertains to the decomposition of the robotic system into subsystems and presents interconnections between them. Style determines the computational and communication concepts utilised to design the system. In many cases the definition of the structure and style of the developed systems is not obvious [11], as often they were created without a clear architectural pattern.

The control system together with the devices it controls can be composed of one or more communicating agents [3, 8]. An agent is a separate system that has an internal imperative that rationally affects its surroundings based on the information collected from the environment. If the environment is physical in nature, then such an agent is called an embodied agent. An embodied agent affects the environment with its effectors and obtains data from it utilising its receptors [20, 3, 9, 22]. An embodied agent is decomposed into a set of communicating subsystems. The activity of each subsystem in our previous work was defined using hierarchical finite state machines (HFSM) [18, 5, 19]. Each state of the upper layer HFSM has a subFSM associated with it. Such subFSM specifies a single behaviour of the subsystem. Those HFSMs facilitate the specification of computational concepts associated with individual subsystems operating in parallel, however treated their communication as an implementation issue.

Alternatively architectural style can be described by a Petri net (PN) with conditions [13, 6, 7]. In that case system compliance with the requirements can be verified [12, 1], as Petri net verification tools exist, and above all, their ability to generate code automatically can be utilised. This paper presents a hierarchical Petri net $\mathcal{H}$ (HPN) modelling the activities of a robotic system decomposed into five layers: 1) multi-agent robot system layer composed of agents, 2) agent layer composed of subsystems, 3) subsystem layer assigning bahaviours to subsystem , 4) behaviour layer representing behaviours in terms of elementary activities and 5) communication layer defining the communication model utilised within a behaviour. Out of this HPN model, robot controller code is automatically generated and verified by simulation.

The structure of the paper is as follows. HPNs are presented in Sec. II. Sec. III briefly reveals the concept of an embodied agent. It presents a robotic system architecture in terms of its structure and activities. Sec. V introduces an example of a robotic system specified utilising the presented modelling method. It also discloses the method of automatic generation of robot controller code out of a HPN. Sec. VI presents the related work and the conclusions are drawn in Sec. VII.

II HPN WITH CONDITIONS

A Petri net is a bipartite graph containing transitions $t$ and places $p$ alternatively connected by directed arcs [13]. In a HPN some places can be substituted by pages $\mathcal{P}$. A page is a HPN with a distinguished single input place $p_{\rm in}$ and single output place $p_{\rm out}$. In this paper we use a HPN with conditions. In such nets with each transition a condition $\mathcal{C}$ is associated. When tokens are assigned to places the net becomes a marked HPN with conditions $\mathcal{H}$. With each place a single operation $\mathcal{O}$ is associated. Places from different nets can be fused with each other. Fused places $p^{\rm fusion}$ are in principle the same place appearing in two or more nets [7]. These places are indistinguishable from each other and thus contain the same tokens. Fusing places of different nets combines those nets into a single net of a more complex structure.

This article uses a graphical representation of the net $\mathcal{H}$ in which places are represented by single circles, pages by double circles, transitions by rectangles, directed arcs by arrows and tokens by black filled circles. Conditions $\mathcal{C}$ associated with transitions are placed within square brackets. If a condition is always fulfilled (i.e. is True) then it may be omitted. Association of two places: $p_{\mathcal{H}_{1},\alpha}^{\rm fusion}$ and $p_{\mathcal{H}_{2},\beta}^{\rm fusion}$, belonging respectively to nets: $\mathcal{H}_{1}$ and $\mathcal{H}_{2}$ is represented by a single place $p_{(\mathcal{H}_{1},\mathcal{H}_{2}),(\alpha,\beta)}^{\rm fusion}$. The definition of a safe HPN requires that in each of its places at the most one marker resides.

III EMBODIED AGENT ARCHITECTURE

III-A Structure

The internal structure of an embodied agent $a_{j}$ ($j$ – name of the agent) is presented in Fig. 1. An agent consists of the control subsystem $\prescript{}{}{c}_{j}$ receiving the aggregated data about the environment from the virtual receptors $\prescript{}{}{r}_{j,k}$ ($k$ – name of a specific virtual receptor) and based on the received data and its internal imperative it formulates the control commands for its virtual effectors $\prescript{}{}{e}_{j,n}$ ($n$ – name of a specific virtual effector). Virtual effectors transform the commands received from $\prescript{}{}{c}_{j}$ into a form acceptable to the real effectors $\prescript{}{}{E}_{j,h}$ ($h$ – name of real effector), whereas virtual receptors aggregate data from the real receptors $\prescript{}{}{R}_{j,l}$ ($l$ – name of a real receptor) into a form acceptable to $\prescript{}{}{c}_{j}$. The agent’s subsystems communicate with each other through buffers (as presented in Fig. 1). A systematic method of naming buffers is used [9, 22]. The letter in the center indicates the type of the subsystem $s$, where $s\in\{\prescript{}{}{c},\prescript{}{}{e},\prescript{}{}{r},\prescript{}{}{E},\prescript{}{}{R}\}$. The right subscript determines the names of: the agent, the subsystem and if it is necessary, the buffer component. While, the left subscript determines, whether the buffer is an input buffer ($x$), output buffer ($y$) or internal memory (in this case this subscript is omitted). The right superscript determines the discrete time stamp, e.g. $i$, whereas the left superscript, determines the type of the subsystem, from which the data is obtained or to which the data is directed. For example: 1) $\prescript{r}{x}{c}_{j,v}^{i}$ is the content of the input buffer receiving data from the virtual receptor output buffer at a discrete time $i$; this input buffer is a part of the control subsystem $\prescript{}{}{c}_{j}$ of the agent $a_{j}$, 2) $\prescript{c}{}{c}_{j}^{i}$ is the internal memory of $\prescript{}{}{c}_{j}$ at time $i$. It should be noted that each subsystem can run at a different sampling rate, thus $i$ for each of those subsystems is different (context distinguishes them).

III-B Activities

A HPN $\mathcal{H}$ determining the activities of a multi-agent robot system consists of five layers (Fig. 2):

multi-agent robot system layer composed of a single net $\mathcal{H}$ defining individual pages $\mathcal{P}_{j}$ for each agent $a_{j}$ within the multi-agent robot system, 2. 2.

agent layer composed of nets $\mathcal{H}_{j}$ responsible for the activation of pages ${}^{s}\mathcal{P}_{j,v}$, which in turn determine the activities of individual subsystems $\prescript{}{}{s}_{j,v}$ ($v$ is the subsystem designator), $s\in\{\prescript{}{}{c},\prescript{}{}{e},\prescript{}{}{r}\}$, 3. 3.

subsystem layer defining nets ${}^{s}\mathcal{H}_{j,v}$ represented by pages ${}^{s}\mathcal{P}_{j,v}$; each net ${}^{s}\mathcal{H}_{j,v}$ contains pages ${}^{s}\mathcal{P}_{j,v\!,\,\omega}^{\mathcal{B}}$ defining particular behaviours $\prescript{s}{}{\mathcal{B}}_{j,v,\omega}$ of $\prescript{}{}{s}_{j,v}$ ($\omega$ is the behaviour designator), 4. 4.

behaviour layer defining behaviours $\prescript{s}{}{\mathcal{B}}_{j,v,\omega}$ represented by pages ${}^{s}\mathcal{P}_{j,v,\omega}^{\mathcal{B}}$, 5. 5.

communication layer determining the communication models used by behaviours $\prescript{s}{}{\mathcal{B}}_{j,v,\omega}$, i.e. defining pages ${}^{s}\mathcal{P}_{j,v,\omega,\rm snd}^{\mathcal{B}}$ (net describing behaviour of $\prescript{}{}{s}_{j,v}$ when data is sent to other subsystems) and ${}^{s}\mathcal{P}_{j,v,\omega,\rm rcv}^{\mathcal{B}}$ (description of how $\prescript{}{}{s}_{j,v}$ behaves when it receives data from other subsystems); example is in Fig. 3; It should be noted that the communication models used both for sending and receiving data pertain to the same subsystem $\prescript{}{}{s}_{j,v}$, and not to the system $\prescript{}{}{s}_{j,h}$ with which $\prescript{}{}{s}_{j,v}$ communicates.

Out of the five layers of $\mathcal{H}$ three have user defined structure, the behaviour layer has a fixed structure, and the communication layer is composed of predefined blocks. The first two layers trigger parallel execution of nets representing the activities of agents and subsystems respectively. Subsystem $\prescript{}{}{s}_{j,v}$ executes its behaviours $\prescript{s}{}{\mathcal{B}}_{j,v,\omega}$. Any behaviour $\prescript{s}{}{\mathcal{B}}_{j,v,\omega}$ calculates the transition function $\prescript{s\!}{}{f}_{j,v,\omega}$ associated with it producing:

[TABLE]

sends the produced output data (from the output buffer $\prescript{}{y}{s}_{j,v}$) to the associated subsystems, updates the discrete time $i$, receives data from the associated subsystems (this data appears in the input buffer $\prescript{}{x}{s}_{j,v}$) and finally checks the error condition $\prescript{s\!}{}{f}_{j,v,\beta}^{\varepsilon}$ and terminal condition $\prescript{s\!}{}{f}_{j,v,\xi}^{\tau}$, where $\beta$ and $\xi$ are the designators of the error and the terminal conditions respectively. The behaviour iterates until one of the above-mentioned conditions is fulfilled. Once a behaviour is terminated, the choice of the next one is based on a predicate called an initial condition $\prescript{s\!}{}{f}_{j,v,\alpha}^{\sigma}$($\alpha$ – predicate designator) [21]. Initial conditions of next behaviours are associated with the transitions pointed at by the arcs emerging from the place with which the just terminated behaviour is associated.

The communication model must define whether communicating subsystems activities are blocked during the data transfer or not. Both the producer and the consumer may operate either in blocking or non-blocking mode. The blocking mode causes the producer to wait for the consumer to confirm that data has been received. In the non-blocking mode the producer does not wait for this confirmation and instantaneously resumes its other activities. In the blocking mode the consumer waits until it receives the data, while in the non-blocking mode it resumes its other operations if data is unavailable. A non-blocking mode used by both the producer and consumer is called a fully asynchronous communication model.

IV CONSTRUCTION OF SYSTEM LAYERS

Construction of a HPN of consecutive system layers is performed as described below (Fig. 2).

IV-A HPN $\mathcal{H}$ of the multi-agent robot system layer

Add to $\mathcal{H}$ a page $\mathcal{P}_{j}$ for each agent $a_{j}$ within the multi-agent robot system, 2. 2.

Add to $\mathcal{H}$ two transitions ${t}_{\rm in}$ and ${t}_{\rm out}$, 3. 3.

Connect by directed arcs ${t}_{\rm in}$ to each $\mathcal{P}_{j}$ and each $\mathcal{P}_{j}$ to ${t}_{\rm out}$.

IV-B HPN $\mathcal{H}_{j}$ of the agent layer

Create a page ${}^{s}\mathcal{P}_{j,v}$ for each subsystem $\prescript{}{}{s}_{j,v}$ within $a_{j}$. For $\prescript{}{}{c}_{j}$ create page ${}^{s}\mathcal{P}_{j,c}$, 2. 2.

Create two transitions ${t}_{j,\rm in}$ and ${t}_{j,\rm out}$, 3. 3.

Connect ${t}_{j,\rm in}$ to each page by a directed arc, 4. 4.

Connect each page to ${t}_{j,\rm out}$ by a directed arc, 5. 5.

Create a place ${p}_{j,\rm in}$ and connect it to ${t}_{j,\rm in}$ by a directed arc, 6. 6.

Create a place ${p}_{j,\rm out}$; connect ${t}_{j,\rm out}$ to ${p}_{j,\rm out}$ by a directed arc.

IV-C HPN ${}^{s}\mathcal{H}_{j,v}$ of the subsystem layer

Create a page ${}^{s}\mathcal{P}_{j,v,\omega}^{\mathcal{B}}$ for each behaviour $\prescript{s}{}{\mathcal{B}}_{j,v,\omega}$ exhibited by the subsystem $\prescript{}{}{s}_{j,v}$, 2. 2.

For each behaviour $\prescript{s}{}{\mathcal{B}}_{j,v,\omega}$ (i.e. ${}^{s}\mathcal{P}_{j,v,\omega}^{\mathcal{B}}$) determine the initial conditions $\prescript{s\!}{}{f}_{j,v,\alpha}^{\sigma}$ that will be associated with transitions ${t}_{j,v,\alpha}$ leading to successor behaviours $\prescript{s}{}{\mathcal{B}}_{j,v,\delta}$ (i.e. ${}^{s}\mathcal{P}_{j,v,\delta}^{\mathcal{B}}$). Connect ${}^{s}\mathcal{P}_{j,v,\omega}^{\mathcal{B}}$ to all successor pages in the following way: connect ${}^{s}\mathcal{P}_{j,v,\omega}^{\mathcal{B}}$ to ${t}_{j,v,\alpha}$ and ${t}_{j,v,\alpha}$ to ${}^{s}\mathcal{P}_{j,v,\delta}^{\mathcal{B}}$ by directed arcs for all successor pages ${}^{s}\mathcal{P}_{j,v,\delta}^{\mathcal{B}}$. 3. 3.

Add to ${}^{s}\mathcal{H}_{j,v}$ two places: ${{}^{s}p}_{j,v,\rm in}$ – input place and ${{}^{s}p}_{j,v,\rm out}$ – output place, and two transitions ${{}^{s}t}_{j,v,\rm in}$ and ${{}^{s}t}_{j,v,\rm out}$. Place ${{}^{s}p}_{j,v,\rm in}$ is connected through ${{}^{s}t}_{j,v,\rm in}$ to a page that represents the initial behaviour of the subsystem. The page representing the terminal behaviour of the subsystem is connected by a directed arc to ${{}^{s}t}_{j,v,\rm out}$, which in turn is connected by another arc to the place ${{}^{s}p}_{j,v,\rm out}$. The places ${{}^{s}p}_{j,v,\rm in}$ and ${{}^{s}p}_{j,v,\rm out}$ are the input and output places of ${}^{s}\mathcal{H}_{j,v}$ (i.e. ${}^{s}\mathcal{P}_{j,v}$).

IV-D HPN ${}^{s}\mathcal{H}_{j,v,\omega}^{\mathcal{B}}$ of the behaviour layer

The structures of all HPNs ${}^{s}\mathcal{H}_{j,v,\omega}^{\mathcal{B}}$ represented by ${}^{s}\mathcal{P}_{j,v,\omega}^{\mathcal{B}}$ follow a single pattern, thus they do not have to be created. Only the parameters of their activities have to be delivered, i.e.: transition function $\prescript{s\!}{}{f}_{j,v,\omega}$, error condition $\prescript{s\!}{}{f}_{j,v,\beta}^{\varepsilon}$ and terminal condition $\prescript{s\!}{}{f}_{j,v,\xi}^{\tau}$, as well as the communication models utilised within pages ${}^{s}\mathcal{P}_{j,v,\omega,\rm snd}^{\mathcal{B}}$ and ${}^{s}\mathcal{P}_{j,v,\omega,\rm rcv}^{\mathcal{B}}$. Behaviour $\prescript{s}{}{\mathcal{B}}_{j,v,\omega}$ is executed by ${}^{s}\mathcal{H}_{j,v,\omega}^{\mathcal{B}}$ in the following way.

The execution of behaviour $\prescript{s}{}{\mathcal{B}}_{j,v,\omega}$ starts when a token appears in the place ${{}^{s}p}_{j,v,\omega,\rm in}$. This initiates the operation ${}^{s\!}\mathcal{O}_{j,v,\omega,1}^{\mathcal{B}}$ which consists in calculation of the transition function $\prescript{s\!}{}{f}_{j,v,\omega}$ by using (1). Transition ${{}^{s}t}_{j,v,\omega,1}$ will not fire until the calculation is complete. 2. 2.

Firing the transition ${{}^{s}t}_{j,v,\omega,1}$ places a single token in the page ${}^{s}\mathcal{P}_{j,v,\omega,\rm snd}^{\mathcal{B}}$, initiating its execution. Page ${}^{s}\mathcal{P}_{j,v,\omega,\rm snd}^{\mathcal{B}}$ represents a net ${}^{s}\mathcal{H}_{j,v,\omega,\rm snd}^{\mathcal{B}}$ determining the communication model used to send the contents of the output buffers $\prescript{}{y}{s}_{j,v}^{i}$ to the connected subsystems. When the page ${}^{s}\mathcal{P}_{j,v,\omega,\rm snd}^{\mathcal{B}}$ finishes its execution, the transition ${{}^{s}t}_{j,v,\omega,2}$ is ready to fire, 3. 3.

The operation ${}^{s\!}\mathcal{O}_{j,v,\omega,2}^{\mathcal{B}}$ is associated with the place ${{}^{s}p}_{j,v,\omega,2}$ that receives the token. It increments the discrete time $i$ of the subsystem $\prescript{}{}{s}_{j,v}$, 4. 4.

Firing the transition ${{}^{s}t}_{j,v,\omega,3}$ activates the page ${}^{s}\mathcal{P}_{j,v,\omega,\rm rcv}^{\mathcal{B}}$, which represents the net ${}^{s}\mathcal{H}_{j,v,\omega,\rm rcv}^{\mathcal{B}}$ determining in what mode is the data received from the associated subsystems, 5. 5.

When the page ${}^{s}\mathcal{P}_{j,v,\omega,\rm rcv}^{\mathcal{B}}$ completes its activity, the error condition ${}^{s}\!f_{j,v,\beta}^{\epsilon}$ and the terminal condition ${}^{s}\!f_{j,v,\xi}^{\tau}$ are checked. If none of them is fulfilled, the next iteration of behaviour $\prescript{s}{}{\mathcal{B}}_{j,v,\omega}$ starts. Otherwise a single token is placed in the output place ${{}^{s\!}p}_{j,v,\omega,\rm out}$. This terminates the behaviour $\prescript{s}{}{\mathcal{B}}_{j,v,\omega}$ execution, and thus completes the activities of the page ${}^{s}\mathcal{P}_{j,v,\omega}^{\mathcal{B}}$. The control returns then to the net ${}^{s}\mathcal{H}_{j,v}$.

IV-E Communication layer – determination of communication model utilised within behaviour ${}^{s}\mathcal{B}_{j,v,\omega}$

The nets composing the communication layer again do not have to be created. As the number of communication patterns is limited, only the selection of the required pattern has to be made. The communication layer is composed of two pages ${}^{s}\mathcal{P}_{j,v,\omega,\rm snd}^{\mathcal{B}}$ and ${}^{s}\mathcal{P}_{j,v,\omega,\rm rcv}^{\mathcal{B}}$. The first one defines how $\prescript{}{}{s}_{j,v}$ sends the data to other subsystems and the second one determines how it receives the data from other subsystems. Those two pages interact with similar pages of the subsystems that $\prescript{}{}{s}_{j,v}$ communicates with. Those pages are created in the following way.

Select the communication model between subsystem $\prescript{}{}{s}_{j,v}$ and other subsystems $\prescript{}{}{s}_{j,h}$, 2. 2.

Express this model in the form of a Petri net (selection of an appropriate net for the two subsystems $\prescript{}{}{s}_{j,v}$ and $\prescript{}{}{s}_{j,h}$), 3. 3.

Divide this Petri net into two Petri nets with fused places: a) presenting how the data is sent, b) presenting how the data is received,

This procedure has to be repeated twice. Once to define how subsystem $\prescript{}{}{s}_{j,v}$ sends the data and once to define how it receives data.

Out of several communication models the fully asynchronous one was selected to exemplify the design procedure. It functions in the following way. The two communicating subsystems are: $\prescript{}{}{s}_{j,v}$ and $\prescript{}{}{s}_{j,h}$. The former executes the behaviour ${}^{s}\mathcal{B}_{j,v,\omega}$ and sends data to the latter, which executes the behaviour ${}^{s}\mathcal{B}_{j,h,\omega^{\prime}}$ (Fig. 3a). Both subsystems, i.e. $\prescript{}{}{s}_{j,v}$ and $\prescript{}{}{s}_{j,h}$, in this mode of communication, compete for access to the communication channel, which contains shared memory. Only a single subsystem may access the shared memory at a time. When subsystem $\prescript{}{}{s}_{j,v}$ gains access to the memory, it removes the token from the place ${{}^{s}p}_{j,(v,h),(\omega,\omega^{\prime}),(\rm snd,\rm rcv)}^{\rm fusion}$, starts the activity associated with place ${{}^{s}p}_{j,v,\omega,{\rm snd},2}$ (inserts the data in the shared memory) and then inserts tokens in places ${{}^{s\!}p}_{j,(v,h),(\omega,\omega^{\prime}),(\rm snd,\rm rcv)}^{\rm fusion}$ and ${{}^{s}p}_{j,v,\omega,{\rm snd},\rm out}$, thus terminating the communication episode. The system receiving the data acts similarly. The subscripts of the fusion place ${{}^{s\!}p}_{j,(v,h),(\omega,\omega^{\prime}),(\rm snd,\rm rcv)}^{\rm fusion}$ specify the direction of data transmission, i.e. from the subsystem $\prescript{}{}{s}_{j,v}$ (executing behaviour ${}^{s}\mathcal{B}_{j,v,\omega}$) to the subsystem $\prescript{}{}{s}_{j,h}$ (executing behaviour ${}^{s}\mathcal{B}_{j,h,\omega^{\prime}}$), emphasizing that this place belongs to both nets ${}^{s}\mathcal{H}_{j,v,\omega}^{\mathcal{B}}$ and ${}^{s}\mathcal{H}_{j,h,\omega^{\prime}}^{\mathcal{B}}$. The net presented in Fig. 3a can then be decomposed into two nets that are respectively pages: ${}^{s}\mathcal{P}_{j,v,\omega,\rm snd}^{\mathcal{B}}$ (Fig. 3 b) and ${}^{s}\mathcal{P}_{j,h,\omega^{\prime},\rm rcv}^{\mathcal{B}}$ (Fig. 3c). Places ${{}^{s\!}p}_{j,v,\omega,\rm snd}^{\rm fusion}$ and ${{}^{s}p}_{j,h,\omega^{\prime},\rm rcv}^{\rm fusion}$ are associated with each other creating a single place ${{}^{s\!}p}_{j,(v,h),(\omega,\omega^{\prime}),(\rm snd,\rm rcv)}^{\rm fusion}$. Page ${}^{s}\mathcal{P}_{j,v,\omega,\rm rcv}^{\mathcal{B}}$ representing behaviour ${}^{s}\mathcal{B}_{j,v,\omega}$ is determined analogically.

If the subsystem $\prescript{}{}{s}_{j,v}$ sends or receives data to or from two or more subsystems, the pages of subsystem $\prescript{}{}{s}_{j,v}$ have to be adequately connected. For instance, let subsystem $\prescript{}{}{s}_{j,v}$ send data to $\prescript{}{}{s}_{j,h}$ and $s_{j,h^{\prime}}$. Pages are defined for each pair of communicating subsystems. The pages ${}^{s}\mathcal{P}_{j,v,\omega,\rm snd,h}^{\mathcal{B}}$ and ${}^{s}\mathcal{P}_{j,v,\omega,\rm snd,h^{\prime}}^{\mathcal{B}}$, specifying the communication of $\prescript{}{}{s}_{j,v}$ with $\prescript{}{}{s}_{j,h}$ and $s_{j,h^{\prime}}$, are connected with each other by association of output place of page ${}^{s}\mathcal{P}_{j,v,\omega,\rm snd,h}^{\mathcal{B}}$ with the input place of page ${}^{s}\mathcal{P}_{j,v,\omega,\rm snd,h^{\prime}}^{\mathcal{B}}$. This results in the creation of a single page ${}^{s}\mathcal{P}_{j,v,\omega,\rm snd}^{\mathcal{B}}$ describing sequential data transfer, first from $\prescript{}{}{s}_{j,v}$ to $\prescript{}{}{s}_{j,h}$, and then from $\prescript{}{}{s}_{j,v}$ to $s_{j,h^{\prime}}$. Alternatively, those pages can be connected in such a way that the data will be sent in parallel to the subsystems $\prescript{}{}{s}_{j,h}$ and $s_{j,h^{\prime}}$. Other communication models mentioned in section III-B require different Petri nets than the one presented in Fig. 3a. They are not presented here due to lack of space.

V EXAMPLE

The presented design methodology is currently tested by specifying robot systems and automatically generating their control code. The example presented here is purposefully kept simple to explicate the methodology and not to obscure it by overly complex robot and its task. Thus the control system of a rudimentary simulated robot executing the follow the line task is presented.

V-A Specification

The task of a two-wheeled robot is to follow a black curve painted on a plane contrasting surface (Fig. 5(a)).

Robot system structure

The designed robot system is composed of a single embodied agent $a_{1}$. The agent $a_{1}$ contains: control subsystem $\prescript{}{}{c}_{1}$, virtual receptor $\prescript{}{}{r}_{1,\rm sensor}$, virtual effector $\prescript{}{}{e}_{1,\rm motor}$, two real effectors $\prescript{}{}{E}_{1,\rm motor_{1}}$, $\prescript{}{}{E}_{1,\rm motor_{2}}$, being the two motors actuating two wheels, and three real receptors $\prescript{}{}{R}_{1,\rm sensor_{1}}$, $\prescript{}{}{R}_{1,\rm sensor_{2}}$ and $\prescript{}{}{R}_{1,\rm sensor_{3}}$ detecting the intensity of the light reflected from the floor surface. The virtual receptor $\prescript{}{}{r}_{1,\rm sensor}$ aggregates data from the real receptors and then forwards the result to $\prescript{}{}{c}_{1}$. The control subsystem, uses the data received from $\prescript{}{}{r}_{1,\rm sensor}$ and sends appropriate commands to $\prescript{}{}{e}_{1,\rm motor}$, which computes the inverse kinematics to control the real effectors.

Robot system activities

The designed robot system consists only of a single agent $a_{1}$ thus HPN $\mathcal{H}$ consists of a single page $\mathcal{P}_{1}$. Petri net $\mathcal{H}_{1}$ determining the agent layer is presented in Fig. 5(b), subsystem layer in Fig. 6(a), behaviour layer in Fig. 6(b) and communication layer in Fig. 3a. For the sake of briefness this paper presents only the control subsystem $\prescript{}{}{c}_{1}$ HPN ${}^{c}\mathcal{H}_{1}$, which exhibits two behaviours: ${}^{c}\mathcal{B}_{1,\rm init}$, which initiates the connection with the simulated robot, and ${}^{c}\mathcal{B}_{1,\rm control}$, which calculates the transition function $\prescript{c,e\!}{}{f}_{1,\rm control}$ (Fig. 4), i.e. calculates the robot linear ${\rm v_{\rm lin}}$ and angular ${\rm v_{\rm ang}}$ velocities using the data received from $\prescript{}{}{r}_{1,\rm sensor}$, and sends them to $\prescript{}{}{e}_{1,\rm motor}$, where the wheel speeds are produced. The specification of $\prescript{c,e\!}{}{f}_{1,\rm control}$ (Fig. 4) must be transformed manually into C++ code, which is subsequently inserted into the robot controller code by the development tool. $\prescript{c,e\!}{}{f}_{1,\rm control}$ is evaluated as an operation associated with the place ${{}^{c}p}_{1,c,\rm control,\rm in}$ in Fig. 6(b).

V-B Petri net generation and execution

The generation of a robot controller code requires the creation of the $\mathcal{H}$ HPN and its subnets. For that purpose a tool has been developed by the authors. The designed Petri net is automatically transformed into C++ code, forming the robot controller. The generated controller representing the HPN with an initial marking is then merged with the library executing the HPN. The resulting C++ code is compiled and the outcome is loaded into the control computer. The code invokes the scheduler, which searches for active transitions (enabled transition with fulfilled condition). One of such transitions is fired, i.e. a token is removed from each input place (place directly connected to the fired transition by a directed arc pointing at the transition) and inserts tokens into each output place (place directly connected to the transition by a directed arc pointing at the place). The operations associated with the output places are executed in separate threads. When the directed arc connects the firing transition with an output page, the input place of that page receives a new token and the associated operation of that input place starts its execution in a new thread. The scheduler repeats the above-mentioned steps either endlessly or until a behaviour commands it to terminate its activities.

V-C Simulation

The robot following a line was simulated utilising the VREP simulator [16]. The simulator utilises a model of the robot (two-wheeled mobile robot from the VREP model library), exemplary environment (the floor with a black line on it) and the automatically generated robot controller, specified by the $\mathcal{H}$ HPN. The generated controller is a C++ code which controls the execution of subsystems working in parallel: $\prescript{}{}{c}_{1}$, $\prescript{}{}{r}_{1,\rm sensor}$, $\prescript{}{}{e}_{1,\rm motor}$. Real subsystems $\prescript{}{}{E}_{1,\rm motor_{1}}$, $\prescript{}{}{E}_{1,\rm motor_{2}}$, $\prescript{}{}{R}_{1,\rm sensor_{1}}$, $\prescript{}{}{R}_{1,\rm sensor_{2}}$ and $\prescript{}{}{R}_{1,\rm sensor_{3}}$ are a part of the VREP simulator.

VI RELATED WORKS

Non-hierarchical PNs have been used for robot control, e.g. [17]. Construction of HPNs by substituting transitions by PNs or places by PNs, and place or transition fusion is described in [7, 14]. Substitution of a PN for a place [7] requires the determination of the input transitions and the output transitions in the parent PN. As the number of input places and output places in the substituted net is not limited, this unnecessarily complicates the structure of the net for our case. In [15, 23, 2, 10] a HPN is created by substituting transitions or places, however place or transition fussion is not considered, thus those nets do not meet the requirements imposed on nets modeling a robot system. In [7] three types of place fusion are distinguished: instance fusion set, page fusion set and global fusion set. The fusion set is a set of places which can be fused into a single place. The instance fusion set merges only places which are in the same page instance, the page fusion set merges places which occur within all instances of the same page, while the global fusion merges all places in the fusion set within the PN. The proposed place fusion types are excessive for our purposes.

As the above mentioned nets are too complex a version tailored to our purposes was developed for the description of the multi-agent robot system activities. Our HPN $\mathcal{H}$ is created using only two constructs: substitution of a place by a net and global fusion of places. Moreover, unlike in [7, 15, 2, 10], where the substituting net could have any structure, a page in our approach can have only a single input place and a single output place. This causes that the definition of the page does not require reference to the transitions located in the parent net (because it is known with which transitions the place is connected). As a result, the page is much simpler to analyze. Moreover, in contrast to the above nets, the HPN we propose, associates operations with places and predicates with transitions.

VII CONCLUSIONS

The paper presents a systematic methodology of designing multi-layer HPNs defining the activities of multi-agent robot systems. Our previous approach was based on HFSM. It treated the communication model used between subsystems as an implementation detail. The communicating subsystems acted independently of each other. Since embodied agents contain communicating subsystems and the communication model between those subsystems was not revealed during system specification, it was difficult to verify the correctness of the developed robotic system. The interactions between subsystems using single HFSMs, assuming sequential execution of subsystem activities, was presented in [18, 5, 19].

A natural inclusion of the communication model into the system specification is possible by using HPNs with conditions. The proposed approach, follows the primary principle of structured programming, stating that the programmer must keep at all times the produced code within his or her intellectual grasp [4]. It structures a robotic system into layers of PNs describing the activities of ever smaller modules. The presented approach enables automatic code generation of the robotic controller. The resulting specification is a single HPN describing the activities of the concurrently executed activities of subsystems, also describing their interactions. The proposed specification method can be used to describe the activities of any robotic system. For a multi-robot system the developer defines separate HPNs for each robot (being itself a multi-agent system). Those HPNs communicate with each other using communication models implemented as interprocess communication.

The purpose of the example presented in this paper has been the exemplification of the proposed specification and implementation method by focusing the reader’s attention only on the methodology, treating the specified robotic system as of secondary importance, thus its rudimentary character. More complicated systems require the development of more complex HPNs. Any addition of a place to a net requires 6 extra lines of code, a new transition generates 6 additional lines, an extra directed arc only a single line, while a page 48 lines. Thus it can be shown that the size of the generated code grows linearly with the size of the designed Petri net, hence the presented approach based on HPNs is scalable.