Team Ten/Final Paper
Team: Faith-Based Robotics
Members: Eben Freeman, Daivon Deans, Veronica Lane, Jonah Baskerville
Robot: Reality Check
Contents |
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. However, in retrospect, a round, two-wheeled robot with a front-mounted box would have been more maneuverable and less apt to get stuck in corners on the field. 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 ran vision processing on the eeePC and everything else on the arduino. This was a simple and effective approach which we would recommend to future teams. Running the robot's control logic on the arduino meant that we pretty much only needed to send data in one direction over the serial connection. It also allowed us to eschew multithreading. This made coding, testing and debugging easier. Vision processing was simple: we thresholded the image to find red and yellow segments, then ran a blob-finding algorithm for each color, selected the best blobs and sent their coordinates to the arduino. We positioned the camera on the robot so that it could pretty much only see the field. This meant that we didn't have to distinguish between on- and off-field parts of the image. Our vision code had less than 200 lines but worked just fine. We ran a finite state machine on the arduino with six states: random walk, left wall follow, right wall follow, drive-towards-ball, drive-towards-wall, and dump balls. Each state had a preset timeout, after which the robot would revert to random walk, in order to avoid becoming stalled in a particular state.
For those with no arduino experience: beware that not all the features of C++ are supported. (Yes, we learned this the hard way.) Avoid trying to use RTTI, polymorphism, and new/delete.
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
- 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"). You should aim to have your robot essentially built by the end of the first week.
- Familiarize yourself with useful software before IAP: ssh, svn, the Arduino IDE, opencv or the vision processing library of your choice. Work on your software before IAP starts. Get an arduino and play with it if you don't have prior experience using them.
- Get started before IAP. Have we mentioned that already? Make a schedule, keep perspective on how you are progressing, and stick with it. Don't even think about falling behind schedule.
- Don't depend on Maslab for tools, parts, machining, etc. Take advantage of places such as the Hobby Shop, MITERS, Edgerton as necessary.
- 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.
- 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.
- 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...
- 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!
- 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.
- Work hard, learn a lot, enjoy!
