Rocking the Engineering Notebook
Rocking the Engineering Notebook
a few tips compiled by Nathan
a few tips compiled by Nathan
The engineering notebook is the #1 most underrated part of VEX. So many teams ignore the notebook and only build their robot. This is a huge mistake. Of the 6 awards at a standard competition. Three require a solid engineering notebook. By making a solid notebook, you are doubling your chances of qualifying for States or Worlds. Most importantly, the engineering notebook helps you develop real world skills. Every engineer must be able to document their design and explain why it is important.
At first, the engineering notebook can appear very daunting. However, the REC Foundation tells you exactly what they are looking for. The Engineering Notebook Rubric and the VEX Judges Guide explain step by step what the judges do. By analyzing these tools, the notebook becomes a matter of following a process. This document is my own interpretation of these tools. I have combined it with feedback I have received from judges across Texas and New Mexico. If you follow the steps in this doc, your notebook will stand out from others at regional and state competitions.
At the start of the day, the judges skim the notebooks. If your notebook is “developed” they set it into a pile for consideration. If your notebook is short and incomplete, they set it aside and ignore it. After that, judges will look through your notebook and give you points based on the Engineering Notebook Rubric. The judges will be looking at the rubric at the very moment they judge your notebook. Remember, it doesn’t matter if you have everything in the rubric. It only matters if the judges notice you have it. This means you have to make it obvious you have everything in the notebook.
That’s why I created this guide. This guide is designed to walk you through the steps of creating an engineering notebook. Everything in this manual will make your notebook easy to grade. Everything down to the exact wording of suggested page titles. Even stuff that seems small can boost your notebook up the rankings. Ultimately, it should be extremely difficult to deny your team points on the rubric.
In the real world, engineering notebooks are used to document (in chronological order) the design process for patenting purposes. As a result, there are some conventions you must follow:
Each page must be numbered and listed in the table of contents. To make it easy, list the page in the table of contents as soon as you finish it. It’s no fun going back to fill in missing entries.
Start each page at the top and work your way down. If there is any extra space, cross it out (with a straight edge!) and sign the cross-line. Furthermore, each page must be signed and dated by a designer and a witness. Everything must be written in blue or black ink. It is best to do all of this before the next page is started. In a crunch, you can mark incomplete pages with sticky notes.
If you make a mistake, cross it out with a single line and initial next to the mistake. This also makes your notebook look neat.
Gluing in graphics is necessary for a good notebook. (Tape is allowed, but discouraged.) Once you glue something in, sign your name so that it crosses the graphic and the notebook page. This is a “tamper seal.” Everything should be cut to the size of the notebook. Nothing should ever be folded.
If you conduct physics calculations pertaining to the robot, show the work in the notebook. Doing some basic kinematics for a launcher can be super helpful in the design process. It’s also super impressive for judges.
Every time you use a picture or reference an idea from an outside source or another team. You must cite it. I recommend using the team number to cite ideas. (e.g. “picture from 136S’s reveal video” or “picture from 26982E’s Instagram”) This is worth points on the Engineering Notebook Rubric.
Take care of your notebook. Don’t make it look like you dragged it behind a car. Anytime you draw a line, use a straightedge. It makes the book look much more professional. Also, make your handwriting decent.
Your engineering notebook should be filled with quality content. Here is a breakdown of the types of pages I include (or wished I included). Anything you do pertaining to the robot must be recorded.
The titles of these pages correspond with points on the rubric. If you are making an “Identifying Design Challenges” page for the February League Day, title it “Identifying Design Challenges: February League Day.” Similarly: if you are making a Project Management page for a new parts order, title it “Project Management: September Parts Order.”
At minimum, this should be the first 3 pages in your engineering notebook. Use detailed explanations, glued in pictures, and dimensioned sketches to describe the challenge. Explain every element of the game that poses a challenge to your design. This includes unusual rules, difficult game elements, and towers that could ruin autonomous. (The game manual appendix contains all field dimensions. For Tower Takeover, I drew the three tower heights with dimensions.) State your “goals for accomplishing the challenge.”
Explain how you managed parts to build your robot. Include plans for managing the team’s finances over the season. I recommend inserting spreadsheets with budget breakdowns and parts orders. Last season, Mario glued in our APS Grant application. I glued in the cost and quantity of our first parts order. It is also a good practice to create entries on fundraisers (like running the pizza window or going to businesses for sponsorships). Be sure to emphasize that students led the charge.
Similar to resource management, project management pages describe how you managed the team to complete the challenge. These pages include specific team member assignments and leadership info.
(a requirement for the Think Programming Award)
Joel included two pages explaining our program’s version control and structure. He also broke down the GitHub structure. You need at least two pages on this every year. Try to put it towards the front.
This fulfills one of the major rubric points: “Records the entire design and development process in such great clarity and detail that the reader could recreate the project’s history and build the current robot from the notebook.” In short, your Design Process Daily Logs should contain everything you did to the robot.
Describe in detail the design challenges that the team noticed at competition. (Possible design challenges include needing more driver practice, losing connection in a match.) Be sure to name specific team members who noticed each problem.
After Identifying Design Challenges, create a plan to fix the issue. Include brainstorming with in-depth descriptions of three possible solutions. (Cite multiple team members who contributed to the brainstormed solutions. If you have trouble citing multiple team members who contributed, use this as a good reminder to ensure you are working as a team.) Be sure to number each possible solution. If you have more than three, that is excellent, but you must have at least three.
The VEX Online Challenges are one of the best kept secrets of big teams. While the judging of these challenges is a bit random sometimes, you can win money and a spot at Worlds. Because of the stakes, submit as many as you can. Be sure to scour the requirements and look at previous winners. (They tend to change from year to year.)
As you create the submissions for these challenges, be sure to document it in the notebook. In Tower Takeover, my team wrote about our website and glued in one of our essays. One of the Texas judges specifically told me this set our notebook apart. (If you do not make notebook entries about online challenges, local judges will not know you submitted anything.)
Once you have established a program, it is good to reach out and help other teams start. Be sure to document with pictures and descriptions what you did.
Be sure to glue commented code into your notebook. Follow the conventions for signing the edge of charts/pictures and crossing out blank space. In addition, write notes glued in code chunks. Point out major elements and changes. Give an update on how you are utilizing the programming structure and version control.
For code like PID, exponential drive, or odometry, more information is needed. This is a great place to demonstrate knowledge. Programming Breakdowns dive deeper than regular software entries: What process did you use to develop this code? How did multiple programmers contribute? Did you cite outside resources? How are you applying advanced math concepts to the program? In what ways does this aid the driver or improve auton beyond a more common approach? How did you eliminate specific bugs? I recommend including charts and code segments, but the bulk of this is a written explanation.
When you test the autonomous mode, log the points scored in a chart. (Don’t skip over the bad runs.) At the end of the day, copy the chart into Google Doc and print it out. For autonomous testing entries, I glued in the chart and explained what we changed in the program. These entries fulfill a rubric requirement and are a good way of tracking the accuracy of your autonomous mode. Here is an example chart.
When testing a launcher (or other robot mechanism), log consistency experiments. Keep the robot in the same spot and run the launcher over and over. Use a sheet similar to the auton testing chart. When you glue it, write a breakdown of the experiment: What patterns did you notice? Is the launcher/mechanism statistically consistent? How did you ensure that the conditions were the same for every test? Were there any possible experimental errors? What steps will you take in the future to improve consistency?
Similar to the autonomous testing chart, log all driver practice and glue it in. This document has different tabs for logging skills runs, practice matches, and time spent by each driver. After you glue it in, be sure to explain the goal of the driver practice: What aspects need to improve? Can software changes aid the driver? Are the team strategies working? Do the spotters effectively communicate with the driver?
Include detailed CAD drawings of your robot. While I never had the chance to do it myself, I recommend building robots in CAD first and then translating it to physical parts. With a quick Google Search, you should be able to find almost every VEX part premade in Autodesk Inventor. (Autodesk Inventor has a free student version.)
To make the daily log more detailed. Feel free to split it up between multiple people.
Document discussion during the team meeting (both full team, sub team, builders, and programmers) How did the team establish the meeting goals? What goals will be reconsidered later? What administrative duties need attending to? This section can blend into the following one.
^Make sure to underline these. This is a must for every entry.
List specific challenges with the robot that need to be addressed
(e.g. fix the tray slide-out catching the top cube)
(e.g. test and monitor intake compression)
(e.g. address odometry code not seeing the gyro)
^These points can correspond to other entries (from the previous page) and daily log sections.
List specific goals for the meeting
(e.g. prepare for the Albuquerque Public School Foundation to visit the lab)
(e.g. create materials for starting a team at Eldorado)
Draw and describe at least three possible solutions. Clearly number each solution. You descriptions and drawings should give a reader a general idea of what each possible solution would do.
^Make sure to include these section headers. It makes it easy for the judges to give you points
Explain why you selected the solution. What factors did you consider? What was the biggest reason why you chose the solution? If team members disagreed, how did you come to a consensus? Walk the reader through the team’s entire thought process. In some cases, use an engineering decision matrix to assign numerical values to certain design features.
^It is very easy to lose points here. So many teams forget to explain why they chose the solution.
How will you implement the solution? Will this be spread across multiple days? What team members will work on this assignment?
Include pictures of students building the solution. Explain how multiple team members contributed to building it. How did you build the mechanism? Were there any unforeseen problems? How did you overcome these problems?
If the needed solution is software based, use this section to guide your response. Explain how multiple programmers contributed. How did you program the solution? Were there any bugs or problems? How did you overcome the bugs?
Update readers on your progress in comparison to the overall project timeline. Cite specific deadlines. Briefly mention how you will stay on track.
I did not conjure this daily log structure out of nowhere. The specific titles of each section directly correspond with major points on the Engineering Notebook Rubric. Try to include as many of these sections as possible on every daily log.
This page was originally created after the Tower Takeover Competition and was later modified during the Tipping Point Season. While the rubric does not change much, make sure and check on it. As the years go by, competitions will change. Be sure to check the latest version of the Judges Guide. (The Engineering Notebook Rubric is in the Judges Guide.) I highly recommend talking to judges after the event and asking them for advice. (This is extra important at Signature Events and Worlds where the judges are especially knowledgeable.)