Quote:
Originally Posted by Sid323
You mentioned having a working robot in two weeks; how did you decide the design by then, especially considering your large number of rookies? Did you get a large number of members just building by then? Our team usually has had tedious design meetings that can extend into the second or even third week which involve everyone sitting and debating different design ideas (which is part of the reason why we are looking at agile).
|
Our typical method is to spend the 1st day of kickoff weekend reading the rules and then brainstorming game Strategy (i.e. what the robot
needs to do, not what it looks like). For all brainstorming we break up the team into groups of 6-10 people (we found 50 students + 12 mentors was too many to get anything done) that are a mix of new & returning students & mentors, and also cross-functional (i.e. no groups of all-mech or all-coding). We pick Strategy as a team, then brainstorm for "robot elements" (i.e. a drivetrain style might be one element while a loader concept might be another), then a 3rd time for fully-integrated robots that have all the elements needed to execute the strategy.
Usually at the end of all that we're torn between 2 or 3 concepts, so we use what I think of as "sudden-death" prototyping. We split into groups that work separately on prototyping the leading concepts, and then as soon as 1 or more prototypes is ready, we meet as a whole team, review the prototypes (including whatever they have even if it's not finished) and vote to pick a concept or continue prototyping.
Here's a video of the concept we picked last year on day 3 or so (without motors or software). Here's what we built for the day-17 robot. The final robot.
While prototypes can be time consuming, we find they usually settle design arguments MUCH faster than sketches and talking.