Today’s build tip is all the more important since it is a lesson I had to relearn this season…
Right after the kickoff broadcast was over, before we even read the game manual in detail or started brainstorming, our team wrote out some goals for the season. The first step in any engineering design process is to define the problem you’re solving – these goals represented our solution to “the big problem” we were working on. They represented our top priorities for what we were trying to get the robot to do. After this we went through the game manual in more detail, did our strategic analysis, and brainstorming.
At the end of day 1 we had a list of robot actions and attributes we would focus our efforts on – we knew “what” we wanted to do, now we’d figure out “how” to do it.
On day 4, we started discussing another robot action / strategic attribute. This one seemed very important at the time and it drastically altered our “overall robot concept.” We changed direction slightly and kept pushing ahead.
By day 6, we realized this new attribute which seemed so important had caused us to shift our direction in a weird way. We had a meeting to discuss the overall system, and do a “state of the build” discussion during which we compared the current robot system with our original goals. The result? – we were off base…
The “gimmick” design attribute had distracted us from what was important.
So that brings us to today’s build tip:
**Always keep sight of your overall goals – stay focused on what is most important!
**
As a team you have already probably figured these out, even if you’ve never vocalized them or written them down. Maybe this would be a good idea? Get your team together and discuss these… ask yourselves “what are we trying to do here?”
Of course… someone will chime in and say: “we’re here to inspire students and have fun!”
To them I say: “Well DUH!” That is implied in everything we do. “What are we trying to do WITH THE ROBOT?”
Too many teams spend far too long on a “well maybe we could…” approach instead of a "by ‘x’ date we need to do ‘y’ " approach.
Your team seems to have their process just about nailed down. My team has not even have a whole-team discussion of what the robot should do until tonight. There is no unified goal. It’s quite different.
I would conjecture that nearly every competitively successful team has unified goals.
What I want to know John, is what is your team’s decision making structure? Hierarchical? Dictatorship? Democracy? Micromanagement? Etc…
“Consensus building” facilitated by a strong veteran mentor group including one lead engineer with “ultimate veto power” (a term I stole from Paul Copioli).
Decisions on 148 are organic and tend to evolve naturally based on logic, reason, and quantitative engineering arguments. Tradeoff decisions are typically decided en masse by a design team where we try to get buy-in from everyone involved on the final decision. We recently went through this process (on Day 6) concerning a subsystem on this year’s machine.
Under no circumstances will we vote. Vote is a 4-letter word in an engineering decision-making process.
We create a rubric of key parameters for the game and then rate them on importance from 1 - 5. The key is that you must create a spread of values, or you are wasting your time with this step.
By forcing ourselves to put a value on each item, we can then know where to focus our efforts and where we can compromise. We compromise on the items of lower value and stay firm on the higher value items.
If you rate everything a 5, then you have specified a robot you cannot design and build, because you have nothing to make trade-offs with. You will try to do everything perfectly and end up doing nothing well.
