Robo-Kitty, Details of the Construction and
Programming of the LSU Robo-Tiger
Patrick McDowell
Louisiana State University
Department of Computer Science
7/17/2000
Introduction
The LSU Robo-Tiger project is a joint effort involving LSU’s Computer Science,
Electrical Engineering, and Athletic departments. The goal is build a cybernetic tiger that
can be used to help the school mascot, Mike the Tiger, with his duties at the schools
various athletic functions. The idea was conceived by Dr. S.S. Iyengar and Dr. Lynn
Jelinski late in the fall semester of 1999. Under the direction of Dr. S.S. Iyengar, the
LSU Computer Science department’s Robot Research Lab has conducted preliminary
studies to determine the feasibility of the project.
The first phase of the project consisted of constructing a small prototype of the tiger. The
original prototype, nicknamed Mickey, was used to identify the various issues involved
developing a full sized robotic tiger. Although the prototype is a much simplified version
of the final product, many of the ideas, concepts, algorithms and construction methods
are applicable. Below we have outlined the key areas in which research and development
is taking place.
Mechanical
Mechanical considerations include the underlying skeleton and joints, the actuators, and
the body panels. The overall shape of the robot is a direct result of its skeletal structure,
as is the robot’s static and dynamic stability. Since the prototype was to be a small
version of Mike the tiger, it was decided that its basic size, proportions, and physical
characteristics would be modeled after those of a cat. To get a feel for the various
dimensions, measurements of a cat skeleton were crosschecked against measurements
taken directly from four cats. It was decided early on that the joints would move only in
one dimension and for simplicity sake, the hip joints would not be articulated. Therefore,
neither Mickey nor the second prototype, Stubby, would be able to reach across their
bodies. From the measurement data, and proportions, a mock-up of the prototypes
skeleton was built. In figures 1 through 3, the mockup is shown in various positions
typical of cats.
1
Figure 1. Mockup in sitting position.
2
Figure 2. Mockup in resting position.
3
Figure 3. Mockup in stretching position.
The legs are made of masonite, the backbone is a threaded rod, and the hips are flat bar
aluminum. The material selection criteria were simple. The materials needed to be light,
strong, easy to work, cost effective, and easily available.
Experience gained in building the mockup included, materials selection, shaping of
aluminum and cutting of masonite, and fashioning simple joints. Masonite turned out to
be a good material because of its relative lightness, it is easy to drill and cut, and its
strength and flexibility are more than adequate for this scale of construction. The joints
are simple masonite sandwiches. They move in one dimension, and offer good support.
From the above figures it can be seen that the basic proportions of a cat were captured by
the mockup.
From the outset of the project one the most pressing problems has been what sort of
actuators should be used. Several methods of joint locomotion have been developed and
used over the years. MIT’s Leg Lab has developed several impressive robots which they
have used for studying walking which can be seen at their website. Many of these robots,
including their Quadruped (1984 –1987) use hydraulic/air spring combinations for
locomotion. But for the prototype tiger, size, cost and complexity considerations led to
the selection of RC servo motors as joint actuators. RC servos like those used in model
airplanes and cars have several good features, ie.; they are common, economical, they
4
come in varying sizes, and computer controlled interfaces are available. On the
downside, they use a considerable amount of power, yet do not produce an overwhelming
amount of torque. The standard Fujitsu type RC servos like we used do not use a worm
gear for torque multiplication, which means that even when a joint is not moving, if there
is a load on it, power must be used to hold it where it is.
Using the body of the RC servo as part of the bone, the limbs and joints were assembled
using the servos in a direct coupling with joints. This method was used because it is
mechanically simple and it was known that this method had been used by others at LSU
and was common in hobby robotics. Because the amount of torque required to move a
servo at the end of a bone is directly proportional to the length of the bone, much
consideration was given to locating the servos in the body of the cat and using
mechanical linkages to move limbs. Most animals that run fast have the bulk of their
muscle on the torso. Tendons attached from the muscle to the bone move the limbs. This
method is much more efficient, but as stated earlier, it is more mechanically complex.
The initial hunch was that by using clever programming techniques mechanical
inconsistencies, weaknesses, and limitations could be overcome. Figures 4 and 5 below
detail the construction of Mickey’s legs.
Figure 4. Front and side view of first prototypes front legs.
The bulk of the servo can be seen in the leg on the left-hand side of the picture.
5
Figure 5. Rear leg of Mickey.
It is obvious from figure 5 that the servo mounted on the rear hip of the robot will be
working hard to lift the servos in the rear leg. Figure 6 shows a side view of the
completed robot, Mickey.
6
Figure 6. Side view of first prototype, Mickey.
Aside from the bunny rabbit looking head and the bones being too wide the overall
proportions of Mickey are very close to the original mockup and to those of a cat.
Commercially available robot kits usually have six legs, arranged like those of a bug.
That is, the joints do not swing in parallel planes. This leads to stability, because the
upper part of the leg is used to widen the “track” of the bug. It is also efficient, because
the robot does not have to expend energy to stand up. Cats on the other hand have
narrow shoulders and their joints move in the vertical plane, parallel to their bodies,
leading to a balance, and control problem. This issue combined with the torque problem
that was detailed earlier made it very hard to control Mickey. Even so, Mickey served as
an excellent platform to interface the computer to the electronics that control the servos.
To overcome the problems, better balance, and more mechanical advantage was needed.
Since new servos were not an option, the limbs were shortened in order to lessen the
amount of torque needed at the joint. Also the rear legs were changed to be like the front
legs, so that the second prototype, Stubby, is not nearly as faithful to the proportions of a
cat as Mickey. But the servo motors can move Stubby around with brute force, where
Mickey had to have perfectly coordinated sequences of moves in order to take even a few
steps. In fact, Mickey could take a few steps, but did not have the power to weight ratio
to get itself back to a standing position. By making a more mechanically powerful robot,
7
the problem of coordinating the movements of the joints became exponentially easier.
Figure 7 below shows a view of Stubby sporting its tiger markings.
Figure 7. The second prototype, Stubby.
Stubby’s shorter limbs decreased the torque required to move the limbs. Also the rear
legs were simplified to operate identically to the front legs. Doing this eliminated the
third servo on the rear leg. Thus, Stubby has two servos per leg, a total of eight servos,
while Mickey had two servos for each front leg and three for each rear leg, a total of ten
servos. These changes definitely take away from the likeness to a cat, but it was a
necessary developmental change. In defense of the change, it was noted that young cats
walk with the majority of the motion coming from the upper part of the leg, as Mickey
was programmed to do, but it was observed that older cats tended to use the middle joint
and the foot more. By providing a more stable platform, by virtue of the robot being
shorter, and a better “power to weight ratio” the job of controlling became easier. Stubby
can bring itself to a standing position with much less of a struggle than Mickey could.
Control and system architecture
The original control system consisted of a PC communicating via serial port to Medonis
Engineering’s Advanced Servo Controller 16 (ASC16) micro controller board. The
board could simultaneously control the position, speed and acceleration of up to 16
standard RC servos. It also featured 8 outputs rated at 250 ma and 8 inputs that could be
read as digital or analog with 8 bit resolution. The general idea was to send micro-code
8
generated by a C program over the serial line to the micro-controller which would in turn
would run the code. The code set allowed servo speeds, accelerations, triggering, and
stopping points to be set. Triggering could be based on time or position. Positions and
analog to digital values could also be returned to the host computer. The system
performed moderately well, but sometimes the servo motions were unpredictable. It was
never determined if this was due to low battery power or micro-coding errors. A short in
a power supply expedited a change in electronics. See figure 8 below.
Figure 8. Control flow using the Medonis ASC16 micro controller board.
Because of parts availability, or lack of it, two Mini SSC II boards from Scott Edwards
Electronics, Inc.were used in place of the ASC16. The Mini SSC II board can control up
to 8 RC servos, thus the need for two boards (The original board failed while on Mickey).
Again, communication is accomplished through the serial port. The new boards had no
reporting or A to D provisions so a National Instruments DAQCard-1200 was slated to
handle sensor inputs. The PC control system was switched from C to LabView in order
to provide a GUI and to communicate with the DAQCard. To command a servo to go to
a new position takes the PC only needs to send a 3 byte code down the serial line. The
command structure is as follows.
Byte 1
<sync marker (255)>
Byte 2
<servo # (0 – 254)>
Byte 3
<position (0 – 254)
9
Unlike the Medonis board, the Mini SSC II does not monitor servo positions and act like
a micro controller, it serves as an interface only. The PC was programmed to handle the
multi-tasking required to control multiple servos at once.
Stubby is equipped with micro switches in its feet so that when a foot is down it can be
detected. LabView uses the DAQCard to monitor these inputs. Figure 9 shows the data
flow using the Mini SSC II boards in conjunction with the DAQCard and PC.
Figure 9. The current system architecture uses 2 Mini SSC II boards (each controls up to
8 servos) to control the servos and a National Instruments DAQCard-1200 to collect
sensor information.
Computational
Three basic strategies were used to create the software that controls Stubby. The first
software was loosely based on code that came with the ASC16 board. This code was fine
for testing but was not easy to tune or adjust.
Realizing that software with direct servo control and editable playback features was
needed, the m0.vi system was created. With this software the user could control each
servo individually and save sequences of positions of the servos. Thus, to make the robot
walk, the walking gait would be divided into a number of discrete times in which each
servo would at be some particular position. The idea was to use the program to move the
10
legs through the gait manually and then play it back. Figure 10 below shows the control
screen of m0.vi.
Figure 10. The m0.vi servo control screen. The individual servos are controlled by the
sliders on the left hand side of the screen. The record and play functions occupy the
lower part of the screen, while the current and next servo positions are shown at the upper
right of the screen.
Using this program and the previously discussed method, Mickey took about three steps,
but because of its mechanical configuration, it was difficult to control. The robot was
barely statically stable and once it started moving the dynamics became unstable, so
without some sort of good feedback loops it was evident that it was going to take a stroke
luck to get good results. The torque problem also made it so that as the cat walked, it was
difficult if not impossible to get it back to a standing position. The legs would simply get
more and more sprawled because the servos lacked the power to raise the cat back up.
Realizing that it was going to take more than just software changes to make the cat walk,
a host of mechanical changes were made (discussed in the previous section) and the
second prototype, Stubby, was born. Using the m0.vi program, Stubby showed much
greater prowess, but “eyeballing” a walking sequence was still proving to be difficult.
Eventually a nine frame sequence was developed with the intention to tune it with a
genetic algorithm. The first frame was the standing position and next 8 frames held the
servo positions for a simple walking sequence. The grow.vi program was created to hone
11
the sequence over a number of generations into a viable walking gait. The program
always left the stand frame alone, and assigned each of the frames in the walking
sequence to a chromosome. It then created a population using mutation based on random
numbers, maximum offsets, and chance of mutation. The individuals of the population
were each run in the robot and the distance that it moved was used as a fitness function.
After each member of the population had its chance, the individuals that walked the
furthest were used to create a new population. Because this was not a simulation,
running thousands of generations with large populations was not feasible, so the mutation
factor was turned up. If a population had a worse average walking distance than the
previous generation, the algorithm was halted and restarted using the best individual from
the previous generation as the seed gait. By repeating this process the Stubby increased
its walking distance in 17 frames from roughly 14 inches to about 25 inches in about 40
generations. At the end of the process Stubby walked, but it walked ugly. Ugly as in the
servo movements were jittery, and it drug its feet. Figure 11 shows the control screen for
the grow.vi program.
Figure 11. The grow.vi program. The inputs in the lower left control the population size,
and mutation. This program improved the walking gait of Stubby significantly.
Even though the grow.vi program did its job, it seemed that it would take an excessive
amount of time to come up with a good walking gait using this method. Again, if the
genetic algorithm were driving a simulation, the solution would take much less time. But
considering it takes between 30 seconds and a minute for each individual to run in the
grow.vi program, and it could hundreds if not thousands of generations to get the gait
right, there had to be a better way. Another major consideration was servo life. How
long could they take a beating and not fail?
12
Logical reasoning and practical experience leads one to believe that walking can be
broken down into some sub-tasks. One may be balancing, another may be reaching out
with a foot, and another would be pulling with the foot once it was in contact with the
ground. If the robot could not loose its balance, for example a well built six leg bug type
robot would not need to worry too much about balance, then its primary concern would
be reaching and pulling with its feet. If acceptable reach and pull movements were
available, then the problem of walking would boil down to finding the right timing for the
reach and pull movements. Said another way, if each leg had a controller that guided it
through a reach or pull movement at the right time, then walking would be a team effort
for the legs.
This reasoning closely parallels Subsumption Theory that MIT developed for some of
their walking robots, and it turns out that biologist say that this is how real bugs walk.
Each leg in bug has neurons in it that manage the task of figuring out when and how to
move. Walking for bugs is a collaboration of the neurons in the legs, not a centrally
directed effort.
The f0.vi program works using the concepts outlined above. By taking advantage of
LabViews multitasking capabilities a virtual controller for each leg was created. Each
virtual controller has a reach section and a pull section. Stubby was stable enough to
ignore the balance problem for the time being, and concentrate on the gait timing. The
initial idea was to let each leg controller know what the other legs were doing, and then it
would make a decision to reach, pull, or wait. The m0.vi program was used to create
acceptable reach and pull sequences. During testing, user setable binary flags were used
to fire the reach and pull sub-controllers. Figure 12 shows the control screen for the f0.vi
program. Note the gait control flags in the lower center of the screen.
13
Figure 12. The control screen of the f0.vi program. Note the buttons on the left for firing
of individual virtual sub-controllers. Also note the binary gait flags in lower central area
of the screen. The four square green lights at the very lower central are the foot up/down
indicators.
By looking at the MIT Leg Labs website simulations for four legged walkers, by
watching their video of their Quadruped (1984 – 1987), reading their literature, and by
observation of cats, the quadruped gait for trotting was selected as the default gait. The
trotting gait, like many others, uses the legs in pairs. The diagonal legs are paired up.
That is the front left and right rear legs pull at the same time, and the left rear and right
front legs reach at the same time, and vice versa. It produced a walk that was not perfect,
but much better than previously achieved. Figure 13 shows a basic data flow diagram for
the f0.vi program.
14
Figure 13. This block diagram shows the basics of the software architecture for the f0.vi
program. Note that all the processes in the rectangular boxes operate asynchronously.
Performance is surface dependent, that is the robot works better on a surface that is
forgiving, i.e. slippery. A similar condition occurs when a football player runs on
astroturf. When he gets tired and his leg motion gets sloppy he has an excellent chance
of tripping because his traction is so good. For ball players, it’s a double edged sword, a
perfect motion creates incredible speed, but less than perfect motions cause tripping and
injury. It all boils down to, the somewhat slipper surface masks errors in the gait, such as
dragging feet during a reach motion, toe stubbing, etc.
At this point in the development cycle, improvements such as sensing that a foot is down
during a reach movement, adapting the reach and pull movements to each leg, and using
and letting each virtual controller set its reach and pull flags have been studied but not
implemented. Eventually the functionality of the virtual controllers will be off loaded to
board computers, letting the PC handle higher level behaviors, and letting the board
computers control the mechanics of moving.
Biological
As discussed earlier, the basic proportions of the robot skeleton were derived from
measurements, anatomical drawings and photographs. Figure 14 below is photograph of
a cat skeleton.
15
Figure 14. Cat skeleton. Note the likeness of the proportions to the mockup in figures 1
through 3 and the original prototype in figure 6.
Summary of Current Work
The mock-up, and the two prototypes Mickey and Stubby, have been invaluable research
tools. With these prototypes, experience has been gained in several different areas,
including:






Materials selection, handling, and fabrication.
Actuator selection and integration.
Electronics interfacing and control.
Sensor fusion.
Algorithm design, gait creation, selection, and control.
Systems integration.
With Stubby, the project has a walking prototype from which to build on. Further work
with Stubby includes integration of sensor inputs, adaptation of walking movements, and
adaptation of the timing of the walking movements. These technologies and procedures
will carry over into the development of the next prototype and finally to the finished
product, the LSU Robo-Tiger.
Together, the prototypes have shown that the mechanical and software design processes
go hand in hand during research and development. Static and dynamic stability as well as
power to weight ratio are also extremely important. Taking cues from biology at the
functional and conceptual level, at the very least, has been a great help. The architecture
of the control system is an excellent example of this.
16
Relevance
Although the Robo-Tiger will be primary used at school athletic functions, the
technologies integrated, applied and created will have exciting and cutting edge
applications in a wide variety of real world situations.
One area of special interest is adaptive control. By nature, the environment of the
football field is unstructured. To look and act in a realistic manner, the Robo-Tiger will
have to adapt to a variety of different field conditions. For example, walking a set pattern
in the lab will probably not work on the field where traction conditions are completely
different and navigation around obstacles may be required. Movements will be able to be
choreographed to some degree, but not in strict sense. One of the main goals of the
design team is not to have to carry the tiger off the field. To make the tiger act in a
realistic manner is going to require integration of low level mechanical control, adaptive
control, and at the highest level, sensor/situation driven adaptation of behaviors.
The subsumption based control architecture that Stubby uses is the ideal foundation for
building the functionality of the robot. Because it is a layered, hierarchical approach, its
capabilities can be extended one piece at a time. Complexity it achieved by adding layers
without disturbing the layers below. New layers are not added until the existing layers
are working well. Thus, behaviors are arranged in hierarchies, with the simplest levels at
the bottom and the more complex activites on the top. The lower layers continue to
operate, unaware of the layers above them.
Another area of interest is in actuator design. Currently most robots use mechanical
actuators that are driven electrically, pneumatically, or with hydraulics. Each of these
methodologies has it advantages and disadvantages, but biological muscles have a the
distinct advantage in that they are quiet. A real tiger, or any animal that relied upon
stealth for purposes of pursuit or evasion would not survive its muscles were whining or
hissing like the mechanical muscles do.
However, in the recent years significant breakthroughs have taken place in smart
materials that change shape and exert force under chemical or electrical stimuli.
Moreover, such changes are reversible, i.e electrical field or potential is generated when
the material is deformed. The materials are collectively known as artificial muscles.
Notable species of such artificial muscles include the Ionic-polymer Metal Composite
(IPMC) material developed at the University of New Mexico, the carbon Nanotube
material developed by the Alliedsignal Inc., Electrostrictive Polymers developed by the
SRI International, Electroactive Polymers (EAP) developed at NASA JPL, and the
polymer Hydrogel developed at MIT.
It has been demonstrated that some of these materials possess force density and response
time equal or exceeding natural muscles. Therefore they have great potential to become
viable robotic actuators. Indeed, a boat propelled by a waving fin, a pair of waving wings
and a full-size skeleton bicycle rider driven by IPMC muscles have been built and
demonstrated at the Artificial Muscle Research Institute of University of New Mexico.
NASA JPL has also demonstrated robot grippers and wipers using the EAP muscles.
17
The reversible change of the polymer type artificial muscles also make them effective
sensors, jut like natural muscles. The collection of the sensor and actuator is a highly
desirable feature for feedback motion control, as it eliminates transport delay in the
feedback loop, thereby increasing the bandwidth (reducing response time) and domain of
stability.
While the feasibility of using IPMC type of artificial muscles as robotic actuators have
been demonstrated, research is needed in learning the dynamic properties and motion
control of such materials before they can be used to produce fine coordinated robotic
motions. The dynamics of these materials are inherently nonlinear, distributed and
elusive to mathematical modeling and conventional motion control algorithms. The
distributed sensory and coordinated motions also call for a hierarchical and massively
parallel control system involving higher level intelligence (logical reasoning performed
by the frontal lobe and the motor lobe of the cortex) for motion planning and lower level
intelligence (reflexive decision and control performed by the cerebellum) for agile and
stable actuation.
Practical Applications
Here we outline three concrete applications which can draw directly from the systems
and technologies developed for the Robo-Tiger.
Walking stretcher.
In the unstructured environments battlefields, natural disasters, etc., medical personal
struggle against time, fatigue, and harsh conditions in an attempt to save lives. Getting
injured personnel to safety can be work intensive, especially in rough terrain. In order to
evacuate one injured man, at least two men are required to give emergency care and
transport him to where he can more closely attended to. Using technology similar to that
used to create the Robo-Tiger, a walking stretcher, or robotic pack animal could be
created. When a man became injured in the field during an exercise or combat, the medic
would lead the walking stretcher to the man. After examination and application of the
necessary medicines, the injured man would be loaded onto the stretcher, and it could be
led back to the safety of the field hospital, or even make the return trip autonomously.
Medical equipment such as IV’s and small monitoring equipment could be integral to the
stretcher. A device such as this would free up manpower, and may well save lives by
lessening exposure to risk, and by keeping the injured more comfortable during their trip
back to safety.
Stealthy Robotic Squirrel.
A squirrel sized sensing platform using silent actuators based on the IPMC technology
discussed earlier could be used to crawl into buildings and transmit data back to a base
station. In order to keep the package size small, the robots would be programmed to seek
out power cables in an attempt to augment their power supplies.
18
Fire Fighting Robotic Ants
Using a platform similar to that of the walking stretcher, these autonomous robots would
be programmed to work in teams, like ants do, to put out fires in unstructured, hazardous
environments, such as nuclear power plant, hazardous waste depots, or on ships. While
various tracked and wheeled robots have been to some degree in this application, legged
robots would have a distinct advantage if they were taught to climb. Environments like a
burning ship or chemical factory could be attacked much more effectively and with less
risk to humans because the robots would have the ability to detect, seek out, and attack
the blaze. With bodies similar to fire extinguisher tanks, and four or six legs the robots
would work in teams to fight fires. Extra power to operate and recharge the robots could
be drawn directly from the blaze itself, via a Sterling engine or some other heat engine
system.
19
References
[1]
J. Zhu and W. Xaio “Intelligent control of time-varying dynamical systems using
CMAC artificial neural network,” Mathematical and Computer Modeling Journal,
Special Issue on neural networks, vol. 21, no. ½, 89-107, 1995.
[2]
J. Zhu and M. C. Mickle, “Missile autopilot design using a new linear timevarying control technique,” AIAA Journal on Guidance, Control and Dynamics, vol. 20,
no. 1, 150-157, Jan. 1997.
[3]
J. Zhu, “Nonlinear tracking and decoupling by trajectory linearization,” a 12-hour
lecture with pp. 137. Lecture note presented at NASA Marshall Space Flight Center,
Huntsville, AL, Grant No. NASA/LEQSF (96-01)-01, May 1, 1998-April 30, 1999.
[4]
M.C Mickel and J. Zhu, “Bank-To-Turn Roll-Yaw-Pitch Autopilot Design Using
Dynamic Nonlinear Inversion and PD-eigenvalue assignment,” Proceedings, 2000
American Control Conference, Chicago, IL, to appear, June 2000.
[5]
J. Zhu, Brad D. Banker and Charles E. Hall, “X-33 Ascent Flight Controller
Design By Trajectory Linearization – A Singular Perturbational Approach,” Proceedings,
AIAA Guidance, Navigation and Control Conference, Denver, CO, to appear, August,
2000.
Simon Haykin; Neural Networks, A Comprehensive Foundation, Macmillan, NewYork,
1994
David H. Freedman; Brainmakers, Simon & Schuster, NewYork, 1994
S. Sitharama Iyengar and Alberto Elfes; Autonomous Mobile Robots Perception,
Mapping, and Navigation, IEEE Computer Society Press, Los Alamitos, CA.
S. Sitharama Iyengar and Alberto Elfes; Autonomous Mobile Robots Control, Planning
and Architecture, IEEE Computer Society Press, Los Alamitos, CA.
Claus Emmeche; The Garden in the Machine, Princeton University Press, Princeton, New
Jersey, 1994
Ralph H. Petrucci; General Chemistry, Principles and Modern Applications, Second
Edition, Macmillan, NewYork, 1977
Jacek M. Zurada; Introduction to Artificial Neural Systems, West Publishing Company,
St. Paul, Mn., 1992
Stephen Prata, Artificial Life Playhouse: Evolution at your Fingertips, Waite Group
Press, Corte Madera, Ca, 1993
Beckers R., Deneubourg J.L. and S. Goss (1992). Trails and U-turns in the selection of
the shortest path by the ant Lasius niger. Journal of theoretical biology,
159, 397-415.
20
Goss. S., Aron. S., Deneubourg J.L. and J.M. Pasteels (1989). Self-organized shortcuts in
the Argentine ant. Naturwissenschaften 76, 579-581.
Free On Line Dictionary of Computing; http://foldoc.doc.ic.ac.uk/foldoc/index.html
Kevin Kelly, Out Of Control, Perseus Books, 1994
21