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

k 
mx dx cx 
+ + 
.. . 
k, m, d, c > 0 
k > 0, c = 1, m & d = 0 
Figure 6.6: Interfacing the control laws through changing the parameters
Switch interface
This interface encapsulates the signals and parameters in blocks which are
already tuned and ready to be used (Figure 6.7). Although very beneficial
from the user’s point of view, it may lead to redundancy in the inner construc-
tion of the interface. To ensure a similar level of functionality as that of the
latter interface and without threatening the abstract nature of the blocks, a
back-door to a limited number of parameters is provided. Hence, an operator
is not restricted by the default values of the parameters but is capable in a
limited capacity to change them if su
fficient knowledge is available.
The functionality in both interfaces does not significantly di
ffer, but their architectural
structure and how the human operator or any other intelligent entity perceives them marks
how contrasting they are. What makes the second interface more appealing for a human
operator is the ability to abstract the required action for a predefined output. Instead of
93

---

6 Software Environment
Manipulator 
FTS 
Impedance 
Controller 
Compliance 
Controller 
Trajectory 
Adaptive 
Accommodation 
Paramet
ers 
Figure 6.7: Interfacing the control laws through triggering predefined blocks
worrying about the inner workings of the underlying control loops, for instance setting the
controller parameters, it defines the controller in term of what the required functionality
is from the system. Thus the user only has to trigger or activate
/deactivate one or more
blocks to achieve a certain functionality. On the other hand, the first interface allows an
adaptive parametrization scheme as required di
fferent parts of a process. Which is readily
consistent with the parametrization scheme mentioned in section 5.3. Thus providing an
adequate interface for artificial intelligent units to manipulate the behavior of the control
structure through parameter manipulation.
6.4.4 Configuration matrices
Configuration matrices are based on the motion and force requirements for each phase
in a cooperative task. The terms stem from the fact that the requirements translate into
connections between signals, which is represented by a matrix-like structure (as seen in
Figure 6.4). Two sets of configuration matrices are defined here:
Programming Configuration Matrix (PCM)
This configuration matrix sets the control modes during programming of a
task. The user influences this by deciding certain actions.
Runtime Configuration Matrix (RCM)
This configuration matrix sets the control modes when a task is in play-back
mode i.e. during execution of the task. In this case the user can’t enable or
trigger any modes (can’t influence them) i.e. automatic operation.
94

---

6.5 Device integration
The di
fference between the two matrices depends on several factors. Chiefly is the
number of phases in any given task and how variable the force and motion requirements
are. This increases the complexity of both the programming and run-time configurations
significantly. Furthermore, the flexibility of the system encourages the operator to combine
several programming methods together by using functionalities inherent to specific run-
time phases during programming. Naturally, such hybrid methods tend to proportionally
increase the deviation between the two configurations.
6.5 Device integration
In this section, two classes of device integration will be discussed. The first is the HMI e.g.
positioning and haptic devices, while the second is concerned with connecting to external
devices through a communication bus. Both rely heavily on the design choices and the
implementation details of the software and the accompanying real-time platform.
6.5.1 Human machine interface
The term HMI is used to describe any interaction between a human and a machine during
a certain task, literally when humans and machines meet (About.com: Ergonomics 2011).
This includes everything from input devices, switch panels to graphical user interfaces
and touch screens (Georgia Institute of Technology et al. 2009, P. 82). Human Robot
Interaction (HEI) is a related field of study which is dedicated to designing and evaluating
interfaces specifically between robots and humans (Goodrich & Schultz 2007)(Reinhart
et al
. 2010a). Consequently, in this section the discussion is limited to devices that allow
the operator to control
/navigate the robots in an intuitive and simple manner. Their main
advantage is their simplicity, thus no prior tutoring to operate them is necessary. However,
they do require some familiarity to be operated e
fficiently, which mainly depends on the
type and structure of the device. The device classes addressed here are divided into:
Positioning Devices
These are input devices that measure the change in their relative po-
sition and
/or the orientation when the user operates them. They may
contain joints and hence exhibit a mechanical structure. Measurement
of those variables could be done by two methods, either by independent
sensors or calibrated sensors. Gyroscopes for rotational movements and
optical encoders for translational movements are common examples of
independent sensors usually built in commercial devices (Pongrac et al.
2007)(Neto et al. 2009). Calibrated sensors on the other hand require
calibration with external components. Laser and infrared tracking de-
vices are common examples which require external calibration (Hein
et al
. 2008)(Brecher et al. 2010).
95

---

6 Software Environment
Haptic Devices
Haptic devices can also be considered a subset of positioning devices.
The main di
fference though is that the device acts not only as an input
device but also as an output device (Mali & Munih 2003). By incorporat-
ing motors in the device, forces and
/or torques could be conveyed back
to the user in real-time. This complicates the mechanical structure and
construction of the device but greatly enhances the user experience when
interacting directly with a virtual environment or a physically remote
environment (Massie & Salisbury 1994)(Stone 2000). Additionally, it
can be used for assisting the operator during o
ff-line programming with
haptic cues (W¨orn et al. 2005).
To accommodate di
fferent classes of devices, an abstraction layer is developed based on
the CHAI3D device abstraction class; namely cGenericDevice (Conti et al. 2011b). As
seen in Figure 6.8, each device is imparted to a certain number of inputs and
/or outputs.
Conventional input signals are for instance position and rotation for both positioning and
haptic device classes. On the other hand, some output signals such as forces, are exclusive
only for haptic device class. After investigating di
fferent devices, other common inputs
and outputs were incorporated in the design of the abstraction layer, for example buttons
and LEDs. Those inputs
/outputs imparted to a certain device are mapped into the signal
matrix as ports specific to this class of device.
HMI 1 
HMI 2 
HMI 3 
User Configuration 
Inputs
 
Pose 
Buttons 
Other 
Outputs
 
Force 
LEDs 
Other 
Abstraction Layer 
Device Driver
 
Mapping  
in the 
Signal  
Matrix 
Environment