Lesson 0.4: Generating and Narrowing Robot Concepts
Technical Context
You cannot choose a strong design if the team considers only one concept. Generate several plausible approaches before committing parts and build time.
Early agreement may simply mean everyone started from the same familiar idea. A short concept session gives each person time to consider alternatives independently.
Separate Generating From Judging
Brainstorms stall when each idea is judged as soon as it is proposed. Separate generation from evaluation so people can finish developing an idea before the group critiques it.
Run the two activities in separate blocks:
Block one, generate. Set aside fifteen minutes and write down every idea without evaluating it. Aim for variety. Even an impractical concept may contain a feature worth combining with another approach.
Block two, judge. Now criticize freely, but criticize against the requirements from Lesson 0.3, not against taste.
A quick sketch gives the group a common reference for geometry, motion, and scale. It does not need to look polished. Module 1.3 covers the details that make a mechanism sketch clear.
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
If the team generates only complete mechanisms, each concept tends to bundle several unrelated decisions. Comparing them becomes harder because one concept may have the better intake but the worse lift.
Break the problem into the functions it must perform. List several ways to satisfy each function, then combine one option from each column.
The arithmetic is the point. Four functions with three options each is not seven ideas, it is 81 combinations, including many that the team would not have proposed as complete mechanisms. 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. 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 often set the tightest limit, so estimate and track them explicitly.
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 leaves more time to build and test the rest of the robot. Treat build hours as a fixed budget, not as an abstract score in the matrix.
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.
A decision matrix is still based on estimates. If the top two concepts are close, build rough versions of both and compare measured results before committing to the final design.
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, the list gives you a useful starting point if the chosen concept later fails. Recheck the rejected options against what the team has learned instead of restarting the search from memory.
- 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?
Only mark complete if you genuinely understand the material. Your progress will be saved in this browser.
Stuck on this lesson?
Ask about anything on this page. It can see which lesson you have open and which part you are reading.