Lesson 0.4: Generating and Narrowing Robot Concepts
Technical Context
The quality of your final design is limited by the best idea you considered. If the team only ever generated one concept, the final robot is that concept, whether or not it was any good.
Generating alternatives feels wasteful when everyone already agrees. It is exactly then that it matters most, because agreement early in a season usually means nobody has thought about it independently yet.
Separate Generating From Judging
The single most common failure in a brainstorm is that someone proposes an idea and someone else immediately explains why it will not work. After that happens twice, people stop proposing.
Run the two activities in separate blocks:
Block one, generate. Fifteen minutes. Every idea gets written down. No evaluation, no "that will never fit," no "we tried that last year." Quantity is the goal. Bad ideas are useful because they mark the edges of the solution space and often contain one good element.
Block two, judge. Now criticize freely, but criticize against the requirements from Lesson 0.3, not against taste.
Ideas described out loud are understood differently by everyone in the room. Ideas sketched on paper are understood the same way. A bad sketch beats a good description. Module 1.3 covers how to sketch mechanisms so they communicate.
Techniques That Actually Produce Alternatives
Work by function, not by mechanism. Instead of "design an intake," write the function: "move a game element from the floor into the robot." Then list every physical principle that could do it: roll it in, scoop it, grab it, sweep it, lift it, funnel it while driving forward. Each principle is a family of mechanisms.
Change one constraint deliberately. Ask "what if the robot could not extend at all?" or "what if we only had one motor for this?" Artificial constraints force the group out of the first answer. Some of these concepts turn out to be better even when the constraint is lifted.
Look at how the problem is solved outside robotics. Element handling is a solved problem in agriculture, packaging, and manufacturing. A conveyor, an auger, and a vacuum are all real answers used at industrial scale.
Steal openly, then understand. Watching match video from past seasons is legitimate research. The rule is simple: if you copy a mechanism, you must be able to explain why each part of it is shaped the way it is before you build it.
Combining Instead of Choosing
Most teams generate whole mechanisms and then pick one. That produces three or four ideas, each of which is somebody's favourite, and the argument becomes about people rather than about the robot.
There is a better move. Break the problem into the functions it has to perform, list ways to satisfy each function separately, then combine one from each column.
The arithmetic is the point. Four functions with three options each is not seven ideas, it is 81 combinations, and most of them are ones nobody would have proposed out loud. Combining also separates decisions that were never related: how you grab the element has nothing to do with how you lift it, and treating them as one choice throws away good halves of rejected ideas.
Concept Combiner
Solve each function separately, then combine. Score the trade before choosing.
| Function | Ways to satisfy it | ||
|---|---|---|---|
This combination
Compliant rollers + Belt path + Cascading slide + Reverse the rollers
Combinations scored so far
Score this one, then change a function and score the next.
These 4 functions generate 81 possible combinations. Your team probably discussed three. Score at least two combinations before deciding anything.
Cost is everything the combination consumes: build hours, money, weight, and complexity. Benefit is what it delivers against your requirements. Neither is a single number in reality, which is exactly why they are kept on separate axes here instead of collapsed into one score.
Cost and Benefit, Kept Apart
Once you have combinations, the temptation is to score each one out of ten. Resist it. Collapsing everything into a single number hides the decision you are actually making.
Keep two axes:
Cost is everything the combination consumes: build hours, money, weight, complexity, and the risk that it does not work. Build hours are usually the binding one, and teams consistently underestimate them.
Benefit is what it delivers against the requirements you wrote in Lesson 0.3, cited by id.
Then look at benefit per cost. A combination that scores highest on benefit and highest on cost is often the wrong answer, because the season has a fixed number of build hours and spending them all on one mechanism leaves the rest of the robot unbuilt.
A mechanism that delivers 80% of the benefit for 40% of the cost frees the hours that make everything else reliable. The best robot at an event is rarely the one with the most ambitious mechanism; it is the one where every mechanism had time to be tested.
Narrowing Without Killing Good Ideas Early
Once you have eight concepts, you cannot prototype all of them. Narrow in two steps.
Step one, screen against constraints. Any concept that violates a hard constraint is out. This is fast and uncontroversial because constraints have sources.
Step two, compare the survivors against weighted criteria. This is the decision matrix, and it is covered in detail in Lesson 1.4. The short version: list the criteria that matter, weight them by importance, score each concept, and look at the totals.
The output of narrowing is not one concept. It is usually the top two, both of which get a rough prototype, because a matrix is a structured opinion and a prototype is evidence.
Every season, some team picks a concept from a matrix, spends five weeks building it, and discovers a problem that a two hour prototype would have exposed in week one. If the top two concepts are close, build both roughly. It costs a weekend and it can save the season.
Recording the Ones You Did Not Choose
Write down every concept you rejected and one sentence on why. This matters for two reasons.
First, judges ask. "Why did you choose this intake?" is a standard question, and "it was the only one we thought of" is a poor answer.
Second, you will need them. When the chosen concept fails in week seven, the list of rejected concepts with reasons is the fastest path to a replacement, because half the thinking is already done.
- Award criteria that reward documented design decisions: FIRST Tech Challenge Game and Season Info
Fill-in-the-Blank Practice
- During the generating block of a brainstorm, evaluation of ideas should be
__________. - Describing the problem as a function rather than a mechanism keeps the team from committing to one
__________too early. - Concepts that violate a hard constraint should be removed during the
__________step, before any weighted comparison.
Show answers
- deferred (postponed to the judging block)
- solution (mechanism or family of mechanisms)
- screening (the constraint screen)
Exercise
Pick one subsystem on this season's robot. Generate six distinct concepts in fifteen minutes, sketching each one. Then screen them against your constraint list and keep the top two. Record the four you dropped with one sentence each.
You will score the survivors properly in Lesson 1.4.
Ready to move on?
Sign in with Google to save your progress with Telemark, or continue without saving.
Stuck on this lesson?
Ask about anything on this page. It can see which lesson you have open and which part you are reading.