Robotic Applications on the HP-71B Using the Interloop I/O
                          Control Board

                         by Tom W. Sibert

The School of Mechanical Engineering at Georgia Institute of Technology is
presently working on a project for NASA on lunar habitation.  The main goal in
this work is development of a robot to serve as a platform upon which many
different functions can be performed, such as digging, drilling, soil moving,
data collection, and construction of housing facilities.

The robot is designed to have the lowest possible mass and yet still be able to
move.  Due to the rough terrain (so to speak) of the lunar surface, and the low
relative gravity (one-sixth that of earth), a tracked vehicle was was
determined to be somewhat less that optimal.  This left either a walking method
of propulsion or levitation of some sort.  Obviously, levitation has yet to be
developed to a practical degree.  So a walking design was selected.  The next
choice was, obviously, the number of legs.  One-legged (hopping) robots have
been developed, but the impact of hopping on the soft lunar soil would render
it inoperative.  Also, the amount of computational power needed would be
enormous, thus increasing the size and scope of the computing package and thus
the payload required to be lifted into orbit and soft landed on the moon.  Most
of these problems can also be applied to a two-legged design.  Also, neither is
stable at rest.  Thus the least number of legs for a stable platform is three.
While this may seem a bit odd at first, think of a man with a broken leg on
crutches - fairly good propulsion with only three appendages.  Three legs keeps
the total weight down, relative to a larger number of legs.  Since the design
is inherently stable at rest (under most conditions), the amount of processing
power is reduced over the one- and two- legged versions because the balance
algorithms, if any, are much less complicated, and the number of degrees of
freedom, and therefore the numbers of sensors and actuators needed are reduced
over four- or so legged designs.

The prototype of this three-legged robot, appropriately enough named
"Skitter", is presently being constructed at The School of Mechanical
Engineering at Georgia Institute of Technology in Atlanta.  The three legs are
symmetrical about a center axis (spaced in a circle, 120 degrees apart), and
each has two degrees of freedom. Each leg consists of a "femur" attached to the
main body, and a "tibia" attached to the femur and reaching to the ground.  The
movements are constrained as if one's leg could move normally except for the
sideways, or lateral, motion at the hip, and the rotation at the same joint.
The default position for the leg is with both segments at approximately 90
degrees to either the body or femur, whatever the case may be.  Since each
segment is actuated by two pneumatic cylinders in series, the total number of
positions in each leg is 2^4, or 16.  These sixteen positions can be
represented pictorially by a simple four by four matrix with femur cylinders on
one axis and tibia cylinders on the other (see figure 1).  When a plot is
made of the actual position of the leg (in a side view of the leg as it is
connected to the body, with the present cylinders), the shape of the sixteen
points is similar to a curved four-sided polygon (see figure 2).  The borders
of this polygon represent the bounderies of the leg's movement.  While sixteen
discrete positions is indeed a bit coarse, it appears to be adequate for
proving that a three-legged robot is workable.

Air flow to the pneumatic cylinders is controlled by twelve 12VDC solenoid
valves attached to the body of the robot.  Source air will come from an air
tank onboard the robot, so that the entire system will be self-contained.  Each
valve's solenoids gets power from an onboard 12V lantern battery connected in
series with a solid state 5VDC relay.  This relay is connected to a single bit
of an output port of an Interloop IL-210-1 HP-IL I/O board.  This interface has
32 bits of digital output, two analog inputs, and 32 digital outputs.  It
requires 12-24VDC as input power, and is controlled via any HP-IL computer.  In
our case the HP-IL source is the HP-71B.

The HP-71B was chosen because it was the only real possibility in the arena of
HP-IL computers.  The HP-41C family was limited by its instruction set and
operational speed.  The HP-110 was limited by its size, weight, and cost, and
its lack of an easy-to-use, HP-IL compatible programming language.  The HP-71B,
on the other hand, is small, light, and fairly inexpensive; it contains a
Hewlett-Packard BASIC, which is a great choice for instrument control; FORTH
and assembler are also available in ROM form; and the processing speed, while
not fast, is completely adequate for the job.  Memory was not a constraint: the
computer can access 512K bytes of RAM, and 32K RAM modules are readily
available and one provides more than enough space.  Since at least three of the
people involved in the project already owned a '71, this was the logical choice
of controller.

The HP-71B has, as previously mentioned, three programming alternatives:
BASIC, which is built in; FORTH, available on a ROM module along with the third
choice, assembler, in the form of the FORTH/Assembler module.  Most of the
group knows how to program in BASIC, and a few of us know FORTH enough to write
simple programs, but not quite well enough to control a robot via HP-IL, and
FORTH's main advantage, speed, was just barely better than BASIC's in many
applications.  Anyone who has ever attempted to debug or modify someone else's
FORTH code knows how much fun that can be.  BASIC is much easier to read and
decipher (depending on the original programmer, of course).  Also, we would
have had to buy a FORTH module, since there weren't enough owned to go around
to everyone who needed one, and this project is being done on a very limited
budget.  Assembler is tedious at best, and while blazingly fast, was definately
not worth the trouble.  Thus BASIC was the most obvious, and practical, choice.

The software is a semi-modular, menu-driven system that allows the user to
input the series of movements of the robot's legs that he desires.  The three
legs are designated A, B, and C.  The sixteen positions mentioned previously
are numbered 1-16, starting at the upper left position on the chart, and
numbering to the right and down (figure 2).  Taken together, the leg designator
followed by that leg's position provide us with an easy way of telling the
computer where to put that leg.  For example, "A15" means that leg A is at
position 15.  This way the user need not concern himself with determining what
solenoid to fire and which to release.  He merely tells the computer to put a
certain leg or legs at a certain position or positions at a certain time.

It was determined that the maximum duration of any forseeable walk would be for
thirty seconds.  Using the IL-210-1 I/O board, we found that the fastest rate
at which we could control the output ports and keep up with the houskeeping
functions was approximately 10 cycles per second, i.e., any given leg or set of
legs could be ordered to a new position no less than 100 milliseconds after the
last command was sent.  Our estimation of the walking algorithm determined that
this would be adequate.  In this scenario, a data file or array with 300
records would hold all the data necessary for a 30 second excursion.  The I/O
board requires a string of the form "Bnxxx" where n is the output port (0-3)
number, and xxx is a three-digit decimal value of the binary bit pattern,
obviously between 0 and 255.  Since each leg has four cylinders, and each
cylinder requires just one bit to control it, a total of 12 bits is necessary
to control the whole robot.  These bits are found in the upper and lower
nybbles of output port 0, and in the upper nibble of output port 1 controlling
leg A, B, and C respectively.  After some deliberation, the choice was made to
work exclusively with 300 record data files (as opposed to a 300 entry string
array) , since they couldn't be DESTROYed by a careless "DESTROY ALL", and as
data files they can be SECUREd.  Since only two output ports are being used,
the maximum number of bytes we will ever need to send to the board is two, and
since the "B" is redundant, the record of each data file need only be eight
characters long.  This means that less than 2.5K bytes is needed for each
(uncompiled) file.  With a 32K RAM module, giving us a total of over 49K, room
is available for several different files.

The three main modules of the software are the Edit, Compile, and Go routines.
There are other choices, but they are not critical to the actual operation of
the robot.  These include an Exit routine, to clean things up and terminate the
program; a Help routine to display a command list; a Reset routine to bring
the robot back to its default position; and a Wait command for entering the
delay between the time the computer is told to make the computer walk and robot
is told to begin moving.  This last command will be used in the presentation of
Skitter so that the speaker will not have to mess with the robot after the
presentation begins, i.e., the program is told to begin executing the walk, but
the robot will not actually begin for the specifies Wait time.

Edit allows the input and editing of the steps in the sequence of solenoid
firings.  This is done using a "time code" where the record number of any given
step is equal to t/10, where t is the time since "takeoff".  In Edit the user
may look at and/or change any given time step.  The prompt displays as

     t=xx.x?Aaa,Bbb,Ccc

where xx.x is the time code of the step displayed, and aa,bb,cc are the new
positions of legs A, B, and C, respectively at that time.  The routine will
display a leg designator and the leg's position only if a change has been
entered at that time.  At this prompt the user may enter either a time between
0.0 and 30.0, or a string of the form shown to the right of the question mark
above.  Entering a number at the prompt will cause the program to jump to the
entered time and display the commands, if any.  Other commands may be entered
at the prompt in the form of single letters.  An input of "E" will exit the
Edit routine and return to the main menu.  An input of "N" or "P" will display
the next or previous change, i.e., the next or previous non-null record.  An
"H" command will display a screen explaining what the single letter commands
are.

The Compile module is a conversion routine where the file of leg changes is
translated to a file of output strings of the form previously discussed and a
number representing the amount of time in seconds before the next change.  This
file will only be as long as necessary to accomodate all the changes.  In other
words, if, during the 30 seconds there are only 220 times that a command must
be sent, the file will only be 220 records long to save memory.  An "uncompile"
routine, while relatively simple, is not necessary since the "source" data file
is not purged upon compilation.  Instead, the compiled file has the same name
as the source file with "rn" tacked on the end, thus limiting source file names
to only six characters in length.  Unfortunately the '71 does not allow
extensions on filename specifiers since the operating system automatically puts
them there.

The Go routine is what makes Skitter dance.  This simple routine merely waits a
predetermined amount of time before beginning execution of the data file, and
then reads in a string and waiting period from the file, outputs the string(s)
to the IL-210-1 board, WAITs for the waiting period, checks for a keypress, and
if none, repeats that procedure until the data is exhausted.  If a key has been
pressed, the robot is frozen in its present state, to avoid any further
problems or injury.  The program will then go back to the main menu, where the
user can press "R" to return the robot to its default (reset) position.  If the
everything proceeds smoothly to the end of the data, the computer resets the
robot, and returns to the main menu.  Since the control system is purely open
loop, if the user is not careful, the robot can cause considerable damage to
shins and knees, or any hands that happen to be in the wrong place at the wrong
time.  Ten meter HP-IL cables will be used in walking algorithm development.

As of this writing, the robot is nearing completion of the mechanical
construction, and the software is being being readied for the first test.  In
the (extremely) hectic final week of the program, the walking algorithm will be
developed, and Skitter is scheduled to prance across the stage at the USRA
conference in Washington, D.C. on June 11, 1987, and again later in the month
at Langely Research Center.  Needless to say, everyone in the group is under
some pressure.  The group consists of seven people.  These are Professor James
W. Brazell of the School of Mechanical Engineering at Georgia Tech, who heads
the project; Gary McMurtry and Brice McLaren, two graduate students in M.E.,
Steve Chicka, an undergradute senior in M.E., Tom Sibert and Brian Walsh, two
industry bound M.E.s, and Omar Bolado, another industry bound engineer.  The
final three people are responsible for the software development, while the
first four are involved in the mechanical development.  In actuality, though,
almost everyone has had significant input to all parts of the project.  In a
required senior design course taught by Prof. Brazell, each design group is
required to design an application for Skitter.  The project is being funded by
both NASA and the School of Mechanical Engineering, so many people in the space
industry are keeping their eye on the robot's development.  "Design News"
magazine recently had an article entitled "A Visit to the Lunar Station",
featuring Skitter's development along with other work going on elsewhere.

The project, though nearing completion, has a great deal of potential.
Projects handed in from the design class need to be sorted through and refined.
Skitter itself could be extensively modified with additions such as closed loop
control, finer resolution of leg positions, intelligence, and greater/faster
computing power.  But for now, we just want it to walk.