Notebook Designs and Decisions#

This section will cover both what needs to be in the notebook and the decisions you need to make about it affecting both individual sections and it as a whole.

Attention

The engineering notebook is completely OPTIONAL. Having a notebook is NOT a requirement for any award. However, judges can technically still ask for the notebook for more information, so some teams still choose to make one. This article remains here for legacy reasons for teams that wish to make engineering notebooks, even though it is completely optional and not required for teams to still have a shot at awards. There have been several instances of teams winning high level awards like Inspire and Think while having no engineering notebook.

Whole Notebook Decisions#

Condensed vs Long#

A trap many teams fall into is that a longer notebook is a better notebook, especially if it’s actually quality writing. Unfortunately, that is not necessarily true.

At a lot of competitions, especially with the notebook being completely optional, judges don’t have a lot of time to read your notebooks. They will likely take a cursory scan at a few pages and take a more detailed look at certain pages. Thus, even if you do write a great but long notebook, they might miss the highlights and rank you lower than you should have. The solution to this is to create a condensed notebook.

This is where you make a purposeful effort to get rid of redundancies and make sure everything written in the notebook serves the purpose of being read and getting things checked off of awards.

So if you know your state competitions are going to be more than a couple of days, write a long, detailed filled notebook. But if it is only a day long, write with every section having a purpose.

Handwritten vs Typed#

This one is a team decision. Some teams swear judges prefer handwritten notebooks, but there is no proof for that. But if you’re a small team or you would prefer to write, do that. Be sure that the handwriting is consistent and legible! Typed notebooks are a lot easier to organize, and judges will definitely be able to read them.

Serious vs Charming#

A team’s notebook is an extension of its personality and branding. Some teams try to come across as an engineering firm or at least very serious, while others act the opposite.

You should try and reflect that in your notebook. Neither way is better, but it’s good early on to figure out your team’s way of acting and writing in a manner that fits it.

Generally, humor is acceptable, but try to keep jokes down to a minimum (after all, the engineering notebook is meant to be a professional-grade document).

Note

Having a consistent team brand is important so judges remember you. A large amount of winning awards is being remembered and advocated for by the judges.

Therefore, having consistent branding helps judges know what team they are talking to and what they know about you.

Individual sections#

Section 9.2.2 of Game Manual Part 1 lists out the type of things that are expected to see in your notebook.

They are listed here:

  • Problem Definition

  • Information Gathering

  • Brainstorming Solutions

  • Concept Design

  • System Level Design

  • Testing

  • Design Improvement

  • Production

  • Promotion

  • Budgeting

  • Planning

  • Outreach

Specific sections named in Game Manual Part 1, the Judges Manual, and Notebook Guidelines are not plentiful. They include a team plan, which is pretty much all non-robot writing—a sustainability plan, a strategic plan, and a business plan all fall into it, and doing one of these sections is required for Inspire award, and telling us what they want in the notebook (listed above). It falls to the individual notebook writers to figure out what they specifically want to call each section and what to put in each section.

Daily Logs and Other Ways of Documenting#

This might be the most common way of documenting in notebooks. Even teams that are so-so about attempting to write a notebook have a couple months worth of logs because overall they are not that hard to do.

Each team approaches it differently, but a standard approach is as follows.

Date

Members of Team Present

Tasks & Pictures

More Information, if the Task Was Completed

Lorem ipsum

Dolor sit amet, consectetur adipiscing elit

Sed do eiusmod

Tempor incididunt ut labore

Et dolore magna

Aliqua ut enim ad minim veniam

There are other methods such as weekly, pure goals, or other engineering based methods such as agile (if you pursue the latter you can use those hard won mentors you have gotten). Weekly or bi-weekly is the same as above, but the date becomes a range and you talk about what happened over that period of time. This is better for a team that has only a couple of people doing the logs because overall logs get more and more tedious.

Pure goals is simply as follows.

Date

Goal and Goal Date

Was the Goal Completed in Time?

Quis

Nostrud

Exercitation ullamco

Nisi

Ut aliquip ex ea

Commodo consequat

Duis

Aute irure dolor

In reprehenderit in voluptate

Building Section and Documenting the Robot#

You have spent a bunch of time reading the rest of this manual to learn about the robot and how to build it. The building section is about how your robot fulfills the challenge, and what the driving factors were in building your robot.

Information about parts and materials, as well as pictures of every mechanism (plus captions) will help the judges piece together how the robot works mechanically. Explanations of the components will illustrate the thought processes behind the design.

Ample graphics (CAD screenshots/renders, pictures, etc.) will help judges understand how it works and why it is useful. However, make sure that each graphic has a caption or explanation. Do not expect judges to understand how your robot works through pictures only.

As with most documentation, using actual CAD screenshots or real world photos is generally better then high quality renders. While renders are interesting from a technological and aesthetic perspective, they usually take more time and effort and also don’t convey your engineering process as well. CAD screenshots tend to make the document more like an actual engineering process documentation and can look much more professional, even if they aren’t as aesthetically pleasing.

Additionally, use math in these explanations to target the Think award.

The second part is much more documentation and writing heavy, but in some ways it is easier. As you are building a robot, you will not get your final bot in the first attempt.

Think about telling a story of how your team progressed from brainstorm and idea conception to prototyping and final design. The judges love to follow a logical sequence of steps as it shows how the team thought through mistakes and improved upon successes.

Each time you iterate upon a part of your robot or move a step further in the engineering design process, document it. Important questions to ask while writing this section are below.

  • What prompted this change/why was this change made?

  • What was the change?

  • How was the modification enacted?

  • What were the results (good and bad)?

  • How can this design be further improved?

This also includes your first unrealized ideas that your team talked about right when the team came together after the season was released.