How do you guys run early brainstorming?

Our team is looking at how to improve our design process, and we were wondering how other teams do it.

We are a very large (45+) team, and want to keep everyone involved in the early design process. In years past, we have had teams of 5-6 design whole robots, and present them to the whole team for a vote. We use subsystems from each design. This system takes a long time, and I feel is noneffective. Especially now, with so many people on our team, 4 hour build sessions are not enough time to present ideas with comment, questions, and concerns and most importantly, discussion.

So, how do other teams do it?

Everyone on our team will meet during kickoff at school to watch it in the auditorium. After kickoff, we have a short lunch break, then start the design meeting. The entirety of the manual (game & robot) is read out, with some field specs depending on relevancy.

Once everyone is fully aware of the goal of the game, we decide what we want to do and then we start throwing out ideas. The next day, a core group of the team meets to continue the design process, and on the first meeting day, we begin prototyping different ideas. From there on, the most effective prototypes become our robot.

I have seen this method a lot in industry. We have used it a few times for our team, we really should use it more. We split into groups and draw out our ideas on paper. We then post them on a wall. The point of doing it on paper is that no one can erase it off the white board. We leave it up for the whole season. The advantage is that some ideas initially appear to not work, but if you look at it a few days later, it can suddenly make sense.

Its pretty handy to keep everyone involved because students become motivated to add to the wall. I make sure they know that no idea is ever bad because all ideas, no mater the quality, can inspire the winning design. I usually suggest outlandish ideas to break the ice. Once they get over hurdle of submitting ideas, the board gets filled up pretty quick. I have lucked out by not being overwhelmed by ideas. Once the students figure out the design qualities they want, the ideas quickly start converging. Usually as the season progresses, we revisit the board as we learn more from testing.

During the first week, we manage to pin down strategy, design, as well as CAD

Our entire process is run by 2 student facilitators (1 Senior/1 Junior). We start off Monday of Week 1 by going over strategy (offensive, fast driving, ground load, minibot for this year). Pretty much, everyone can throw out ideas onto a whiteboard, and then we go through, and evaluate what we want our robot to do. Then, once strategy is hammered out, we go into basic robot functionality in small groups. The groups come up with ideas on what they want to do to accomplish the decided strategy. They come up with ideas like, mecanum drive, forklift style lift, roller claw grabber, launching minibot deployment. Each group has new students and at least one experienced member. After some time, the groups come back, and one of the new students presents the ideas. This helps them work on communicating effectively, as well as helps the 2 student facilitators combine ideas so that the whiteboard doesn’t get cluttered. After all the ideas are pitched, they go back to small groups to decide if they want to incorporate ideas of another group. Then they all come back and present. We do this a few times. Eventually, most groups will probably agree on a general design, at which point, we break into subteams to go over specifics of the designs. This is when the subteams do napkin drawings, calculations, and other specifics. Eventually, all the subteams will have what they plan to do, at which point, we combine all the ideas into one cohesive robot, and send it off to be CADed while Manipulator subteam does prototypes of ideas.

If you have any questions about our process, PM me, and we can talk more in depth.

historically, we have done strategical decisions first, what role in the game do we want to play, offense, d-fence, and so on. from there we decide what drive-train we want to use, and then mid level manipulator (usually, arm or lift) and from there we decide what end manipulator.

what we are gravitating towards, is to play to our strengths.
decide what roll we want to play, then the most familiar mid level manipulator, one of our two (mechanum, Tank with omnis on ends) drive-trains that we have worked with before. from there we can decide what mid level manipulator we want (we have experience with conveyors and lifts.) and then decide what kind of end level manipulator we want (usualy designed around an rs550 or similar motor)

i hope that designing to our strengths, rather than designing to what we think might be the best, will allow for a faster, and more problem free build season, and allow us to get in some more driver practice, as well as having more members of the team fluent in the way the robot is put together.

We’re in the same boat, with student membership nearing 80 (about 2/3 of which attend Kickoff and are heavily involved in the initial design phase).

*Just skip the italics if you don’t really care how we got to the system that works best for us.

We’ve undergone a little refinement of our system. In years prior to Breakaway, we’ve had 3 teams of various sizes and of students’ choosing doing brainstorming of systems right from the end of breakout sessions. The result is a chaotic mess of ideas, with no clear indication to anyone outside the subteams what anyone is trying to convey. It generally resulted in an subteams split along class and veteranship lines, with a group of new members largely clueless.

For Breakaway, we finally decided to get organized. We had four teams this year because we were bigger, each was headed by one mentor, one build officer, and one non-build officer. For the rest of the students, they were sorted into tiers of understanding, i.e. veteran build member, veteran non-build member, rookie members who have demonstrated expertise and have been working with build, and rookie members who have largely been working on non-engineering aspects. From each tier, we tried to distribute it evenly, and if possible keep friends with friends because people are more comfortable with people they like.

The main issue with this was that each group was dominated by the veteran build members and even the mentors. The group most eclipsed were the new students who did not enjoy engineering. It was a terrible experience for them, and many of the students leading the discussion tried to pressure them into sharing ideas. We still did not have a very good idea about how to brainstorm.

Between Breakaway and Logomotion, JVN’s journals for their 2010 season were published, and Armadillo’s design process was publicized. After our mentor brought a copy of it to one of our meetings, we asked each of the build officers to read it, and from there we started going for a more systematic breakdown of strategy, analysis of game objectives, and WHATs before HOWs.*

For Logomotion, we didn’t use small groups at all, unless you count partnerships. Because we noticed small groups still discouraged participation from some members, we opted to use partnerships over subteams. In a partnership, you cannot escape discussion because you’re the only one to discuss with. It’s easier to find just one person you are comfortable working with rather than 15.

From there, every partnership had the same task. First, identify confusing rules and then game objectives (whether with point values or not, e.g. “expand to 60 inches to play defense” is totally valid). After about 10 minutes, we evaluate where each of the groups are, and we keep adding a short interval (3 - 5 minutes) until all but one or two groups are done. We got together, and made a massive list of possible objectives on the board simply by asking people to read aloud what they have on paper. No evaluation of anything said; after 25-30 partnerships, nobody remembers who said what, and nobody will feel pressured or under attack. This psychological security was fairly pivotal in involving the more shy, less confident rookie members..

We repeat the small group discussion -> compilation -> large group discussion and evaluation process for everything (game rules, objectives, strategy possible mechanisms, in that order). We had the best synergy in our team’s history. We had one partnership of our two build officers that led each segment as an “example” and got a high number of ideas down each time, rather than putting a partnership of newer members on the spot each time. Mentors filled in whenever there were conspicuous gaps.

Throughout the entire thing, there should be a couple of people constantly comparing what is said with the rules to provide reality checks. A projector is handy.