An Engineering Notebook provides a place for students to practice writing skills, express ideas through drawing, and create a chronological account of the team's use of the Engineering Design Process.
In the professional world, an engineering notebook is very important. Engineers use these notes as legal documentation of Intellectual Property and to communicate ideas and progress to other members of their team.
These notebooks serve a similar purpose in competitive robotics. The REC Foundation places great value on well-designed and executed engineering notebooks. One of the pathways to success in competition is the Design Award, which is primarily concerned with a team's application of a design process and how well they document that process in the engineering notebook.
Ultimately, the engineering design notebook should be considered a tool and not an end in itself. This Guide is an introduction to using the engineering notebook in an effective way. When used properly, an engineering notebook will strengthen a team’s critical thinking, collaboration, creativity, and communication.
The engineering notebook is first and foremost a chronological account of design decisions. Whether the notebook is hardcopy or electronic, it should always be a historical account of what a team has been through on their design journey. It should document the team's failures as well as their successes. Advanced teams' notebooks will include enough detail that a reader could recreate the team's robot or code following the steps in the notebook.
What Should You Use as a Notebook?
Notebooks can be created as hard-copy books or electronic versions. Hard-copy notebooks can be as simple as an English composition book and as fancy as a professional hardback notebook. VEX Robotics offers a good notebook for VRC teams here and for IQ teams here. Regardless of which book you decide to use, keep in mind that all notebooks should adhere to the following minimum requirements:
- All notebooks should contain a table of contents
- All pages should be numbered
- All notebooks should present a chronological account of the team's work during a single season
If you run out of room in a hard-copy notebook, another book can be used. Simply number the first book “1 of __” and fill in the total number of books at the end of the season.
Who Should Write in the Notebook?
A team notebook serves as a tool for the whole team: designers, builders, coders, drivers, and everyone else who helps with the robot or its code. Any or all team members can write in the notebook, and every team member should contribute to it in some way. Many teams designate a single member of the team to be responsible for the notebook. This “Notebook Manager” can ensure that the book is kept safe and that all entries are consistent with the team’s style and overall goals. Regardless of who does and does not write in the notebook, all team members should be familiar with the contents.
Who Should NOT Write in the Notebook?
Advisors, coaches, parents, and any other person who is not a member of the team should NEVER be permitted to add things to a team's engineering notebook. If your team uses 2nd signatures as witnesses to notebook entries, a non team member could do that if no team members are available. Everything else in the notebook should be created and entered by student team members.
What Should Be in the Notebook?
There are many things that can be put in a notebook, but not everything should be in the notebook. Major design considerations, pictures or drawings of prototypes, and data collected from testing should all be included. Entries may be in the form of drawings, printouts, or text. All steps of the Engineering Design Process should be detailed in the team's engineering notebook.
The team should document their project management practices including their use of personnel, financial, and time resources. The notebook should also include notes on the robot’s computer code, how it is designed to interact with the robot’s mechanical systems to create an overall integrated system. Placement of sensors for software feedback systems and algorithms used for the control of the robot should be clearly documented. A good notebook would allow a person who is unfamiliar with the team’s work to take over the robot design/construction based on a team’s detailed documentation.
Things to Leave Out of the Notebook
Quantity isn't always quality in a student engineering notebook. For example, a notebook should not include the entire game manual or any other document that isn't created by the team. If content doesn't demonstrate the team's use of the Engineering Design Process to design, build, test, or code the robot, it probably doesn't belong in the notebook.
The Notebook is Not a Journal
Daily journal entries that detail routine team business or non-robot projects like Online Challenges do not need to be in the engineering design notebook. Many teams create a separate “team journal” or scrapbook for those types of records.
A Team Journal (or album/scrapbook) is an opportunity to document everything a team does so that it can serve as a historical guide of lessons learned and best practices. It is not a design notebook, but rather a place for teams to tell their team story (a team historical timeline, team meeting notes, pictures, student biographies, notes from competitions, team members’ observations and thoughts, team organization practices, and any other information that a team finds useful). Teachers may choose to use the journal as a collaborative writing exercise, however journals are completely optional and will not collected by Judges. It is a way for teams to tell how the VEX Robotics Competition experience has helped them to develop as better students.
Visit this article for more information on the differences between an Engineering Notebook and a Team Journal.
There is no universally accepted “correct” way to organize an engineering notebook, but here are some tips to get you started:
- The team name and team number should be recorded conspicuously on the front cover of each volume of a hard-copy notebook; for electronic notebooks, the file name should include this information.
- If multiple hard-copy notebooks are used, each volume should have “## of __” on or in the front of the book (e.g., if three books are used, they should be labeled “1 of 3”; “2 of 3”; and “3 of 3” at the end of the season).
- A title page at the beginning of the notebook should include details like:
- Team Name, number, and school/organization
- A list of team members and the dates they joined the team; include an end date a member leaves mid-season
- Start Date and End Date of that specific notebook
- A table of contents should include:
- Page numbers
- Entry titles
- Entry dates
- Each page should include the following:
- Page number
- Title that describes the work completed during the work session
- Date of entry
- List of team members who worked that day
- Detailed descriptions of the work done that day, which could include text, sketches, photos, text plans/results, brainstormed lists, and ideas for the future
- Additionally, a large work may benefit from an alphabetical index of key terms and information found in that particular volume. This information would be added to the back few pages of the book after it is complete.
Criteria for Success
The Engineering Design Process
Each Engineering Notebook is created through a concerted effort by a team to document their design decisions. Teams should start their notebooks early and update them often.
Engineering is an iterative process whereby students recognize and define a problem, brainstorm and work through various stages of the design process, test their designs, continue to improve their designs, and continue the process until a solution has been identified. During this process, students will come across obstacles, encounter instances of success and failure, and learn many lessons. It is this iterative process that students should document in their engineering notebook.
The Engineering Design Process dictates the engineering notebook’s basic structure and content. Refer to the article on the Engineering Design Process for an in-depth description of the typical steps used by teams.
REC Foundation Judging Rubric
All team members should familiarize themselves with the Engineering Notebook Rubric. The REC Foundation notebook rubric is a scoring guide used by tournament Judges to evaluate the quality of students' work. It lists all criteria that Judges consider when scoring teams' notebooks. Teams looking to meet the highest standards will need to focus on the Expert column of the rubric. Judges will evaluate how well the team's notebook addresses each of these topics:
- Engineering Design Process
- Identify game and robot design challenges and goals
- Brainstorm and diagram or protype solutions
- Select the best solution and plan
- Build and program the solution
- Test solution
- Repeat design process
- Usefulness and repeatability of the team's documentation
- Usefulness of the notebook as a tool to record team and project assignments
- Notebook includes evidence that it was created sequentially through the design process
When studying the Engineering Notebook Rubric, consider what each rubric point means, and what a Judge might look for to quickly score a notebook on that rubric point.
Code in Notebooks
Not every line of code from every revision of a team’s program should end up in a team notebook, but it's important that the Judges can see that the team's code was developed in parallel with the robot. Teams should remember that the Judges are looking at the team’s robot design process, including their code. The Judges’ job of reviewing teams’ work is difficult when there aren’t many references to the builder working with the coders as part of the design process. Judges are left to assume that rather than developing the code in parallel with the physical robot, robot code was a last minute afterthought. Teams that include documentation of code development as part of their notebook will paint a better picture for judges to evaluate their design process.
It is up to each team to determine how much code to include in their engineering notebook. This will vary from team to team, and robot to robot. Teams should include enough code to communicate their design process to judges. Teams should record code development discussions and include examples, which could be as simple as pseudocode, as well as test results. For example, the a notebook entry might include the definition of which sensors/motors are assigned to which port, and might include snippets of exceptionally innovative portions of the team's code.
An example of code to leave out of the notebook is the multiple versions of similar code that are created in a debugging process. In this case, the team should simply record the issues encountered during the code generation and testing and what was done to overcome them.
There is no need to include every revision of code in the engineering notebook. Teams may wish to keep all versions of their code in a team journal so as to track all of their code development.
Tips for Good Notebooks
- Store your hard-copy notebook in a safe place.
- Make sure you have backups of your electronic notebook if it's not stored in the cloud.
- Never let a non-team member add anything to your notebook.
- Start hard-copy entries at the top of each page and work down.
- All entries in hard-copy notebooks should be legible.
- Label everything you add to the notebook, especially sketches and photos.
- Use a numbering system to label figures and drawings so they can be easily referenced.
- Try to fill empty spaces with pictures, design drawings, or pseudocode.
- All work in hard-copy notebooks should be in pen or permanent ink.
- Do not use markers that can bleed through the paper in a hard-copy notebook.
- Document research and cite all sources.
- Show all mathematical work, not just the answers.
- Pages should not be added or removed from a hard-copy or electronic notebook.
- Correct errors in a hard-copy notebook by putting a single strikethrough line; Judges want to see mistakes, too.
- Attachments such as pictures or printouts should be taped or glued in a hard-copy notebook. A written entry should accompany the attachment to validate its entry into the book.
- Document failures and wrong turns, not just successes and the final robot.
- Code development should be documented alongside robot development.