**1. Introduction**

Because of the generality of the robot's physical structure, control and reprogrammability, it is expected that more and more robots will be introduced into industry to automate various operations. This flexibility can be exploited if the robot control system can be programmed easily. Anyway, it is quite obvious that a single robot cannot perform effective tasks in an industrial environment, unless it is provided with some additional equipment. For example, in building a component, two robots are required to cooperate, one holding some part while the other attaches some other part to it. In other tasks, robots may pursue different goals, making sure that they both don't attempt to use the same resource at the same time. Such synchronization and coordination can only be achieved by getting the robots to talk to each other or to some supervising agent. However, for large-scaled and complicated manufacturing systems, from the viewpoint of cost-performance and reliability appropriate representation and analysis methods of the control system have not sufficiently been established [1]. The lack of adequate programming tools for multiple robots make some tasks impossible to be performed. In other cases, since the control requirements are diversified and often changed, the cost of programming may be a significant fraction of the total cost of an application. Due to these reasons, the development of an effective programming method to integrate a system which includes various robots and other devices that cooperate in the same task is urgently required [2].

In programming by the well-known teaching-playback or teaching by showing, the programmer specifies a single execution for the robot: there are no loops, no conditionals, no data retrieval, nor computations. This method can be implemented without a generalpurpose computer, and it is especially adequate for some applications, such as spot welding, painting, and simple materials handling. In other applications such as mechanical assembly

© 2012 Yasuda, licensee InTech. This is an open access chapter distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. © 2012 Yasuda, licensee InTech. This is a paper distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

#### 76 Petri Nets – Manufacturing and Computer Science

and inspection, robot-level languages provide computer programming languages with commands to access sensors and to specify robot motions, enabling the data from external sensors, such as vision and force, to be used in modifying the robot's motion. Many recent methods in robot programming provide the power of robot-level languages without requiring deep programming knowledge, extending the basic philosophy of teaching to include decision-making based on sensing. Another method, known as task-level programming [3], [4], requires specifying goals for the positions of objects, rather than the motions of the robot needed to achieve those goals. A task-level specification is meant to be completely robot-independent; no positions or paths specified by the user depend on the robot geometry or kinematics. This method requires complete geometric models of the environment and of the robot, referred to as world-modeling systems. An object oriented approach has been held for modeling, simulation and control of multiple robot systems and intelligent manufacturing systems [5]-[9]. The main drawback of these methods relative to teaching is that they require the robot programmer to be an expert in computer programming and in the design of sensor-based motion strategies. Hence, this method is not accessible to the typical worker on the factory floor [10], [11].

Implementation of Distributed Control Architecture for Multiple Robot Systems Using Petri Nets 77

net can describe parallel flows, design and implement real-time robot control tasks [14]-[16], so that the process schedule is easily and effectively laid down, inspected and corrected. Each robot may be programmed in its own language in order to maintain best performance of each machine. Each step of the programming procedure can be verified by graphic simulation in order to improve the interaction between the operator and the robots and to

In this chapter, the method described in the previous work [17] is applied to program cooperative tasks by multiple robots and to concurrently control real robots. The aim of this chapter is to describe and implement a programming and execution system based on Petri nets that allows easy programming of a control system which includes multiple different robots and a variety of auxiliary devices. The problem how the control and coordination algorithms based on Petri nets are realized in an example of two robots carrying parts

Because discrete event robotic systems are characterized by the occurrence of events and changing conditions, the type of Petri net considered here is the condition-event net, in which conditions can be modeled by places whilst events can be modeled by transitions. A token is placed in a place to indicate that the condition corresponding to the place is holding. Because a condition-event net should be safe, which means that the number of tokens in each place does not exceed one, all of its arc weights are 1's and it has no selfloops. Condition-event nets can be easily extended and can efficiently model complex robotic processes. By the Petri nets extension, some capabilities which connect the net model to its external environment are employed. A gate arc connects a transition with a signal source, and an output arc connects a place with an external robot to send a command. The marking of a net changes, when a transition, which is enabled, eventually is fired. The place

and gate variables involved in transition firing are shown in Figure 1.

*P k g*

> *I k g*

**Figure 1.** Place and gate variables involved in transition firing test

The firing condition of transition *kt* can be written as

‧ ‧ ‧

*<sup>k</sup> I Ok*

*kt*

‧ ‧ ‧

make possible the off-line programming.

**2. Net models of robotic processes**

cooperatively is resolved.

Robot program development is often ignored in the design of robot control systems and, consequently, complex robot programs can be very difficult to debug. The development of robot programs has several characteristics which need special treatment. Because robot programs have complex side-effects and their execution time is usually long, it is not always feasible to re-initialize the program upon failure. So, robot programming systems should allow programs to be modified on-line and immediately restarted. Sensory information and real-time interactions are crucial and not usually repeatable. The ability to record the sensor outputs, together with program traces should be provided as a real-time debugging tool. Further, because complex geometry and motions are difficult to visualize, 3D graphic simulators can play an important role. Another difficulty comes from the fact that each robot has its own programming system, and it is often undesirable to alter or substitute it with something else. Besides cost considerations, this is because each robot programming language is tailored to the machine it has to control, and it would be simply impossible, for example to obtain a good performance from an articulated robot using a language designed for a Cartesian one. To attend the above requirements, a universal robot programming method with real-time automatic translation from a robot language to another one is required in integrated manufacturing systems.

The decision was then taken to develop a robot programming method for multiple robot systems that would provide the following characteristics. All the activities of the global system should be supervised by the control system, which is the method suitable to the integrated management that is necessary in manufacturing systems. So the integral controller with the strong computational power to do the complex task of the coordination system is needed. According to the parallelism among the subtasks in the multi-robot coordination system, advantage of the parallel architecture of the control system is taken to reach the good control capabilities [12]. To give a prior attention to the requirements about the part flow control, the control algorithm is designed based on the Petri net [13]. The Petri net can describe parallel flows, design and implement real-time robot control tasks [14]-[16], so that the process schedule is easily and effectively laid down, inspected and corrected. Each robot may be programmed in its own language in order to maintain best performance of each machine. Each step of the programming procedure can be verified by graphic simulation in order to improve the interaction between the operator and the robots and to make possible the off-line programming.

In this chapter, the method described in the previous work [17] is applied to program cooperative tasks by multiple robots and to concurrently control real robots. The aim of this chapter is to describe and implement a programming and execution system based on Petri nets that allows easy programming of a control system which includes multiple different robots and a variety of auxiliary devices. The problem how the control and coordination algorithms based on Petri nets are realized in an example of two robots carrying parts cooperatively is resolved.

#### **2. Net models of robotic processes**

76 Petri Nets – Manufacturing and Computer Science

accessible to the typical worker on the factory floor [10], [11].

required in integrated manufacturing systems.

and inspection, robot-level languages provide computer programming languages with commands to access sensors and to specify robot motions, enabling the data from external sensors, such as vision and force, to be used in modifying the robot's motion. Many recent methods in robot programming provide the power of robot-level languages without requiring deep programming knowledge, extending the basic philosophy of teaching to include decision-making based on sensing. Another method, known as task-level programming [3], [4], requires specifying goals for the positions of objects, rather than the motions of the robot needed to achieve those goals. A task-level specification is meant to be completely robot-independent; no positions or paths specified by the user depend on the robot geometry or kinematics. This method requires complete geometric models of the environment and of the robot, referred to as world-modeling systems. An object oriented approach has been held for modeling, simulation and control of multiple robot systems and intelligent manufacturing systems [5]-[9]. The main drawback of these methods relative to teaching is that they require the robot programmer to be an expert in computer programming and in the design of sensor-based motion strategies. Hence, this method is not

Robot program development is often ignored in the design of robot control systems and, consequently, complex robot programs can be very difficult to debug. The development of robot programs has several characteristics which need special treatment. Because robot programs have complex side-effects and their execution time is usually long, it is not always feasible to re-initialize the program upon failure. So, robot programming systems should allow programs to be modified on-line and immediately restarted. Sensory information and real-time interactions are crucial and not usually repeatable. The ability to record the sensor outputs, together with program traces should be provided as a real-time debugging tool. Further, because complex geometry and motions are difficult to visualize, 3D graphic simulators can play an important role. Another difficulty comes from the fact that each robot has its own programming system, and it is often undesirable to alter or substitute it with something else. Besides cost considerations, this is because each robot programming language is tailored to the machine it has to control, and it would be simply impossible, for example to obtain a good performance from an articulated robot using a language designed for a Cartesian one. To attend the above requirements, a universal robot programming method with real-time automatic translation from a robot language to another one is

The decision was then taken to develop a robot programming method for multiple robot systems that would provide the following characteristics. All the activities of the global system should be supervised by the control system, which is the method suitable to the integrated management that is necessary in manufacturing systems. So the integral controller with the strong computational power to do the complex task of the coordination system is needed. According to the parallelism among the subtasks in the multi-robot coordination system, advantage of the parallel architecture of the control system is taken to reach the good control capabilities [12]. To give a prior attention to the requirements about the part flow control, the control algorithm is designed based on the Petri net [13]. The Petri Because discrete event robotic systems are characterized by the occurrence of events and changing conditions, the type of Petri net considered here is the condition-event net, in which conditions can be modeled by places whilst events can be modeled by transitions. A token is placed in a place to indicate that the condition corresponding to the place is holding. Because a condition-event net should be safe, which means that the number of tokens in each place does not exceed one, all of its arc weights are 1's and it has no selfloops. Condition-event nets can be easily extended and can efficiently model complex robotic processes. By the Petri nets extension, some capabilities which connect the net model to its external environment are employed. A gate arc connects a transition with a signal source, and an output arc connects a place with an external robot to send a command. The marking of a net changes, when a transition, which is enabled, eventually is fired. The place and gate variables involved in transition firing are shown in Figure 1.

**Figure 1.** Place and gate variables involved in transition firing test

The firing condition of transition *kt* can be written as

$$t\_k = (\bigcap\_{i \in I\_k} p\_i \cdot \bigcap\_{j \in O\_k} \overline{p\_j} \cdot \mathbf{g}\_k^P \cdot \overline{\mathbf{g}\_k^I}) \tag{1}$$

Implementation of Distributed Control Architecture for Multiple Robot Systems Using Petri Nets 79

performance evaluation. In case of "Waiting" place for a specified timing, after the interval the end signal is sent by the timer. In case of "Waiting" place for a specified signal, the logical function is tested and the resultant signal is sent as a gate condition in place of end

(a)

**Figure 2.** Net representation of robotic action: (a) macro representation, (b) detailed representation

(b)

token exists in the path of places from "Grasp" to "Return".

Grasp Stretch out

Figure 3 shows the net representation of real-time control of a chucking operation with an external device. Each action place represents a subtask. The "Loading" place represents the macro model of the operation and indicates that, when a token is in the place, only one

Chuck

Loading

External device

C6 S6

Waiting Pull back Return

C5 S5

External robot controller

C1 C2 S1 S2 C3 S3 C4 S4

C1-C6: command start request S1-S6: acknowledgment or end status

**Figure 3.** Net representation of chucking operation with a robot and an external device

signal by the sensing module.

where denotes the logical product operation, and

*<sup>k</sup> I* : set of input places of transition *kt*

*Ok* : set of output places of transition *kt*

*P <sup>k</sup> g* : logical variable of permissive gate condition of transition *kt*

*I <sup>k</sup> g* : logical variable of inhibitive gate condition of transition *kt*

The marking change of input and output places of transition *kt* can be written as follows:

$$\begin{aligned} \textit{For} & \quad p\_i \in I\_{k'} & \quad p\_i = \overline{t\_k} \cdot p\_i \\ \textit{For} & \quad p\_j \in \mathcal{O}\_{k'} & \quad p\_j = t\_k + p\_j \end{aligned} \tag{2}$$

If a place has two or more input transitions or output transitions, these transitions may be in conflict for firing. When two or more transitions are enabled only one transition should be fired using some arbitration rule. Well-known properties of the condition-event net are as follows. From (1), if the directions of the input and output arcs of a place and the existence of token in the place are reversed, the firing conditions of all the transitions in the net are unchanged. If there is no conflict place in a net, then the net can be transformed into a net with no loop. If there is a loop with no conflict place in a net, the number of tokens in the loop is unchanged. In case that initially there is no token in a net marking, if there are parallel paths between two transitions, the maximum number of tokens in each path is equal to the minimum number of places in each path. So, by addition of a dummy path with a specified number of places, the number of tokens in each path can be controlled.

The dynamic behavior of the system represented by a net model is simulated using the enabling and firing rules. One cycle of the simulation comprises the following steps, which are executed when some gate condition is changed.


In any initial marking, there must not be more than one token in a place. According to these rules, the number of tokens in a place never exceeds one; the net is essentially a safe graph. A robotic action is modeled by two transitions and one condition as shown in Figure 2. At the "Start" transition the command associated with the transition is sent to the corresponding robot or machine. At the "End" transition the status report is received. When a token is present in the "Action" place, the action is in progressive. The "Completed" place can be omitted, and then the "End" transition is fused with the "Start" transition of the next action. Activities can be assigned an amount of time units to monitor them in time for real performance evaluation. In case of "Waiting" place for a specified timing, after the interval the end signal is sent by the timer. In case of "Waiting" place for a specified signal, the logical function is tested and the resultant signal is sent as a gate condition in place of end signal by the sensing module.

78 Petri Nets – Manufacturing and Computer Science

where denotes the logical product operation, and

are executed when some gate condition is changed.

using (1).

using (2).

*<sup>k</sup> g* : logical variable of permissive gate condition of transition *kt*

*<sup>k</sup> g* : logical variable of inhibitive gate condition of transition *kt*

*<sup>k</sup> I* : set of input places of transition *kt Ok* : set of output places of transition *kt*

*P*

*I*

( )

*P I*

(1)

(2)

*k k*

The marking change of input and output places of transition *kt* can be written as follows:

, , *i k i ki j k jk j*

If a place has two or more input transitions or output transitions, these transitions may be in conflict for firing. When two or more transitions are enabled only one transition should be fired using some arbitration rule. Well-known properties of the condition-event net are as follows. From (1), if the directions of the input and output arcs of a place and the existence of token in the place are reversed, the firing conditions of all the transitions in the net are unchanged. If there is no conflict place in a net, then the net can be transformed into a net with no loop. If there is a loop with no conflict place in a net, the number of tokens in the loop is unchanged. In case that initially there is no token in a net marking, if there are parallel paths between two transitions, the maximum number of tokens in each path is equal to the minimum number of places in each path. So, by addition of a dummy path with a

specified number of places, the number of tokens in each path can be controlled.

The dynamic behavior of the system represented by a net model is simulated using the enabling and firing rules. One cycle of the simulation comprises the following steps, which

1. Calculate the logical variable of the transition associated with the new gate condition

2. If the transition is fired, calculate the logical variables of its input and output places

In any initial marking, there must not be more than one token in a place. According to these rules, the number of tokens in a place never exceeds one; the net is essentially a safe graph. A robotic action is modeled by two transitions and one condition as shown in Figure 2. At the "Start" transition the command associated with the transition is sent to the corresponding robot or machine. At the "End" transition the status report is received. When a token is present in the "Action" place, the action is in progressive. The "Completed" place can be omitted, and then the "End" transition is fused with the "Start" transition of the next action. Activities can be assigned an amount of time units to monitor them in time for real

3. Then the marking is changed and a new command is sent to the corresponding robot.

*For p I p t p For p O p t p*

*k i jk k iI jO t p pg g* 

**Figure 2.** Net representation of robotic action: (a) macro representation, (b) detailed representation

Figure 3 shows the net representation of real-time control of a chucking operation with an external device. Each action place represents a subtask. The "Loading" place represents the macro model of the operation and indicates that, when a token is in the place, only one token exists in the path of places from "Grasp" to "Return".

S1-S6: acknowledgment or end status

**Figure 3.** Net representation of chucking operation with a robot and an external device

#### 80 Petri Nets – Manufacturing and Computer Science

Figure 4 shows the procedure of macro representation of a pick-and-place operation by a single robot. Figure 4 (a) shows the detailed net model, where if the first transition fires it never fires until the last transition fires. So, a dummy place "Robot" can be added as shown in Figure 4 (b) and a token in the place indicates that the state of the robot is "operating", because a real robot may load or unload only one part at a time. Thus, the place represents the macro state of the task without the detailed net as shown in Figure 4 (c).

Implementation of Distributed Control Architecture for Multiple Robot Systems Using Petri Nets 81

A single task executed by a robot or machine is represented as a sequential net model. The places are connected via transitions, each having a Boolean condition or gate condition. This condition is tested while the transition is enabled, i.e., when the preceding place is active. If the condition is true, the succeeding place becomes active, and the preceding place becomes inactive. Places for motion and computational actions have a unique output transition. Decision actions introduce conflict into the net. The choice can either be made nondeterministically or may be controlled by some external signal or command from the upper level controller. Figure 6 shows a basic net structure with task selection. Figure 7 shows a net model with task selection and its corresponding VAL program [18], which is written using direct commands for the hardware robot controller and implies the lowest level

Ready Selection (Home)

Moving Moving Picking Inserting

(VAL program)

APPRO P1, 50 MOVE P1 CLOSEI DEPART 70

<var1> = <var2> ?

Cooperation which requires the sharing of information and resources between the processes, is usefully introduced into the composite net which is simply the union of such sequential nets. Figure 8 shows two equivalent net representations of concurrent tasks with

OPENI DEPARTS 150

**Figure 7.** Example net model with task selection and robot language program

APPRO P2, 100 APPRO P3, 100 MOVES P2 MOVES P3

Moving Picking Placing Moving

detailed representation of the subtasks.

**Figure 6.** Basic structure of macro net model with task selection

**Figure 4.** Macro representation of Pick\_and\_place operation by a robot: (a) detailed representation, (b) parallel representation with dummy place in direct path, (c) macro representation

A dummy place is used to control the maximum number of tokens in the paths parallel to the direct path. In case that the hardware of a robotic system is composed of one or more motion units or axes, the number of tokens in the dummy place indicates the maximum number of processing or parts processed by each motion unit. The overall action is decomposed into detailed actions of constituent motion units by the coordinator.

**Figure 5.** Net representation of robotic system composed of two motion units

A single task executed by a robot or machine is represented as a sequential net model. The places are connected via transitions, each having a Boolean condition or gate condition. This condition is tested while the transition is enabled, i.e., when the preceding place is active. If the condition is true, the succeeding place becomes active, and the preceding place becomes inactive. Places for motion and computational actions have a unique output transition. Decision actions introduce conflict into the net. The choice can either be made nondeterministically or may be controlled by some external signal or command from the upper level controller. Figure 6 shows a basic net structure with task selection. Figure 7 shows a net model with task selection and its corresponding VAL program [18], which is written using direct commands for the hardware robot controller and implies the lowest level detailed representation of the subtasks.

**Figure 6.** Basic structure of macro net model with task selection

80 Petri Nets – Manufacturing and Computer Science

coordinator.

Figure 4 shows the procedure of macro representation of a pick-and-place operation by a single robot. Figure 4 (a) shows the detailed net model, where if the first transition fires it never fires until the last transition fires. So, a dummy place "Robot" can be added as shown in Figure 4 (b) and a token in the place indicates that the state of the robot is "operating", because a real robot may load or unload only one part at a time. Thus, the place represents

**Figure 4.** Macro representation of Pick\_and\_place operation by a robot: (a) detailed representation, (b)

A dummy place is used to control the maximum number of tokens in the paths parallel to the direct path. In case that the hardware of a robotic system is composed of one or more motion units or axes, the number of tokens in the dummy place indicates the maximum number of processing or parts processed by each motion unit. The overall action is decomposed into detailed actions of constituent motion units by the

Robot

parallel representation with dummy place in direct path, (c) macro representation

Motion unit 1

Motion unit 2

**Figure 5.** Net representation of robotic system composed of two motion units

the macro state of the task without the detailed net as shown in Figure 4 (c).

**Figure 7.** Example net model with task selection and robot language program

Cooperation which requires the sharing of information and resources between the processes, is usefully introduced into the composite net which is simply the union of such sequential nets. Figure 8 shows two equivalent net representations of concurrent tasks with

#### 82 Petri Nets – Manufacturing and Computer Science

synchronization. In Figure 9, a loop with no token implies that the net falls into a deadlock because of inconsistency with respect to transition firing.

Implementation of Distributed Control Architecture for Multiple Robot Systems Using Petri Nets 83

requires mutual synchronization between two tasks [19]. Synchronization of transitions is also employed for decomposition of a complex task into simple tasks cooperatively executed

**Figure 10.** Distributed implementation of synchronization between two machines

**Figure 11.** Decomposition of a complex net into two simple nets using synchronization mechanism of

The decomposition procedure of a net is as follows. First, a new place is added in parallel to the input place of the decomposed transition. Then, transitions are added in the input and output of the two places. The input transition of the new place is a source transition. Each place exchanges internal gate signals to input and output transitions with the other place

Robot 1

Robot 2

transitions

by two robots, as shown in Figure 11.

**Figure 8.** Net representations of basic structure of cooperation between two robots: (a) cyclic, (b) parallel

**Figure 9.** (a) Example net which has a loop with no token, (b) parallel representation which indicates a deadlock situation
