About Our Robot

Structure

Our robot used almost every lego piece in the kit. By the end of construction we had 4 one by two beams left, a few miscellaneous plates, and a big chunk of robot lego. With a 10 by 11 inch base and an average height of 7 inches, our robot fit easily within the contest qualification box. As you can imagine, this ment that our robot was almost solid lego, and as such, it never broke or came apart, even when rammed.
An arm mounted on the back of the robot lowered to catch one ball, and a set of three wheel pairs running up the back could be driven to lift the ball over the edge of the tabel. Our other neat feature was a radar, which spun at the front of the robot, looking down on the playing court.

Drive System

We are very proud of our drive system. It is the only thing which actually worked correctly, and we spent the first half of the class tweaking it. Using four-wheel drive with front two-wheel independant steering, our robot was able to turn about any point on its rear axis quickly, and without much slippage. A gear ratio of 45 to 1 kept our robot fast, and with the use of 4 motors it had the power to move it's heavy frame, as well as shove balls over the court edge.

Electronics

In addition to the 4 motors and 2 servos for the drive system, our robot used one servo for the arm, and a motor each for the ball-lifting-wheels and radar. A circular potentiometer measured the angle of the arm and radar. Other sensors employed include: two breakbeam sensors on the rear wheels; two rear mounted distance sensors for ball location, one on each side of the arm; a distance sensor mounted on a lego steering wheel as a radar; four light sensors on the bottom of the robot to determine starting orientation; a light sensor in the center of the robot to detect the start light; two touch sensors, one on each of the back corners, for rear wall alignment; a touch sensor on the back to detect if we have caught the ball; and the IR beacon/ detector which each robot must be equipped with.

Code

We designed a navigation system for our robot, which (at least in theory) gave our robot's location coordinates (measured in inches) relative to the board center. At startup we assigned our robot a location of (0,-18), and an angle pased on cds cell readings of starting location. We then used break beam sensors and wheel angle to update our position during the contest. The breakbeams were also used extensivly to help our robot drive straight and to check turn angles. As an additional check of turn angle, our robot was able to align itself up with the wall behind it and reset it's angle.

If you are interested, please take a look at our code:
align.c   arm.c   ball.c   cds.c   main.c   main.c   misc.c   motor.c   move.c   move_to.c   nav.c   orient.c   qtrig.c   radar.c   servo.c  

Strategy

Our robot had a very simple strategy: drive into the opponent's court, find a ball, try to drag it to our side, and if that fails, toss it off the edge. Although we had grand aspirations of using the location of the other robot to determine appropriot strategy, time, physical, and memory constraints limited our ability to do so.

Expectations vs Realizations

Well, our robot lost both of it's first competitions, and was, therefor, not elibible to compete in the final round. We ran into a number of problems with our robot design, mostly resulting from overambition and a heavy dose of perfectionist tendencies. This is why our robot is basically a lesson in:

How Not To...

Our first mistake was assuming that a well built robot was the most important design feature. As shown in the contest, the best robots are not the sturdy ones, but rather the ones with the best strategy. By focusing all of our energy on building a sturdy robot with an excellent drive system, we ran out of time and legos when it came to strategy components. Most notably, our tiny arm which caught one ball was no match for the giant armed robots which carried up to 4 balls at once.
Our second big mistake was overcoding. The handyboard was simply insufficient for the code that we envisioned. We overfilled it early on, and had to continually cut down our navigation code to make room for strategy. In fact, although we built and began coding for the radar, there simply wasn't enough memory left to make the radar useful. We simply programmed it to turn back and forth during the contest and look cool.
And the third, and most fundamental big mistake? Ignoring the playing field. All the succesful mobile robots in the game used wall following to guide themselves, however the structure of our front wheel drive system made wall following impossible for us to impliment. Our nav system worked very well (1 inch accuracy) on flat surfaces, however during the game, the slanted playing court proved a problem for our robot. When the robot hit the grove at an angle, one back wheel would sometimes spin in the air for a few cycles, causing our robot to think that it had turned. Thus, although our robot maneuvers beautifully on flat surfaces, it freqently gets lost on the playing court.

How we named the robot...

We realized about halfway through the coding that our robot would have difficulty in the competition. As the deadline got closer, we continued to lament our over-coding, but were in to deep to back out and re-code everything. We decided to give our robot an upbeat name, hoping to encourage it to do better. The supposedly random winamp player which entertained us during construction called up "Shiny Happy People" three times in one night, dispite 6 gigs of songs to choose from, and so we named the robot "Shiny Happy Robot." The "a.k.a. KAMIKAZE" comes from our final night of coding, when in an act of desperation, we programmed the robot's final strategy- make a mad "kamikaze" dash for the ball. Given our robot's tendency to get lost, it seemed that sending it blissfully into competition was a bit of a suicide trip, and so "Shiny Happy Robot, a.k.a. KAMIKAZE" seemed the perfectly ironical name.