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

Operating System
Software Environment (PuppetMaster 4D)
CHAI3D
QT
QTCore
Container, Signals and Slots
QTGui
Graphical user Interface
QTNetwork
UDP-Server & Client
QTXml
XML-Reader
No
vin
t
F
a
lc
o
n
hdFalcon
S
e
n
sa
b
le
P
HA
NT
O
M
hdPhantom
Q
U
A
NCO
M
W
iib
re
w
L
ib
 
N
inetendo
W
iiM
ot
Figure 6.1: Library components of the software environment (Hubele 2009)
6.3.2 Joints
The choice of CHAI3D included the choice of ODE as the physics engine. ODE is an
open source physics engine with a small foot-print and e
fficient calculation schemes
(Smith 2011). Inherent to the engine is also a collision detection capability which is
connected to the physics calculation. Of particular interest in ODE are the types of joints
representing several types of real life motors and actuators (Figure 6.2). They are described
as follows:
82

---

6.3 Environment
Ball
possesses 3 rotational DOF and is specified by one point i.e the anchor.
Hinge
possesses 1 rotational DOF along an axis at the anchor and is commonly
used to represent rotational motors (whether geared or not).
Slider
possesses 1 translational DOF along an anchor and is mainly used to repre-
sent linear motors.
Piston
possesses 1 translational and 1 rotational DOF and is in reality a combination
of a slider and a piston and represents the motion in an internal combustion
engine.
Fixed
possesses no DOF, its main aim is to fix two bodies together preventing any
relevant movement between.
[a] Ball
[b] Hinge  
[c] Slider 
[d] Piston
Figure 6.2: Joint types in
ODE from http://www.ode.org
6.3.3 XML-based description
XML is quickly becoming the language of choice for information saving and retrieval.
Its simple and human-like structure makes it an ideal contender for cross-application
information exchange (Bray et al. 2008)(World Wide Web Consortium 2011). This is
reflected in the increasing number of applications which define their information in XML
structures
/files (Arnaud & Parisi 2007). In the computer graphic industry an effort is being
83

---

6 Software Environment
undertaken to unify the environment descriptions in graphic software including modeling,
animation and manipulation. The COLLADA consortium developed a simple and intuitive
environment definition based on the XML language specification to describe 3D content
(Sony Computer Entertainment Inc. & Khronos Group 2011). In this work, a similar
data structure was developed to describe a dynamic virtual environment (Barnes et al.
2008). The data structure represents not only the graphical and dynamical description
of the software but also the signals and information flowing through the software. In the
following descriptions the di
fferent components of the structure will be presented:
Environment properties
A basic environment definition must contain certain information at the beginning of the
description. This includes the name (name), dynamic simulation parameters (erp, cfm)
and light properties (ambient,specular). For the dynamics to be correctly calculated
the gravity vector has to be defined (gravity). The background color of the graphical
environment could also be directly defined (color). According to the user’s needs,
di
fferent light objects could be included to give a photo-realistic graphical rendering of
the environment. A combination of the latter elements in a basic environment definition
would look like the following xml-listing:
FILE: test_environment . env
< environment name =" Test_Environment " scale =" 1.0 " erp =".8" cfm ="1e -18 "
ambient =" -.8" specular ="1.">
< gravity z=" -9.81 "/>



< translation x="50" y=" 100 " z="80" />


Object hierarchical structure
To accommodate chained structures, the XML-description is based on a hierarchical
structure. It allows the aggregation of objects that constitute one body or mechanism to be
represented in a parent-child manner. For instance, in the following listing an articulated
robot with six DOF is described accordingly from base to wrist:
FILE: RobotTypeX . prt













84

---

6.3 Environment



Beside being easy to understand the relation between di
fferent objects, this method is also
used to build a library of commonly used components and referencing them for repeated
use or saving them for use in other definitions. A prime example thereof is that of robotic
mechanisms. Using the definition of a specific robot class in the latter listing, one could
reference it repeatedly in the same environment but with di
fferent names and locations to
create an array of similar robots. It has to be noted though, that in their definition di
fferent
base locations have to be defined.
< environment >
[...]


< translation x="0" y="0" z="0" />


< translation x=" 100 " y=" 100 " z="80" />


< translation x=" 200 " y=" 100 " z="80" />


[...]
< environment >
Object I
/O
Where the  denotes the existence of inputs (the  structure)
and
/or outputs (the 

 structure) for the object it is wrapped in. The latter signal
structure is not only limited to simulated objects but also to graphical and external objects.
The controller sets the variables for the position control of the respective component
and additionally sets limits on the positional and rotational DOF. Moreover graphical
lines denoting the forces from external FTS sensors could be visualized according to a
predefined scale:

< ioobject switchports =" true ">
< controller >








85

---

6 Software Environment
6.3.4 Graphical components
The graphical components allow the user to comfortably interact with the structural
components of the software environment. With the exception of the signal matrix, all
of the components are dynamically defined. Hence they are only available when the
user creates them in run-time. Furthermore, most of the graphical components have
emitter
/receiver ports (this will be detailed in in Table 6.1).
Graphical view
The graphical view represents a 3D render or a view port of the environment
in run-time, through which the user can visualize the e
ffect of interactions
and changes by him or by the constraints imposed by the physics engine. The
user can also create more than one view port to visualize the environment
from di
fferent perspectives. Additionally he can also manipulate each view
independent of the others by zooming, panning and rotating it using the
computer mouse.
Signal matrix
The signal matrix represents the front-end or graphical interface to the signal
management scheme that will be introduced in section 6.4. It enables the
user to reconfigure the signal connections between the di
fferent components
in run-time. This window is constantly updated to accommodate new signals
being dynamically defined or destroyed. If the user clicks a connection
between two defined objects, an attachment window opens up beside the
main window exhibiting the emitter and receiver ports of those objects.
Recorder
A recorder is a dynamically defined window, which contains several sub-
windows. After the user creates a recorder in run-time, he is allowed to
define an infinite number of signals in the shape of channels. Each channel
has a type and a name and is considered both an input and output object. If
the channel is connected to a signal as in input, it records the data from that
signal with time and is thus a recorder. On the other hand, connecting the
same channel to a signal as output makes the channel a play-back device and
thus could be used to execute recorded signals.
Switch-box
A switch-box is a dynamically defined window, which is derived from a
connection between two objects. It enables the user a simple and direct
access to important boolean signals in the signal matrix, without having to
resort to the complicated and error-prone process of clicking through and
managing the signal matrix.
UDP connection
This window represents a connection to an external device via Ethernet. It
can be configured using a special configuration file containing the name
86

---

6.3 Environment
[4]
[1]
[2.a]
[3]
[5.b]
[5.a]
[4]
[6]
[7]
[8]
[5.c]
[2.b]
[5.b]