Build and Program

This analysis uses the up-to-date rubric as of August 2025. As new versions of each rubric are announced, this article will be updated shortly following. The up-to-date rubrics can be found in this article and on the RECF website.

It is important to repeat each criteria of the notebook throughout the Engineering Notebook, rather than using each step once for the initial design cycle. Consistent repetition of each step will lead to higher rubric scores.

Criteria Definition

Records the steps the team took to build and program the solution. Includes enough detail that the reader can follow the logic used by the team to develop their robot design, as well as recreate the robot design from the documentation.

This section of the rubric is relatively straightforward: documenting the process of building or programming your solution. In this section, detail is key - thoroughly describing your step-by-step process for developing the solution. One important thing to note: the rubric explicitly calls for the steps taken to build or program the solution. Formatting these entries in a sequential format is key for a successful notebook.

The key to achieving maximum points for this criteria is through use of extreme detail when recording the action process for this step. Achieving a high level of detail can be accomplished through recording each step to complete the action, a list of all parts used in each step, and pictures of the action at various stages of completion, as a few examples.

An additional item to consider for this criteria is consistency - many engineering notebooks will begin with a high level of detail for the overall initial robot design at the start of a season, and then begin to use less detail with smaller changes later in the season. It is important to introduce a consistently high level of detail throughout the season for maximum points.

One common misconception within this category is that Programming documentation has to follow a separate structure when compared to the rest of the notebook. On the contrary, utilizing the Engineering Design Process and typical Build entry structure can help provide much more thorough and comprehensive documentation of your team's programming process. As such, these articles should be applicable to both areas.

Building and Programming

Outside of utilizing a sequential format overall, there are some general best practices that help to improve overall quality. The title of each entry, for instance, should be describing what was done rather than a generic "10/12 Mechanics Entry." In this way, it is easy to gain a sense of progression even just from reading page titles in the Table of Contents. Additionally, it is recommended to begin each entry with the goals for the meeting, a basic timeline of what you want to accomplish, and everyone who attended the meeting. Add lots of well annotated photos, any testing that occurs, and an analysis of the progress as well. The end each entry should include specifics of what was accomplished, and what should be accomplished by the next meeting.

In this segment, one effective way to format information is using an already established format, one that has already been detailed earlier in the notebook: the Engineering Design Process. While the Engineering Design Process (EDP) is mainly used to outline large, major goals and iterations, showcasing the EDP in minor tasks throughout the season is essential as well. For instance, applying the EDP to something as simple as fixing a broken lift could provide a clear outline of progress in the notebook. Defining the problem at the beginning of the entry, identifying and implementing solutions, and following up with additional testing are just some of the steps that are taken within this small fix that are also key factors in the EDP. Using these steps as headings within an entry of any size is an easy and effective way to format.

As far as programming specifics, there are two areas that help to set this section apart: flowcharts and pseudocode. Utilizing flowcharts can help to more effectively brainstorm different routes for the Autonomous Period, visualizing different routes and laying out potential solutions. Pseudocode can help to outline the logic that the program will follow for each step of an autonomous routine, providing more context behind steps taken in the program.

The included notebook photos are from the BLRS2 Over Under ('23-'24) Notebook. While the notebook did win Design Award at the 2024 World Championship, it should be noted that this is not a perfect notebook, though it is a good example to start with.