22 October 2015

 This lecture was actually presented four times in succession with just a dry erase board in 25 minutes each; this presentation captures the information presented and the results, but not the details of elicitation.  The actual format guided a small group (4-6 students and up to 2 mentors) through developing the engineering process by guiding them through an engineering process. I recommend presenting in a similar interactive format. Therefore, this presentation is intended more as a “train the trainer” and shall cover a few of the “dead ends” and the appropriate responses. If doing this by yourself, answer the question at the top of each screen before you continue into the answers I got, which are intentionally sorted with the “farthest from correct” answers first. If you find your answer along the list, read the response there and try again.

 To answer a question/to learn something ◦ No – that’s the scientific method (what’s the difference between science and engineering?)  To build something [a robot] ◦ How do you know what to build?  To design something [a robot] ◦ Why are you designing something?  To play the game/compete ◦ Right, but too specific to FRC. What about a bridge?  To solve a problem ◦ Precisely. The engineering process is a structured method to solve a problem.

 Build a prototype ◦ How do you know what to build?  To design something [a robot] ◦ How do you know what to design?  Read the Rules ◦ For FRC, that’s a key step in the first part. Let’s try to do this for a more general engineering problem: what’s the first step to solving a problem?  Admitting you have a problem. ◦ Yes, that’s the first of the 12 steps for addiction, and is also valid here. However, by entering the engineering process, we’ve already identified that we have a problem. What’s after that?  Define/Identify/Know the Problem. ◦ Ding! Ding! Ding! If you do not clearly define the problem, including the requirements and constraints that the solution must meet, you are likely to design/build something that does not really solve the problem.

 Design (or build) a solution ◦ Too fast – let’s break this down a bit more. Assume that this is a problem you have not seen before. What do you need to know before you design a solution?  Brainstorm ideas ◦ Still a bit too fast – do you really need to brainstorm something from the bottom up if a wheel, lever, or gear is the solution?  Research known solutions ◦ Yes! Search Chief Delphi, search engineering sites, search youtube, search wherever someone may have looked at some or all of your problem, whether it’s a gearhead site for gas-powered racers, or a site dedicated to frisbees or footballs. DON’T REINVENT THE WHEEL – READ ABOUT IT!

 Design (or build) a solution ◦ Too fast – let’s break this down a bit more. Assume that none of the solutions you found in research seem certain/likely to solve your problem completely. What do you do next?  Imagine/Brainstorm ◦ Yes! Extending known solutions is more likely to solve your problem, but also feel free to propose a totally new solution if it seems appropriate. Sometimes a new “stupid” solution can inspire an innovative adjustment to a “known” solution, or vice-versa. Start by accepting apparently unworkable solutions, but force solutions to become more realistic before you proceed to the next step.

 Build a robot/prototype ◦ What shall we build? The imagination/brainstorming processes generated ideas, not buildable designs.  Design a solution ◦ Did you only imagine one idea?  Evaluate and Select a Concept ◦ Yes! OK, now what basis do you use for the evaluation?  Can we build it in time? - good point, but not the key.  Can it be updated and repaired easily? – same  Does it solve the problem – Most important! Consider not only if it will do the necessary functions, but do them quickly enough to compete.

 Profit! ◦ Slow way down! People don’t buy design concepts.  Build a robot ◦ What shall we build? The imagination/brainstorming processes generated ideas, not buildable designs.  Prototype ◦ If the prototype is something really quick to help figure out what size wheel to use for a subsystem, perhaps that could be part of this.  Design a solution/Draw up Plans ◦ Yes! More details…

 Blueprint/CAD/drawing/model ◦ Yes, good start. How much detail?  At a minimum, define the major dimensions and which motors/pistons you will need. Some teams CAD up a full design down to the fasteners and wire routing before building anything. We’re somewhere in between. ◦ If you haven’t already run the numbers, do it here. Do you have enough power, speed, force, grip to handle the load?  Bill of Materials ◦ Yes, you must especially list everything you need that you don’t already have so you can buy it or make it.  Schedule ◦ Absolutely! It’s better to have a robot that does three things a week before bagging than one that will do six, but is still waiting on parts to come in or be built. Don’t forget that our problem is not to “build a robot” but to “compete at the 20-whatever FRC game”, we need to schedule time for driver practice as well as construction.

 Build It! ◦ Of course.  As you build or install each part, be sure to refer back to the plans. ◦ Is it the right size? ◦ Is it in the right place? ◦ Are we on schedule?  If anything is built outside of the specifications, either rebuild it, or go back to the plans and coordinate an update with everyone. (Don’t leave the programmers out!) Then make sure everyone is using the latest plans!

 Compete with it! / Bag It! ◦ We should have an initial build done a week or more before bagging. What do we do with this time?  Driver Practice ◦ So the first time we apply power to the robot, we expect the driver to be able to drive to, pick up, and score a game piece? Do each of these functions really work? Let’s take smaller steps first.  Test/Evaluate ◦ Yes. If your subsystems are relatively independent, you may even test them separately before installing on the robot. In any case, once you have a full-up prototype, you’ll want to go back and test its ability to meet each of your detailed design requirements.

◦ Rebuild the bad parts/systems ◦ Improve the bad part(s) ◦ Redesign the bad part(s) ◦ Scrap the robot and start over ◦ Change the game strategy  Good answers. What do all of these have in common? ◦ Repeat the engineering process, or part of it. If something was built incorrectly, you might just go back to build. If something cannot be made to work (within resources), you may have to go back to redefining the problem.

 The engineering process is a structured method to solve a problem, consisting of: ◦ D efine the Problem in detail ◦ R esearch known solutions ◦ I magine possible solutions and select one ◦ P lans (Blueprints and Schedule), in detail ◦ P rototype/Build ◦ E valuate/Test the prototype ◦ R epeat as necessary

 Different types of engineering may expand one of our steps into multiple pieces, or collapse two or more together.  The biggest point of variation is “repeat”. Civil engineers (bridges and buildings and such) don’t get a chance to repeat after design, so their repeats are earlier. Software developers and inventors tend to have a lot of different return arrows. Next are some examples.

 To solve a problem, first define the problem, and keep it in mind as you work.  Fail faster! The earlier you find out that something doesn’t (quite) work, the more time you have to fix it.  Objects in calendar are closer than they appear.  Test It! Repeat as Necessary.  Better and Good Enough are necessary adversaries. Don’t let either destroy the other.  When in doubt, go back to the problem definition. Sometimes you have to step around the alligator and get back to draining the swamp.