Robo-Kitty, Details of the Construction and Programming of the LSU Robo-Tiger

Therefore, neither Mickey nor the second prototype, Stubby, would be able to reach across their bodies.. Using the body of the RC servo as part of the bone, the limbs and joints were ass

Robo-Kitty, Details of the Construction and

Programming of the LSU Robo-Tiger

Patrick McDowellLouisiana 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 thatcan 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 LSUComputer 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 Theoriginal 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

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

Figure 1 Mockup in sitting position.

Figure 2 Mockup in resting position.

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

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 overwhelmingamount 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 Thismethod 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

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

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 fewsteps 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,

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 Stubbycan 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 boardcould simultaneously control the position, speed and acceleration of up to 16 standard RCservos 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

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

<sync marker (255)> <servo # (0 – 254)> <position (0 – 254)

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 finefor 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 robotwalk, 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

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 upperright 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 strokeluck to get good results The torque problem also made it so that as the cat walked, it wasdifficult if not impossible to get it back to a standing position The legs would simply getmore 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

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 randomnumbers, 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 mutationfactor 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 fromthe 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 Butconsidering 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?

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 thereach 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 itwould 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.viprogram Note the gait control flags in the lower center of the screen