JVN Build tip: WHAT before HOW

[JVN]

Hi Everyone,
As FIRST teams around the world are all digging into their design processes, I thought I'd post a few tips from our team to yours...

Today's tip is: Figure out the "WHAT" before the "HOW."

As you're digging into your robot build you NEED to figure out WHAT you want the robot to do before you figure out HOW you're going to do it. This is easier said than done -- make sure during your brainstorming you don't let anyone get "hung up" on what design the robot will use, or what specific mechanism the robot will use; instead have them focus solely on the robot ACTIONS.

One good way of doing this is to list ALL the actions a robot can perform. On 148 we start by listing ALL the ways a robot can score a point, then we add defensive actions, then we add all other actions. Once we have the "big list" of all robot actions, we figure out what is most important: this is done through a combination of scoring analysis, strategic brainstorming, simulation, and good old-fashioned prototyping.

If you take the time to list out ALL the robot actions (using brainstorming, where there are NO bad ideas) you'll be much happier later on, trust me...

As always... good luck in 2011!

Originally posted here:
http://jvengineering.blogspot.com/20...efore-how.html

[Tom Line]

Nice. Hopefully some of the teams that are talking about how much of their robot they've built take a break and realize that until you understand ALL the aspects of the game, building is pointless. See 469 from last year as a perfect example of why understanding the game is critical. We've been in game understand groups for 2 days - today will be overall robot strategy. No one's touched a cad computer other than to clarify rules (like the evil 60 inch cylinder) and the parts got taken out only to inventory.

[JaneYoung]

I wonder if there would be a way to create a section in CD for JVN's Build Tips. It would make a great archive and be easy to access for current and future reference.

Just a thought,
Jane

[kaliken]

I completely agree.

Its not only difficult to keep the students from wanting to design the mini-bot/arm/telescope/grabber etc. But sometimes also the mentors. We often get into solving the problem first without making sure we are solving the right problem. It tough to tell them that I don't want a widget but want reasons why Strategy X is better than Strategy Y.

I concur with the robot task list. We did the same thing as well. Next step we are going to take is determining strategic importance and assigning level of effort. The LoE is important because our team does not have that many students so we ahve to prioritize tasks based upon complexity as well.

In the end we all want to build a robot. But we need to design the robot to fullfill our selected strategy based upon our game analysis and our techinical capability.

[Chris is me]

Great suggestion. Realizing what we did have to do (or more accurately, what we didn't) opened up design possibilities that I didnt think were possible.

[JesseK]

Some examples of WHAT's versus HOW's this year are:

WHAT: Score tubes on the middle row.
HOW: Launch tubes to the middle row.

WHAT: Win the minibot race to the top
HOW: Use deadman switches and 2 motors geared YYY:1 to power the minibot

WHAT: Move the minibot to the pole for deployment
HOW: Activate the scissor arm that has the minibot attached

WHAT: Acquire game pieces from the opposite side of the field
HOW: Drive to the opposite side of the field and put Manipulator A in position Y

WHAT: Pick up game pieces from floor
HOW: Put Manipulator A in Position Z and the Claw into Position 2

Once the WHAT's are listed, I'm a fan of using students to act the WHAT's out. As the ideas flow, drill down into WHAT's where necessary, or use 6 students to try 6 different things at once. We got this idea from 116, though I'm sure others have thought of it too.

Interestingly enough, defining a solution for a WHAT is a HOW. As the design is detailed, the HOW's then become WHAT's, with their own more specific solutions (aka, drill down).

[Chris Fultz]

This is a great video that each team should watch.
(apologies if it is already linked somewhere else.)

http://www.youtube.com/watch?v=Wk_QHkIwp7w

The key phases Grant brings out are DEFINE, IDEATE, CREATE, SOLVE.

Right now, you should still be in the DEFINE phase - understanding what problem you are trying to solve.

[DonRotolo]

Exactly. For another example of What before How:

Requirement: Ability to drive cars on the driveway after a snowfall.
Capability: Remove snow from my driveway.
Methods: Melt snow. Push snow. Throw snow. (etc...)
Mechanisms: Hot air guns. Electric wires that get warm. Big magnifying glass to focus solar energy. Hot water heater. Propane torch. Use chemicals to lower melting point. (etc. And that's just the "melt" method...)

Last, from all the mechanisms, you find the one that's "best" (which can be debated) and build it.