**4.1. Task specification based on work flow**

Based on robot task level programming of the specified part flow, the coordination task of carrying parts from a machining station to depository is represented as a work flow graph for a part sequentially processed by the arm robot and the mobile robot.In the work flow graph, each node represents a place where any processing is performed on the part, while an arc represent physical processing such as picking, loading, transfer or machining. The work flow comprises the following three arcs as shown in Figure 13.

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

1. picking from the station pallet by the arm robot

84 Petri Nets – Manufacturing and Computer Science

communication between different robots.

mobile robot.

transceiver and visual sensor

**4.1. Task specification based on work flow** 

work flow comprises the following three arcs as shown in Figure 13.

**4. Net based multiple robot coordination** 

when a token is in the place. The gate arcs are implemented using asynchronous

A coordination task of carrying parts from a machining station to depository is considered as an example application using multiple robots. An arm robot picks up a part from the station and loads it into a mobile robot by which the part is sent to the storehouse. The arm robot is equipped with a visual sensor via which it can recognize the parts as well as their positions and also equipped with a force sensor which is necessary for grasping and loading the parts. On the mobile robot, a radio transceiver is used for its communication sending back feedback information from the sensors and receiving the control information from the main controller. The visual sensor is used for landmark recognition in the environment and infra-red sensors are used for obstacle avoidance. Figure 12 shows the arm robot and the

**Figure 12.** View of experimental robot systems: (a) arm robot, (b) autonomous mobile robot with radio

(a) (b)

Based on robot task level programming of the specified part flow, the coordination task of carrying parts from a machining station to depository is represented as a work flow graph for a part sequentially processed by the arm robot and the mobile robot.In the work flow graph, each node represents a place where any processing is performed on the part, while an arc represent physical processing such as picking, loading, transfer or machining. The


Station Arm robot Mobile robot Depository Picking Loading Transfer

The picking, loading, or transfer is specified using a local path in the neighborhood of the start and end place and a global path from the two places. Mutual exclusive resources or shared workspace such as buffers are also considered to avoid robot collision. The work flow diagram is transformed into a conceptual net model considering machines in charge of each processing. Figure 14 illustrates the net model of the coordination task between the two robots. At this point, associated processing such as object identification, alarm processing, exception handling is added. Then each processing is translated into detailed operations or actions. At each step of detailed specification, places of the net are substituted by a subnet in a manner which maintains the structural property such as liveness and safeness. Hierarchical decomposition assures detailed net models free from deadlock.

**Figure 14.** Net model of carrying task by two robots

The conceptual coordination task is specified as follows. First, after the reception of a start command, in "Identification" place, the arm robot judges whether or not there are still parts in the station using the visual sensor. If not, the arm robot informs the mobile robot that the task has been finished with "End of task" place and returns back to its home position. On the contrary, the arm robot starts to get the position of a part and grasp it. The mobile robot moves to the station, and the arm robot, after the completion of the "Grasp" subtask and the "Movement to station" subtask, starts "Loading" subtask while the mobile robot waits at the specified position. After the completion of loading, the mobile robot moves to the depository, and the arm robot executes the "Identification" subtask repeatedly. If the signal of "End of task" is on, the mobile robot returns back to its home position, and if not it moves to the station. From the "Movement to station" and "Movement to depository" places, the gate signal is sent to repeatedly execute the "Obstacle avoidance" subtask using infrared range sensors. In the coordination task, synchronization is represented as a shared transition which is implemented using a sequence of asynchronous communications as shown in Figure 10.

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

Arm drive circuits

Wrist drive circuits

> Hand drive circuits

Teaching box control circuit

Figure 14 shows the hardware structure of the microcontroller-based control system. The visual sensor detects the coordinates of the center of an object and the orientation of an edge of the object. The proximity sensors, which are composed of several LED arrays attached to the fingers can detect the distance and orientation of the object with respect to the planes of the fingers. For the grip command, the grip action raises the grip force till the signal from the slippage sensor becomes zero. When the hand is moving down vertically, if the signal

from the slippage sensor rises inversely, then the hand is opened.

CPU 3

CCD camera

**Figure 16.** Block diagram of multi-axis arm control system

model and simulating again.

Capture board

CPU 1

PC

CPU 2

Hand sensors circuits

When programming a specific task, the task is broken down into subtasks through task planning. These subtasks are composed of the position data and the programs that are edited using the robot motion simulator. Each subtask is represented as a place. A place can also represent the internal state of the robot, which is operating or idle, and the state of external devices. The relations of these places are explicitly represented by interconnections of transitions, arcs and gates that are edited with the robot task program editor and simulator. For places that represent subtasks, the following parameters are necessary: 1) the code of the controller such as the vehicle, arm, hand or sensor etc., that executes the subtask, 2) the file name where the subtask such as MOVE, GRASP, RELEASE, or HOLD, etc., is explicitly written with some programming language, and 3) the file name of a set of position data that will be used to execute the subtask. The procedures of editing and simulating of the net model are done interactively until certain specifications are satisfied. At this point, it is expected that problems such as deadlock, conflict resolution, concurrency, synchronization, etc., have been well studied and analyzed. If some error is found, that is if the net model does not satisfy the specification, it can be easily amended by reediting the net
