[Alex.q]

I know almost nothing about your team, so I can't give comments directly to your situation, but I will describe ours this past year. We are one of if not the largwest FRC team in Minnesota with about 50 kids that show up on a regular basis. Every year it seems we have re-structured our build plan and leadership. This past year, we considered the same idea with two different robots, and decided it would be a lot of wasted effort because much of the work would be redundant and it would not create any opportunity to iterate. The idea then became 1 chassis with two competing manipulator teams to see who could design the best manipulator. (While we did not use this approach, I think it would have worked well for a subsystem like the shooter, but I'm not sure if it would have meant a catapult and a wheeled shooter or two different but similar designs.) Anyway, we decided that it could be hard to decide which one was better (at what point do you decide, and at the deadline point the truly better manipulator is still waiting to get its essential part in the mail) and could also create hard feelings within the team. We also considered employing large number of students to build more prototypes. I'm not exactly sure of the approach we chose, because as soon as we started the build season, the approach changed to create our traditional build subteams (chassis, manipulator 1, manipulator 2). (As a sidenote here, I remembering vehemently opposing this, having experienced in lunacy compartmentalized subteams who failed to properly integrate their subsystems. Beware of this.)

In short, instead of 2 robots, build 1 chassis 2 different yet similar subsystems that will employ the same game strategy. (It would be hard to compare good ball collector to a mediocre shooter). OR Build 2 robots and iterate upon the first version to improve it. This is probably the more popular method.

I have been thinking about how to once again restructure the build process, and this is what I am currently considering. Everyone as a team decides what strategy they want to employ. Then groups break out into subgroups (chassis and manipulator) to brainstorm possible ideas for the sub-assembly on which they will specialize. Ideas are presented to the whole team, some shot down; a select few will be prototyped. A smaller group of students will work as the design team to do the detailed design work. As they do this, they will assign build tasks to the builders (prototype what amount compression will be needed on the ball). Once an iteration of the robot is designed, everyone works to build it. Its tested, evaluated to see waht could be improved. Re-design flawed systems, continue to test v1.0 while designing and building 2.0.

*Keep in mind I am accustomed to a large team, with a smaller team, I am sure you would adapt this structure.