Team Ten/Final Paper

Team: Faith-Based Robotics Members: Eben Freeman, Daivon Deans, Veronica Lane, Jonah Baskerville Robot: Reality Check

Overview

--We originally set out to build a robot that would collect all the balls on our field, store them until the end of the match, and then shoot them into the green box with a tennis ball machine-style launcher. We realized pretty quickly that precision shooting was kinda pointless given that there was a low chance of balls being returned in the last 15 seconds or so of the match. We eventually opted for a gated hopper that let gravity roll the balls into the far field to score big money. But then we were plagued by a failure of a roller, and a robot that couldn't score balls. We spent three frantic days getting rid of the hopper and roller, adding a four-bar linkage and a box with which to lift balls up and over into the other field. Our robot, Reality Check, served as stark contrast to our team's nigh unbeara-- err, unbeatable optimism. Born of acrylic, lego, and frustration, RC reminded us of the soul-crushingly inescapable, despair-filled void that is reality. But I'm getting ahead of myself...

Mechanical/Hardware Design

--As our plans solidified, we opted for a rectangular footprint with rounded corners. Our robot had enough ground clearance that balls could fit underneath, and the front had a "skirt" made of lego pieces that would swing to let balls in, but not out. This design was motivated by the simplicity of not using a roller or something similar, which would've been more expensive and require unnecessary work. At the back of our robot was a small metal box that would collect a few balls as our robot moved. A ziptie-covered roller kept the balls from leaking out. When the yellow wall was found, RC would get close to it, lift the box, and dump the balls on the other side. We ended up using three short-range IR sensors (one on the front, two on the sides), to allow our bot to follow walls and avoid obstacles. Four bump sensors covering the corners of RC helped him to not be stuck so much. Reality Check won't be the winning girl in any beauty pageant, but at least he's got what he needs to get by.

Software Design

We went with a finite state machine, which contained: random walk, wall follow, turn-towards-ball, drive-towards-ball, turn-towards-wall, drive-towards-wall, and dump states. We opted to do vision processing entirely on the eeepc, and handle the other sensor readings and logic on the arduino. This turned out to be a lot more challenging than we anticipated. Programming in C++ was a real treat all by itself, but as it so happened, programming on the arduino in C++ was even more of an adventure. Many sleepless nights were had, and at least one member of our team is probably going to gray a little early...

Overall Performance

While our robot seemed to be developing nicely, we found ourselves get behind. Mock 1 made us realize that we needed to pick up the pace a little. By mock 2, however, we still found that things weren't going so well. A big problem was that we weren't able to do enough testing. We had a great robot in theory, but it was taking us too long to get all the pieces together and run it in practice. When we did, we found that our initial strategy wasn't going to work, and while we managed to recover from this, it put us at a pretty big disadvantage as far as combining the mechanical and software components goes. The competition was rather exciting. About an hour before everything started, Eben noticed that one of the wires from our battery had snapped. We ran back to the lab and did some last minute soldering, and then ran back down and competed. Everything except scoring sorta worked, which was fine until the set screws on one of our motors came loose. Somehow, we managed a tie (even though we both went way overtime and RC drove in circles) both rounds. We collected a few balls, but ultimately, it was the cheesecake Team 5 had put on their robot that decided the match. For the first time in maslab history, we got a little kid from the audience to weigh our robots, and theirs was morbidly obese... After our first win, we ran around frantically looking for a way to fix our ailing robot. Long story short: we did. Then we got stomped on by the team that would ultimately win the competition... :D Overall, maslab was a lot of fun. Things were stressful when it got down to the wire (heh heh, so punny), but that was just a part of the experience. In the end, we all learned a lot, built a robot, and got free stuff. Time well spent, I'd say.

Future Suggestions

1) Try to get as much of the design finalized before IAP even starts. We had no prior idea about what our robot should look like, and our design ended up being pretty slow (as in, we didn't have a finished, working robot until well into "fail week").

2) Try to create a balanced team. Having two coders and two builders is a pretty solid strategy (three coders and an experienced builder is even better). We had one person write all of the code, and programming an autonomous robot is a pretty meaty problem for anybody to solve on their own.

3) Good communication is essential. Making sure everyone is up to date with the robot on both fronts is a great way to ensure that everything proceeds smoothly and unforeseen setbacks are dealt with promptly.

4) Avoid overloading your robot with extra stuff. While a robot with crazy localization and mapping abilities is pretty neat, great localization is only marginally more effective than decent random walking in this competition. It's safer to pull together working versions of the things you'll need before you go off building that dalek...

5) Do fun stuff on the side! My single greatest regret was not going out to eat more often. Building the robot and working late at lab was fun in its own way, but so is randomly going out and getting sushi with everybody. Make sure you mix it up a little!

6) Prototyping is your friend. Even if you have a design already laid out, chances are, something is not going to work right. It's a whole lot better to spend a day discovering the hang-ups in your strategy and discussing them, than to go a week (or two) not knowing that they're actually there.