Dissertation: a work Piece bases Approach for Programming Cooperating Industrial Robots

Table 4.1: Motion and force requirements for each phase in a cooperative task
4.3 System prerequisites
The discussion in section 2.6 points out the drawbacks of current robot work-cells w.r.t.
their architecture and their adverse e
ffect on the robot’s programming capability. To
overcome this, it is imperative to develop a flexible robot architecture that facilitate a
simpler and more intuitive (re-)programming and operation of robotic work-cells. A
flexible architecture should not dictate specific programming technique to the user, but
allow him to create and mix di
fferent paradigms together.
47

---

4 Prerequisites and Conceptual Framework
commercial 
robot 
controller 
commercial 
robot 
controller 
SLAVE 
SLAVE 
work-piece controller 
User-interface 
simulation environment 
MASTER
 
program 
Figure 4.2: The envisioned architecture for implementing the WPBA on industrial cooper-
ating robots
Consequently, rethinking of components and interactions in a robot architecture is deemed
necessary to achieve this. To implement the WPBA a robotic architecture (as seen in
Figure 4.2 compared to the classical architecture in Figure 2.9) is envisioned. Despite the
similarity between both architectures, the proposed architecture exhibits nevertheless a
significant departure from the classical controller. For instance, the work-piece controller
and the master controller in classical arrangements represent the same centralized control
approach but the former is tightly integrated with the simulation environment and the user
interface. Additionally, force signals are exchanged between the robots and the controller,
making dynamic information available for di
fferent control schemes irregardless of their
location (centralized vs. decentralized schemes). Hence both kinematic and dynamic
synchronization is guaranteed. Moreover, the integrated nature of the architecture allows
the signals to be available for all other system components. On the whole, the architecture
reduces the robots to mechanical units while control on all levels is unloaded to an
external controller which communicates with the robots through appropriate interfaces.
Consequently, it renders the work-cell more flexible to reconfigure according to the task
at hand and the selected programming paradigm. Thus, the latter architecture leads to
certain assumptions about what the CIR system should be capable of. In this section the
prerequisites for such a system -which would fulfill the WPBA- are discussed.
48

---

4.3 System prerequisites
4.3.1 Bandwidth-oriented control
In the classical sense, bandwidth defines the ability of the controller to respond to system
inputs within a given time period (Mastascusa 2005) (System Dynamics - Response
Time). This is mainly a
ffected by actual implementation of the control loops i.e. the
type and speed of hardware and communication means available to preform the control
task in the real world. In this work, bandwidth oriented control is a redefinition of the
classical layered control theory, where the layers are stacked upon each other according to
decreasing bandwidth. Since decreasing bandwidth also means variable sample rate, it is
convenient to define each layer with its own sample rate. Although the term multi-rate
control could be theoretically used to define such a scheme, it is crucial to point out the
significant di
fference between the two concepts. Multi-rate control denotes the existence
of several sample rates in the control loop without alluding to any functionality inherent to
these di
fferent rates. On the other hand bandwidth oriented control contains layers with
di
fferent sample rates that are prescribed certain functionalities. Thus, not only is the
control system limited to low-level control (i.e. high BW) but also to intelligent control and
decision making. This technique is famous among robotic researchers which investigate
both high-level and low-level control (Gueaieb et al. 2007b).
4.3.2 Sensor-based architecture
A sensor-based control architecture would allow the manipulators to continuously update
their knowledge base and thus be more adaptive to the immediate environment they
are in contact with (Schmitt et al. 2010). With this capability, adopting the needs of
the task to those of the process would be greatly simplified by augmenting the control
capabilities with sensoric measurements. Sensoric values augment an architecture in
three di
fferent capacities. In a programming capacity, it could be used for correcting
automatically generated code from an o
ff-line simulation tool. Additionally sensors could
also be directly utilized for programming the work-cell and hence facilitating simpler
programming techniques as mentioned in section 2.2.1.3. In a control capacity, sensors
are used in a closed loop control manner for disturbance rejection and achieving control
objectives associated with the operation; whether they are motion or force requirements.
Another common use is for safety measures during operation, where critical values are
monitored and consequently safety procedures are triggered if they exceed defined limits.
And finally in a high-level intelligence capacity, it is utilized for decision making and its
accompanying real-time control during operation.
4.3.3 Flexible information flow
Guaranteeing that signals between di
fferent components and devices are freely exchanged
in a robotic system is necessary to ensure maximum flexibility of information flow and
signal transparency. Consequently, this provides a solid base for a flexible architecture as
earlier proposed. Signal transparency here means that all signals flowing in the subsystems
49

---

4 Prerequisites and Conceptual Framework
must be accessible to all decision-making entities whether they are human operators,
intelligent control units or even remote entities. However, at one point in the control stack
a line has to be drawn between low-level control and decision making. Although this
line is up to the human system designer, it is imperative to reach a compromise to avoid
over-flooding the signal interface with a huge number of signals. Safety is also an issue to
be considered, if critical signals were allowed to be freely manipulated. On the other hand
restricting the number of signals would lead to a classical situation where the interface
is limited and would thereby restrain the capability of the whole architecture regarding
information flow. Nevertheless, during actual implementation the designer should take
performance issues into consideration. Details such as signal origins, signal data types,
communication data rate and data types have a direct impact on inter-communication in
an architecture and can’t be overlooked.
4.3.4 Intuitive human machine interfaces
Since programming represents the focus of this, simple and intuitive methods to inter-
act with the system are of paramount importance. Interaction here could be classified
according to the activity of the human operator. Initially, during programming the operator
should be able to dictate the motion of the robots and
/or work-piece using intuitive input
devices. Additionally, this has to be augmented with an easy-to-understand graphical
user interface (GUI) to enable quick editing of programs. These devices and interaction
methods should also be extensible to be utilized during testing and subsequent execution.
Hence, mechanisms for uncomplicated configuration between programming and execution
have to be designed.
50

---

4.4 Framework
4.4 Framework
Based on the latter task and system requirements a generic framework was derived to
simplify programming of CIR by implementing the WPBA. It is imperative to understand
that the framework is not a detailed design for a literal solution to the problem of program-
ming CIR. It rather represents a conceptual blueprint which could be utilized in a generic
manner. This also renders it flexible enough to be scaled and adopted according to the
required functionality and specifications. Naturally, this makes it open for interpretation in
light of several factors, chiefly being the designers’ engineering backgrounds, technical
preferences and prior experience. Furthermore, available hardware and budget constraints
have a profound influence on the interpretation of the framework and subsequent imple-
mentation of the solution. As seen in Figure 4.3, the components of the framework could
be aggregated into three main classes:
Class 1: Functional Components
This class contains two modules
1. Control Module: Encompasses algorithms and functions that possess
real-time constraints i.e. that require high bandwidth. Any break
down in the deterministic operation of this module leads to a failure of
major functionalities in the system, in other words reliability has to be
guaranteed at all times.
2. Software Module: Encompasses high-level control functions which
are not critical to the safe operation of the system. Additionally it
should provide the user with an intuitive GUI and simplify access to
di
fferent HMI.
Class 2: Device Components
This class contains four modules
1. Robot Module: Is composed of the actual commercial manipulator
and any extra actuators or linear motors attached to it. Any connections
between the manipulators’ commercial controllers and the rest of the
components are defined according to the type and capabilities of the
accompanying interface, whether it is real-time or not.
2. Sensor Module: Consists of all types of sensors such as FTS or in-
frared sensors.
3. HMI Module: This module consists of all HMI devices available to
the user. It is interfaced through the software module. Visual monitors
and haptic devices are examples of such devices.
4. Task-level Peripheries: These are devices that are imperative to task
execution but are usually independent from low level control, such as
grippers.
51

---

4 Prerequisites and Conceptual Framework
Class 3: Communication Architecture
Encompasses all communication buses connecting all the components to-
gether on an inter- and intra- module level.
The framework represents the backbone of this research work and accordingly the next
three chapters will discuss the technical realization thereof. In chapter 5, the control
module is realized as a multi-layered control architecture. Subsequently, in chapter
6, the software module in the form of a flexible software environment is developed.
Since the remaining two classes namely [device components] and [communication
architecture] rely heavily on the available hardware, they will be discussed in chapter
7 within the development of an industrial test-rig.
Proximity 
sensor
Force sensor
Laser scanner
Control module
……..
Communication bus
Sensor module
External PLCs
Gripper(s)
Task-level
peripheries
Haptic device
Positioning 
device
HMI module
Communication bus
Software module
Robot #1
Robot module
Robot #n
Sensor standard interface
Bandwidth-oriented
control 
architecture
Robot trajectory
generator
Sensor Data 
processing
RTOS standard interface
Work-piece trajectory
generator
Robot standard interface
3D Visualization
HMI standard inter
fac
e
Work-piece
trajectory
Process 
Prerequisites
Playback  mechanism
Degree Of Freedom 
mapping strategy
Signal management
scheme
Task specification
Communication bus
Communication bus
Communication bus