Over the course of the class we toyed around with all sorts of programs, producing more implementations of the code than you could shake a stick at. This, though, describes only the polished, stripped-down code that we used for the contest.

Before the robot was placed on the board, we would decide which strategy to use. We basically had three options to choose from, and they all revolved around one central strategy: get the block and end the game as quickly as possible. The “standard” strategy was to go forward, swiping the card once on the way, retrieve the block, back up and swipe the card twice more to end the game. Optionally, we could set a delay, so that the robot would wait at the start before moving, giving enemy bots time to get out of our way. The “wait-at-the-wall” strategy got the block as usual and waited at the wall for a few seconds before ending the game (to block the path of a significantly faster robot). Finally, the “mayhem” strategy got the block as usual and instead of ending the game as quickly as possible, simply went full speed back and forth between the two walls, hopefully catching the other robot and ramming it to pieces. As it turns out, we never used the last strategy, but it’s included in the code anyway.


Abstract code description:

When the robot is first powered on, it checks the dipswitches and RoboKnob to determine what side of the board it is on, what strategy to use, and how long of a delay to use (if applicable). After pushing the choose button, it begins searching for the start light. After the game starts, it waits for the preset delay (if using the standard strategy), goes forward, gets the block, waits for the set time (if using the wait-at-the-wall strategy), backs up and then reverses direction over and over to swipe the card at least twice more and end the game.


Technical (i.e. boring) description

When we placed the bot on the board, we selected one of the three strategies using the last three dipswitches. In addition, we used the first dipswitch to set which side of the board we were on (although this didn’t matter at all to us, it was used to set the transmit frequency of our IR beacon). When the robot is first turned on, it checks the value of the dipswitches – since they represent a 4-bit binary number, if the first switch is set (indicating we are on the black side), the decimal equivalent will be greater than 8. If the first switch is off, it must be less than 8. The first few lines of the code check this and set the IR beacon appropriately. After turning on the IR beacon, it allows us to set the delay for the strategy using the RoboKnob. Since the RoboKnob produces an integer between 0 and 255, it was simply a matter of dividing by ten and converting to a floating-point number to produce a delay anywhere from 0 to 25.5 seconds. It displays the value on the LCD, and when we get the delay we want, we hit the choose button to start the main program. After this point, the robot is autonomous. It checks the value of the dipswitches and goes to the appropriate function to initialize the strategy. The functions “strat0()” – “strat10()” display the name of the strategy on the LCD, so we can double check that we have the right strategy, set the variable “final” used to keep track of the strategy later in the program to either “s”, “w”, or “m” (for standard, W-A-W, or mayhem), and then proceed to the main function, quickwin(). This function waits until the light sensor reaches a certain threshold (indicating the start light) and beeps when it finds it to tell us the program is now running. It checks the value of the variable “final”, and if we are using the standard strategy, waits for the specified delay. After this, it starts to go forward, using a simple counter to keep track of how long it takes to get to the wall. This is very important later on. When it hits the wall, the mercury switch trips, stopping the motors and dropping the arm, and then retracting the arm once it has the block. At this point, the code gets kind of complicated. It checks the value of “final,” and if we are not using the WAW strategy, it simply reverses and backs up, decrementing the counter until it reaches zero. (This use of the counter ensures that we back up to the same position every time, regardless of battery level, accumulated wear-and-tear, etc) If we are using the WAW strategy, however, it makes a duplicate of the counter variable, and begins decrementing that without reversing. The purpose of this is to allow the arm to retract the exact same way it would if the robot were backing up. This whole process usually takes around 1.25 seconds, so after the counter is up and the arm stops retracting, it then waits for the remainder of the set delay (i.e. the delay minus 1.25 seconds). After the delay runs out, the function then goes on as usual, using the counter variable to back up to its original position (and then some, just to be safe). At this point, the program branches, depending on the strategy we are using. If we are using one of the first two strategies, which have the same ending, it goes to standard_final(), which cause the robot to go back and forth several times until the game ends. If we are using the mayhem strategy, it performs a much exaggerated version of the same strategy a set number of times.

And then…well, we win.