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

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.

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 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.

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 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, 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 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 Byte 2 Byte 3

<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 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 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 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.