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 through 3, the mockup is shown in various positions typical of cats Figure Mockup in sitting position Figure Mockup in resting position Figure 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 not produce an overwhelming amount of torque The standard Fujitsu type RC servos like we used 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 and below detail the construction of Mickey’s legs Figure 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 Rear leg of Mickey It is obvious from figure that the servo mounted on the rear hip of the robot will be working hard to lift the servos in the rear leg Figure shows a side view of the completed robot, Mickey Figure 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 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 below shows a view of Stubby sporting its tiger markings Figure 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 outputs rated at 250 ma and inputs that could be read as digital or analog with 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 below Figure 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 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 byte code down the serial line The command structure is as follows Byte Byte Byte