CARLETON UNIVERSITY

Department of Systems and Computer Engineering

SYSC 4805/4806 Project Specification – Winter 2009

Resource Management of a Multi-Robot Assembly Cell

1. Problem Statement
The topic of the project is flexible manufacturing systems that, in simple terms, are robotic
factories. A factory generally has several lines, each comprised of assembly cells. An assembly
cell is a set of robots that collectively perform a cohesive set of tasks. From a manufacturing
technology perspective, an assembly cell may be considered as a system that is processing
physical objects. The objects flow through a sequence of functional units, which perform
different assembly operations specified as task-level instructions. Such an assembly operation
has two distinct phases: "object fetching" and "object assembling".
In the object fetching phase, the object is brought within the grasp of a robot hand by a so-
called "object presentation units," (OPU). Different devices may be used to implement the
functions of this phase, such as mechanical devices (containers, feeders, conveyors, etc.), and/or
sensory devices (vision, position sensors, etc.).
In the object assembling phase the object is submitted to a sequence of motions as requested
by the specific assembly operation. Twelve basic assembly operations were identified in
literature: simple peg in hole insertion, push and twist, insert peg and retainer, multiple peg in
hole insertion, force fit, remove locating pin, flip object over, provide temporary support, crimp
sheet metal, remove temporary support, screw, weld or solder. The functional unit responsible
for the assembling phase is called "assembly processor" (ASP). It consists of a self-contained,
sensor-based, robotic system (i.e., a robot arm plus the proper sensors and algorithms) capable to
perform assembly operations specified as task-level instructions.

Figure 1. Example of a car assembly cell

 Ideally, a multi-robot assembly cell should be modular, extensible, reliable, efficient, robust,
and adaptable. In order to meet these requirements, the programming of such systems is done at
two levels of abstraction: a) task-level programming specifies the basic assembly operations
independent of the actual ASP platform (hardware and software); and b) detailed ASP
programming specifies the detailed robot motions and sensor conditions for performing a given
operation. In general, different ASPs can perform different assembly operations, which are
specified in a capability list. Some ASPs are general-purpose, others may be more specialized.
A task-level program (a.k.a. task plan) can be represented by a precedence graph, as in
Figure 2. A node represents a task and is specified by the following information:
task := <operation>, <object>, < place>, [<options>]
where:
<operation> := basic assemby operation {e.g., SMP_PEG_HOLE, PUSH_TWIST,
FORCE_FIT, REMOVE_PIN, FLIP_OVER, CRIMP_SHUT, SCREW, WELD_SOLDR}
<object> := object label (e.g., AXLE, PEG, WHEEL)
<place> := place on the assembly where the <object> is to be assembled
<options>:= optional parameters specific to this <operation>

Figure 2. Simple example of a task plan for Figure 1

The tasks from Figure 2 are defined as follows:
T1: WELD_SOLDR, AXLE, REAR
T2: WELD_SOLDR, AXLE, FRONT
T3: SMP_PEG_HOLE , WHEEL, RL
T4: SMP_PEG_HOLE , WHEEL, RR
T5: SMP_PEG_HOLE , WHEEL, FL
T6: SMP_PEG_HOLE , WHEEL, FR
2. Project Objective
The objective of the project is to develop a RR-RT model for the resource management of a
flexible multi-robot assembly cell that supports task-level programming. The model will be used
to verify the correctness of the design, and will support quantitative analysis of performance/cost
tradeoff for different cell configurations and task plans.
The resources of a cell include the assembly processors ASPs, the object-presentation units
OPUs as well as (3-dimensional) physical space. The model is to be based on a decentralized,
message-driven architecture that allows for negotiated task planning and sharing of resources
(OPUs and physical space) to achieve an optimal configuration for a given task plan.
Instead of a centralized script or controller in which ASPs and OPUs are pre-selected
according to a static task plan, ASPs are allowed to bid on each instruction of the task plan
according to their availability and capability. This approach accommodates variations in
completion times and workload. In general, it leads to a more flexible resource management
scheme that maximizes throughput of the assembly cell and utilization of its components. The
resource management system contains a task scheduler that is responsible for determining which
tasks can be executed. When a task’s turn to be executed arrives, the task scheduler broadcasts
the request and each ASP that is able to carry out the task and is available may bid for it. If
multiple ASPs bid for the task, one is selected according to a given scheduling policy. The
selected ASP is granted the task and starts to execute it, while the remaining ASPs may continue
to bid on the next task(s).
In performing a task, the selected ASP must then negotiate the use of the assembly cell’s
shared resources: the OPUs as well as physical space. A close look at the sample assembly cell
shows that the same OPU1 transports both wheels and axles to both ASP1 and ASP3. The ASP
must move to the OPU, grasp the presented object and move to the designated assembly place to
perform the indicated assembly operations. Different ASPs may share the same working space
while working on parallel tasks. Before moving (either to the OPU or to the assembly place), an
ASP must avoid the risk of collision with other ASP moving in the same space, by asking the
space manager for an available pathway. Once granted, all other intersecting pathways are
blocked until the path is released. Requestors of a blocked path shall be queued by the space
manager; as soon as the path becomes unblocked, they will be notified to continue their activity.

Testing Requirements
The objective of the project is to develop a model with the Rational Rose Real-Time (RR-
RT) tool. Certainly, you will be required to verify the correct behaviour of your model according
to the description above. For example, robots should not collide when they move.
As stated above, the model must support the quantitative analysis of performance/cost
tradeoff for different cell configurations. By cell configuration we mean the number of ASPs
(each with known capabilities and cost) and the number of OSPs (with known costs) for a
particular assembly cell. Once your model is working, you must use it to collect performance
data (such as total execution time (including waiting) for a task plan, utilization of ASPs and
OPUs (i.e., percentage of time they are working on behalf of a task, from the allocation to the
completion) and cell throughput. Below, we provide sample numbers for a basic test suite in the
form of (1) a set of tasks (2) a set of components (OPUs and ASPs) and their capabilities and (3)
sample timings for assembly operations. You may use these numbers to try different
configurations of an assembly cell and compare their performance (eg. 2 ASPs and 1 OPU versus
2 ASPs and 2 OPUs, versus 3 ASPs and 2 OPUs, etc.). Please note that the examples given –
both the car assembly cell and the sample test plan – are meant as one sample that should help
you understand the project’s objectives. A good design will be general, and will allow easy
replacement with other sample data.
Let us define the tasks: T1, T2, T3, T4, T5, T6
Let us define the cell components, and list the capabilities of each (which tasks it can do)
• ASP1 = {T1, T3, T5}
• ASP2 = {T1, T4, T6}
• ASP3 = {T2, T5, T6}
• OPU1..3 shall all be able to present the appropriate objects for T1..T6
Let us define the timing of each operation as averages:

Assembly Operations Units of Time

Reset of assembly platform 1

Any OPU to fetch an object: 4

Any ASP to move towards the OPU which delivers a requested object 1

Any ASP to move the grasped object to the assembly place 1

An ASP to join an object within the assembly according to tasks T1 or 6

T2

An ASP to join an object within the assembly according to tasks 4

T3,T4,T5,T6

Marking Expectations (Things to think about)

Due to student workload constraints, many aspects that are important in real life are simplified in
the project. Instead, the expectation is good software engineering, extensible and flexible
designs, and the knowledgeable use of UML features (including but not limited to composite
states, ports and contracts, nested states, sending data in messages and using operations).
ƒ Depending on the cell configuration, an OPU could serve exclusively an ASP, or
could be shared by two or more ASPs. In the second case, the OPU behaviour is more
complex than in the first one, as the requests arriving while OPU is busy must be
queued for later processing. You may choose to implement the simple case (without
queueing), where the association ASP-OPU is one-to-one, or the more complex case
(with queueing), where the association is n-to-one.
 ƒ The scheduling policy for selecting an ASP in the case of multiple bids for a task is
left open. You may implement as you wish, but your design should allow for easy
replacement.
ƒ The approach to space management could be very simple (e.g., if two ASPs can move
in the same space, allow only one to move at a time) or more complex. Think about
different solutions, but start with a simple one at first.
ƒ Models that are general and extensible will earn a potentially higher grade (as long as
they are well done and well documented) whereas models that are specific will limit
the maximum possible grade. As one example, a model that handles the general case
of OPUs being shared by ASPS has a higher potential grade than a model that
assumes that there is always one OPU for each ASP.
Please note that the problem statement will not change, but we may add other details if it
becomes necessary.