# Notebook Walkthrough We'll go through most of the notebook sections you should include, with examples. Every page of the notebook should make it easier for the judges to give your team a perfect score on the notebook rubric. Here's the notebook rubric, for reference: *** ## Introductory Pages These should go at the front of your notebook; they organize and propel the rest of the notebook. ### Title Page The title page should prominently feature the team name, number, and logo (if you have one). This allows the judges to easily identify which notebook is yours and makes it more memorable when they are distributing awards.

### Table of contents The table of contents organizes the rest of the notebook. When appropriate, each entry should be color-coded based on the Engineering Design Process. For example, the game introduction falls under the "ask" step, so it's colored red in the table of contents below. There are a number of ways to format the table of contents itself, but it should be clear when each entry was made and what step of the Engineering Design Process it shows.

Example table of contents from team 96504C. Some formatting adopted from team 96504P

### Engineering Design Process The Engineering Design Process is the essence of VEX Robotics. Thus, a brief description of the process, in the form of a graphic or text, should be included in the notebook. Make sure to cite your sources for images that are taken from another website!

### Team Profile After the Engineering design process, you should include a brief description of the team. This helps the judges match faces to teams, and makes your notebook more memorable. For a great example of a team profile (and other good notebook advice), check out ### Notebook Formatting Next, we recommend including a page about how the notebook is formatted. This should give the judges a basic idea of how the notebook is set up, and allow them to navigate and grade the notebook quickly.

Google docs has version history tracking! Use that or something similar to verify dates of contribution

### Goals The goals section can be very short, but your team should outline a few targets to reach. A few example goals: * Qualifying to States / Worlds * Winning a tournament * Learning a new programming technique * Building a low friction drivetrain ### GANTT Chart A GANTT chart is a simple, concise, and effective time management tool. It gives a rough outline of how much time should be allocated to each aspect of robotics and demonstrates advanced time management skills. Here's an example early-season GANTT chart:

### Budget Following 515R's example, we recommend including a budgeting page at the beginning of the notebook. This will help your team to get a realistic estimate of the financial resources necessary to compete at the level you want to. Again, this shows the judges that your team can manage the project diligently and effectively.

Why the pie chart? Because it looks nice and conveys information effectively

## Content Pages These pages make up the bulk of the notebook; they document the designing, building, testing, and refining of the robot and game strategy. ### Game Analysis The game analysis section has four main goals: 1. Describe the **goals** of the game and how to score points 2. Document the **specifications** of field and game elements 3. Discuss the game **rules** in-depth 4. Determine which game **strategies** are viable #### Describe Goals The engineering notebook rubric states that teams must: > Identify the game and robot design challenges in detail at the start of each design process cycle with words and pictures. State the goals for accomplishing the challenge Thus, it is important to explicitly lay out the goals for the game. Here's a simple example for VEX Over Under:

#### Document Specifications Next, make sure to identify the dimensions of **each** field element and game piece. This will come in handy later, during the designing phase. Here's an example of the goal dimensions in Over Under.

#### Discuss Rules After that, describe the specific rules of the game. We recommend giving a broad overview of the scoring and penalty rules, then summarizing each specific game rule.

Concise summaries of three specific game rules. Use your words, not the game manual's!

#### Determine Strategies Then, list out some of the potential strategies that might be viable. This will help with the designing of the robot later on, as it shows you which aspects of the game are the most important. We analyzed 7-8 different strategies in Over Under; here's a small snippet:

The Advantages / Disadvantages tables are adapted from team 515R's notebook

### Design Constraints While not technically required by the rubric, adding a short and sweet section on the basic design constraints in VEX adds an element of completeness.

Not a complete list, but a good starting point

### Brainstorming This is where your team generates possible designs for the robot. The Engineering Notebook Rubric states that the notebook should > List **three** or more possible solutions to the challenge with labeled diagrams. Citations provided for ideas that came from outside sources such as online videos or other teams. Each subsystem of the robot should have at least **three unique designs**, in order to earn full credit on the rubric. Each design should include a full **CAD** (or at least a detailed drawing), as well as **labels** for each aspect of the design. Then, **explain the design** and list the advantages and disadvantages of it. Here's an example page showcasing a possible design for the drivetrain:

Give credit where credit is due! Note the small text underneath the table

### Planning At this point, your team should have analyzed the game and identified three possible designs for each subsystem of the robot. But how do you know which design you should build? That's the purpose of a **decision matrix**; it determines the best design by comparing each design's strengths and weaknesses. Testing also works, but the decision matrix is more efficient. The Engineering Notebook Rubric says that the notebook must: > Explain why the solution was selected through testing and/or a decision matrix. Fully describes the plan to implement the solution. Here's an example of a **decision matrix** for the drivetrain. Make sure to explain each criteria in the decision matrix. See the page on decision matrices for more information on how to make one.

Furthermore, make sure to **fully describe the plan** to implement the solution. The plan doesn't have to be extremely detailed or complex, but it does have to be there.

### Building Now, it's time for the fun part! Once you've determined the best design, it's time to build it! According to the Engineering Design Rubric, the notebook should: > Record the steps 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. That is, the notebook should include enough detail that anyone could re-create the exact robot just from the notebook and the materials used. **Label** images as much as possible, and make sure to **explain every last screw** on the robot and **why** it is there. Here's an example of a page detailing how part of an intake was built:

It's worth noting that you should also include the full **code** of the robot after every major revision. When only a small part of the code changes, only include that bit of code, and make sure to describe what changed and **why**. Here's a small snippet of a main loop, in C++

### Testing Does the robot work? Well, there's only one way to find out. Test it! The Engineering Notebook Rubric is very clear; the notebook should > Record all the steps to test the solution, including test results. There's a lot of freedom in terms of how you decide test the robot. Of course, the tests should be a valid **measure** of the **effectiveness** of the robot or subsystem. Here's an example of a drivetrain test:

### Tournament Analysis Tournaments are a great way to stress-test the robot under intense gameplay. After each tournament, your team should analyze: * How and why the robot malfunctioned * Number of points scored from each element of the game in each match * Other robot designs and strategies that worked well Here's an example of how to document the problems the robot encountered:

Be specific--the purpose of this is to allow you to fix these things later on so it doesn't happen again

Here's an example of scoring analysis from Spin Up. Note how we kept track of how we scored points, which allows us to see our strengths and weaknesses.

Here's an example of how to analyze other strategies (for Spin Up):

Again, be specific and thorough when analyzing strategy

## Design Process At some point in every team's season, they will realize that their current robot simply will not do. Then, they are forced to redesign and start from scratch. The Engineering Notebook Rubric is well aware of this fact; one of the requirements is > Show that the design process is repeated multiple times to improve performance on a design goal, or robot/game performance. Thus, a redesign has to be properly justified in the notebook. Perhaps the robot needs a faster drivetrain or a smaller chassis, so it can navigate the field faster. Or maybe the other mechanisms on the robot can be replaced with something better. Whatever it is, make sure the notebook explains why the new design will be better than the old one. Here's an example of a redesign justification from Spin Up:

Show that the new design is better--because it is!

## Project Management This part of the notebook is intuitive, but often overlooked or implemented inconsistently. For each meeting, there should be set goals, and the notebook should evaluate whether or not the team met those goals at the end of the meeting. Additionally, the notebook should keep track of time and resource constraints that are relevant to the team. The Engineering Notebook Rubric puts it this way: > Provides a complete record of team and project assignments; team meeting notes including goals, decisions, and building/programming accomplishments; Design cycles are easily identified. Resource constraints including time and materials are noted throughout. There are a couple of ways to do this; we recommend setting 2-4 goals per meeting and evaluating the meeting at the end. For example, here's the very first part of a meeting entry:

And here's the corresponding summary at the end of the meeting:

Note how this notebook also sets a tentative goal for the following meeting--that's time management!

## Other Notebook Requirements We've covered 90% of the notebook, but there are a couple more requirements to keep in mind (based on the Engineering Notebook Rubric). Here's the first one: > Team shows evidence of independent inquiry from the beginning stages of their design process This simply means that teams should take initiative and test their own designs, instead of simply copying from another team online. The next requirement refers to the completeness of the notebook: > Records the entire design and development process in such clarity and detail that the reader could recreate the project’s history. That is, every aspect of the designing, building, coding, and testing of the robot should be included in the notebook so well that anybody could build the exact robot using only the notebook as a guide. The last requirement is why all of the example notebook pages have dates and signatures (yes, they were redacted) in the footer of each page: > Five (5) points if the notebook has evidence that documentation was done in sequence with the design process. This can take the form of dated entries with the names of contributing students included and an overall system of organization. For example, numbered pages and a table of contents with entries organized for future reference See the "Formatting" article for a good example of how to incorporate digital signatures in the notebook. ## Conclusion That's it! Follow all of the above steps, and your notebook will shine! --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://ascendrobotics.gitbook.io/ascend/vex-robotics/engineering-notebook/notebook-walkthrough.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.