[Peter Matteson]

Originally Posted by Siri

In the past, our major problem with brainstorming was that we just didn't spend enough time on it. Often we'd skip right over considering the game and strategy straight to robot design, and even then not really plan what we were trying to achieve. (Note: always set and document quantifiable/testable requirements. Always. And then work to them. ) We're working on it and are going to hold a practice kickoff soon with a different game to practice what we've learned.

Originally Posted by Basel A

One issue we've had is jumping into design before strategy is decided. There's usually several ways to implement a strategy, so limiting yourself to a single design generally isn't the way to go.

Highlighted from these two posts to say I think this is the problem I've seen most frequently with teams over my tenure in FIRST. You need to figure out what you have to do before you tried to build it.

Also there is a point where you have to start cutting chips so you can get something together for testing. Even if it doesn't work the way you intended you will learn from the failure and be able to move on to something that works better.

Shameless copying of mechanisms that did something well in the past that you need to accomplish tasks for this years game is encouraged. Why reinvent something when you have a solution that works well. I can point out 2-3 mechanism variations that we use almost every year on my team because they are ready solutions in our arsenal that we know will be reliable.

Finally reliability is king. Never underestimate the value of not breaking in the middle of a match/elimination tourney/regional. It takes 20-25 matches to win the championship 10-15 of which are in the elimination tournament alone. Assume you have to do this with minimal maintainence to be competitive, because you can't play if you don't get out to the field everytime.