Ascend
Coding
Ascend
  • 🚀Introduction
  • VEX Robotics
    • 🛠️Building
      • 📏CAD Design
      • 🔧Best Practices
      • 🏎️Drive Trains
        • 🔩Screw Joints
        • 🥊Boxing
        • 🔵Bearing flats
        • 🛤️Fixing Friction
        • 🔥450 RPM on 2.75"
      • 🏍️Motors
      • 🪨Metal
      • Plastic
      • 🎈Pneumatics
      • ➕Additional Mechanisms
        • 🖨️3D Printing
        • ↔️Ratchets
        • 🏹Catapults
        • 🎣Intakes
        • 🏋️Lifts
    • 💻Coding
      • ⚖️Choosing Your Coding Environment
      • 🔴VEXCode Pro
        • 🖥️Getting Started
        • 🚗Drive Code
        • 🚴Coding Motors
        • 🌬️Coding Pneumatics
        • 🎛️Advanced
          • 📡Coding Autonomous
          • 📈Coding PIDs
            • ⬆️Drive PID Tutorial
            • ↩️Turn PID Tutorial
            • 🎸Tuning PIDs
              • 🔢Ziegler-Nichols Method
              • 📊Graphing PIDs
          • 📋Tasks
          • 🚝Advanced Drive Code
      • 🟡PROS
    • 📗Engineering Notebook
      • 📔Formatting
      • ⭐Notebook Walkthrough
      • 💠Decision Matrices
        • 📌Decision Point
      • ➕Additional Resources
    • 🏆Tournaments
      • 🗣️Team Interviews
        • 🪙Interview Tips
        • ⛳Interview Scoring
        • 🤽‍♀️Interview Practice Questions
      • 🤹Skills
      • ℹ️Ranking and Stats
      • 📷Filming Matches
  • Other
    • 🧑‍💼Management
      • 🕑Time Management
      • 👨‍👩‍👧‍👦Team Management
        • 👮Delegation
        • ⚓Optimal Team Size
      • 🖇️Code Management (GitHub)
      • 🚋Resource Management
      • ⁉️Stuck?
    • 🍎Physics
      • ⚙️Torque
      • 😑Stress Forces
    • 👾Extra stuff
      • 📸96504 Gallery
      • ⛑️VEX Team Resources (High Stakes)
      • 🏎️Driving Simulator
Powered by GitBook
On this page
  • Introductory Pages
  • Title Page
  • Table of contents
  • Engineering Design Process
  • Team Profile
  • Notebook Formatting
  • Goals
  • GANTT Chart
  • Budget
  • Content Pages
  • Game Analysis
  • Design Constraints
  • Brainstorming
  • Planning
  • Building
  • Testing
  • Tournament Analysis
  • Design Process
  • Project Management
  • Other Notebook Requirements
  • Conclusion

Was this helpful?

  1. VEX Robotics
  2. Engineering Notebook

Notebook Walkthrough

Step-by-step notebook guide

PreviousFormattingNextDecision Matrices

Last updated 1 year ago

Was this helpful?

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.

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

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.

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.

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.

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:

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.

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:

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:

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):

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:

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:

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!

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

📗
⭐
https://wiki.purduesigbots.com/team-administration/team-documentation/how-to-start-a-notebook/segments-of-the-notebook#the-team
https://recf.org/documents/2023/06/guide-to-judging.pdf/#page=40&zoom=100,44,62
Simple title page
Example table of contents from team 96504C. Some formatting adopted from team 96504P
Cite your sources!
Google docs has version history tracking! Use that or something similar to verify dates of contribution
Why the pie chart? Because it looks nice and conveys information effectively
Concise summaries of three specific game rules. Use your words, not the game manual's!
The Advantages / Disadvantages tables are adapted from team 515R's notebook
Not a complete list, but a good starting point
Give credit where credit is due! Note the small text underneath the table
A picture is worth a thousand words
Example code
Short and sweet
Be specific--the purpose of this is to allow you to fix these things later on so it doesn't happen again
Scoring analysis
Again, be specific and thorough when analyzing strategy
Show that the new design is better--because it is!
Note how this notebook also sets a tentative goal for the following meeting--that's time management!