Back to Top
The most frustrating part of the course was realizing that all the clichés regarding simplicity are, in fact, true. Everyone takes implementation for granted, but it needs to constrain your strategic options early on in the course. For example, we figured we could build a robot capable of color sensing each ball, but this turned out to be very difficult. We and the teams who got far all ended up using passive ball sorting based on initial ball location.
The following sections detail aspects of our robot which we hope you will find helpful.
Design Overview
Strategy
Code
Results and Advice
Please see the pictures at the end of the page if you're interested.
The design was driven by the need to quickly capture and move small (1-2" diameter balls) around the table. Thus, the entire underside of the robot was kept clear so that up to all the balls (22) of one color, green or red, could be carried around at once. To capture balls, a simple intake was designed as far forward as possible: six of the fatter, smaller lego wheels were strung together on a series of long cross-bars. The spacing between the wheels and the distance of the intake assembly above the ground were carefully matched. Thus, when the intake spun one way, balls were sucked in under the wheels. Balls were shot out, although not at high velocity, when the intake was driven the other way. Simply driving over a set of balls with the intake in "pull" mode was sufficient to suck the balls in like a vacuum.
Our strategy, explained below, placed a high emphasis on speed, so a low 25:1 gear ratio was chosen at first. This led to a very fast robot, but it was very difficult to control (controllability is the hardest part of 6.270!). It would take a long time for a motor to spool up, and due to the low gear ratio, the robot would coast - setting the motor speed to 0 was a poor brake. Because of this, we simply doubled up the motors by directly putting another standard motor over the already present ones (one had a 16-tooth gear on the shaft, the original had an 8-tooth gear). The controllability of the bot improved considerably.
The gyro was used to turn. We were able to modify the gyro turning code such that our turns were really fast and crisp, with a small correction period at the end (consisted of "bumping" the robot in increments and sleeping for a short time to check whether or not the orientation was within the desired threshold). For distance control, a shaft encoder was used. We experimentally determined a "clicks per distance unit" ratio.
The most notable part of our design was the driven caster. It was a small wheel at the back of the robot which was driven by a servo. To go straight, it was kept parallel to the other wheels (straight); to turn, the servo rotated the caster 90 degrees. This really helped our steering, since our differential drive did not have to be exactly right for the robot to travel in a straight line. Also, it ensured that we could pivot the bot without having it translate. By the end of the course, we even had implemented a "servo turn" which was a sweeping arc created by turning the servo slightly in one direction, then giving differential speeds to the drive motors.
Design Overview
Strategy
Code
Results and Advice
Our strategy was seriously the bomb, but it bombed becuase of a bug. While almost all other robots quickly scored 2 points by pushing in the 4 "easy" balls at the beginning, we took advantage of this time to dart over to their side of the table and steal all their balls of a certain color. Then, on the way back, our robot was supposed to overshoot the voting booth to grab 2 extra balls in addition to the 8 from their side, then do a sweeping servo arc turn back to be in front of the voting booth. To vote, it turned its intake on "push" mode and slammed the booth a few times to ensure all balls went into the voting booth, then it backed up enough to turn back "home." It was then meant to capture all remaining 6 balls on our side plus the 4 "easy" balls on the way back to the scoring area nearest to our starting position.
Thus, the final score should have always been 14 to negative whatever. Even if the other robot decided to go the same way (towards the same color) that we originally wanted to visit, we would stop, turn 180 degrees, and retreat to the other side of the board because we were using RF position data to ensure that we wouldn't hit the enemy on the first risky move into their area. The problem is that we came up with this variation of the strategy about 2.5 hours before impounding and did not get a chance to make sure every preprogrammed distance was the right length. On the ONE distance that we guessed on because we ran out of time, we guessed wrong. This caused to robot to be too far away from the voting booth before voting; thus, on its sweeping arc turn to get into vote position, it was not able to acheive the right orientation because it hit the barrier in the middle of the board. This screwed up everything after that move. Aaaaaaah.
Design Overview
Strategy
Code
Results and Advice
The following .c files were all loaded onto the HandyBoard using a .lis file:
team13ballhandle.c
team13constants.c
team13gyro.c
team13init.c
team13main.c
team13mcgruff.c
team13misc.c
team13movement.c
team13strategy.c
Design Overview
Strategy
Code
Results and Advice
Using a hasty, unfinished strategy unlike the one described above, our robot qualified to be the fifth seed overall going into the final day of competition. It was clearly a frontrunner, but the aforementioned bug was our demise.
The first loss we incurred was actually due to a sensor problem in Kresge - we must have been casting a shadow during sensor calibration. The sensors are used to determine initial orientation, so our robot basically was useless once the round started. We still felt we had a chance to win despite the first loss by being careful about the calibration, so it was on to the next round.
Here, unfortunately, was where we noticed the bug in the code. After capturing almost all intended balls for voting, the bot was clearly too far away from the voting booth wall. We were nervous, and for good reason: the next move, a backwards, arcing turn, ran the robot straight into the central barrier (bad). The funny thing is that we would have easily defeated both of our opponents had the robot executed its intended path correctly. We took a risk by not testing the final code change, and we paid the price. However, we do encourage taking risks - our whole strategy was a crazy one, and we feel confident that it would have worked had we just not messed up that one line of code.
In conclusion:
-Finish your robot as soon as possible so you can practice the actual execution of your strategy.
-Don't make it too mechanically complicated.
-You are limited in terms of lines of code, so watch out and don't come up with insanely detailed strategies.
-Perfect the driving straight and turning functionality of your robot before moving on to strategy execution.
-Keep track of battery charge!!! It really matters in terms of robot driving qualities. We used a voltage divider and an analog port to keep track of the Hawker batteries' charge through the HandyBoard.
-Don't hog the practice tables and steal people's ideas because others will tend to dislike you, and it's much more fun if you make friends with the other teams.
Back to Top