IEEE TRANSACTIONS ON EDUCATION. VOL. 3 2 , NO.
4, NOVEMBER 1989
A Graphics Simulator for a Robotic Arm
Abstruct-A graphics robot simulator designed for an IBM
PC/XT/AT or PS/2 personal computer is presented. The simulator
is a terminate and stay resident (TSR) program that runs in the back-
ground and intercepts commands that would normally go to the robot
controller through the COMl serial communication device. With the
use of the simulator, students can develop and test robot control pro-
grams off line without a physical robot present using the language of
their choice. The status of the simulated robot is available through a
3-D graphics display and a one-line text window, each of which can be
activated from the keyboard or from within a user program. Data files
are used to specify the robot to be simulated and the environment or
workcell within which it is to operate. Currently supported robots in-
clude the Rhino XR-3 educational robot and the Adept One and Intel-
ledex 660 industrial robots. The workcell, which can be customized by
the user, features an overhead camera and objects that can be sensed
by the camera and manipulated by the robot.
I. INTRODUCTION
S IMULATION is a well-established engineering tool
for design, analysis, and control of physical systems.
Computer simulation can be used to provide safe and in-
expensive training for the operation of complex and dan-
gerous equipment [5]. Robotics instruction is particularly
well suited for the application of graphic computer sim-
ulation techniques [2], [3], [6], [9], [lo], [13]-[15]. In
this paper we describe a graphics robot simulator that was
designed to run on an IBM PC/XT/AT or PS/2 personal
computer [14]. The simulator features a popular educa-
tional table top robotic arm, the five-axis Rhino XR-3 ro-
bot. However, other robots can also be simulated includ-
ing two industrial robots, the four-axis Adept One and the
six-axis Intelledex 660. The information describing the
robot to be simulated is contained in a data file that is
specified when the simulator is installed. A second data
file describing the environment or workcell within which
the robot is to operate is also specified at installation time.
The workcell data file can be customized by the user and
includes an overhead camera and several workcell objects
which can be sensed by the camera and manipulated by
the robot.
The simulator is a terminate and stay resident (TSR)
program that runs in background and can be activated by
the user either through the keyboard or from within a user
program [ 11. The basic assumption is that the robot to be
simulated is controlled through the COMl serial com-
Manuscript received March 25, 1988; revised July 6 , 1989. This work
was supported by a grant from the Westinghouse Educational Foundation.
R. B. White was with the Department of Electrical and Computer En-
gineering, Clarkson University, Potsdam, NY 13676. He is currently with
the ROTC. Fort Kiley, KS.
R. K. Read, M. W. Koch, and R . J . Schilling are with the Department
of Electrical and Computer Engineering, Clarkson University. Potsdam,
NY 13676.
IEEE Log Number 8930746.
0018-9359/89/1100-0417$01.OO
417
munication device. This is the case, for example, with the
Rhino XR-3 robot [8]. The simulator monitors the COMl
port from the background; and whenever a character is
sent it intercepts the character and responds to it as the
robot controller would. The status of the simulated robot
is available to the user through a 3-D graphics display of
the arm and also through a one-line text window. The ro-
bot controller that is simulated is a generalization of the
Rhino XR-3 controller [ 111. Therefore any program writ-
ten for the Rhino XR-3 robot should run on the simulator
without modification.
The primary motivation for developing the simulator
was for teaching robotics at colleges and universities. The
simulator was developed and tested at Clarkson Univer-
sity over the past three years and has been used by stu-
dents of electrical engineering, mechanical engineering,
and computer science. With the use of the simulator, stu-
dents develop and test robot control programs off line
without a physical robot present using the language of
their choice. Their final programs can then be tested on
the physical robots. This tends to reduce hardware main-
tenance costs substantially. Experience has shown that the
simulator is both more convenient and more reliable than
a mechanical manipulator. For schools which plan to in-
troduce an instructional program in robotics, but do not
have the resources needed to fully furnish a robotics lab-
oratory, a graphic robot simulator is a cost effective al-
ternative. It does require that students have access to a
personal computer with some graphics capability, but this
general purpose tool is widely available at most institu-
tions.
11. BACKGROUND
In order to develop the simulator, background theory
from three disciplines was needed: computer graphics, ro-
botics, and assembly language programming using inter-
rupts. Both graphics and robotics employ four-dimen-
sional homogeneous coordinates which use three position
coordinates plus a scale factor [12]. Through the use of
homogeneous coordinates, both rotations and translations
can be represented by 4 X 4 coordinate transformation
matrices. In the field of robotics, a homogeneous coor-
dinate transformation matrix is expressed as follows:
0 1989 IEEE
418
Here the 3 x 3 submatrix R in the upper left corner of
T i s a rotation matrix which represents the orientation of
the coordinate frame, while the 3 x 1 submatrix p in the
upper right comer of T i s a translation vector which rep-
resents the position of the coordinate frame. Homoge-
neous coordinate transformation matrices are also used in
graphics [4], but in this case the convention is to use the
transposed version of the matrix in (1).
A . Graphics
One of the main features of the simulator is its 3-D
graphics display which uses a wire-frame representation
of a robot. The type of projection displayed by the sim-
ulator is an orthographic projection. An orthographic pro-
jection is a parallel projection in which the projectors
which create the image on the view plane are parallel to
each other as well as being normal to the view plane [4].
Fig. 1 shows an orthographic projection of a 3-D object,
the Rhino XR-3 robot, onto a 2-D plane. The view plane
in this example is orthogonal to a line between the origin
and a point with coordinates (1, 1, 1).
The transformation matrix Tcomposite, which the simula-
tor uses to obtain the graphics display, maps the three
dimensional points of the wire-frame robot into two-di-
mensional points representing the projection of the robot
onto a 2-D plane. This matrix is derived from a view vec-
tor which is specified by the user. This allows for a wide
variety of angles at which the simulated robot can be
viewed. The derivation uses the properties of orthogonal
vectors, and the specific calculations can be found in [ 141.
The wire-frame representation of the robot consists of
a number of 3-D points representing the vertices of the
physical links of the robot. These 3-D points are trans-
formed by the matrix Tcomposite to obtain the 2-D view co-
ordinates. The final transformation in displaying the robot
is applied by the graphics software package [ 7 ] . A trans-
form is applied in order to convert the view coordinates
into the pixel coordinates to be plotted on the screen. The
size of the world coordinate frame depends on the view
selected and the maximum extents of the x, y, and z axes
as specified in a work cell data file.
B. Robotics
The simulator itself is not robotic specific. However, it
does assume a particular form for the robot controller, one
that is upward compatible with the controller of the Rhino
XR-3 educational robot. Thus, the simulated controller
will respond to all of the commands that the Rhino XR-3
controller would, plus some additional higher level com-
mands. The characteristics of any robot with up to six
axes, plus a tool, can be simulated. This flexibility is
achieved through the use of general kinematic equations.
The Denavit-Hartenburg representation can be used to
construct a link coordinate diagram for any robot [12].
Once a link coordinate diagram is obtained, the kinematic
parameters of the robot can be determined. These include
vectors specifying: the joint angles 8, the joint distances
d, the link lengths a , and the link twist angles a . The joint
IEEE TRANSACTIONS ON EDUCATION, VOL. 32, NO. 4 NOVEMBER 1989
b
Fig. 1 . The Rhino XR-3 robot from perspective ( 1 , 1, 1 )
and link parameters can be used to determine the relation-
ship between the coordinate frames attached to adjacent
links of the manipulator. This is accomplished through
the use of the following link coordinate transformation
matrix which transforms the coordinates of frame k to the
coordinates of frame k - 1:
Tf- 1
[
cos ek -cos ffk sin ek sin ffk sin Ok ak cos 8
=
sin Ok cos ffk cos 8 k -sin ffk cos 8 k ak sin 0
0
0
sin f f k
0
cos CYk
0 1
dk
The simulator needs this flexibility in order to simulate
1.
(2)
the motion of any robot in the graphics display. The
graphics data are maintained with respect to different co-
ordinate frames. In order to display the data it must first
be transformed into base coordinates so the orthographic
and pixel transformations can be applied. The geometric
descriptions of the links, as well as the kinematic param-
eters for the robot, are specified in a robot data file.
The link coordinate transformation matrices can be
combined to form the transformation matrices necessary
to convert between any two coordinate frames. The com-
positions used by the simulator transform the coordinates
of each frame into frame 0 which corresponds to the robot
base. For an n-axis robot, these matrices have the follow-
ing form where k specifies the coordinate frame attached
to the kth link:
Ti = TAT: Tf-,, 1 Ik 5 n. (3)
The link coordinate transformation matrices are generic
because they depend explicitly on the kinematic parame-
ters as shown in (2). One drawback of this generality is
the computation involved. These matrices must be con-
stantly updated as the simulated robot moves. Whenever
WHITE er a l . : SIMULATOR FOR ROBOTIC ARM 419

joint k moves, the matrix T i - I must be updated because key. The original keyboard interrupt sets flags for the Shift
the joint variable ( Ok or d k )has changed. To further com- and Alt keys. So if the original interrupt routine is exe-
plicate matters, whenever T i - I changes, the matrices T i cuted first, it is simply a matter of checking these flags to
for k Ii In must also be updated because of their de- see if these keys were, hit. The original interrupt routine
pendence on the matrix T i - l . can be executed before the patch code by simulating an
The simulator models joint motion as if the joint actua- interrupt. An interrupt is actually just a specialized func-
tors were variable-speed motors with incremental position tion call, the only differences being that an interrupt saves
encoders. The move commands that the simulator uses are the status flags on the stack and disables further inter-
upward compatible with those of the Rhino XR-3 con- rupts. By pushing the flags onto the stack a patch can make
troller. The microswitches associated with each joint of a the stack look like it would upon entry into an interrupt.
Rhino XR-3 robot are simulated as well. However, there A call then passes control to the original interrupt routine.
is a slight difference with the simulator. Once closed, the When the iret (interrupt return) statement is encountered
switches on the simulator remain closed as long as the at the end of that code, it will pop the flags and return
robot continues to move in the direction which first closed control to the line following the call.
the switch. On the physical robots, the switches are closed
for a limited number of encoder counts due to the nature 111. DATAFILES
of the mechanical design. The simulator itself is not robot specific. Instead, data
Inter-axis coupling is another feature supported by the describing the robot to be simulated are contained in a
simulator. On the Rhino XR-3 robot, the shoulder joint is data file that is specified when the simulator is installed.
coupled to the elbow joint, and the elbow joint is coupled The environment or workcell within which this robot is to
to the wrist pitch joint. The inter-axis coupling informa- operate can also be specified using a second data file called
tion is also specified in the data file. the workcell data file. This section explains the structure
and contents of these data files which are used to custom-
C. Interrupts ize the simulator.
The simulator is designed to run under the MS-DOS
operating system. By patching into the software interrupts A . Robot Data File
the simulator is able to monitor 1 / 0 devices from the The data files used by the simulator contain comment
background and activate itself when certain events occur. lines (starting with a ‘*’) which document the contents of
A simple example is the activation of the graphics display each file. The simulator presently supports three different
when the key stroke ( Alt F1 ) occurs. robotic arms as summarized in Table I.
Every interrupt has associated with it a vector. The in- Each robot has its own data file describing the kine-
terrupt vectors are simply addresses to which control is matics and physical appearance of the manipulator. Al-
passed when a specific interrupt occurs. DOS maintains a though different robots can be simulated, they all use one
table of these interrupt vectors. Each is four bytes in controller, a generalization of the Rhino XR-3 controller.
length and specifies the segment and offset of the start of Thus programs developed specifically for the Rhino XR-
the interrupt routine. The segment address for the vector 3 robot should run on the simulator without modification.
table is 40H (hexadecimal), while the offset within the Joint Data: The first item in the robot data file specifies
segment is 4i for the ith interrupt. In order to patch into the number of axes or joints. The tool or gripper is not
the interrupts in a manner that does not interfere with nor- regarded as a separate axis even though it has an actuator
mal operation one must save the original interrupt vector, associated with it. Following the axis specification are
set the interrupt vector to point to the new patch code, blocks of data which contain information specific to the
and have the patch code, in some way, execute the orig- each joint of the arm as summarized in Table 11.
inal interrupt routine. The joint and link parameters (6, d, a , a ) are deter-
The simulator accomplishes these tasks and therefore mined from a link coordinate diagram. The position spec-
results in no conflict with the interrupt drivers already in ified by the default values of the joint variables defines
place. The first two steps can be accomplished through the soft home position of the simulated robot. This is dis-
direct memory access or via the use of DOS functions tinct from the hard home position, the position at which
35H and 25H, respectively. The third step can be accom- all the joint microswitches are closed.
plished in a number of ways. One approach is to jump to The joint variable specification jvar allows the simula-
the original interrupt routine after executing the patch tor to model both revolute and prismatic joints. The vari-
code. This is the fastest and most straight forward ap- able jvar specifies a number, either 1 or 2, which identi-
proach. However, it can only be done at the end of the fies which parameter in the set { 6, d } is the joint vari-
patch since the original interrupt routine ends with an iret able. Thus, a ‘1’ implies that the joint is revolute, while
(interrupt return) statement which ends interrupt process- a ‘2’ implies that the joint is prismatic. The two link pa-
ing. rameters { a , (Y } are constants whose values are deter-
The original interrupt driver may provide some useful mined when the manipulator is designed.
processing that may be difficult or uneconomical for the The joint actuators of the Rhino XR-3 robot are dc servo
new code to duplicate. One such example is processing a motors with incremental encoders. Since the position en-
420 IEEE TRANSACTIONS ON EDUCATION, VOL. 32, NO. 4, NOVEMBER 1989

TABLE 1 Tool Data: Following the data for each joint of the ro-
ROBOTS
SUPPORTED
BY T H E SIMULATOR
bot is the tool data. There are two types of tools sup-
Robot TY Pe Axes
ported, a parallel jaw type gripper in which the fingers
close in a prismatic fashion, and an angular jaw type grip-
Adept One SCARA 4 per in which the fingers close in a revolute fashion. In the
Rhino XR-3 articulated 5 first case, the tool variable is the distance between the
Intelledex 660 articulated 6
fingertips, while in the second it is the angle between the
fingers. Most of the data required for the robot joints is
TABLE I1
also specified for the tool including: tool precision, tool
DATAf:OR EACHJOINT speed, tool limits, microswitch position and mask, and
tool label. Unlike the links of the robot, the tool is not
Item Units one solid piece. Therefore, the parts of the tool that move
joint angle: 0 degree
when the tool is activated (opens/closes) are also specified
joint distance: d inch (mm) in the data file.
link length: a inch (mm) Link Data: Recall that coordinate frame k is attached
link twist angle: 01 degree to link k and moves with it. We define the points describ-
joint variable: jvar none
joint precision units/count ing the physical shape of link k using frame k coordinates.
joint limits counts Thus the base is defined with respect to frame 0, the
joint speed countsis shoulder is defined with respect to frame 1, and so on until
microswitch position counts
microswitch mask none we get to the tool which is defined with respect to frame
joint direction none n. A change in joint variable k causes a change in the
joint label none position and orientation of frames k through n . Since link
k is defined in terms of frame k , the position and orien-
tation of link k in the graphics display will change as joint
coders are incremental, the absolute joint position cannot variable k changes.
be determined directly, only the change in position can The links of the robot are specified as a series of 3-D
be measured. The joint precision is the amount of change points. Associated with each point is a command: move
in the joint variable corresponding to one change of state or draw. A point command of ‘1’ implies that the graphics
(count) of the incremental encoder. The precision is spec- cursor should move to this point, while a command of ‘0’
ified in jvar units per count. implies that a vector should be drawn to the point. Up to
The joint limits specify the valid range of travel for each 48 points can be used to specify the physical shape of each
joint. For a revolute joint the limits are specified as a min- link. A color index is also included for each link because
imum and maximum angle, while for a prismatic joint they adjacent links can be more easily distinguished when
are specified as a minimum and maximum extension. For drawn in different colors or different shades of a color.
a joint which has no limit, such as the wrist roil of the The 3-D graphics points for link k are mapped to base
Rhino XR-3, very large limits are specified. coordinates by the matrix Th specified in (3), and the 3-D
The joint speed, like the precision, is expressed in terms base coordinates are mapped to 2-D world coordinates by
of the simulated actuators. The speed is specified in units TcompoSlte. Finally, the world coordinates are translated to
of encoder counts per second. The values in the existing pixel coordinates by the graphics software package [7] and
data files are approximations of the observed speed of the the result is the wire-frame robot we see on the screen.
physical robot. General Data: There are some data that apply to the
In order to simulate the Rhino XR-3 controller as manipulator as a whole. For example, inter-axis coupling
closely as possible, microswitches have also been in- is a feature that was included in the simulator to allow for
cluded in the simulator. The microswitch positions are accurate simulation of the Rhino XR-3 robot. Since cou-
specified in encoder counts. Microswitch bit masks are pling between joints is robot specific, this is another char-
also included and are used to simulate the Rhino XR-3 acteristic which is defined in the robot data file. The mo-
commands which return the status of the microswitches. tion of any joint of the robot can be physically coupled
The joint direction indicator is used to define the direc- with any other joint. For the Rhino XR-3 robot the shoul-
tion of positive movement for the actuators. An indicator der is coupled to the elbow, and the elbow is coupled to
of ‘1’ implies that the positive direction of the actuator the wrist pitch. Both couplings are opposing, so a move-
corresponds to increasing values of the joint variable, ment of m counts in one joint results in a movement of
while a ‘ - 1’ indicates the opposite direction. -m counts in the other. In the data file this is specified
Joint labels are individual letters used to distinguish one by saying joint 2 is coupled to joint -3, and joint 3 is
joint from another. With the Rhino XR-3 robot, the tool is coupled to joint -4, the negative joint numbers indicating
labeled A , the wrist roll joint is labeled B , and so on an opposing motion due to the coupling.
through the base joint which is labeled F. These joint la- Another general feature included in the simulator is the
bels are used in commands which control the robot motion introduction of a protected region about the base of the
181. robot. If the tool enters this protected region, the simu-
WHITE er o l . : SIMULATOR FOR ROBOTIC ARM 42 1

lator will stall. The region is defined as a cylinder about of the block measured with respect to the x axis of the
the base axis of the robot. The height and radius of this base. The blocks are represented in the same manner as
cylinder are specified in the data file. Of course, the sim- the links of the robot, except that the vertices of each block
ulated robot does not have to worry about reaching inside are defined with respect to its centroid.
itself, but with a physical robot this can be hazardous to The simulated robot is able to manipulate the blocks. If
its health! a block is grasped by the tool, the vertices of the block
The last item in the robot data file is the specification are drawn with respect to the tool coordinate frame. When
of the net wrist roll. This information is used in conjunc- the block is released, the block centroid is updated to the
tion with manipulating blocks in the workcell. The net new tool tip position and the block orientation is updated
wrist roll is determined by summing joint variables of to reflect the current orientation (net wrist roll) of the tool.
joints specified in the data file where a negative joint in- To keep the simulator simple, dynamic effects including
dex indicates subtraction instead of addition. The net wrist gravity are not simulated. Therefore if a block is released
roll is a useful way to specify the global orientation of the in midair, it will remain there rather than fall to the work
tool when objects are being manipulated from directly surface.
above. Sensor Data: There is only one workcell sensor that is
simulated. It is a binary vision system with a single, sta-
B. Workcell Data File tionary camera mounted directly over the work surface.
Whereas the robot data file allows one to simulate dif- The information supplied in the data file includes the lo-
ferent manipulators. the workcell data file allows one to cation of the camera in base coordinates, the length and
simulate different rnvironmenrs for each manipulator. A width of the field of view, and the precision of the vision
customized workcell data file can be created by using an system in pixels the and y
interactive program called WORKCELL.COM. "The IV. INTERRUPTS
workcell data file specifies the size of the workspace, the
blocks or objects in the workspace, and the sensors used The simulator is a terminate and stay resident (TSR)
to locate these objects. program that runs in the background and is invoked au-
Workspace Data: The first item found in the workcell tomatically when certain events occur [l]. Each of these
events generates an interrupt on an IBM PC/XT/AT or
data file is the size of the workspace which is defined by
PS / 2 computer running MS-DOS. The simulator makes
three numbers: X , Y , Z. The workspace is defined as the
box with the following extents relative to the base coor- use of the four interrupts listed in Table 111.
The timer tick interrupt and INT 28H are used for tim-
dinate frame:
ing purposes. Through the use of these interrupts, the
0 I X S X , simulator is able to model the time-varying behavior of
-Y 5 y I Y , (4) the manipulator. The keyboard interrupt allows the user
to invoke certain functions of the simulator directly from
0 I Z I Z .
the keyboard. For example, ( Alt F1 ) invokes the graph-
Thus, a region in front of, above, and to both sides of ics display.
the robot base is specified. A small region behind the base The fourth interrupt the simulator uses is the Serial 1 / 0
axis ( x < 0 ) sufficient to display the back of the robot is interrupt. Recall that the simulator is based on the Rhino
also included. The values of X , Y , and Z determine the XR-3 controller. With this controller, all communication
view volume. The view volume is the volume in three- with the robot is through an RS232-C serial port. Thus
space which gets projected onto the view plane. What is the robot behaves as if it were a COMl device. When the
actually determined is the size of the view plane. The simulator is enabled, it intercepts all commands sent to
points ( X , 0, 0), (0, Y , 0 ) , (0, - Y , 0 ) , and (0, 0, 2 ) the COMl device and responds to them as if it were the
are transformed to 2-D coordinates and the minimum and actual controller.
maximum values of these points determine the minimum The Serial 1 / 0 interrupt occurs every time a character
and maximum extents of the view plane. This calculation is input from or output to a serial port via a BIOS function
is done every time the view vector changes, since this call. Upon entry to the interrupt routine, register DX con-
changes the line-of-sight and hence the orientation of the tains the serial card number ( 0 or 1 ), register AH contains
axes on the screen. the operation code (op code), and register AL contains the
Block Data: Following the workspace specifications are ASCII code of the character. A flowchart describing the
the block specifications, one per line. Up to five blocks actions taken by the simulator when the Serial 1 / 0 inter-
or workcell objects can be defined. In order to simplify rupt occurs is shown in Fig. 2.
the simulator, each block is assumed to be a rectangular The first thing the simulator does is to check if the ac-
box. The information that the simulator needs for each cess is for COM 1. This is done by checking to see if DX
block is its length, width, height, initial position, and ini- is equal to zero. If it is not, then we do not want to process
tial orientation. Position and orientation are specified with it so we simply pass control to the original interrupt rou-
respect to the robot base frame with orientation being the tine by jumping to it. If the access is for COM 1, we con-
angle of rotation about a vertical axis through the centroid tinue by checking to see if the op code is a 1. This tells
422 IEEE TRANSACTIONS ON EDUCATION, VOL. 32, NO. 4, NOVEMBER 1989

TABLE 111 crease the speed of processing characters. If the registers

INTERRUPTS USEDBY THE
SIMULATOR
were saved immediately upon entry, they would have to
be restored before passing control to the original interrupt
Interrupt Name routine. This saving and restoring is a waste of time if the
simulator is not going to process the character in AL.
INT 08H Timer Tick Since the COM 1 device is monitored for commands, all
INT 09H Keyboard
INT 14H Serial I / O robot commands must be sent through the COMl port in
INT 28H unnamed a manner which will activate the simulator. Any serial
1 / 0 function which uses a BIOS function call will accom-
plish this. Simulating the Rhino XR-3 controller com-
mands in software is fairly easy to accomplish. Each of
Jump
INT 14H > to old
interrupt
the joints on the physical robot is modeled in software by
using program variables that describe the state of the joint.
A variable called called error replaces the 8-bit error
counter register in the controller. Another variable, to-
tal-counts, is used to determine whether or not a joint
has moved far enough to close the microswitch associated
with the joint.
Moving a joint is accomplished by periodically (via INT
08H and INT28H) updating the error variable for that
joint. As with the actual controller, the simulator will
move the joint in the direction which reduces the magni-
tude of error. If the error variable for a joint is not zero,
that implies that the joint should be moved. The number
r
of counts the joint is moved is determined by calculating
Process the time elapsed since the last time the joint was moved
the
Character
< and multiplying by the speed of the joint. The result is
then added to total-counts for that joint, and the joint
variable is updated to reflect the move by multiplying the
Return
number of counts by the joint precision.
>
. 'All OK' When a joint of a physical robot encounters a hard limit,
IRET a local stall condition occurs. The simulator has no phys-
ical hard limits, but in order to simulate a stall the simu-
lator uses the range information specified in the robot data
file. After updating the joint variable, a check is made to
us if a character is being output. If the op code is for see if the new position falls within the valid range of travel
anything but output, we simply ignore the function, say for the joint. If not, a local stall has occurred. In this case
everything is OK, and return from the interrupt. The "all the joint is backed up to the point at which the limit was
OK" is given by returning a status code in AX which violated, and the error for that joint is adjusted accord-
states that no errors have occurred and that the device is ingly. For example, if a joint has a precision of 0.25" per
ready for either input or output. If the op code specifies count and a minimum range value of - 90", and the new
output, then we need to check to see if the character is an joint variable value was - loo", a local stall would occur
"@" (ASCII code 40H) which is the simulator enable/ because the minimum range value was violated. The joint
disable command. If the value in AL is not 40H, then we variable would be updated to reflect a position of -90"
check to see if the simulator is enabled. If it is enabled, and a total of - 10" /0.25" per count = -40 counts would
or if the value in AL is 40H, processing continues. If the be added to the error for that joint. A flag is then set to
simulator is not enabled, again control is passed to the indicate that the joint has stalled. This flag is used by the
original interrupt routine. The processing of the character simulator to warn the user of the stall condition through
includes saving the registers and setting the segment reg- the graphics display and a status line. After it has been
isters and stack pointer to point to the simulator stack. determined that a joint has stalled, coupling is accounted
The character in AL is moved to a Turbo Pascal variable for by moving the joints coupled to it. The flags for the
and then a high level routine is called to process the char- status of the microswitches are also updated.
acter.
Interrupt routines save the current state of the processor V . COMMANDS
before executing by saving the registers on the stack, and
then restore the processor state after they are done. In this The simulator has two modes of operation, command
interrupt routine, the saving of registers is postponed until mode and program mode. In command mode the opera-
just before we call the processing routine in order to in- tion of the simulator is controlled directly from the key-
WHITE er al.: SIMULATOR FOR ROBOTIC ARM 423

board, while in program mode it is controlled from within TABLE IV

a user program. COMMAND
MODEKEYS

Function Default
A. Command Mode
In the command mode the simulator uses the function Alt KP- Enter/Exit Command Mode Menu inactive
keys ( Alt F1 ) - ( Alt F6 ) and the key ( Alt KP- ) where Alt F1 Display Robot display off
Alt F2 Change View Vector (1, 1, 1 )
KP- stands for the key pad “ - ” key. The functions of Alt F3 Home Robot home position
each of the command mode keys and their default condi- Alt F4 Select Status Line Option blank
tions are summarized in Table IV. Alt F5 EnableiDisable Simulator enabled
Alt F6 EnabldDisable Function Keys enabled
EntedExit Command Mode Menu: (Alt KP-) : The En-
cer/Exit Command Mode Menu option, ( Alt KP- ), al-
lows the user to review the options available in Command TABLE V
Mode. It displays a menu similar to Table IV and allows STATUS
LINEOPTIONS
the user to execute any of the functions or return to the
mode active when the menu was selected. The Alt prefix Option Display
allows the user to invoke the Command Mode options di-
Blank line
rectly. The Alt key should nor be used from within the Tool-Configuration Vector: HI

Command Mode menu. Joint Variable Vector: q

Display Robot: (Alt F l ): The Display Robot option, Microswitch Vector: s
Error Count Vector: e
( Alt F 1 ) , generates a graphic display of the robot using Block 1 Configuration: 11,
the currently selected view vector. It typically takes a
short time for the display to appear because the simulator
has to update a series of display vectors that are used to 5 + n Block n Configuration: IJ,,

draw a wire frame image of the robot. Pressing any key

will then turn the display off and return to the mode of
operation active when ( Alt F1 ) was pressed.
Change View Vector: (Alt F2): The Change View
Vector option, ( Alt F2 ), allows the user to alter the
3-D view of the simulated robot by entering a new view
vector. The user is requested to supply three integer co-
ordinates ( x , y , z ) which specify the end point of the line-
of-sight for viewing the robot. The coordinate values en-
-
tered must be in the range [ -9 . 91, and they should be
separated by commas or spaces. Pressing (Enter) after
the third value completes the input. Only the relative
magnitudes of the integers are important as the viewing
distance, or scale, is automatically adjusted to display the
entire workspace. The default view vector is ( 1 , 1, 1).
Home Robot: (Alt F3 ): The Home Robot option, ( Alt
F3 ), returns the simulated robot to the default soft home
position specified in the robot data file. This option can
be used for recovery when the robot is inadvertently driven
into a stall condition by a user program.
Set Status Line: (Alt F4): The Set Status Line option,
( Alt F4 ), controls the information displayed on the top
line of the screen. When ( Alt F4 ) is pressed the status
line display will rotate through the options listed in Table
V. Note that option 1 is a blank line which effectively
turns the status line off.
The status line is continually updated by the simulator.
Consequently, if the user outputs anything to the top line
of the screen, it will be overwritten by the simulator.
However, if the blank line option is selected, the simu-
lator will not overwrite any user data on the top line. In
this way, the user program can have access to the top line.
Enable/Disable Simulator: (Alt F5 ) : The Enable/Dis-
able Simulator option, ( Alt F5 ), toggles the simulator
between active and inactive states. When the simulator is
enabled, all commands sent to the COMl device are in-
tercepted and processed by the simulator, which responds
as if it were the robot controller. When the simulator is
disabled, commands are passed through to the robot or
whatever hardware is connected to the COMl port. The
only exception is the “@” character which will re-enable
the simulator.
Enable/Disable Function Keys: (Alt F6) : The Enable/
Disable Function Keys option, ( Alt F6 ), allows the user
to choose whether or not the simulator will respond to the
function keys. When the simulator is installed, this option
is enabled and the function keys ( Alt F1 ) - ( Alt F6 ) are
under control of the simulator. If ( Alt F 6 ) is pressed
when the function keys are enabled, they will become dis-
abled. In this way the user program can have access to
the function keys. Thus, a user can use the function keys
as “hot” keys without interfering with the simulator if
the function keys have first been disabled. However, ac-
cess to the command mode functions becomes less con-
venient because it can only be accomplished by using the
command mode menu. Once the function keys have been
disabled, the only way to re-enable them is by entering
the Command Mode menu and pressing ( F6 ) .
B. Program Mode
The other mode of operation is the program mode. Pro-
gram mode commands allow the user to invoke functions
similar to those of command mode, but from within a user
program. Like the robot controller commands, the pro-
gram mode commands are ASCII character strings written
to the COMl device. The program mode commands are
divided into two categories: controller commands and en-
vironment commands. The controller commands are used
 424
to control the motion of the robot, while the environment
commands are used to select simulator options and read
workcell sensors.
The program mode controller commands are summa-
rized in Table VI. The first four commands are the com-
mand set for the Rhino XR-3 controller, Version 4.0 and
earlier [SI. The remaining commands in Table VI are en-
hancements to the Rhino XR-3 controller commands.
Most of these enhanced commands (plus some others) can
be implemented on a physical Rhino XR-3 robot through
a change in the controller firmware [ l 11. The variable a
in Table VI specifies a joint label in the range of A through
G, the variable n is a signed one-byte integer in the range
of [ - 128 * * 1271, and the variable m is an unsigned one-
byte integer in the range [ 0 . . 255 ].
Move Joint: an: This command is used to move joint a
by n encoder counts. The move is accomplished by add-
ing n to the 8-bit error counter for the joint. Whenever an
error counter is nonzero, the simulator moves the joint
associated with it in the direction which reduces the mag-
nitude of the error. The move command is not executed
instantaneously, but occurs over time as it does with the
physical robot.
Stop Joint: ax: The stop command is used to stop joint
a after it has been activated by a move command. This
command has the effect of setting the error counter for
joint a to zero.
Query Joint: a?: The query joint command is used to
determine exactly how far joint a has moved. This com-
mand provides a response on the COMl serial port (ad-
dress 3F8H) which can be read by the user program. The
value returned is the magnitude of the error counter, plus
32.
Interrogate Switches: AI, AJ: The interrogate switches
commands return the status of the microswitches associ-
~ ated with each of the joints of the robot, plus 32. The
value (0 for open, 1 for closed) of each of the switches
can be masked out of the response to this command. The
switch masks are specified in the robot data file. The one-
byte response to this command is obtained through the
COMl serial port.
Extended Query: UT: The extended query command is
a more versatile implementation of the query command.
It returns the actual value of the error counter. For ex-
ample, if the error counter for joint a was - 10, then the
query command would return 1 - 10 1 + 32 = 42, but the
extended query would return the value - 10, expressed as
a one-byte two’s complement integer.
Joint Switch: aV: The joint switch command is an en-
hanced implementation of the interrogate switches com-
mand. It returns the status of the switch associated with
joint a. The status is 0 if the switch is open and 1 if it is
closed.
Set Joint Speed: mS: The set joint speed command is
used to control the speed of the individual joints of the
robot. The simulator initially moves the joints at a default
speed, specified in counts per second, which is taken from
I EEE TRANSACTIONS ON EDUCATION. VOL. 32. NO. 4. NOVEMBER 1989
TABLE VI
PROGRAM
MODECONTROLLER
COMMANDS
Syntax Description Response
an Add n counts to the error counter for joint a -
ax Zero the error counter for joint a -
U? Return I error I + 32 for joint a 32 to 127
A I , AJ Return the microswitch states + 32 32 to 95
aT Return the error counter for joint U - 128 10 127
uv Return the microswitch state for joint a 0, I
amS Set the speed ofjoint a to rn counts/sec -
the robot data file. This command will change the speed
for joint a to m counts/second. The valid range for m is
[ l * * 2551.
The program mode commands in Table VI are com-
mands that control the motion of simulated robot. A sec-
ond group of program mode commands select simulator
options and read workcell sensors. These program mode
environment commands are summarized in Table VI1
where square brackets [ ] denote optional arguments.
Graphics Display: A#: The A# command activated
deactivates the graphics display of the robot. Once acti-
vated, the graphics display will remain active and will be
updated periodically until another A# command is sent.
The default period for refreshing the graphics display is
about three seconds, but this can be changed.
Change View Vector: A!x, y , z!: The !x, y, z! com-
mand changes the view vector for the graphics display to
( x , y, z ) . Here ( x , y, z ) are integer values in the range
[ -9 91 representing the coordinates of the end point
of the line-of-sight. For example, to look at the robot from
the side along the y axis a view vector of ( 0 1 0 ) could
be used.
Home Robot: A$: The A$ command puts the simulated
robot in the soft home position. This command is useful
to recover from a stall, or in any robot control program
which assumes that the robot starts out in the home po-
sition. The A$ command and ( Alt F3 ) can be used in-
terchangeably.
Enable/Disable Simulator: A@: The A @ command en-
ableddisables the simulator in the same manner that ( Alt
F5 ) does in the Command Mode. If a physical robot is
connected to the COMl port of the computer, then the
simulator must be disabled when the robot is to be con-
trolled directly. When the simulator is disabled all com-
mand mode keys are still active so the simulator can sub-
sequently be enabled at any time. The A @ command and
( Alt F5 ) can be used interchangeably.
Set Screen Updated Period: A.x: The A . x command
sets the update period for the graphics display to x / 2 sec-
onds. The default value is x = 6 which updates the graph-
ics display every 3 s. If x is set too small, the simulator
will spend almost all of its time updating the graphics dis-
play, and will have little time left to execute the user pro-
gram that moves the robot.
Path Option AI: The AI command toggles a flag which
tells the simulator whether or not to erase the screen be-
WHITE er al.: SIMULATOR FOR ROBOTIC ARM
TABLE VI1
PROGRAM
MODEENVIRONMENT
COMMANDS
Syntax Description
Turn the graphics display on/off
Change the view vector to (I,y, i ) ( I . 1. I )
Home the robot
Enableidisable the simulator
Set screen update period to x / 2 s
Enable/disable path option
Update display
Return intensity of pixel (x, y )
Return configuration of block b
Set status line option to x
Reserved
fore updating the graphics display. The default is to erase
the screen. By turning off the erase feature, it is possible
to get a multiple-exposure sequence of pictures of the
simulated robot as itAmoves. ~
Update Display A : The A command immediately up-
dates any displays which are currently active. This com-
mand is used to override the automatic screen update when
the graphics display is active. If the status line display is
active, it will immediately update the status line to reflect
the current state of the simulated robot.
Camera Pixel Intensity: AYx, y: The AYx, y command
returns the intensity of pixel ( x , y ) of the simulated over-
head camera. The values for x and y are integers and
should not exceed the number of pixels defined for the x
and y axes of the camera in the workcell data file. The
simulated camera sees only a binary image, so the values
returned are 0 for background or 1 for foreground. A pixel
is in the foreground if it lies within one of the objects or
blocks in the workcell. The camera ignores the robot, so
regardless of its position, it will never appear in a camera
image.
Block Conjiguration: A W [ b , n]: The AW command re-
turns information about the blocks in the simulated work-
cell. Sending the AW command without any parameters
instructs the simulator to return the number of blocks in
the workcell. The parameters b and n are used to obtain
the position and orientation of individual blocks. Both b
and n are integers with b ranging over [ 1 * * number of
blocks], and n ranging over [ 1 * 41. Table VI11 sum-
marizes the options available with the block configuration
command.
For the x , y, and z position values, the number returned
is the position of the centroid of the block, rounded to the
nearest inch (cm) in the range of [ - 128 * 1271. For the
block orientation, the number returned is the principal an-
gle of the block with respect to the positive x axis of the
robot base, rounded to the nearest degree in the range
[ -90 901.
Set Status Line Option: AUx: This command is analo-
gous to command mode option ( Alt F4 ) . It allows the
user to change the status line display at the top of the
screen. The parameter x specifies which of the display
options listed in Table V to place in the status line.
425
TABLE VI11
BLOCKCONFIGURATION C O M M A N D
Default Command Description Response .
Off AW Return number of blocks in workcell 0 to 5
AWb. I Return x coordinate of block b in inches -128 to 127
home AWb, 2 Return y coordinate of block b in inches - 128 to 127
enabled AWb, 3 Return z coordinate of block b in inches -128 to 127
6 AWb, 4 Return principal angle of block b in degrees -90 to 90
disabled
C. Auxiliary Programs
There are also programs that work in conjunction with
the simulator to set up the robot workcell and provide the
user with useful programming information. They include
WORKCELL.COM and SPECS.COM.
WORKCELL. COM: The program WORKCELL.COM
is an interactive program that allows the user to build a
description of a work environment, or workcell, for the
simulated robot. The physical characteristics of the work-
cell are summarized in the ASCII data file WORK-
CELL.DAT, which is created by WORKCELL.COM.
First the user is prompted for the physical dimensions of
the workspace. The graphics display will be scaled to dis-
play the entire workcell. Consequently, in order to get as
large a picture of the robot as possible, it is best to make
the workspace dimensions as small as the reach of the
robot will permit. Next the user is prompted for the num-
ber of workcell blocks, their sizes, their positions, and
their orientations. These blocks can be manipulated by the
robot. Finally, the user is prompted for the physical char-
acteristics of an overhead camera including the camera
position, the field of view, and the camera resolution in
pixels.
SPECXCOM: The program SPECS.COM is used to
extract and display robot and workcell information con-
tained in the data files that customize the simulator. The
program takes two command line parameters, one for the
robot data file, and the other for the workcell data file.
SPECS. COM creates a list of robot characteristics useful
for programming the robot. For example, to develop a
robot control program the programmer needs to know the
joint labels, the joint precisions, the joint ranges, etc.
Useful workcell information is also printed, including the
initial positions and orientations of the blocks and the
camera characteristics. An example of the output pro-
duced by SPECS.COM is displayed in Fig. 3 . This is the
information for the Rhino XR-3 robot and its default
workcell.
VI. EXAMPLES
In this section we demonstrate several features of the
simulator through examples. Some of these examples can
be executed directly from the Command Mode, while oth-
ers require simple user programs.
A. Graphics Display
The most prominent feature of the simulator is the 3-D
graphics display. The display is programmable in the
426 IEEE TRANSACTIONS ON EDUCATION, VOL. 32, NO. 4, NOVEMBER 1989

Data flle RHINO.OAT

JOlnt theta alpha d a PreCISlon Range Speed Mask

base-F 0 . O O V -90.00 9.750 0.000 0.1374 -180.0.. 180.0

150 8
Shldr-E -90.00~ 0 . 0 0 0.000 9.000 0.1145 -160.0.. 60.0
150 4
elbow-0 9O.OOV 0.00 0.000 9.000 0.1145 -90.0.. 150.0
150 2
pltch-C 0 . 0 0 ~-90.00 0.000 0.375 0.1145 -200.0.. 70.0
150 1
roll-B -90.00~ 0.00 7.612 0.000 0.2310 -9999.9..9999.9 150 32
hand-A 0.00~ 0.00 1.0917 -60.5.. 9 0 . 5 150 16

Data flle RHINOCEL.DA1

Block I y 2 Length Wldth Helght Roll

________________________________________-------------------------
1 10.007.001.00 2.00 2.00 2.00 0.00
2 10.0013.00 1.00 2.00 2.00 2.00 0.00
3 10.00 10.00 2.50 6.00 1.00 1.00 90.00
4 11.00 -11.00 1.50 3.00 1.00 3.00 0.00

Fig. 3. Robot and workcell data from SPECS.COM.

sense that the view vector or line-of-sight can be changed

by the user, either from the keyboard or from within a
user program. For example, the Rhino XR-3 robot was
Fig. 4. The Rhino XR-3 robot from perspective ( 0 , 1, 0 )
previously displayed in Fig. 1 using a view vector of ( 1,
1, 1 ). This same robot can be viewed instead from the
side, looking down the y axis, by using a view vector of
( 0 , 1, 0 ) as shown in Fig. 4.
Another important feature of the simulator is that it can
be customized to simulate different types of robots since
all of the robot-specific information is contained in a data
file. Data files for three different robots are currently
available, the five-axis Rhino XR-3 robot, the four-axis
Adept One robot, and the six-axis Intelledex 660 robot.
A graphic display of the Adept One robot using a view
vector of (1, 1, 1 ) is shown in Fig. 5. This is a SCARA
type robot with three revolute joints and one prismatic
joint.
A graphic display of the Intelledex 660 robot using a
view vector of (1, - 1, 1 ) is shown in Fig. 6. The Intel-
ledex 660 robot is an articulated robot with six revolute
joints. Whereas the Rhino XR-3 robot is a small table top
educational robot, the Adept and Intelledex robots are
larger industrial robots.
The graphic display of the simulator can be active while
a move is in progress thereby allowing the user to watch
the simulated robot as it moves. As an illustration, the
Rhino XR-3 robot was programmed to move from its soft Fig. 5. The Adept One robot from perspective ( 1, I , 1, )
home position, q = ( 0 , -90, 90,0, -90), to the position
q = ( 0 , 0 , 0, 0, -90) which corresponds to the arm able for the status line were summarized in Table V . The
reaching straight out. The pictures displayed by the sim-
first option is the tool conjiguration vector w. The tool
ulator as the program executed are shown in Fig. 7. In
configuration is a vector in six-dimensional space which
this case a graphics update period of 0.5 s was used and
specifies the position and orientation of the tool in base
the path option was selected. Normally the graphic dis-
coordinates. When the simulator is first installed using the
play is erased each time it is updated, but with the path
Rhino XR-3 robot data file, the tool configuration option
option selected it is not erased and therefore results in a
displays the following information:
multiple-exposure image as shown in Fig. 7 .
w = (-9.375, O.OO0, 11.075, O.OO0, 0.000, -0.607).
B. Status Line
The status line is a 1 X 80 character text window at the (5)
top of the screen that functions as a real time display of Here the first three components ( w l , w 2 ,w,) specify
the state of the simulated robot. The display options avail- the tool tip position, while the last three components ( w4,
WHITE er al.: SIMULATOR FOR ROBOTIC ARM
Fig. 6 . The Intelledex 660 robot from perspective ( 1,
/?\
Fig. 7 . Display of motion with the path option.
w5, w 6 ) specify the tool orientation. The tool orientation
is specified by taking the approach vector of the tool and
scaling it by exp(q,/n) where qn is the tool roll angle.
For a more detailed explanation of the tool configuration
vector, refer to [ 121.
The second display option of the status line is the joint
variable vector q . For the Rhino XR-3 robot, the joint
variables are joint angles because each of the five joints
is revolute. The same is true of the Intelledex 660 robot
which has six revolute joints. However, for the Adept One
robot, the third joint variable is a joint distance which
427
specifies the extension of the prismatic joint. The display
of joint variables for the Rhino XR-3 robot in the soft
home position is as follows:
= (0.0, -90.0, 90.0, 0.0, -90.0), T = 0.0. (6)
The Tat the end of the line specifies the position of the
tool. Here a value of T = 0 implies that the tool is in the
fully open position. The joint variable option is quite use-
ful because it can quickly inform the user where the robot
is without the use of the graphics display. If the user is
developing a program to perform a move in joint space,
this single line of text can tell the user whether or not the
program is functioning properly.
The next display option of the status line is the micro-
switch status vector s. When the Rhino XR-3 robot is in
its soft home position, the microswitch status vector dis-
plays the following information:
s = (open, open, open, open, open), T = open. (7)
Thus, all of the switches are open in the soft home po-
sition. If we attempt to move the tool by 90 counts in the
negative direction (a move command of A-90), the tool
microswitch will close and the microswitch display vector
- 1. 1) will be updated as follows:
s = (open, open, open, open, open), T = closed!. (8)
The ! at the end of the tool microswitch status indicates
that the tool has stalled because an attempt has been made
to drive it past a hard limit. In the graphic display, the
tool turns red to indicate that a stall has occurred.
The fourth display option of the status line is the joint
error vector e. Like the actual controller, the simulator
attempts to maintain each error counter at zero. If the ro-
bot is not moving and no stall conditions exist, the joint
error vector will be zero. However, since we have in-
duced a stall of the tool in (8), the simulator can no longer
move the tool in the specified direction so the error count
for the tool is nonzero. Looking at the joint error vector
we would see the following:
e = (0, 0, 0, 0, 0), T = -53!.
This tells us that the tool was able to move only 37 of
(9)
the 90 counts that were sent. To clear the stall we could
send the command AX or the command A53 as both will
zero the error counter for the tool.
It is also possible to create a global stall condition in
which the robot as a whole attempts an illegal move such
as entering a protected region. For example, an attempt
might be made to penetrate the work surface with the tool.
A tool-configuration status line indicating a global stall
might look something like this
w = (5.6000, 10.000,
-0.305, 0.000, 0.000, -0.607)!. (10)
Note that w 3 < 0 which means that the z coordinate of
the tool tip is below the work surface! When a global stall
occurs, the entire robot turns red in the graphic display,
428 IEEE TRANSACTIONS ON EDUCATION. VOL. 32, NO. 4. NOVEMBER 1989

and an exclamation mark appears at the far end of the

status line. The only way to clear a global stall is to reset
the robot to the home position using A$ or ( Alt F3 ) .
The last display option of the status line is the block
conjguration vector U . Each block in the workcell has
associated with it a four-dimensional block configuration
vector which specifies the position and orientation of the
block. The following block configuration vectors corre-
spond to the Rhino XR-3 default workcell configuration.

zil = (10.000, 7.000, 1.000, 0.00) (11)

zi2 = (10.000, 13.000, 1.000, 0.00) (12)
213 = (10.000, 10.000, 2.500, 90.00) (13)
214 = (11.000, -11.000, 1.500, 0.00). (14)
The first three components ( v l , v2, u 3 )specify the po-
sition of the centroid of the block in base coordinates. The
last component v4 specifies the principal angle of the block
in the x - y plane of the base frame. Thus, the only measure Fig. 8. The pick operation.
of orientation used is the angle of rotation about a vertical
axis. This is useful when blocks are being manipulated
directly from above. For some robots, such as the four-
axis Adept One, this is the only way blocks can be ap-
proached.

C. Pick and Place Operation

The simulator not only tells the user where the blocks
are located, but it also allows the blocks to be manipu-
lated by the simulated robot. Therefore loading and un-
loading operations, material handling operations, and
simple assembly operations can be simulated. To illus-
trate this feature a simple pick and place operation was
programmed and the graphic display option was acti-
vated. The sequence of pictures shown in Figs. 8-10 il-
lustrate the motions of the manipulator as it picks up a
block (Fig. 8), transfers it (Fig. 9), and then sets it down
(Fig. 10).
In this case block number 4 was moved to place coor-
dinates (0, 10, 1.5) and its principal axis was aligned
with the base y axis. The configuration vector for block Fig. 9. Transfer of the block.
number 4 is then updated and the corresponding status
line display becomes
VII. CONCLUSIONS
u4 = (O.OO0, 10.010, 1.449, 90.08). (15) A 3-D graphics robot simulator which runs on an IBM
The block configuration information is also available to PC/XT/AT or PS/2 personal computer has been pre-
the user program through the block configuration com- sented. Using the simulator, students can develop and test
mands summarized in Table VIII. These are high-level robot control programs off line using the language of their
environment commands that the user can exploit to plan choice. The simulator is based primarily on the Rhino
a sequence of pick and place motions. Alternatively, the XR-3 robot, a popular five-axis educational table top ro-
camera pixel intensity command can be used to take a bot. However, with the use of data files that are specified
picture of the work surface using the simulated overhead when the simulator is installed, other robots can be sim-
camera. The resulting binary image can then be analyzed ulated including the the four-axis Adept One robot and
to determine the block configuration information [12]. Al- the six-axis Intelledex 660 robot. The simulator runs in
though this technique is slower, it is a more fundamental the background as a TSR program. It intercepts com-
approach that is useful for teaching students how to use mands that would normally go to the robot controller
raw data from an overhead camera to plan robot motion. through the COMl device and responds to them as if it
WHITE et al.: SIMULATOR FOR ROBOTIC ARM
Fig. 10. The place operation
were the robot controller. The state of the simulated robot
is available to the user through a 3-D graphic display and
also through a one-line text window. The environment o r
workcell within which the robot operates is also specified
in a data file that can be customized by the user. The
workcell includes an overhead camera and several work-
cell objects that can be sensed by the camera and manip-
ulated by the robot.
REFERENCES
N. Andrews, “Moving toward an industry standard for developing
TSR’s,” Microsofr Syst. J . , vol. 1, no. 9 , Dec. 1986.
J. F. Callan, “The simulation and programming of multiple-arm ro-
bot systems,” Robotics Eng., vol. 8, pp. 26-29, 1986.
K. Chevasin and R. Prieiner, “Robot activity simulation and plan
testing,” ISA Trans., vol. 23, no. 4, pp. 51-54, 1984.
J. D. Foley and A. van Dam, Fundamentals of Interactive Computer
Graphics. Reading, MA: Addison-Wesley 1982.
R. Hammond, J . Hansen, and L. Hansen, “Software simulates a ro-
bot cell,” Welding Design & Fabric., vol. 59, pp. 55-57, 1986.
W. R. Iversen, “Reprogramming a robot may get a lot easier and
faster,’’ Electronics, vol. 59, pp. 16-17, 1986.
R. Nelson and D. Delorie, “SMARTG: A smart graphics package,”
Educ. ComDut. Sew., Clarkson Univ., Potsdam, NY, 1987.
Sandhu, H., Hands-on Introduction to ROBOTICS, The Manual f o r
the XR-Series Robots. Champaign, IL. Rhino Robots, 1983
T Sata, F Kimura, and H. Hiraoka, “An approach to model-based
robot software for industrial applications,” Compur. Industr?, vol 7,
pp 211-225, 1986.
[ 101 T. Sata, F. Kimura, and A. Amano, “Robot simulation as a task plan-
ning tool,” in Proc 11th ISIR, 1981, pp 595-602
[ l l ] R. J. Schilling and S . W. Williams, “A firmware voltage controller
for a robotic arm,” IEEE Trans Educ , vol E-30, pp 164-173, Aug.
1987.
[I21 R J Schilling, Fundamentals of Robotics Analysis and Con-
trol. Englewood Cliffs, N J Prentice-Hall 1990
[I31 B J Schroer and W Tech, “A graphical simulation tool with off-
line robot programming,” Simulation, vol 47, pp. 63-67, Aug 1986.
[ 141 R B White, “SIMULATR A graphics sottware tool for robotics
education,” M S thesis, Clarkson Univ , Potsdam, NY, Dec 1987.
[ 151 T Raz, “Graphics robot simulator for teaching introductory robot-
ics,” IEEE Trans Educ , vol 32, pp 153-159, May 1989
429
Robert B. White was born in Brooklyn, NY, in
1964. He received the B.S. degree in computer
science and math in 1986 and the M . S . degree in
electrical engineering in 1987. all from Clarkson
University, Potsdam, NY.
He was a teaching assistant at Clarkson Uni-
versity for the 1986-1987 academic year. After
completing the M.S. degree, he spent a year in a
software engineering position at General Electric
Company in Syracuse, NY. He is currently sew-
ing an ROTC obligation, working as an Intelli-
gence Officer and is stationed at Fort Riley; KS. His current interests in-
clude digital design, low-level microcomputer programming, and graphics.
R. K. Read (M’86) was born on July 17, 1958 in
Indianapolis, IN. He received the B.S. degree
from Rose-Hulman Institute of Technology, Terre
Haute, IN, in electrical engineering and computer
science in 1980. and the M.S. and Ph.D. degrees
from Purdue University, West Lafayette, IN, in
electrical engineering in 1982 and 1986, respec-
tively.
He is currently an Assistant Professor of Elec-
trical and Computer Engineering at Clarkson Uni-
versity, Potsdam. NY. His present research inter-
ests include computer I;imulation, real-time programming. control systems,
image processing and pattern analysis, robotics, and path planning tech-
niques.
Dr. Read is a meml,er of the IEEE Computer Society and Control Sys-
tems Society.
M. W. Koch (S’83-M’85) was born on August
28, 1957 in Ballston Spa, NY He received the
B S degree from Clarkson University, Potsdam,
NY, in electrical and computer engineering in
1979, and the M S and Ph.D degrees from Pur-
due University, West Lafayette, IN, in electrical
engineering in 1981 and 1985, respectively
H e is currently an Assistant Professor of Elec-
trical and Computcr Engineering at Clarkson Uni
versity His present research interests include
neural networks, computer vision, and artificial
intelligence.
Dr. Koch is a member of Eta Kappa Nu and Tau Beta Pi.
R. J. Schilling (M’74) was born on August 28,
1947 in Cloquet, MN He received the B.E.E de-
gree in electrical engineering from the University
of Minnesota, Minneapolis, in 1969 and the M S
and Ph D degrees i n electrical engineering from
the University of California, Berkeley, in 1970 and
1973, respectively.
He was a Lecturer in the Department of Elec-
trical Engineering and Computer Science at the
University ot California. Santa Barbara. trom
1974 to 1978 He joined the Department of Elec-
trical and Computer Engineering at Clarkson University, Potsdam. N Y , as
an Assistant Professor i n 1978 He is currently an Associate Professor at
Clarkson University He has written two textbooks, including one in the
field of robotics entitled Fundamentals of Robotic Anal\c./s und Control
His current resedrch Interests include robotics, nonlinear systems, descrip-
tor systems, and digital control