New teams might wonder, what the heck is an engineering notebook, and why do we need one? Teams with a few seasons under their belt may want to strive for the Design & Excellence Awards, and take their notebook to the next level.

In a generic sense, the notebook is what laboratory scientists, inventors, and engineers keep to record their experiment/build/design activities, as a record for themselves or for others. It's a “daily journal” of sorts, where all important and relevant information about the project is included. Can't remember what that test result was from last week? Just flip backwards in the notebook, and there it is. (Photo credit¹⁾)

Why do VEX teams need one? First, it's just a good idea; that's why scientists and inventors throughout the ages have used them. For a robotics team, it also serves as a way to transfer information between team members if Person A did something last week, but isn't here today, and Person B is picking it up now.

From a trophy shelf-perspective, it's hard to win any trophies for said shelf without an engineering notebook. If a team works hard and has some luck on their side, they can rack up tournament champion and skills champion bling; however, all judged awards will expect to see a high-quality engineering notebook for your team to really even be in the running. The most obvious award relying on the notebook is the Design Award, but the Build, Create, Innovate, Amaze, and Think awards all rely on the notebook as well. You are unlikely to beat out another team for one of these awards sans engineering notebook; judges want to see your team's thought process, project management, testing, iterations, etc.

At a typical competition, teams with an engineering notebook hand it in when they check their team in first thing in the morning; judges (praise the volunteer judges!) spend all day reading through them and (combined with the other award criteria) make their award determinations. At the very end of the day, generally when match play or alliance selection is complete, teams pick up their notebooks from some central location. So if there's any vital information in the engineering notebook that your team needs during the day at a competition, be sure to have them write it down in a separate location, as they will not have any access to their notebooks during the tournament.

Veteran teams and coaches generally recommend using some sort of bound composition book. The REC website says, “A bound quad-ruled notebook is the preferred format. The notebook should never be edited.” In the past, the “preferred format” wording resulted in inconsistent interpretation by judges at different tournaments. In 2017 that phrase remains unchanged, but the Design Award Rubric now gives a 3-point bonus for a bound notebook in lieu of a 3-ring binder. Some teams still find that the binder approach works better for their team, and will continue doing things that way, with the understanding that they will not get the 3 bonus points. As of 2017, the Design Award rubric can be found on the last 2 pages of the Awards Appendix. (Photo credit²⁾)

Why does the bound book get bonus points? It shows that the work was done by students over time; printed materials in a 3-ring binder could be done by an “over-helping” adult for all the judges know, and could include retroactive additions which negates the spirit of a laboratory notebook recording daily work and observations. However, for some teams a bound book is not useful or doable given their meeting schedule or the number of people needing to work on the book at once.

But what about stuff that doesn't really fit into a bound notebook, like computer code? Some teams also maintain a small 3-ring binder with that other stuff (including outreach efforts, code, and anything else that's many pages and/or not directly related to the design/build process) and rubber-band it to their notebook and submit both at tournaments. Teams using the REC-provided notebook, which is 3-hole punched, can put the engineering notebook in the 3-ring binder and submit it all that way.

The Design Award rubric is crystal clear about what scores points for this award. The thing that this author's team did not realize in our rookie season is that there is lots of stuff that must be at the beginning of the book in order to score points in certain categories. Adding it later won't work. [Note: the information below is all related to the first page of the Design Award rubric; the second page of the rubric is based on the team's interview, which is not covered here.]

In years past, this author's team used color-coded post-it flags in their notebook to mark major events—in lieu of a formal TOC—but it doesn't really cut it. The REC-provided notebook and most commercially available lab notebooks include a built-in TOC, implying that it really is necessary. If a composition book doesn't already include a pre-printed TOC, teams should leave the first few pages blank for this purpose.

While not specified in the award criteria, many teams include some introduction pages introduction right at the start, with a group photo and description, followed by 1/2 page team-member bio-with-photo sections (age, school, interests).

At the bottom of each team member's half-page, specify the team member's role(s). Even for very small teams, where every member is involved in most aspects of the robot, should have specified roles identified somewhere in the book. Judges want to see specific roles identified as a sign of project management capabilities and the team's use of its human resources. Teams can invent their own roles; there's no pre-set list that must be used (“battery boy” was one role mentioned by a Worlds Excellence Award winner). This author's team uses regal titles—Building Queen, Cutting King, Programming Peon, etc. Having some fun here is allowed, and it is expected that team members will have multiple roles. Leaving some room for expansion at the bottom of each person's bio half-page is helpful.

The Design Award rubric states explicitly that it wants roles assigned in the “Resources” line-item:

The notebook shows good use of human resources by assigning members roles based on their strengths.

This author's team also includes a list of the team's goals for the coming year, which are decided as a group even before starting in on the new game.

In the Design Award rubric, full points are scored for this line-item if the notebook

describes the challenge at the beginning of the notebook with words and pictures and states the team's goals toward accomplishing that challenge

You have to describe the game? Doesn't everyone already all know what the game is??? Well, the judges would like to see that a team not only understands the game, but that they have done some sort of systematic analysis of it: how to score points, how to de-score (if applicable), design restrictions, etc. Analyzing the game at the beginning will lead to a more considered brainstorming process.

Taking the game analysis one step further, once a mastery of the rules and details is achieved, teams can brainstorm different match play strategies (being a defensive robot/wall-bot, being fastest to pick up game objects; handling multiple game objects at once so more points can be scored at once; a robot that is very good at picking up Game Object A, because they are higher-point objects, and being less good at picking up Game Object B; and so on). Thinking about what, specifically the robot should do leads naturally into the next step: brainstorming.

This section of information must come first in the notebook, after the team's introduction (if included). Adding this content later does not demonstrate to the judges that there was a systematic process that was used at the start of the season.

Full points in this category are awarded if the notebook

generates an extensive list of possible approaches to the challenge with labeled diagrams

Rookie teams may have the (understandable) desire to get building ASAP, and launch into prototype building, having fixated on one way to play the game, or one type of object manipulator. But a full brainstorming process, in which many different ideas are considered, leads to a better final product. In the engineering notebook, it's important to include all of the team's brainstorming ideas, including the road not taken. Judges want to see that a team considered many different ideas and didn't charge off to build the first thing they thought of. Be sure to include descriptions and sketches (they don't have to be architecturally beautiful blueprints, just sketches) of each thing the team dreams up. If one's engineering notebook is a graph-paper-lined book, this makes drawing in the book easier; if not, a team can draw them separately on graph paper and tape them into the book.

Make drawings in pencil, and then draw over them with ink when finalized.

The next thing that needs to be in a team's notebook is an evaluation of its various ideas from the brainstorming process. Full points are given if the notebook

explains why the selected approach was chosen, and why the other alternatives were not chosen

Again, note that last part—documenting the road not taken.

At this stage, your team should make a timeline that extends from now until your first tournament (or approximate date, if you don't know yet), laying out exactly what should be accomplished at each stage. A Gantt chart is one idea, but in general, the more detail the team can include here, and the more foresight that is shown, the better. Full credit in the “Resources” category is given if the notebook

shows the team's efficient use of time with an overall project timeline. The team uses checkpoints to help them know how well they are staying on schedule and readjusts their schedule as needed.

After the team's first tournament, the group may find that it needs another timeline, for modifications or programming that need to be completed between now and the next tournament. Be sure to include all subsequent timelines and project plans in the notebook.

Here's where achieving full credit gets a little crazy. Two separate line items in the rubric that net your team 3 points each are as follows:

• Design Process: Build and Program. The notebook

records the building and programming process in such detail that someone outside the team could recreate the robot by following the steps in the notebook.

• Usefulness. The notebook

is such a detailed account of the team’s design process that the reader could recreate the project’s history

For real. Could recreate the robot by following the steps in the notebook. This author is not sure how many teams achieve the 3 points in this category, but that is the standard against which teams are measured.

During the season, make sure that the team makes entries on every meeting day (and if work was done between meetings). This author's team refers to the engineering notebook as “the journal” to emphasize its daily nature. Even if the team did teeny-tiny amounts of stuff, it needs to be in there. Recommended for each day's entry:

• Today's date
• Meeting attendees
• Goals of the day's meeting. Go back to the overall project timeline that the team created after the brainstorming process, and be sure to include those steps in the meeting notes, or any sub-tasks developed from the overall timeline.
• What the team did in the meeting today, including drawings or photos if applicable. Include as much data as possible, and try not to get complacent as the year goes on. Instead of “We had drive practice today,” write “We had drive practice today and can now score 20 points in 1 minute.” Or, “The lifting arm stalls when we lift xx pieces, and here's what we will do about it.”
• At the end of the entry, make note of the goals not completed that will be carried over to the next meeting.
• The person writing the entry should sign & date the bottom of the page.
• Fill up the large white spaces on the page with diagonal lines (prevents unscrupulous scientists from adding content retroactively).
• Write in pen; if there are errors, make a one-line strikethrough.

Make sure that all team members take turns writing entries. It doesn't help the team in the “Teamwork” scoring section to have all entries written in one handwriting, even if it is the neatest. (Photo credit for this somewhat-unrealistic notebook page³⁾)

This author's team dedicates the last 15 minutes of the scheduled meeting to journal-writing and clean-up; everyone is doing one or the other. We can all leave on time, and we don't fall behind in journal entries.

But someday the team will fall behind. In that case, take notes (as detailed as possible in the time available) on a separate piece of paper, and tuck them into the journal so that at the next meeting, someone can enter them. The more a team can avoid falling behind, the higher-quality their entries will be. If a team is 4 meetings behind, whoever takes the journal home to enter all the back-content will end up doing a less-thorough job than if those entries were done one at a time, in the lab, on the day of the meeting.

If one team member has nothing to do in the middle of the meeting, they can certainly get that day's journal entry started, with attendees, meeting goals, and what has been done so far.

Don't forget to include entries written by the team's programmers. It's easy to include only build/design entries, and forget to document the programming and autonomous testing process. It's useful to include pseudo-code in your journal entries (full code printouts can be included in an add-on 3-ring binder), as well as keeping track of the values used for important variables or constants. These latter items tend to shift over time, and unless they are documented in the engineering notebook, no one will remember that holdPOT was originally 450 but now it's 520, and hence will not realize that important shifts have taken place in the structure or functioning of the robot.

Be sure to include a write-up of the team's performance at competitions, and make sure that competitions are easy to find in the TOC. Teams can download all match results, final rankings, playoff results, and skills scores from the tournament's RobotEvents website. Display the team's relevant data in a clear and consistent display from tournament to tournament. Also make note of any awards received, or playoff alliance number.

Before the year's first tournament, decide which match-activity statistics would be useful to know to evaluate the robot's performance realistically and identify weak areas. Create a grid for each robot team, with one row to be used for each match, and the columns going across holding the statistics chosen (balls in high goals, shots missed, win autonomous?, cubes dumped over the fence, etc). Assign a student or parent to keep this printout on a clipboard in the stands and tally the robot's activities in real-time for each match. Sometimes it's helpful for one person to be calling the “play by play” (high goal, low goal, low goal, miss, bonus ball, miss…), and the other person making tick-marks on the grid. Included these statistics for each match on the journal's competition page as well.

Finally, after each competition, the robot's team members should have a “pow wow” and reflect on everything that went well in the tournament, and all the things they would like to do differently in the future. Write down these reflections in the engineering notebook.