Repeat Design Process

Within this category the focus is around determining if a notebook documents an iterative design process. As a team progresses through a season they will most likely undergo numerous design changes. This could be a completely new robot or a variation of a subsystem.

As modifications are being made, is the team looking at the following ensuring they are documenting updates. Additionally are teams identifying why changes are being made from one revision to the next in their documentation.

• Identifying the problem

• Brainstorm, Diagram, or Prototype Solutions

• Select Best Solution and Plan

• Build and Program the Solution

• Test Solution

A good way to indicate the changes that are being made from one revision to the next is to reference the previous pages that point to an older design phase.

One area that teams may forget to include in this area is programming. While the physical build of the robot is easy to track, teams should remember that there are often changes they make to their programming that should be documented.

For instance a team may change their drive base design from 4 to 6 wheel or implement a new drive base speed such as going from 360 to 450 RPM. This could require the team to update their drive base code or possibly make some modifications to their PID implementation that is being used. Maybe the team has learned how to implement odometry and now needs to include code for this. These changes and updates can be included as repeating the design process and thus can be a factor in this category that often gets overlooked.