Revision as of 20:54, 3 February 2013

Overall Strategy

Our strategy for this game was to collect as many balls as possible and then score all of them in the last minute by shooting them into the tower or over the yellow wall, whichever one it saw first. However, we built our robot such that it was tall enough to score into the blue tower for 50 points, in the event the robot did aim for the tower. We originally were going to just aim for the blue tower, because we thought the middle tower would have a large capacity. But, when we found out that the blue tier could only fit four or five, we started aiming for the yellow wall as well, because that offered more points than scoring in the purple tier would. If we had enough time, we would have optimized the code to score balls in the top two tiers, and then the rest over the wall. However, we didn't have time to get that running. We also anticipated that our robot would have a much larger capacity than the other robots, which ended up being kind of true, so our strategy involved pressing the cyan button to put as many balls on the field as possible. We also thought that clearing the field would be a good strategy, but figured it would be difficult to do reliably, especially if there was a ball in a relatively isolated location that the robot never got to. Though we would have mechanisms to theoretically find all the balls, it might have taken a long time. Also, since the button released the balls in small area, theoretically, it would not have been difficult to pick up all of those balls in the area and then move on.

Mechanical Design

Drive System

In order to maximize the amount of traction we could get on carpet, we made ridiculously dangerous wheels with spikes. However, the field was changed to a black foam, and our wheels would have destroyed it. Therefore, we put tape around the circumference of our wheels, and that seemed to do the trick. However, sometimes the robot got stuck in small kinks on the field (like where the pieces of foam came together), and sometimes didn't seem to move terribly well on the foam.

Rubber Band Pick Up System

In previous years, this design seemed to work well. For other teams, this design seemed to work relatively well too. This was actually the system we had the most trouble with. The first time, the roller was too low, and the balls jammed the roller. In fact, it ruined our first motor. The second time, the roller was too high, and the balls didn't grip the balls enough. The third time, we finally got the height about right, even though we had to add zip-ties to help grab the balls and kick them into the tower system that lifted the balls. Unfortunately, though the zip-ties helped us out, they also sometimes caused the motor to jam when picking up the balls. Additionally, the roller seemed to stall when picking up multiple balls at once.

Double Helical Brush Lift System

Deoxyrobonucleic acid :P

Shooting Bridge

Four-point joint thing??

Software

Architecture

Vision

FSM

Our finite state machine had two basic states: the exploring/ball collection state, and the scoring state. Within these two basic states, we had "substates" that would mostly control the behavior of the robot. We first sketched out our state machine, which essentially looked like this... [insert picture of state machine]

So in summary, the robot first looked around for balls by turning around on the spot, and if it saw any, it would chase them down. If it didn't, the robot would go wall follow until it saw another ball, or for 15 seconds passed, after which it would scan over the field again. If the robot saw the button, then we would aim for it, as if it were a ball, and ram into it four times consecutively (turns out there was a 20 second delay on it, so it would have been more effective to collect the released balls first). We continued doing that for the first two minutes. In the third minute, the robot searched for the yellow wall or the yellow box in the tower, aligned itself, and then released the balls that were sitting in the tower. After it tried scoring, it would look around and search for any balls (to find the ones that missed the tower or failed to go over the wall), and then try to shoot again with 10 seconds remaining.

We threaded all of our sensors so that they would continuously be updated and set flags as true or false, which would in turn be read by the state machine. At first, some of us were afraid that having so many threads would slow down the processing, but it turns out that it didn't actually affect it too much. On the other hand, it didn't seem to give us any more of an advantage, except for the fact we didn't have to hard code checking the sensors in every state.

Scoring

Because we were able to see the yellow wall from the tower and align to that, we decided to only search for yellow when scoring. Unfortunately, that meant the robot would be more likely to go for the yellow wall because of its larger size, but if we had enough balls that would be okay.

In terms of aligning to the tower and the yellow wall, we simply used PID control to target the center of the wall, and then have it drive towards it until it triggered a bump sensor. Unfortunately, relying only on the bump sensors meant that the robot couldn't bump into any other wall before hand, or else it would dump the balls prematurely.

Modularity

The advantage of having sensor code, vision code, and the finite state machine in different places was the modularity of how the robot was going to behave. This was particularly useful for the mock competitions, so we could work on coding for the final competition, but still have our robot function minimally even if not everything was working at the moment.

We also wrote simple test modules, which would allow us to test our sensors and motors quickly. That proved to be extremely useful before and during the competition to make sure everything was functioning.

Placing in the Mock Competitions

The only reason why we got second place is because we didn't have to face the Mengineers (Team 3) earlier in the game. And that's because neither of us seeded particularly well, and we were worse than they were.

Problems Encountered

Mechanical Design

Electronics

Bump sensors are difficult to make reliable. If they are not properly fixed onto the robot, they can be pushed but not be triggered. Also, most provide small coverage, making it a matter of chance that when the robot hits the wall it will actually hit the bump sensor. We tried adding extensions to our whisker bump sensors, and repositioned them many any times. Only after many iterations, and securely attaching the sensors onto the robot the day before the competition did they work reasonably well (until we accidentally broke one off right before our final match >.>). Note that bump sensors need a pull down resistor (essentially a resistor in series) in order to work probably.

We also soldered connections onto the Arduino shields in order to make better, more reliable, and more permanent electronic connections from our sensors to the Arduino. However, in addition to its benefits, there were its own problems, probably resulting from inexpert soldering...

Code

During the Competition

Hindsight is 20/20