Programmer 7500/MAX_PROGRAMMERS.iso/INFO/C/ROBOT04.ZIP/RCCOVR.TXT

Text File | 1988-02-02 | 27.9 KB | 764 lines

.ND
.FS
This work was partially supported by a Grant from the CNRS
project ARA (Automatique et Robotique Avanc\o"e\'"e), France, and
by the Ransburg Chair of Robotics.
This material is also based on work supported by the National
Science Foundation under the Grant No. MEA-8119884.
Any opinions, findings, conclusions, or recommendations
expressed in this publication are those of the authors
and do not necessarily reflect the views of the National
Science Foundation.
Facilities to perform this research are provided by the Purdue University
CIDMAC
project.
.FE
.ce 1
Introduction to RCCL : A Robot Control "C" Library
.sp 7
.ce 1
Vincent Hayward
.sp 5
.ce 3
School of Electrical Engineering
Purdue University
West Lafayette, Indiana, 47907
.sp 5
.ce 1
TR-EE 83-43
.sp 5
.ce 1
October 1983
.bp
.EQ
delim $$
.EN
.AB
RCCL is a robot programming system that enables a user to
specify robot manipulators tasks employing a set of primitive system calls
similar in spirit to those of the UNIX input-output system.
This document is not intended to be a manual, but tries to give
the flavor of the underlying ideas.
The goals addressed in the RCCL system are:
.IP
manipulator task description;
.IP
sensor integration;
.IP
updatable world representation;
.IP
flexibility;
wide range of applications;
.IP
medium level robot programming;
.IP
off-line programming;
.IP
efficiency;
.IP
manipulator independence;
.IP
portability;
.IP
foreground-background programming;
.IP
Cartesian path programming;
.IP
Arbitrary path specification;
.IP
Tracking;
.IP
Force control;
.AE
.bp
.NH 1
Introduction
.PP
Most of the current robot programming systems are based on a dedicated
programming language.
Quite a large number of them exit
(AL, AML, HELP, JARS, LM, MCL, RAIL, VAL).
They consist of a language interpreter running at low priority
specifying motion parameters to a trajectory generator.
The trajectory generator, running at high priority,
and usually interrupt driven,
computes the sequence of joint variables
so as to produce the desired motion.
The sequence of joint variables is in turn transmitted to
a servo process capable of actuating the robot's joints.
The execution flow of the robot program is synchronized with the
actual motion of the manipulator.
Most language based systems, if not all,
are strongly tied to the computer hardware they are running
on, as well as to the type of manipulator they control.
The more sophisticated robot programming languages become,
the more they resemble high level computer programming languages
(ALGOL, PASCAL, etc.)
augmented with the data structures and operators
necessary to control robots.
Some languages can handle concurrent
processing.
.PP
RCCL is not a language but a set of system calls suitable for the
control of robot manipulators.
Manipulator programs become ordinary computer programs, and the
manipulator is considered as a peripheral device.
Since manipulator control primitives are put at the system level,
a program written in any language able to provide the proper
list of arguments can use the manipulator primitives.
.PP
Instead of designing yet another robot programming language,
we use the C language to obtain manipulators programs.
The RCCL system is itself written the C language.
C is a high level structured language suitable for any project sizes,
but allows us to deal with low level implementation details.
Programs are easily portable, and yet can be efficiently implemented.
Two criticisms are often made of compiled languages based systems.
The compilation time increases the edit-test cycle time.
If a program fails either because it is wrong from the manipulation
point of view, or from the programming point of view, the whole
task has to be stopped.
Practice has shown that these limitations are largely offset
by the gain in flexibility and generality.
If for some applications, an interpreted language is needed,
the interpreter of a general purpose or a dedicated
language can also make use of RCCL system calls.
We would obtain, in that case, a large gain in modularity.
The RCCL design approach has advantages in modularity,
flexibility and hardware independence.
.FS
The first implementation runs on a VAX 11/780 computer under UNIX.
It has been used to control a PUMA manipulator and a Standord Arm.
.FE
.NH 1
Overview
.NH 2
Manipulator task description
.PP
The location of an object is described by its position and orientation
with respect to some reference coordinate frame.
In the remaining, the word 'position' will implicitly
stand to 'position and orientation'.
Tasks are described in terms of positions to be reached in space
to grasp, displace or exert forces on objects located in the robot
work space.
Tasks are also described by the sequence and the type of motions necessary
to carry out the work.
Position descriptions require special data structures and
sequential operations of a robot require special primitives.
Both can however be implemented with the tools provided by
high level languages, namely, data structures, functions ,and
structured flow of control.
(The C language does not know anything about a file, for example.
Users wishing to manipulate files in their programs have to include
a system file called "stdio.h".
This file contains a description
of the necessary data structures.
Files can be manipulated by system
primitive functions like
.I
read, write, filbuf, or, flsbuf
.R
[1]).
.NH 3
Structured position description
.PP
RCCL handles what is referred to as structured position description [2].
The basic construct is the homogeneous transformation
that is a mathematical construct
describing the position of coordinate frames.
A homogeneous transformation can  either be interpreted
as the description of the position of a
coordinate frame with respect to another, or
as a transformation performed on the first coordinate frame.
Homogeneous transformations are a very general tool [3],
however in manipulation we will restrict them to
to the following :
.EQ
left [
matrix {
  ccol { n sub x above n sub y above n sub z above 0 }
  ccol { o sub x above o sub y above o sub z above 0 }
  ccol { a sub x above a sub y above a sub z above 0 }
  ccol { p sub x above p sub y above p sub z above 1 }
}
right ]
.EN
.PP
The left upper 3 by 3 matrix is a rotation matrix constructed with three
orthogonal vectors $n$, $o$, and $a$.
When the corresponding coordinate frame is attached to
the end-effector of a manipulator, the three vectors
$n$, $o$, and $a$ can be interpreted as the
.I normal
vector,
the
.I orientation
vector, and the
.I approach
vector.
The $p$ vector is a translation vector or
.I position
vector of the end of the manipulator.
.PP
Relative positions of objects can be described with
transformations products.
For example, let $OBJ$, a transformation, describe the position of
an object relative to a reference coordinate frame.
Let $HOLE$ represent the position of a hole with respect to
the frame $OBJ$.
The matrix product $OBJ~HOLE$
which is also a homogeneous transformation,
describes the position of the hole relative to the
reference coordinate frame.
One important property of orthogonal homogeneous transformation
is that the inverse transformation can be obtained
at reduced computational costs.
.PP
One dedicated transformation $T6$, represents the
position of the end-effector with respect to the reference
coordinate frame located at the base of the manipulator.
A given manipulator position can be specified in base
coordinates by writing:
.EQ
T6~=~POS
.EN
However, such a description is usually insufficient.
For instance, one might need to express that a tool
attached to the arm end-effector must reach the position $POS$.
This is achieved by writing:
.EQ
T6~TOOL~=~POS
.EN
A more complete description of a motion to a goal position is often
written as:
.EQ
REF~T6~TOOL~=~CONV~OBJ~PG
.EN
Where:

.IP $REF$ 8
is the position of the manipulator with respect to
the reference coordinate frame.

.IP $T6$ 8
describes the position of the manipulator end-effector with respect to
the reference coordinate frame attached to the shoulder or
to the base of the manipulator.

.IP $TOOL$ 8
expresses the position of a tool attached to the end-effector.

.IP $CONV$ 8
represents a conveyor belt, it can be a moving coordinate
frame with respect to the reference coordinate frame.

.IP $OBJ$ 8
is the position of the object to be grasped lying on the conveyor belt.

.IP $PG$  8
is the position of the end-effector,
relative to $OBJ$, where the object is to be grasped.

.PP
Position equations are solved for $T6$ to obtain the desired
position of the manipulator with respect to the reference coordinate
frame:
.EQ
T6~=~REF sup -1~CONV~OBJ~PG~TOOL sup -1
.EN
One RCCL system call directly implements position equations in
terms of dynamic data structures.
The positions can be modified at the level of the move
statement in terms of small translations and rotations described
in the
.I tool
frame.
This provides a convenient short hand for specifying approach and deproach
positions, or for specifying purposely over shooting motions if the arm
is to perform a guarded motion [21].
.NH 3
Motion description
.PP
A task is made up of a number
.I
path segments
.R
between successive positions.
There are many ways for generating trajectories for a manipulator[4][5].
RCCL provides two types of motions.
The first one, called
.I
joint mode,
.R
consists of computing
the set of joint values for each end of path segment and generating
all intermediate values by linear interpolation.
The second type, that we will call
.I
Cartesian mode,
.R
requires the system to solve a modified position equation
each sample intervals
and to compute the corresponding joint coordinates.
The position equation is internally modified in such a way
that one frame, called
.I
tool frame,
.R
moves along straight lines and rotates around
fixed axis.
These motion types are discussed elsewhere [3][6].
Here, we will assume that we are dealing with a manipulator for which
exists an analytical solution relating a Cartesian position to
a set of joints coordinates [7][8][9][10].
In the current implementation, manipulator motions are obtained
by specifying a sequence of desired joint values to the servo processes
controlling the manipulator joints.
However, most of what follows does not assume a particular control
method.
.PP
Path segment transitions involve three positions.
The manipulator is on its way from position $P1$, is about to
perform a transition next to $P2$ in order to head toward $P3$.
Transition are rendered necessary to avoid velocity discontinuities, and
are computed using a quartic polynomial.
At the time of a transition, the subsequent
.I
path segment
.R
is fully described by the goal position $P3$, $P1$ and $P2$ being known
from the current motion, by the time of the transition,
and by the time of
the segment itself.
RCCL allows to specify velocities, as well as segment times.
If the velocity is specified, the Cartesian distance of each tool frame
is determined to
automatically compute the segment time.
.PP
When the manipulator is to move while exerting forces or torques
on objects, the manipulator must be controlled in a such a way that
forces and torques are controlled directly in place of positions.
The manipulator is then said to be controlled in a
.I comply
mode.
Several methods [11][12][13][14] are proposed for such a control.
RCCL provides for compliance specifications in the
.I tool
coordinate frame which is specified in the position equation.
Compliance is specified in terms of forces along, and torques
around the principal axes of the
.I tool
frame.
The manipulator looses one if the positional degree of freedom for
each direction along, or around which the manipulator is complying in force.
The trajectory is then constrained by the geometrical features of the
objects in contact.
A more complete discussion of this subject can be found in [15].
.NH 2
Sensor integration; Updatable world representation;
.PP
One of the main goals of RCCL is to facilitate the integration of sensors [16].
Sensors are used to influence the behavior of the manipulator according
to information acquired from itself or from its environment.
Sensor information can be classified in many different ways :
according to the data type necessary to
represent it, booleans, scalars, vectors, arrays, tensors, etc...;
by meanings, touch, limit, distance, position, temperature,
vibrations, forces, etc...;
by the order of magnitude of the acquisition time, minutes, seconds,
milliseconds, microseconds; by accuracy ;and so on.
Considering this variety, the RCCL approach
is to deliberately ignore, when possible,
the type of information we may have to deal with, but on the contrary,
to provides means for an efficient utilization of this information.
.NH 3
Foreground - background programming
.PP
As robot programs will have to interact with the environment
while the manipulator is moving, programs are not implicitly synchronized
with the robot motions.
Each time a motion is required, a
.I motion
.I request
is entered into a 'First-in first-out' queue.
The request consists of a record containing all the informations
necessary to perform the corresponding path segment.
This feature allows us to specify ahead at time a sequence of
motions and to perform input output operations and calculations
as the robot is executing the requests.
When the motion queue becomes empty, the manipulator is brought to
rest.
This is obtained by repeatedly evaluating the last position.
We will see that it does not necessarely mean that the manipulator
is brought to a stop in absolute coordinates.
Slow sensors as computer vision systems requiring lengthy computations
can then be efficiently used as there is no need to stop the manipulator
while the data is acquired and processed.
A 'wait' primitive is provided when it is necessary to synchronize
the execution of the program with the manipulator's motions.
A similar technique to allow for the simultaneous control of
several manipulators or positioning devices may be implemented in the future.
.NH 3
Influencing positions
.PP
End of segment positions can be modified according to information
acquired at run time.
This is achieved by changing the value of transformations within
position equations.
Transformations likely to be modified at run time must be declared as such
(
.I hold
transforms).
The system makes a copy the transformation at the time
the corresponding
.I move
.I request
is issued, and enters it in the motion queue.
It is therefore possible to use the same transformation to
describe a coordinate frame whose value is different from
one path segment to another.
Using a copy of the transformation, makes
possible to change its value at an arbitrary instant
even if the corresponding position equation is currently being evaluated.
For efficiency, this feature is used only when specified.
The use of
.I hold
transformations causes more processing to be performed at run
time because they prevent the optimization of transform equations by
pre-multiplication of constants transformations.
.PP
User interaction and slow sensors like computer vision
require the use of
.I hold
transformations.
Position data can be acquired ahead at time in a completely asynchronous
manner.
.NH 3
Influencing trajectories
.PP
Fast sensors can provide for direct synchronous sensory feedback.
This corresponds to the class of
.I functionally
defined transformations.
In this case, a transformation is attached to a function that
will be evaluated at sample time intervals.
The purpose of the function is to calculate the value of the transformation
as a function of sensor readings.
The position equation in section 2.1.1. makes use of such a functionally
defined transform to describe a position with respect to a conveyor belt.
If the motion is performed in
.I Cartesian
mode, the tracking is perfectly
accurate, since the position equation is evaluated at sample time intervals.
When the motion is performed in
.I joint
mode, the system estimates the expected position at the end of the
segment by linear extrapolation.
If the functionally defined transform is computed as a function of time,
we can obtain mathematically described motions (circles, ellipses etc...).
.PP
The transitions to, or from path segments involving moving coordinate frames
must deal with unpredictable velocity changes.
Smooth transitions are obtained by adding a third order polynomial trajectory
modification during the transition time.
We have seen that manipulator stops are obtain by repeating a move to
the same position.
When the position involves moving coordinate frames, the stop will be
relative to those moving coordinate frames.
If a stop in absolute coordinates is required, a move to a fixed position must
be performed before specifying the stop.
The system internally maintains a position equation which always reflects
the current position of the manipulator.
It is therefore possible to have the manipulator stop at an arbitrary instant
at the position it currently occupies.
Functionally described transformations can be used anywhere in a position
equation.
Trajectories can be affected with respect to any coordinate frame which
provides unlimited applications.
.NH 3
Influencing path segment times
.PP
The second way to influence the manipulator behavior is to modify
the length of the path segments, to start and to stop the manipulator
according to external events.
The RCCL system allows to interrupt the execution
and cause a transition to the next
path segment at any moment
by merely setting a global flag.
A motion termination code enables to determine the cause
of the path segment termination.
For example, the system internally checks for joint limits and
brings the manipulator to an absolute stop when one of them is reached.
The termination code allows us to check the proper termination
of the motions that may cause a joint limit and to take an appropriate
action.
For any motion terminated on condition, a meaningfull termination code is
returned.
An arbitrary monitoring function
can be specified as part of a motion
request, the termination code is then chosen by the user.
Start, stop, motion interruption and resumption are achieved using the
same mechanism.
.NH 3
Internal sensing
.PP
Internal information is acquired from the manipulator
itself.
Two particularly useful kinds of informations
are internally maintained in RCCL: position and force.
.NH 4
Position
.PP
For any motion terminated on a condition, the world model
may have to be updated to account for the actual position where
the manipulator stopped.
The system is then
asked to
.I update
a transformation in a position equation.
The equation is solved for requested transformation using the
actual value of $T6$ when the path segment ends.
This new position information might be very useful
in any subsequent motion related to this location.
For example, consider the case of
a manipulator picking up an object which it had previously
placed on a surface whose height is only approximatively known.
The manipulator
is able to retrieve the object immediately
if the final position of the object was updated.
.NH 4
Force
.PP
Joint torques are also obtained
from the manipulator state.
The complete determination of the forces and torques
exerted on an object based on the joint torques leads to lengthy
computations [17], RCCL, however provides a mechanism that
compares the actual forces and torques against expected values.
This information may be used to cause a path segment termination when
some specified limit is reached.
The subsequent path segment will usually contain compliance specifications.
.NH 1
The RCCL implementation
.PP
When a manipulator in under RCCL control, four processes
are concurrently running.
At the lower level a
.I
servo process
.R
controls the position or the torque
of each manipulator joint
as input parameters.
The
.I
setpoint process,
.R
running at interrupt level, computes the Cartesian
trajectories and determines the corresponding joint parameters.
A real time
communication channel swaps information between the
.I
servo process
.R
and the
.I
setpoint process.
The
.I
user process
.R
running under time sharing contains the RCCL system calls.
The
.I
setpoint process
.R
communicates with the
.I user
process via a motion request queue containing all the necessary information.
.NH 2
Servo process
.PP
The present implementation makes use of Unimation PUMA robot controllers.
These controllers include six micro processors, one per joint.
Each joint servo micro processor receives position commands specified
in incremental encoder values.
The joint processors can also read and transmit the joint position information.
The Stanford arm controller has been modified [18][19] so that
joint 1, 2, and 3 can be force servoed.
The Puma arm controller can drive the joints motors with current
specifications.
A method for relating joint torques to motor currents has been
developed and implemented by Zhang Hong [20].
The method take into account the friction effect of the joint drives.
.NH 2
Joint processor control and host machine interface
.PP
A LSI11 microprocessor supervises the joint processors and establishes
the communication with the host machine.
At each sample time interval, the microprocessor gather data from the
manipulator, transmits it to the host machine, accepts commands,
and sendss the corresponding values to the joint processors.
It also executes a calibration procedure at startup time.
.NH 2
Real time channel communication
.PP
The real channel, besides transmitting information between the
controllers and the host machine performs several functions such as
the conversions of encoder values to trigonometric angles,
the torque to current mapping,
joint limits ,maximum velocities
and maximum currents monitoring.
It also checks for data integrity.
A manual stepping mode and an automatic rest position return are built in.
.NH 2
Setpoint process
.PP
The
.I setpoint
process is interrupt driven.
Each time a path segment terminates, the process attempts to obtain
a new motion request from the queue.
If there is one, the transition parameters are computed according
to the type of path segment and the transition parameters are computed.
Many types of transitions occur : joint mode, Cartesian mode, moving coordinate
frames, constrained motions.
The final result is always a set of joint positions and torques.
.NH 2
User process
.PP
The
.I user
process consist of the user program calling the RCCL primitives.
Memory space is dynamically allocated for each new position
equation.
This space can be released when needed no longer needed.
Several functions are provided to handle transformations:
rotations, Euler angles, roll pitch and angles, transform multiply,
transform inversion, etc...
.NH
Tools
.NH 2
Trajectory planning
.PP
There exists a version of the RCCL library, which instead of computing
the trajectories in real time, computes them off-line.
This is simply achieved by calling the setpoint function in a loop instead
of activating it on interrupt.
The same manipulator programs, provided that they do not depend on
external events and information, can be run in this fashion.
Some debugging tools are then provided.
The system can be asked to keep a trace of the motion requests,
to store the sequence of setpoints on file in order to replay them afterwards,
or to plot them.
.NH 2
Teaching
.PP
A manual control program is included within RCCL.
It consists of a very simple command line language
enabling an operator to interactively move the manipulator in
Cartesian space.
Motions can be specified in world or tool coordinates.
Positions can be recorded via the
.I update
primitive.
The manual control program is entirely implemented in terms
of RCCL primitives.
.NH 2
Transformations data base
.PP
A simple data base system has also been developed.
Transformations values can be recorded and read on line
in manipulator programs.
The values can be displayed and modified off-line for maintenance.
.NH
Conclusion
.PP
The main goal of this project was to show that manipulator
control could be brought in a more general context than within
the framework of a stand alone controller bound to it's own language.
The current RCCL implementation does not yet offer the convenience
of dedicated robot controllers because it requires a large machine.
However,
as microprocessor based computers become more powerful and
can run operating systems like UNIX, the RCCL approach shows
many advantages over conventional robot controller design.
The conclusion is that robot control can be though as an addition
to an already existing, tested, and standardized system, rather
than the design from scratch of a system arround robot control.
.NH 1
References
.IP [1]
Kernighan ,B. K., "The C Programming Language",
Prentice-Hall, 1978.
.IP [2]
Paul ,R. P., "Manipulator Language", Workshop On The Research
Needed to Advance The State Of Knowledge In Robotics,
April 15-17, 1980, organized by J. Birk and R. Kelley, supported by N.S.F.
.IP [3]
Paul, R. P., "Robot Manipulators: Mathematics, Programming,
and Control", MIT Press 1981.
.IP [4]
Derby, S., "Simulating Motion Elements of General-Purpose Robot Arms",
International Journal of Robotic Research, Vol. 2, No. 1, Spring 1983.
.IP [5]
Castain, R. H., Paul, R. P.,
"Polynomial Robotic Trajectories: A New Approach",
TR-EE 82-37, Dec 1982.
.IP [6]
Hayward, V., Paul, R. P.,
"Robot Manipulator Control Using the C Language Under UNIX",
IEEE Workshop on Languages for Automation, Chicago, Nov. 1983.
.IP [7]
Shimano, B. E., "The Kinematic Design and Force Control of Computer
Controlled Manipulators",
Stanford Artificial Laboratory, Stanford University, AIM 313, 1978.
.IP [8]
Paul, R. P., Stevenson, C. N., "Kinematics of Robot Wrists",
International Journal of Robotic Research, Vol. 2, No. 1, Spring 1983.
.IP [9]
Paul, R. P., Shimano, B. E., Mayer , E. G.,
"Kinematic Control Equations for Simple Manipulator",
IEEE Transactions on Systems, Man, and Cybernetics,
Vol SMC-11, No 6, June 1981.
.IP [10]
Fisher, W. D., Private communication.
.IP [11]
Inoue, H., "Force Feedback In Precise Assembly Tasks",
MIT Artificial Intelligence Laboratory, Memo 308, Aug 1974.
.IP [12]
Raiberg, M. H., Craig J. J., "Hybrid Position/Force Control of Manipulators",
Journal of Energy Resources Technology, Vol. 103, June 1981.
.IP [13]
Salisbury, J. K., "Active Stiffness Control of a Manipulator In Cartesian
Coordinates", 19th IEEE Conference on Decision and Control, Dec. 1980,
Albuquerque, New Mexico.
.IP [14]
Geschke, C. C., "A System for Programming and Controlling Sensor-Based
Robot Manipulators", IEEE Transactions on Pattern Matching and Machine
Intelligence, Vol. PAM1-5, No. 1, Jan 1983.
.IP [15]
Mason M. T., "Compliance and Force Control for Computer Controlled
Manipulators", MIT TR-515, April 1979.
.IP [16]
Rosen, C. A., Nitzan, D., " Use of Sensors In Programmable Automation",
Computer Magazine, December 1977.
.IP [17]
Paul, R. P., "Computational Requirements of Third Generation Manipulators"
.IP [18]
Fisher, W. D., "The Modification of a Robotic Manipulator and Digital
Controller to Incorprate Both Force and Possition Control", MSEE Thesis,
Purdue University, May 1981.
.IP [19]
Luh, J. Y. S., Fisher W. G., Paul, R. P.,
"Joint Torque Control by Direct Feedback for Industrial Robots",
IEEE Transactions on Automatic Control, Vol. AC-28, No. 2, February 1983.
.IP [20]
Zhang, H., Paul, R. P.,
"Determination of Simplified Dynamics of Puma Manipulator", Purdue University.
.IP [21]
Will, P. M., Grossman D. D.,
"An Experimental System for Computer Controlled Mechanical Assembly",
IEEE Trans. Computers C-24 9, 1975, 879-888.