The Robotics Laboratory
This chapter describes the developed concept
and set-up of our robotic laboratory. It is aimed at the
technically interested reader and explains some of the hardware
aspects of this work. A real robot lab is a testbed for ideas
and concepts of efficient and intelligent controlling,
operating, and learning. It is an important source of
inspiration, complication, practical experience, feedback, and
cross-validation of simulations. The construction and working of
system components is described as well as ideas, difficulties
and solutions which accompanied the development.
For a fuller account see (Walter and Ritter
1996c). Two major classes of robots can be distinguished:
robot manipulators are operating in a bounded
three-dimensional workspace, having a fixed base, whereas
robot vehicles move on a two-dimensional surface – either by
wheels (mobile robots) or by articulated legs intended for
walking on rough terrains. Of course, they can be mixed, such as
manipulators mounted on a wheeled vehicle, or e.g. by combining
several finger-like manipulators to a dextrous robot hand.
2.1 Actuation: The Puma Robot
The domain for setting up this robotics
laboratory is the domain of manipulation and exploration with a
6 degrees-of-freedom robot manipulator in conjunction
with a multi-fingered robot hand. The compromise solution
between a mature robot, which is able to
Figure 2.1:
The six axes Puma robot
arm with the TUM multi-fingered hand
fixating a wooden “Baufix” toy airplane. The 6D
force-torque sensor (FTS) and the end-effector mounted camera is
visible, in contrast to built-in proprioceptive
joint encoders.
Figure 2.2:
The Asymmetric
Multiprocessing “Road Map”. The main hardware
“roads” connect the heterogeneous system components and
lay ground for various types of
communication links. The LAN Ethernet (“Local Area Network”
with TCP/IP and max. throughput 10 Mbit/s) connects the
pool of Unix computer workstations
with the primary “robotics host” “druide” and the “active
vision host” “argus” . Each
of the two Unix SparcStation is bus master to a VME-bus
(max 20 MByte/s, with 4 MByte/s S-bus link). “argus”
controls the active stereo
vision platform and the image processing system (Datacube, with
pipeline architecture).
“druide” is the primary host, which
controls the robot manipulator, the robot hand, the sensory
systems including the force/torque wrist sensor, the tactile
sensors, and the second image processing system. The hand
sub-system electronics is coordinated by the “manus”
controller, which is a second VME bus master and also accessible
via the Ethernet link. (Boxes with rounded corners
indicate semi-autonomous sub-systems with CPUs enclosed.)
carry the
required payload of about 3 kg and which can be turned
into an open, real-time robot, was found with a Puma 560
Mark II robot. It is probably “the” classical industrial robots
with six revolute joints. Its geometry and kinematics1
is subject of standard
robotics textbooks (Paul 1981; Fu, Gonzalez, and Lee 1987). It
can be characterized as a medium fast (0.5 m/s straight line),
very reliable, robust “work horse” for medium pay loads. The
action radius is comparable to the human arm, but the arm is
stronger and heavier (radius 0.9 m; 63 kg arm weight). The Puma
MarkII controller comprises the power supply and the servo
electronics for the six DC motors. They are controlled by six
parallel microprocessors and coordinated by a DEC LSI-11 as
central controller. Each joint microprocessor (Rockwell 6503)
implements a digital PD controller, correcting the commanded
joint position periodically. The decoupled joint position
control operates with 1 kHz and originally receives command
updates (setpoints) every 28ms by the LSI-11.
In the standard application the Puma is
programmed in the interpreted language VAL II, which is
considered a flexible programming language by industrial
standards. But running on the main controller (LSI-11
processor), it is not capable of handling high bandwidth sensory
input itself (e.g., from a video camera) and furthermore, it
does not support flexible control by an auxiliary computer. To
achieve a tight real-time control directly by a Unix
workstation, we installed the software package RCI/RCCL (Hayward
and Paul 1986; Lloyd 1988; Lloyd and Parker 1990; Lloyd and
Hayward 1992).
The acronym RCI/RCCL stands for Real-time
Control Interface and Robot Control C Library. The
package provides besides the reprogramming of the robot
controller a library of commands for issuing high-level motion
commands in the C programming language. Furthermore, we patched
the Sun operating system OS 4.1 to sufficient real-time
capabilities for serving a reliable control process up to about
200 Hz. Unix is a multitasking operating system,
sequencing several processes in short time slices. Initially,
Unix was not designed for real-time control, therefore it
provides a regular process only with timing control on a coarse
time scale. But real-time processing requires, that the
system reliably responds within a certain time frame.
RCI succeeded here by anchoring the
synchronous trajectory control task (a special thread) at a
special device driver serving the interrupts from a timer card.
The control task is thus running independently and
outside the planning task. By this means, sensory
information (e.g. camera or force sensors) can be processed and
feedback in a very effective and convenient manner.
For example, by default our DLR 6D wrist
sensor is read out about the currently exerted force and torque
vector (3+3=6 D) between the robot arm and the robot hand (Fig.
2.1, 2.4). The DLR Force-Torque-Sensor (FTS) was developed by
the robotics group of Prof. Hirzinger of the DLR,
Oberpfaffenhofen, and is a spin-off fromthe ROTEX Spacelab
mission D2 (Hirzinger, Brunner, Dietrich, and Heindl 1994). As
indicated in Fig. 2.2, the FTS is an micro-controller based
sensory sub-system, which communicates via a special field-bus
with the VME-bus.
Figure 2.3:
A two-loop control scheme
for the mixed force and position control.
The inner, fast loop runs on the joint micro controller
within the Puma controller, the
outer loop involves the control task on “druide”.
The resulting robot control system allows us to implement hybrid
control architectures using the position control interface. This
includes multisensor compliant motions with mixed force
controlled motions as well as controlling an artificial spring
behavior. The main restriction is the difficulty in controlling
forces with high robot speeds. High speed motions with
environment interaction need quick response and therefore
require, a very high frequency of the digital force control
loop. The bottleneck is given by the Puma controller structure.
The realizable force control includes a fast inner position loop
(joint micro controller) with a slower outer force loop
(involving the Sun “druide”). But still, by generating
the robot trajectory setpoints on the external Sun workstation,
we could double the control frequency of VAL II and establish a
stable outer control loop with 65 Hz.
Fig. 2.3 sketches the two-loop control scheme
implemented for the mixed force and position control of the
Puma. The inner, fast loop runs on the joint micro controller
within the Puma controller, the outer loop involves the control
task on the Sun workstation “druide”.
The guard block checks on specified sensory patterns,
e.g., forcetorque ranges for each axes and whether the robot is
within a safe-marked work space volume. Depending on the desired
action, a suitable controller scheme and sets of parameters must
be chosen, for example, S, gains, stiffness, safe
force/position patterns). Here the efficient handling and access
of parameter sets, suitable for run-time adaptation is an
important issue.
Figure 2.4:
The endeffector.
(left:) Between the arm and the hydraulic hand, the
cylinder shaped FTS device can measure current 6D force
torque values. The three finger
modules are mounted here symmetrically at the 12 sided regular
prism base. On the left side, the color video camera
looks at the scene from an end-effector
fixed position. Inside the flat palm, a diode laser is directed
in tool axis, which allows depth
triangulation in the viewing angle of the camera.