From the Brain to the Field: Brainstorming a Robot

Team 178 just recently vacated our workspace that we’ve used for the last 11 years. In this transitional state, students and mentors have begun meeting to improve on one of our teams weak points: our inefficient brainstorming of robots. This year especially we felt that great ideas were not considered because we tried too hard to stick to a set plan. We want an improved process for 2016 and beyond so we are open to suggestions, so my question to everyone is:

How does your team arrive at a final robot design?

Please include any detail you believe is important, thank you.

Don’t start with a robot. Start with a strategy and then build a robot to play that strategy.

Our basic process is to come up with a strategy (days 1 and 2) and then define requirements for a design based on that strategy (day 3). Then we go to brainstorming how to meet those requirements including using math, physics, and a lot of JVN spreadsheet time. Once we have a plan we begin to prototype and build and then iterate as much as we can.

Take a look at Karthik’s Presentations, its hard to argue with the results.


It’s also helpful to not only identify a strategy for you to pursue, but also other strategies and how your role interacts with both strategies of your opponents and partners.

Things like understanding that a good floor pickup in 2013 doesn’t just have the benefit of extra autonomous points, but it also plays well with full-court shooters.
Or what would any robot in 2014 be doing when they aren’t directly manipulating the ball? How do you play better defense and play through more defense in 2014 because of this?

It can be easy to focus in on what your robot is doing without thinking about how other robots on the field are affected by these actions.

As with any engineering project, begin with requirements. In this case, your requirements begin with the rule book. Then, after you’ve broken down the scoring and identified opportunities and challenges, list your strategic requirements. Prioritize the requirements.
NOW brainstorm designs. Usual brainstorm rules - build ideas up, but don’t tear them down yet. Somebody must be in charge of notes!
Select a few basic designs to draw up - more detailed than a napkin, but not a full-detail CAD. Don’t pick these by popular vote, but by whether anyone (or a small group) is willing to champion them and do the rough design. We usually have some hand-drawn and some in power point; we’ve even had some executed in such media as dry-erase and cardboard. As a group, review and rank them according to cost/benefit/risk for meeting the requirements. Look at the likely contenders and see if any of them can be improved prior to prototype. Pick one or two designs to prototype.

If you’re ten days in and aren’t down to one or at most two designs, you’re going too slowly. If you’ve picked one on kickoff day or the day after, you’re going too quickly - either you didn’t analyze the game well enough or you haven’t slept. The sweet spot is somewhere in between these two, and we haven’t quite found it yet; too slow our first three years, too fast this year.

So the way I start (and I say I because we invite all methods o’ madness to the table when designing) designing for ANY sort of game is I take the most complete manual we get at kick off and I tell my team to leave me alone while I go think and meditate.
Then I go through and research similar games (or jobs but using games is easier for the sake of advancing my brainstorming process) and I look at the “meta” or predetermined methodology that is accepted as the standard for playing the game.The basic idea is that whatever this game is similar to, whatever sport it is like some group somewhere takes it super seriously. That group has some valuable information that you can pull from. Those experts are the ones writing the meta. Whatever you pull from them you bring to the table for discussion. This meta dictates a strategy as well as design constraints and capabilities and tools that will help your robot do well. With this you can pick your build path.
This process I stand by in FIRST, in any video games I play, even in work sometimes.
Of course this is also the process that told me mecanum was what we should go with this year,
And I still feel gross for standing behind it…

Karthik’s presentations are very enjoyable and helpful, but he admits that he isn’t the best resource when it comes to mechanical implementation. His presentations focus on the “What we want to do” rather than the “How we do it”. He is a good resource when determining the final robot strategy, but, from what I’ve seen, has no resources on how to arrive at a final robot design.