1. Engineering Notebook Getting a Better Score
Mike King
July 20-21, 2017

2. Agenda Overview of Notebook Scoring Why does the structure matter?
Some Interesting Notebook Metrics
Major Sections of the Notebook
General Suggestions
Section by Section

3. Why is an Engineering Notebook Important?
Engineering and Technical Careers need to communicate
Technical requirements,
Operations concept,
Design,
Test approach and results,
Quality assurance,
Maintenance & user manuals,
Business Careers need to communicate:
Response to request for proposals,
Marketing Approach
Sell your ideas
Justify your concepts

4. EN - Score % of Total

5. Major Sections of the Notebook
Research Paper (13% of overall score)
Design Process (57% of overall score)
Many sections
Including; Implementation, Brainstorming, Evaluation, Off/Def Strategies, SW/Sim, Safety, Support Docs.
Quality & Completeness (30% of overall score)
Average “Lost Points” for the “top” 8 teams (~8points, out of 30)
Research Paper ~0.6
In 2016 Regionals, the top 10 teams were all within 1 point
Design Process ~5
Contains seven sections, but ~60% (~3 points) lost from just two sections (Support Docs being the largest single loss of points)
SW/Sim and Support Docs
Quality &Completeness ~2
A difference of 2 points was the difference between 1st place and 4th place in the notebook judging for the 2016 RM BEST Hub competition

6. General Suggestions Start collecting information from day one
Have someone assigned to manage the Engineering Notebook
Write everything down
Save everything!
You can choose later what to actually put in the notebook
Make sure info is in an obvious place in the Notebook
Judges don’t have time to search around
Currently, judges only look at specific sections related to what they are judging, so if info is in some other section, they won’t even see it
Have well defined sections that are clear as to what they contain
Having sections that directly relate to the areas mentioned in the Score Sheet is critical
When describing lots of technical information, tables and charts are usually better than a lot of words
Use a reference to Support documentation when you have a lot of backup data to support a statement
Make sure you clearly reference where in the support documentation the info resides
Just because the information is in the support documentation, doesn’t mean the judges will see it

7. Why does the structure matter?
Good Structure is the easiest way to help the judges!
Table of contents can then be the basic roadmap to find information

8. Why does the structure matter? (cont)
Scoresheet
EXAMPLE 1
1. Introduction
2. Impl of the Eng Design Process 3
Identify Problem or Need:
Establish Criteria and Constraints:
Analyze the Task:
Brainstorm Solutions:
Key Testing and Refining Results:
3. Analytical Evaluation of Design Alternatives
Analysis of Robot Design Elements Table:
The Lift:
Final Game Strategy
5. Off/Def Evaluation
Point scoring strategy:
Practicing Driving:
Interactions with other teams:
4. Software Design:
Simulink:
7. Safety
9. Research Paper
10. Support Documentation
EXAMPLE 2
Introduction: Our team
Overview of Plan/Strategy
The Build
1. The Arm
1.1. Original Idea
1.2. Second Idea/Built Idea
1.3. Final Build
2. The Front Wheel
2.1. Original Idea
2.2. Second Idea/Built Idea
2.3. Final Build
7. Programming
7.1. Programing errors and fixes to final program
Marketing
8. The booth frame
8.1. Original Idea
8.2. Second Idea/Built Idea
8.3. Final Build
9. The Booth
10. Ways of Communication
11. T-shirt
12. Agriculture Research Paper
13. Safety
14. Budget
Research Paper
Implementation of Design Process
Brainstorming
Evaluation
Off/Def Stategy
Software/Sim
Safety
Support Docs
Quality/Compl

9. Section by Section Research Paper Design Process
Quality & Completeness

10. Research Paper (13%) Most Common Missing Information
Relating topic to your local area
Just mentioning Colorado, or your town, is not enough
You need to document a meaningful connection
Relating Topic to the current game
In 2016 Eight Teams didn’t even have this section

11. Design Process (57%) Implementation of the Design Process
Brainstorming
Analytical Evaluation of Design Alternatives
Offensive/Defensive Strategy Evaluation
Software/Simulation
Safety
Support Documentation

12. Implementation of the Design Process
Layout the process you will use
Show evidence that the design process was used effectively
A description of the design process used
Document items generated in this phase
Requirements
Testing
Brainstorming
Evaluations
etc

13. Brainstorming Not just sitting around and talking
Decide on a brainstorming technique
There are many to choose from
Document your brainstorming
Use tables and charts as well as text to
show different ideas that were discussed
Indicate how/why you rated ideas
Document ideas that were thrown out during this phase, and why

14. Analytical Evaluation of Design Alternatives
Method for choosing from the results of your brainstorming
Descriptions of all alternative designs, even the ones you throw out
Reasons for choosing the winner, as well as the losers
A table of pros & cons for each idea is good here
Use a grading system based on the pros & cons
Any analysis you had to do to help decide on a particular course of action (Show your math!)
Large/Small Wheels
Use of gears to enhance torque
Etc.
What tools were used to aid in the evaluation
And how did they help
This section is greatly helped with tables/diagrams/charts/etc

15. Offensive/Defensive Strategy Evaluation
Offensive Strategies
This is where you need to describe how you determined which points you are going for, and why
Some discussion of strategies that were discarded, and why, would also help
Defensive Strategies
This is usually the weakest section
Just because the robots don’t interact, doesn’t mean there aren’t defensive measures
Making sure the robot can maneuver around various items littered on the game floor
Making sure the robot can extract itself from being stuck for various reasons
Being able to avoid other robots, while still performing tasks
Etc.

16. Software/Simulation
Document the process that was followed to generate your software
Simulation is where you will lose points if no advanced simulation techniques are used
However, even if you have no simulation, it is only a total of 0.3 points overall
You can get some credit if you discus simulation techniques, and what they can do for you
You could also consider building a cardboard protoype that would allow you to get an idea of how it would fit on the field
This is an example of “simulation”, and if you do something like this, make sure you write it up
Debugging
How did you accomplish this? (debug terminal, print to screen, real-time debugger, etc)
Any tools used? Simulink, debuggers, etc.

17. Software/Simulation (cont)
Show that program functionality implements your requirements
Map to the rules that drove your design
Map to the strategies that you developed
Testing
Have a process for testing
Document it!
Both the process and the actual test results
Documentation to support statements
This is where a lot of references to support documentation could be useful
Detailed design
Test results
Etc.
Include your code in an appendix so you can reference it

18. Software/Simulation (cont)
Judges will be looking for “Consideration of good software design practices”
Comments
naming conventions
design simplicity
Modularity
Portability
etc.
These can most easily be seen in the actual code
If you just “state” that you did something, it will not be as good as being able to actually show the judge by referencing the code in the support docs.

19. Safety
Describe your general process for making sure you are working in a safe environment
List specific actions that were taken to implement safety
Include all documentation that illustrates your safety
Safety classes conducted
Training material used
Signatures on forms that show who took safety classes
Etc.

20. Support Documentation
Support Documentation was the most overlooked resource
Have already mentioned many items that should go here
Additional stuff not already listed in these charts
Daily logs of activities
Organizational Charts
Meeting minutes

21. Quality & Completeness (30%)
Have a documented set of criteria for your notebook
Manager of the Notebook should make a final review
Check for required items (see score sheet, as well as rules for a complete list)
Table of Contents (with page numbers!)
Standard Binder
1” margins
Proper Cover sheet
Etc.
Check for “weird” formatting
Inconsistent indenting
Mixed fonts/sizes
Words that are spelled correctly, but are not the correct word
Make sure you have all the required sections
Organized well
Easy to tell in what sections the various information will be located