[KenWittlief]

When engineering students first graduate and land their 1st job, they very often fall into a 2 step design process:

1. This is what we are trying to do
2. This is how to build it

after you have been an engineer for several years, and you work with senior engineers, maybe take some requirements specification training, design spec training, continuous process improvement training, then you eventually learn than design follows a cycle, the engineering design cycle.

Hooray for the CD search function! (I posted the text below previously so I dont have to type it all again)

the engineering design cycle:

1. there is a problem to be solved. 1st you must clearly define the problem (understand it), understand WHY this system you are designing is needed, and specify WHAT your system will need to do in order to be an effective solution. (example: our bot needs to pick tetras up off the floor and place them on the goals, and it needs to do this 10 times within 90 seconds - this is WHAT our robot will do) note that this is all focused on the game (in our program). how do you play the game? how will you score? how can you get the best score? The reason you must do this now: many teams will jump into the middle of the design of the robot in the first few days, and then a few weeks later they realize they are designing the robot to do the wrong thing.

2. you brainstorm ways to create a system, and you decide HOW your system will do the WHAT. (example: we will create a robot with two wheel drive that can move and pivot quickly, with an arm that raises up and down in 2 seconds or less, and with a claw that can grab a tetra from the top. This is HOW our bot will pick up tetras and place them on the goal). This is top level design - at this point you are not writing code, or choosing materials, or selecting motors.

3. you break up the system into mechanical, electrical, SW, sensors, user interface, and go through the WHY, WHAT and HOW for each of these subsystems. Each subsystem now looks like a smaller version of the design cycle. This allows people to focus on smaller parts of the big system. The person designing the claw doesnt have to worry about how the tires will get the best traction on the carpet. The subteams know what they must do to meet their part of the system design requirements, and how it will fit in to the rest of the system.

4. you create drawings and SW algorithms, wiring diagrams, sensor schematics... of what needs to be built. This is what most people think of as design (this is what new engineers want to do on day two of the project!)

5. you have your subsystems fabricated and assembled: this is finally the build stage.

6. you test the system to see how it works, and if necessary go back to any previous point in the design cycle to make adjustments or modifications, but only if necessary to make the system work as intended (not to change what it does).

BTW, there are 6 steps here, and for a well disciplined team, each step should take about a week! You could push the first 3 steps into two weeks, and allow yourself 2 weeks for build. I know some people are reading this and saying "thats impossible - how can we build the robot in only two weeks?" the answer is: How can you build the robot when you have not figured out WHAT its going to do yet, or HOW its going to do it?

The reason this is called a cycle: when you are all done with the last step your system is deployed. In our program this means it goes to regionals and plays in matches. At that point you will see new problems to be solved, things that could be done better, additional things that might be added to allow you to score more points, or play better defense. Then you go through the whole design cycle again for those improvements and modification - you dont jump back to the 2-step approach.

The main reason you follow this method is a human brain can only think of so many things at one time - and not many things! When you are still deciding how you want to play the game you cannot be writing SW control system loops. When you get to the test phase (last of the six weeks + your 1st regional) that is not the point to be thinking "we should have designed a shooter instead of a goalie - how can we change our goalie robot into a shooter robot....?"

One last rule for this: When you are done with one phase you are done with it - no going back, no changing your mind 3 weeks in. If you want to add stuff or change stuff it has to be on the next loop through the cycle.

For FIRST teams that means either after your FIRST regional (see how the robot performs in action 1st, then consider whether you want to change it) or its means storing up ideas for next years robot.

I know its tempting sometimes, usually around 11pm on a saturday, when something is not going well, to start thinking "instead of 2 wheel drive we should change to 4 wheel, or tank treads". Its temping but dont do it - starting over takes you back 2 or 3 weeks - you cant add two or three weeks to your schedule. Work the problem, dont flush the design and start over. If you do your next design may be worse than the one you abandoned.

One last thing I would add personally: Dont judge your teams efforts on whether you win or lose events - judge your team on how well your robot does what you designed it to do. Celebrate your accomplishments and take notes and learn from your mistakes.