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