O.Z. Maimon Massachusetts Institute of Technology,

Laboratory for Information and Decision Systems,

Cambridge, Mass. 02139 and

Digital Equipment Corporation, Computer Integrated Manufacturing,

Maynard, MA. 01754

S. Y. Nof School of Industrial Engineering,

Purdue University, West Lafayette, Ind. 47907

Coordination of Robots Sharing Assembly Tasks A multiple robot assembly cell for batch manufacturing is described and a new con­cept of an Activity Controller (AC) for such a cell is developed. The problem de­fined for the Activity Controller is which robot is to perform which operation, how, in terms of spatial routes and accessories, and when, in terms of timing and syn­chronization, in order to effectively achieve a certain task objective (e.g., minimize makespan time). The Activity Controller functions, structure, and algorithms for optimization and operational control are discussed, and then demonstrated on an actual assembly case.

I Introduction

With the growing number of manufacturing facilities that integrate robots and other programmable equipment there is an increasing degree of operational integration and complex­ity. As a result, there is a greater need to develop effective in­tegrated systems that will plan and coordinate individual com­puterized units, and supervise the operation as a whole.

The robot control unit is more complicated if two robots are to cooperate rather than each work by itself. The motivation for the robots to cooperate is to increase the overall cell pro­ductivity as compared to individual robot work without coor­dination capabilities.

Motivation for Cooperation Between Robots. The follow­ing are several typical possibilities of and motivations for cooperation between robots.

(1) Sharing a task: Each robot by itself is doing part of the task, but is able to perform some or all of the tasks of the other robot. This cooperation increases the reliability of the cell by introducing backup in case of failure of one robot. The control unit is in charge of detecting failures and transferring responsibilities among robots.

(2) Sharing a task while working together on different facets of the same part. This decreases the total cycle time.

(3) Sharing a task such that each robot is doing part of the total task and the cooperation is through a shared buffer. This decreases space, cycle time and material handling equipment necessary in other modes of operation. It creates some more functions for the controller such as to avoid collision which might happen if both robots try to enter the shared space at the same time.

(4) Some operations require more than one robot, e.g., lifting a long tub of water such that it is level at all times. This requires close force control and extensive communication between the robots. The advantage here is clear, as one robot is not able to carry out the desired task.

(5) Taking advantage of diverse capabilities of different

Contributed by the Dynamic Systems and Control Division for publication in the JOURNAL OF DYNAMIC SYSTEMS, MEASUREMENT, AND CONTROL. Manuscript

received at ASME Headquarters, September 18, 1985.

robots, e.g., one as a programmable fixture for heavy part lifting, and the other with precision assembly capabilities.

As a contribution to the development of robot cooperation, this work presents a method of operating and controlling a multiple robot assembly cell with the objective of achieving many of the above advantages. The cell is designated to operate in a dynamic batch manufacturing environment.

We view an automated manufacturing plant as an in­tegrated system of units (cells), which are controlled by a general monitor program, following the concept of a Manufacturing Operating System [Nof et al. 8]. The function of the operating system is to assign work to individual cells for each time period and to coordinate the inter-cell activities. Control functions are defined for the individual cell in order to achieve the imposed task.

In this article we focus on the Activity Controller (AC) com­ponent of the cell control.

We define the Activity Controller to be the function which determine which particular robot is to perform which opera­tions; how operations will be best performed by the robots, in terms of spatial routes and accessories, and the planned op­timized timing and synchronization of operations. The control of the robots themselves is considered as a lower machine level of control, as described later. The objective of the Activity Controller in making the above decisions is to achieve certain task goals, such as minimize makespan time of a task. It is mainly materialized by high utilization of the two main robot advantages: spatial flexibility and functional versatility.

Considering a multiple robot assembly cell, there are dif­ferent modes of operating it, depending on the type of robots, tasks, configuration, etc. (Maimon [5], [6]).

The conceptual work here is of general nature but the details of the control may vary according to the types of operations considered. A two robot cell case study is described in detail in Section IV. It illustrates the algorithm which are used for one typical mode, and demonstrates clearly the benefits of robot cooperation. The theory and concept presented in this article have also been applied in an extensive laboratory experiment with two cooperating assembly robots. This complex experi­ment is analyzed in Maimon [5], and further demonstrates the

Journal of Dynamic Systems, Measurement, and Control DECEMBER 1985, Vol. 107/299

Copyright © 1985 by ASMEDownloaded From: http://dynamicsystems.asmedigitalcollection.asme.org/ on 09/20/2013 Terms of Use: http://asme.org/terms

advantages of coordinated robots operation under the supervi­sion of the Activity Controller.

Background. Most of the literature about robot assembly operation to date is concerned with single robot operation. For example, the two automatic assembly conference pro­ceedings, [9] and [10], contain numerous articles of robotic assembly. Assembly work that relates to this work is, however, concerned with operations of more than one robotic arm. To date, only a few publications have appeared in this area. Two company brochures by General Electric [2] and Westinghouse [11], describe the capabilities of their multiarm systems.

General Electric A-12 assembly robot can control simultaneously one to four arms, with a total of up to twelve sychronized degrees of freedom. Westinghouse Series 5000 In­dustrial Robot is a gantry type robot with one, two, or three operating arms with up to nine servo controlled axes working either independently or simultaneously. The company also supplies a conveyor transport modules to be part of the robotic cell.

Kohno et al. [4] present an experimental robot system for mechanical assembly comprising two articulated robots and a vision system. With the aid of vision, the system can handle parts which are randomly placed. Each robot has six degrees of freedom and is equipped with two hierarchically linked microprocessors, that control the coordinated motions of the arm and the interaction with the vision system. A newly developed language facilitates the programming of the two robots and the vision system.

Kondoleon [3] presents a method of simulating the motions (gross, fine, and interface) of robots to determine the cycle time of a robotic system. Simulation of various multirobot assembly systems compare the effects of various system con­figurations on the assembly cycle time.

While the above references involve multiple robot assembly cells, they do not address the problem presented in this article, namely the overall optimized coordination and control of the multiple robot operations within the cell.

Characterization of the Multiple Robot Assembly Cell. Generally, a robotic assembly cell can be described as comprised of four basic components: robots, parts (in­put/output), storage, and accessories. The robots perform the material handling and assembly operations using the needed accessories, such as tools, jigs, fixtures, and machines for secondary operations. The parts that are needed are stored in the cell or are provided through an input system (e.g., con­veyor). At intermediate stages the products can be stored in the cell, while the ready products are sent out of the cell through an output system. In a multiple robot assembly cell, some of the parts, storage space, and accessories are shared and some are separate for each robot.

For the purpose of this article, we describe the main features of the control structure over the operation of the cell com­ponents. The control unit of the assembly cell is comprised of a micro (or mini) computer. It is connected to the individual robot controllers and to the other components of the cell, and is in charge of the assembly cell components.

From the cell control commands are issued to lower control

Nomenclature

MS = a maximal horizon Sk = a feasible horizon G = available gripper capacity

G, = number of required gripper capacity for operation /

P •= • process (P/-the /th process)

units (mainly the robots, but also to other programmable units, if any are used) which in turn control the actual opera­tions accordingly.

The control of the cell is divided into four main functions which operate in a hierarchical structure;

(1) Process Scheduling (PS), (2) Robot Scheduling (RS), (3) Activity Control (AC), (4) Machine Control (MC). The process scheduling is the level that communicates with

the plant level to get tasks and schedule them according to priorities and the general capacity of the cell. Next, the robot scheduler decomposes the given tasks and assigns them to each individual robot. This gross assignment is performed ac­cording to the product structure, to each robot performance capability, and to general availability of the necessary aux­iliary equipment.

The Activity Controller receives input from the Robot Scheduler, namely specific instruction for the task and the general schedule of each robot in the cell.

The role of the Activity Controller is then to determine how to execute the given task planning and to control the physical routes and sequence of operations of each individual robot, in order to achieve a predefined objective. The Activity Con­troller is also responsible for the coordination and syn­chronization of the individual robots with regard to utilizing shared resources, (e.g., tools, work space) in order to avoid conflict situation.

The Activity Controller transmits instructions to the machine controllers which are in charge of actually executing the sequence of moves and operations by each robot.

Each control level provides feedback to the level above it upon achieving specific tasks and when certain problems occur during execution. Higher control levels in the control system dynamically respond to this feedback, and to changes in in­puts external to the cell, such as new production demands.

II The Activity Controller

The basic problem of the Activity Controller, as described above, is the sequencing and synchronization of robot movements in order to perform the operations in the cell in a productive manner. The Activity Controller algorithms are designed to prevent and resolve conflicts, for instance when two robots need the same tool at the same time; to select from several routing options and coordinate them to minimize the total performance time, etc.

The Activity Controller will attempt to expedite a job if so instructed by a higher control level, or operate to meet a predefined schedule that is running late due to, say, some operational problems that had occurred.

The duties of the Activity Controller are divided into a plan­ning phase and a response phase. The response phase may in­itiate another phase of planning if the pertubation from the plan is too large. In such a case, the plan may no longer be close enough to optimum, or may cause serious synchroniza­tion problems later. Alternatively, the perturbation may be dealt with on the local level, by responding to a problem that has occurred.

M = motion (M,-the /th motion) O = operation <Of—the fth operation)

S,Sl,S2,SP = semaphores P(S),V(S) = operations on semaphores

L,Ll = labels </> = the empty set

300 / Vol. 107, DECEMBER 1985 Transactions of the ASME

Downloaded From: http://dynamicsystems.asmedigitalcollection.asme.org/ on 09/20/2013 Terms of Use: http://asme.org/terms

Both planning and response phases use the same two mechanisms. We name them: Activity Controller-I, which includes the routing logic, and Activity Controller-II, which includes the synchronizing logic. In each phase (the planning and the response) both mechanisms are activated. The result of each phase is output commands that are issued to the Machine Controller. Each of the mechanisms is comprised of several functions. Not all of them necessarily operate in each phase. For instance, in responding to dynamic changes the nature of the problem dictates the solution technique, e.g., due to a delay in some operation, collision avoidance algorithm should be activated, while the other conditions are possibly unaffected at all.

The routing algorithm determines the sequence of opera­tions of each robot, taking into account the spatial and timing constraints, as well as the accessories needed for each opera­tion in the planning horizon. Then, the synchronizing algorithms complete the routing plan by adding mechanisms to treat real-time problems and asynchronous tasks of the two robots. The mechanisms are also serving as a safety device to avoid conflict situations, which otherwise may cause damage (e.g., collision) or program stoppage (e.g., when a necessary tool is used by the other robot).

Figure 1 depicts the two mechanisms and their main func­tions, which will be described in detail next.

(s<

Planning S Optimization For Each Robot

quence, rou te , pa th , speed)

Given Precedence Constraints and

Cell Physical Model

< ^

A c t i v i t y Con t ro l l e r - I I

Mechanisms for Synchronizat ion to Avoid Con f l i c t S i t ua t i ons (that may

occur due to Asynchronous Tasks o f each robot)

u Instructions

Output to Machine Controller

The main duty of the Activity Controller - 1 is the planning of how each robot should pursue its assembly tasks, i.e., finding the optimal (according to some objective function) se­quence of paths each robot should follow, in order to ac­complish its tasks, complying with the constraints of the cell, the product and the other robot activities.

The responsibility of the Activity Controller-II is the control of real-time asynchronous tasks. The results are mechanisms to avoid conflicts between robots. Possible conflict situations to consider are presented in Fig. 2. The synchronization algorithms attempt to prevent some of the conflicts ahead of time and operate to recover from conflicts once they do occur.

Depending on the mode of operation and the input from the routing logic, the relevant circumstances that may cause con­flict are first identified, then detected, i.e., checked if they ac­tually may occur in the given plan. If so, steps are taken in order to prevent and avoid them, or wait and recover if they do occur. The Machine Controller provides feedback of con­flict situations that do happen and then suitable preplanned recovery routines are invoked.

The above four functions (identify, detect, prevent, and recover from conflict situation) define the responsibilities in each situation. However, there are tradeoffs among those four functions. Certain critical situations must be identified, detected and prevented, e.g., potential collision of two robots. On the other hand, there are less critical situations in which we will not make an effort to predict and avoid (since the effort of doing so for all cases may be prohibitively large versus the recovery option) but would rather handle them only when they actually happen. For example, in the case of waiting for a fix­ture that is temporarily occupied by another robot, we can decide to wait until it happens and then apply a recovery routine planned before. For instance, if waiting for that fix­ture does not significantly change the work plan, we may stay in a wait loop until this fixture is free.

Conflict Situation

Fig. 1 Activity controller's two-step solution procedure

Fig. 2 Possible conflict situations

III Algorithms for the Activity Controller

In this section we introduce the algorithms that perform the AC tasks as defined previously. We present a planning method to find the optimal sequence of robot activities. Each in­dividual path is assumed known.

Algorithm Outline: The overall structure of the algorithms in the Activity Controller is:

Activity Controller—I -

Step 1: Determine maximal horizons and feasible horizons of the task.

Journal of Dynamic Systems, Measurement, and Control DECEMBER 1985, Vol. 107 / 301

Downloaded From: http://dynamicsystems.asmedigitalcollection.asme.org/ on 09/20/2013 Terms of Use: http://asme.org/terms

Step 2: Determine the "cost," as specified by the objective function, of each horizon found above.

Step 3: Determine the optimal sequence of motions and operations for each robot, with regard to the other robot constraints (e.g., precedence).

Activity Controller—II—

Step 4: Identify shared resources and potential con­flict situations.

Step 5: Prevent and detect algorithms. Step 6: Recovery algorithms.

We briefly discuss each step, and in the next section show in detail how it is used to solve an actual assembly case.

Step 1 -Horizon Algorithm. The input to the algorithm is the assembly tasks which are given as a sequence of motions and operations with their precedence relationship.

Observe that an assembly task is comprised of a generic se­quence. In this sequence parts are brought (later referred to as "motions") from feeding devices to a fixture (or fixtures), where assembly operations are executed. An "operation" is the activity that requires precision as the robot interacts with another object. A set of motions and operations is called a "process." A sequence of processes is called a " job . " The product assembly consists of a set of jobs. (See [6] for addi­tional information on the assembly structure.) The routing problem is to find the best sequence of motions for each robot so as to perform all processes and thus accomplish a job.

The generic sequence described above suggests a decomposi­tion of the input sequence into several subsequences, each comprised of a set of motions and operations (step 1); solving each one separately (Step 2), and then finding the optimal way of composing them (Step 3) to determine the route of the whole task. The routing problem is therefore regenerative each time the robot starts again on its tour from a fixture to feeders and back to a fixture (exceptions exist).

A maximal tour is the one that contains the maximum number of motions. For instance, with a double gripper, two parts can be brought in on a tour to a fixture. This maximal tour is denoted as "maximal horizon." It is determined by the structure of the product, the work cell and the robot gripper capacity (i.e., the maximal number of parts that can be gripped simultaneously. Subsets of the maximal horizons are called horizons. The horizon algorithm determines all the possible horizons, among them the optimal combination is later achieved.

In Section IV we present in detail an algorithm to find all horizons for one robot equipped with a gripper capacity of n parts.

The result is the decomposition of the general task into sub-tasks, defined by the horizons. For each (some could be eliminated by bounds) we apply Step 2 as follows:

Step 2—Minimum Horizon's Cost Algorithm. This algorithm determines the minimum cost route for a horizon. A route is a sequence of paths that the robot follow in order to get to execute the operations that are included in the horizon. A cost, e.g., traversal time, is associated with each path. The sum of the paths' cost, for the paths in the sequence, is the route cost. There are several possible routes for a horizon. In this step we present a way of finding the optimal one with respect to some objective function. Observe that for a par­ticular horizon there is a same start and end point - usually a fixture (or robot home position at start and end of its assembly task). Therefore the problem could be formulated so that a modified Traveling Salesman algorithm could be used for this step. The objective function is

Min £jCjjXjjk/ovtx the horizon's motions),

where motion from point i to j costs Cy if it is chosen at the k-th leg of the route (then Xm = 1, otherwise-0). In the next section we show examples of how to formulate the problem and obtain the best route. Once the problem is formulated as a Traveling Salesman problem, then existing algorithms can be used that guarantee optimality.

Step 3 — Optimal Sequence. The result of Steps 1 and 2 are the optimal motions of components of the task, namely the horizons. This step determines which horizons to choose so that the overall assembly task cost is minimized. This is the composition of the horizon to the total task, namely the op­timal sequence that covers all motions and operations. Several modified shortest path and parallel scheduling techniques are utilized here depending on the mode of operation of the cell.

Step 4 - Identifying Shared Resources. So far the optimal sequence was determined. However, the time of operations may change as recovery routines are invoked (e.g., if an inser­tion fails the first time, force sensing is used for correction, or another part is fetched). Therefore, conflict situations may oc­cur such as collision when two robots may get to a fixture at the same time, or one robot may try to get the tool, when it is not available. Some conflicts should definitely be prevented, e.g., physical collision between robots. Other conflicts could be resolved when they occur, e.g., a temporarily missing tool. However, for the system to continue its operation, each con­flict should be resolved. Therefore, we now consider potential problems that may occur in real-time due to asynchronous operations in an environment with shared resources and nondeterministic times. Special mechanisms are developed and incorporated into the optimal sequence in order to assure the smooth operation of the cell.

For each mode of operation of the cell, we refer to its poten­tial problems, following three steps:

Step (i): Identify shared resources. Step (ii): For each shared resource, identify specific

potential problems. Step (iii): For each potential problem, decide which of

the above possible conflict situations need to be handled by prevention, detection or recovery.

Step 5— Prevent and Detect Algorithm. Each conflict situation that should be prevented is constantly monitored. Two approaches exist for detection and prevention. The first one is a detection of a conflict by the Activity Controller. It is achieved by obtaining real-time information on each robot current and near future activities, and checking for a possible conflict. If a conflict is detected, then preventive action is taken, e.g., changing a trajectory of a robot to prevent colli­sion, or waiting for another tool. The second approach is prevention of conficts through software mechanisms. In this case, explicit permission is required for each robot for any ac­tion which might lead to a conflict. For example, when a robot requests a shared tool, the request is either granted or denied. Then the robot could wait or the Activity Controller would direct the robot to another action. The second approach is pursued in detail for the case study in the next section.

Step 6—Recovery Algorithm. This step applies to those potential conflict situations that were identified in Step 4 (iii). Recovery solutions are invoked when a conflict situation does occur. Each conflict is identified with a solution. For instance, if the robot sends a message that a requested tool is unavailable, then the Activity Controller instructs the robot to retreat to a safety location and wait for the signal to proceed to take the tool when it becomes available.

302 / Vol. 107, DECEMBER 1985 Transactions of the ASME

Downloaded From: http://dynamicsystems.asmedigitalcollection.asme.org/ on 09/20/2013 Terms of Use: http://asme.org/terms

IV Case Study

The objective of this section is to demonstrate the Activity Controller operation through particular assembly example. We first present the example and add some necessary general notation; then we propose specific algorithms to optimally plan and control the robot assembly operations.

The case considered here is of a valve assembly [7] which in­volves inserting a spool, a spring and a plug into a center hole in the valve. The plug is a threaded bolt on which an O-ring should first be placed. The general cell layout is depicted in Figs. 3 and 4. Some components and accessories are depicted in Fig. 5. Motions and motion times in the cell are given in Figs. 6 and 7, respectively. Different valves may require dif­ferent or identical motion speeds, springs and plugs. The part feeders are shared, thus increasing the cell flexibility to assem­ble more valve types.

Fig. 3 The valve assembly cell

Bolts Vacuum Hose Stand

- - .ngs Di f ferent Types a D n . Mandrel and

ve Tool Stand

Fixtures ( f o r d i f f e r e n t valve types)

Shared

Storage

Fig. 4 Functional description of the assembly cell

n •

The Mandrel mounts over the threads on the p lug. The O-ring is mounted over the top of the Mandrel.

The spr ing loaded blocks in the center l e t the dr ive tool siiovm Xn this—figure—follow the contour of the mandrel ( for inser t ing the O-ring on the plug)

Fig. 5 Sample components and accessories for the valve assembly case

Assembly Cell Description. An input conveyor carries in the different necessary valve bodies. The other parts and ac­cessories, required in order to perform the assembly task with a robot, are prepositioned periodically in the cell. Upon shortage or replacement, the input conveyor carries new valve bodies into the cell according to instructions from a higher control level (the plant level).

In this example we assume that each robot in the cell can perform all operations. Operations and recovery times are known in advance. However, the actual operation time may vary due to several reasons, for example, the actual time depends on the assembly recovery routines that are invoked on appearance of defective parts. In this case, re-routing may be required.

Vacuum Hose

Storage

indrel and Drive Tool

Fig. 6 The layout graph

s

1

z

.3

!)__

5

T

S

0

1

9

0

I

i

2

7

5

0

3

7

5

0

0

k

5

1

3

3

1 o .

5

6

2

*

1|

2

0

T

1 0 •

3 ,

1 2

2

5 . _

8

0

Fig. 7 Routing matrix in time units (symmetric for this example)

Product

Fig. 8 The example jobs precedence graph

Individual motion times are also known in advance, but on­ly after the Activity Controller determines the optimal se­quence for each robot we know which specific motions will be executed.

Journal of Dynamic Systems, Measurement, and Control DECEMBER 1985, Vol. 107/303

Downloaded From: http://dynamicsystems.asmedigitalcollection.asme.org/ on 09/20/2013 Terms of Use: http://asme.org/terms

The product assembly consists of three jobs:

Job 1: Assembly of O-ring to a threaded bolt (the plug) Job 2: Inserting the spool and then the spring to the valve

(could be divided into two sequential jobs) Job 3: Inserting and tightening the plug to the valve

The jobs precedence can be depicted as a graph, with the jobs in the nodes and arcs as precedence constraints. Figure 8 depicts the example graph.

Following the definitions at the end of Section I, we now show the role of the planning and control functions when the plant monitor assigns several valve types to be assembled.

The Product Scheduler. Given the cell capabilities, it calculates priorities, e.g., to minimize tardiness, and decides that for the next period of time valve Type 1 (which needs bolt Type 1) will be assembled.

The Robot Schedule. Knowing each robot capabilities, the general cell arrangements and operations times, it decides that Robot 1 will assemble plugs (Job 1) while Robot 2 will assem­ble valves (Jobs 2 and 3). Thus, the loading is balanced, in general only, as the routing and hence motions times are not exactly known at this stage. Further activity details are the duties of the Activity Controller.

The Activity Controller determines the physical routing and timing by the AC-I, and then the AC-II handles real-time coordination and resolve conflict situations.

The Machine Controller, according to the input from the Activity Controller, controls the actual motion between any two specified points and then controls the operation called for at that point. If the operation consumes more time due to necessary recovery routines, or needs re-routing (e.g., due to defective parts) the Machine Controller informs the Activity Controller, which, in turn, responds to the changes and issues new orders as required.

In order to understand the algorithms, two general concepts should first be presented. The first is the operation subroutine and operation neighborhood. Recall that the product to be assembled consists of jobs which are collection of processes. Each process consists of motions and operations. We assume that the robot knows in advance (e.g., by teaching) how to perform the operations and they are stored in the robot's con­troller. The robot has to reach a point (pre-starting point) close to the starting point and then invoke "Operation i" subroutine which causes the robot to move to the starting point, perform a sequence of activities and end at the end point.

The prestarting point has to be inside a neighborhood of the starting point which from any point there to the starting point, no collision can occur on the robot's path. The neighborhood of starting point depends on the cell configuration. The ad­vantage of the neighborhood concept is that the robot is re­quired less accuracy when reaching this point, and a rather high speed can be used for the motions (which are from an end point of operation to pre-start point of the next Operation).

The second concept is that of the assembly routing sheet format. This is the input which defines each job that a robot has to execute. The following notation is required to introduce the routing sheet:

P —process M - motion O -operation < - denotes precedence relation

For the algorithms proposed here, the routing sheet has to be organized such that

0 , < 0 , + , ./=1,2, .

0,<j> or M,<j>

M:</Mk>

Operation i precedes operation i +j (but some of the motions may be iterleaved) Operation or motion / requires grip-per capacity of J. In this case J defaults to 1. Motion / is conditional on motion k, i.e., motion k must be completed before motion / can start.

PI:

P2:

P3:

P4:

P5:

Ml:

Ol: M2: 02: M3: M4( 0 3 : M5: M6: 04: 0 5 : M7:

06:

M8: M9:

Using the above notation we present the routing sheet for .', b 1 out of the three jobs in the cell (see Figure 8).

bolt - > fixture (motion 1 is from the bolt to the fixture) bolt placed in a fixture Mandrel - > fixture Mandrel placed on the bolt Vacuum hose (VH) - > O-ring

/M3): O-ring - > fixture O-ring placed on the top of the mandrel Vacuum hose - > home position (VH) Drive Tool (DT) - > fixture Pushing O-ring down on the mandrel Grasping drive tool and mandrel together Drive tool and mandrel - > home posi­tion (DT) Taking the assembled bolt out of the fixture Assembled bolt - > storage (shared) Start next task, or Robot back to home position.

Example's Solution Procedure. The six steps of the Activ­ity Controller algorithm presented previously will now be used to plan the robot's tasks, i.e., determine the optimal sequence of the robot's motions and operation. The optimal sequence is with regard to the objective function of minimizing the makespan time it takes to assemble the product. Then in real­time to control the robot activities such that all conflict situa­tions are resolved. In order to explain how the general con­cepts of the Activity Controller - 1 are applied, it is sufficient to consider only job number 1. For Activity Controller-II, however, we need to consider more than one robot and one job as the main goal of the Activity Controller - II is to handle all potential inter-robot and inter-job problems. Following is the six-step algorithm as applied to the particular case.

Step 1. Horizon's Algorithm

The formal steps are:

Initialize: ('= 1 Step(i): (1) STOP if last motion of the task was

reached MS = 0 (the maximal horizon) G < - n (current gripper capacity avail­able)

(2) If G<Gh <Gj is the required gripper capacity) MS is the maximal horizon, go to Step (ii) else G<-G-Gi

(3) M S < - M S U { M , j / < - / + 1 (next motion) go to (2)

Step (ii): Find all feasible horizons Sk C MS. Step (iii): For each sub horizon, go through Steps (i) and

(ii) until STOP occurs. (Each feasible horizon is a branching point from which a next maximal horizon is built using the above algorithm.)

The output of this algorithm is the maximal horizon (Step

304/Vol. 107, DECEMBER 1985 Transactions of the ASME

Downloaded From: http://dynamicsystems.asmedigitalcollection.asme.org/ on 09/20/2013 Terms of Use: http://asme.org/terms

(i)) and feasible horizons (Step (ii)) which are subsets of that maximal horizon.

Some of the sequences are given in Figure 9, which also demonstrates the different possible motion sequences from which, at Step 3, the best one will be chosen.

H5, M6

H8, H9 H7, H8, H9

Fig. 9 Possible sequences of motions of job 1

Step 2—Horizon's Cost. Applying a Traveling Salesmn Algorithm, the minimum cost of each of the horizons is deter­mined. Figure 10 shows two simple examples of how to for­mulate the problem as a Traveling Salesman problem, and the solution that is obtained.

1. Horizon: H I , H2 Graph:

Solut ion: S - 2 - 1 - T

Hinlmum Cost - 7 + 5 + 3 - 1 5 Time Uni ts.

Note: Arc (TS) Is added as a duimjy arc wi th zero cost because the algorithm requires returns to or ig in

2. Horizon: H3. n't, M6

s 1 2 T

S 00 9 7 0

1 2 T 9 7 00 00 5 3 5 00 2 3 2 00

From

T 5 4 3

T 5 4 3

(0 8 00 2 » 00 2 It 5 00 00 3 2 It 3 00

Minimum Cost = 13 Time Units.

Fig. 10 Examples of finding horizon's minimum cost by the Traveling Salesman algorithm

Step 3 — Composition. In the mode of operation utilized here, the robot jobs are mutually dependent through a shared buffer. Motion optimization is first obtained for each of the robots separately. Figure 11 depicts the combined graph of all the horizons generated in Step 1, and their minimum costs, as computed in Step 2.

The shortest path algorithm [1] is now used on the graph that is presented in Fig. 11. The optimal sequence is found to be (Ml), (M2, M3, M4), (M5, M6), (M7, M8, M9), where brackets determine the chosen horizons.

Note that the optimal plan is to utilize only one side of the gripper at first, (Motion Ml). By simple reasoning one would tend to start with fully using the double gripper. Applying the latter (start with Motions Ml and M2) will, however, lengthen the makespan time of the job from 48 to 52 Time Units in this case.

Step 4—Real-Time Control—Identifying Shared Resources.

Step (i) The shared resources are: (1) storage and (2) space

Fig. 11 Compositions of the horizons to find optimal sequence

(The values of nodes are the horizons' minimum cost)

The shortest path is: (M1); M2"l M3 M 4 j

; f M5 "l;fM7"") ; I M6 I; M8

LM9J

with the cost of: 12 + 13 + 14 + 9 = 48 Time Units.

The solution found by the heuristic rule "always use maximal gripper capacity possible" is marked with xx, with the cost of 15 + 13 + 14 + 10 = 52 time units.

Step (ii) Potential problems with respect to shared storage: (1) for Robot 1 —attempting to add a part to a full slot in the shared buffer; (2) for Robot 2 - at­tempting to remove a part from an empty slot; potential problems with respect to shared space; (3) potential collision if both robots attempt to enter the shared space at the same time.

Step (iii) For this case the decision is to prevent all poten­tial problems above. Collision should always be prevented and for the rest, there are only two possible conflicts which would be handled by ef­ficient algorithms, as presented in Step 5.

Step 5—Prevention and Detection. The second approach mentioned in Step 5 in the previous section is implemented here by assigning various semaphores to detect and prevent the three possible conflicts mentioned above. Each time a part is added to the storage or removed from it, the appropriate semaphore is incremented or subtracted from. Accordingly, the storage becomes locked for Robot 1 when it becomes full, or for Robot 2 when it becomes empty. The shared space is controlled by the semaphore, SP, such that only one robot at a time is allowed to enter the shared space. Next the algorithms to implement the above are presented with a detailed simula­tion of their operation that shows how all conflicts are detected and prevented. Those algorithms exist in a host com­puter that communicates with both robot controllers. The primitives used in the above algorithms are later explained.

The algorithm for Robot 1: L: < assemble bolt >

P(S1) (a request to put a part; check for full storage)

Journal of Dynamic Systems, Measurement, and Control DECEMBER 1985, Vol. 107/305

Downloaded From: http://dynamicsystems.asmedigitalcollection.asme.org/ on 09/20/2013 Terms of Use: http://asme.org/terms

P(SP) (a request to enter the shared space) < put the assembled bolt in the shared buffer > V(SP) (release shared space) V(S2) (informing that a bolt was placed in the shared buffer) go to L.

The algorithm for Robot 2: LI: < assemble spring and spool to valve >

P(S2) (a request to remove a part; check for emp­ty storage) P(SP) < remove a bolt from the shared buffer > V(SP) V(S1) (informing that a bolt was removed) < continue valve assembly > go to LI. S is a semaphore.

Initial values for this case are SI =2 and S2 = 0.

The primitives that are used in the algorithm are next defined: P(S):S = S - 1 ;

if S < 0 , then block (S);

V(S):S = S + 1 ; if S<0 , then unblock (S);

SP is a semaphore initially set to 1 Block (SP) means blocking the shared space.

The simulation of the cell operation, under the real-time control of Activity Controller - 1 is presented next in order to demonstrate the operations.

V Conclusions

We have introduced a new concept of Activity Controller for a multiple robot assembly cell. The responsibilities of the Activity Controller were divided into two: the first includes the routing logic and the second includes the synchronizing logic. The Activity Controller role was described with respect to the general control scope of a multiple robot assembly cell.

Start With Empty Shared Storage (Max. Storage: 2 Units)

Execution Simulation

1. 2.

3.

4.

5.

6. 7.

8. 9.

10.

11. 12. 13. 14.

15. 16.

17. 18.

19. 20. 21.

22. 23. 24.

25.

EVENT INITIALIZATION R2 Requests to remove a part (storage is empty) Rl Requests to put a part Not blocked. There­fore gets the shared area Free to actually put the bolt Release space R2 takes the shared area Takes the bolt Clears the Shared Area Rl assembles next bolt

Rl assembles next bolt

Rl assembles next bolt (blocked-storage is full)

Now Rl put the bolt

Robot 1

-

P(S1)

P(SP)

V(S2)

V(SP)

_ -

_

P(S1) V(SP) V(S2) P(SP)

P(S1) V(SP) V(S2)

P(SP)

P(S1)

--

-P(SP)

V(S1) V(SP)

Actions

Robot 2

-

P(S2)

_

-

—

-

P(SP) V(S1)

V(SP)

_ ---

_ ---

-

P(S2) P(SP) V(S2)

V(SP)

-

— -

Semaphore

SI 2

2

1

-

1

1

1 2

2

1 1 1 1

0 0 0

0 - 1

block Rl - 1 - 1 0

Unblock Rl 0 0

1 1

Value

S2 0

- 1 block

R2

- 1

- 1

0 unblockR2

0

0 0

0

0 0 1 1

1 1 2

2

2

SP Semaphore Rl

Activate 1

1

1

0

1

0 0 1

1 0 0

1

1

1

0

0 1

R2 Activate

0 0

1

1

0 0

1

306/Vol. 107, DECEMBER 1985 Transactions of the ASME

Downloaded From: http://dynamicsystems.asmedigitalcollection.asme.org/ on 09/20/2013 Terms of Use: http://asme.org/terms

A detailed case study demonstrated an implementation of the Activity Controller algorithms for both phases. A simple example was chosen so that the details of the algorithm could be presented. The example captures the core problems that arise in other cases. Even for that simple case, the cell cannot work without the Activity Controller unit that coordinates the cell activities. An optimal routing was achieved and it was shown by simulation that the cell operations are synchronized and conflict situations are avoided.

References

1 Dijkstra, E. J., "A Note on Two Problems in Connection with Graphs," Numerische Math., Vol. 1, 1959, pp. 269-271.

2 General Electric Assembly Robot Model A12, bulletin GEA-11048 A, 1981.

3 Kondoleon, A. S., "Cycle Time Analysis of Robot Assembly System," The C. S. Draper Lab, Proceedings of the 9th International Symposium on In­dustrial Robots, Mar. 1979, pp. 575-587.

4 Kohno, M., Takahashi, M., Isobe, M., and Horino, H., "An Assembly Robot System with Twin Arms and Vision," Hitachi Ltd., Proceedings of Autofact III, 1981, pp. 475-481.

5 Maimon, O., "A Multi Robot Control Experimental System with Ran­dom Parts Arrival," Proceedings of the IEEE International Conference on Robotics and Automation, Mar. 1985, pp. 895-900.

6 Maimon, O., "Activity Controller for a Multiple Robot Assembly Cell," Ph.D. dissertation, School of Industrial Engineering, Purdue University, West Lafayette, Ind. 1984.

7 Nagel, R. N., Lechtman, H., Plomann, L. E., Webber, N., and Sutton, T., "Connecting the Puma Robot with the MIC Vision System and Other Sen­sors," Robotic Lab., International Harvester, Nov. 1981.

8 Nof, S. Y., Whinston, A. B., and Bullers, W. J., "Control and Decision Support in Automatic Manufacturing Systems," AIIE Trans., Vol. 12, No. 2, 1980, pp. 156-165.

9 Proceedings of the 1st International Conference on Assembly Automa­tion, I. F. S. (Publications) Ltd., Brighton, U.K., Mar. 1980.

10 Proceedings of the 2nd International Conference on Assembly Automa­tion, I. F. S. (Publications) Ltd., Brighton, U.K., Mar. 1981.

11 Westinghouse-series 5000 Industrial Robot System, Bulletin 22-530, Jan. 1982.

Journal of Dynamic Systems, Measurement, and Control DECEMBER 1985, Vol. 107/307

Downloaded From: http://dynamicsystems.asmedigitalcollection.asme.org/ on 09/20/2013 Terms of Use: http://asme.org/terms