Documenting the Design Process
The Design Process: the backbone of the engineering notebook. This is what judges are looking for. They want to see that you are following the design process as you go through the season. Documenting in the engineering notebook isn't simply documenting what your team does. Instead, it is documenting how your team follows the design process. For me personally, I follow the design process from the PLTW course (which is fitting since I am doing VEX robotics).
Below, I break down this design process and how I document each step. I give suggestions on how you may want to document each step in your notebook, if you do decide to follow the PLTW design process.
1) Define the Problem
For this step, I break down the game. Our team looks at the rules, field layout, and other things part of the challenge VEX gives us that specific season.
I usually include a visual of the field set-up and the game elements. I talk about the goal of the game and what we must do to win a match.
2) Brainstorm
For this step, the team gives random ideas they have for the new game, whether it be in-game strategies or robot ideas they may think of.
I usually include strategies each member of the team can think of. Brainstorming can include the brainstorming of possible autons, game strategies, or robots.
3) Research and Generate Ideas
Here, we finally compile and organize the robot ideas we have for the game. Each team member gives their own ideas based on research and original ideas they can think of. Research can include looking at old VEX games, other robots, or maybe online research.
I usually include a full robot idea from each member. I also include any research we may do, such as Youtube videos.
4) Identify Criteria and Constraints
This step is more or less a continuation of our rules analysis. However, instead of analyzing the game, we analyze the robot constraints. We will be looking for size limits, expansion limits, and more. We list it down so it is clear to the team what criteria we must meet to legally compete.
I usually include a few pages listing rules every team most follow when building a robot (such as the 18 x 18 size limit or any expansion limits in the game).
5) Explore Possibilities
This step is continues the brainstorming process, as we start looking into each different idea even more. We analyze each idea and see what we are looking for in a robot.
I usually include the brainstorming pages as part of this step. The explore possibilities page is mostly a continuation of the brainstorming step of the process.
6) Select an Approach
This step is where we finally chose the robot we want to do. We each evaluate the brainstorming ideas and use a design matrix (with specific criteria) to grade each one fairly. The highest scoring idea is what the team usually plans on eventually building. Example of design matrix criteria include: TIME - EFFECTIVENESS - COMPLEXITY - RELIABILITY - EFFICIENCY - CREATIVITY
I usually include the design matrix in these pages of the notebook along with an explanation of how we decided on the robot.
7) Develop a Design Proposal
When developing a design proposal, we re-sketch the idea we chose, except it is in greater detail now. Some people may want to use CAD Modeling for this (though it is not necessary).
I usually include the design proposal for the top 3 ideas we chose. I get top 3 ideas, because we may need back-up designs just in-case the first idea fails or we change our minds in doing it.
8) Model or Prototype
This is when the building finally begins, but not the final product. Here, we are just building and prototyping each subsystem in hopes to see how well it works.
I usually include and document how we built the prototypes. Also, I would include the testing process and results from each test we do on the prototypes.
9) Test and Evaluate
This is when we test and analyze each prototype we have built. We like to see how well it performs and compare it on how we originally wanted it to work versus how it really is.
I make sure to evaluate how each test went. I give in-depth analysis on how we tested each subsystem and explain any major problems we have. I would also discuss how we may plan on fixing the problem.
10) Refine
This is when we start changing the prototype based on how the testing went. Sometimes, a prototype is perfect and everything is good. Other times, the prototype is not very good so we need to redesign the prototype. No matter what, refinement is a step closer to getting the finished product completed and done.
I usually document the process at which we refine the robot. The documentation process is very similar to how I document the prototypes: in a way that breaks down how we built each one. I also make sure to compare it to the original build.
11) Create or Make
This is the building of the final robot. Here, all our plans are solidified and we are able to get a clear picture of how we want the robot to be at the end. The robot we end up with at the end of the create or make process is usually the robot we will be competing with at a tournament or competition.
I usually document the process at which we finalize the robot. The documentation process is very similar to how I document the prototypes and the refinement steps. Create or Make is basically the "finalization" part of the build process.
12) Communicate Results
This is the part where we say how we liked to turnout of the robot. We analyze how well it drives and see how well it performs. We compare it to the original plan by asking ourselves: does it live up to our expectations?
I usually document the robot's performance in driving. This may also include competition documentation by analyzing how well the robot performs during a tournament against other robots.