// Section 01

Sensor Notebook Templates 📝

🗺️ Flowchart — Adding a sensor — notebook entry workflow

When you add a sensor to the bot, the notebook entry has a specific shape: which sensor, why, install, test, results.

flowchart TD
    Start([Decided to add a sensor]) --> Why[Document WHY:
what problem does it solve?
which question does it answer?]
    Why --> Pick[Pick sensor type:
use sensors-roadmap flowchart]
    Pick --> Install[Document INSTALL:
port number, mounting,
wire color/length]
    Install --> Code[Document CODE:
declaration in main.cpp
helper function if any]
    Code --> Test[Document TEST:
what value range observed
at what physical position?]
    Test --> Threshold[Document THRESHOLD:
chosen value + why
e.g. 200 = our cones detect]
    Threshold --> Done([Sensor entry complete])

    style Start fill:#1e293b,stroke:#22d3ee,stroke-width:2px,color:#e2e8f0
    style Done fill:#1e293b,stroke:#22c55e,stroke-width:2px,color:#e2e8f0

Engineering notebook entry patterns specifically for sensor work. Five entry types: build, calibration, programming, debug, and tournament logs. Each one structured to satisfy EN1–EN5 rubric criteria with sensor-specific evidence.

📝 Notebook Templates 🏆 Student-Authored 🔮 Sensor-Specific

Why Sensor Work Deserves Its Own Templates

The standard engineering notebook template (covered in Notebook Template guide) handles general design entries well, but sensor work has rhythms that don't fit cleanly:

Calibration entries are mostly tables of measured values. Different from a build entry.
Debug entries trace from symptom to cause to fix. Different from an iteration entry.
Tournament logs for sensors capture what worked under venue lighting, what re-calibrated. Different from match notes.

The five templates in this guide are designed to be reused across the season. Pick the right one for the work you did, fill it in, paste sensor data, photo of the mount.

The Five Entry Types

Build Entry	You mounted a sensor. What part, where, why, with what hardware, and what does it look like? — Section 02.
Calibration Entry	You measured live values from a sensor and built a lookup. Hue ranges, pot angles, GPS reference points. — Section 03.
Programming Entry	You wrote or revised code that uses a sensor. Pseudocode or annotated code, test results, integration with chassis library. — Section 04.
Debug Entry	A sensor wasn't working. You traced the cause. Symptom, hypotheses, tests, root cause, fix. — Section 05.
Tournament Log	What sensor performance looked like at a real event. Venue conditions, recalibrations needed, failures observed. — Section 06.

Student Authorship Reminder

⚠️

Students write their own notebook. Use these prompts to record your actual observations, decisions, and reasoning. A template supplies questions, not answers.

Related Guides

📚

Notebook Pathway

Full notebook setup and rubric overview

📝

General Notebook Template

Standard build/iteration entries

🔮

Sensor Onboarding Roadmap

When and which sensors to add

1 of 7

// Section 02

Sensor Build Entry 🔧

Use this when your team has just mounted a sensor for the first time, or moved an existing sensor to a new location.

What This Entry Captures

Why this sensor was chosen (decision rationale).
Where it was mounted (location, photo, sketch).
What hardware was used (standoffs, brackets, cables).
Initial sanity check that it's reporting data.

Template

Sensor Build Log — [SENSOR NAME]

Date

_______________________

Author

_______________________

Sensor type

_______________________

VEX part #

_______________________

Port

_______________________

Robot

_______________________ (Clawbot / Hero Bot / Comp Bot)

Why This Sensor (EN1: Identify)

Question: what problem does this sensor solve that we couldn't solve without it?

Your answer: ___________________________________________________________________

_______________________________________________________________________________

Alternatives Considered (EN2: Brainstorm)

List at least two other ways the team could have solved the same problem, and why you picked this sensor over them:

Alternative A: ___________________________ — why not chosen: ___________________
Alternative B: ___________________________ — why not chosen: ___________________

Mounting Location (EN3: Plan)

Where on the robot is it mounted? Why this location?

Location description: ___________________________________________________________

Reason for this location: _______________________________________________________

Photo / Sketch (paste below):

[ PHOTO OR SKETCH OF MOUNT ]

Hardware Used

Part	Part #	Quantity	Purpose
__________	__________	__	__________________
__________	__________	__	__________________
__________	__________	__	__________________

Build Steps — Evidence for Optimize

Brief sequence of how the team mounted it. Bullet points are fine. Include any improvisation:

______________________________________________
______________________________________________
______________________________________________

Initial Sanity Check (EN5: Test)

Did the sensor return live data when first powered on? What did the V5 Brain screen show?

Result: ______________________________________________________________________

If it didn't work first time, what did you change? ____________________________________

What's Next (EN6: Reflect)

The next step for this sensor is: __________________________________________________

(Likely: a calibration entry, see Section 03.)

Tips for Filling This Out Well

Be specific in "Why this location." "Mounted on the rear of the robot, 10.5″ off the ground, because the GPS Sensor needs to see the field code strip and game elements would block a forward-facing mount" is much better than "Mounted on the back."
Photos beat sketches. A clear photo with arrows pointing to relevant parts is judge-friendly. Take the photo at the time of build, not later.
The "alternatives considered" section is where EN2 (Brainstorm) is graded. Don't skip it. Even if the choice is obvious, name the alternatives.

2 of 7

// Section 03

Calibration Entry ⚙️

Use this every time you measure live sensor values to build a lookup table for code use. Hue ranges, pot angles, IMU drift checks, GPS reference points.

What This Entry Captures

The setup conditions (what was measured, where, lighting).
The raw measurements (table of values).
The decisions made from those measurements (constants, ranges).
Re-calibration triggers (when to re-do this).

Template

Sensor Calibration Log — [SENSOR NAME]

Date

_______________________

Author

_______________________

Sensor

_______________________ (port _____)

Robot

_______________________

Location

_______________________ (school workshop / venue / etc.)

Lighting

_______________________ (bright / dim / fluorescent / mixed)

Calibration Goal

What are we trying to learn?

_______________________________________________________________________________

Measurement Procedure

How were values collected? (e.g., "Held each ring 5cm from sensor face, recorded value from V5 Brain screen, repeated 3 times per ring.")

_______________________________________________________________________________

Raw Measurements (Table)

Trial / Position / Object	Value 1	Value 2	Value 3	Average
_______________________	______	______	______	______
_______________________	______	______	______	______
_______________________	______	______	______	______
_______________________	______	______	______	______
_______________________	______	______	______	______

Constants & Ranges Derived

From the measurements above, the team will use these constants in code:

Constant Name	Value	Used In
_______________________	______	__________________
_______________________	______	__________________
_______________________	______	__________________

Reliability Check

How consistent were the measurements? Did any outlier values show up?

_______________________________________________________________________________

Re-Calibration Triggers

When will we need to re-do this calibration?

[ ] Different venue / lighting
[ ] After mechanical changes to the mount
[ ] After cable replacement
[ ] Before every tournament
[ ] Other: ___________________________

What We Learned (EN6: Reflect)

Anything surprising? Anything we'd do differently next time?

_______________________________________________________________________________

Example: Optical Sensor Calibration

This shows roughly what a filled-in version might look like. The student writes the actual content; this is illustrative only.

🔬 What Filled-In Looks Like (illustrative structure only)

The team mounted the Optical Sensor inside the intake throat to detect ring colors. They held a red ring at the sensor face three times, recording hue (~5°), saturation (~0.85), proximity (~225). Repeated for blue rings (~230° hue). Built a hue range table: red rings = 350–15°, blue rings = 215–245°. Saturation gate of > 0.3 used to reject grayscale readings. Proximity gate > 200 used to reject distant objects.

Re-calibration triggers: any new venue, any time the LED PWM is changed.

3 of 7

// Section 04

Programming Entry 💻

Use this when the team adds or revises sensor code. Explain intent and development using pseudocode, flowcharts, or annotated code excerpts, with outside sources credited.

⚠️

Explain the code: An excerpt alone does not explain its purpose. Add student-written reasoning, changes, and test evidence. Keep the complete project in version control and follow the student-centered policy guidance.

What This Entry Captures

What the code is supposed to do.
Pseudocode or flowchart of the logic.
How the code integrates with the chassis library (EZ-Template / LemLib).
Test results and tuning notes.

Template

Sensor Programming Entry — [FUNCTION / FEATURE NAME]

Date

_______________________

Author

_______________________

Reviewed by

_______________________

Sensor(s) used

_______________________

Library context

_______________________ (standalone / EZ-Template / LemLib)

Git commit

_______________________

Goal (EN1: Identify)

What is this code supposed to do? Describe the outcome, not the implementation.

_______________________________________________________________________________

Approach (EN3: Plan)

How does the code achieve the goal? (Natural language description, no source code.)

_______________________________________________________________________________

Pseudocode

Step-by-step logic in plain language. Example structure:

      WHILE the auton has not finished:

         READ proximity from Optical Sensor

         IF proximity > threshold:

            READ hue

            IF hue is in alliance range:

               [stop intake; trigger scoring]

            ELSE:

               [reverse intake to eject]

         DELAY 20 ms

Your pseudocode here:

[ team writes pseudocode here ]

Flowchart (Optional)

[ FLOWCHART OF SENSOR LOGIC ]

Integration with Chassis Library

If this code interacts with the chassis library (EZ-Template / LemLib), describe the composition pattern:

[ ] Sensor-triggered motion exit (sensor cancels chassis motion early)
[ ] Pre-move sensor check (sensor decides whether to issue chassis motion)
[ ] Background sensor task (independent task; chassis runs separately)
[ ] None (this code doesn't touch chassis)

Brief description: _____________________________________________________________

Test Plan (EN5: Test)

What did you test, and how?

Test Case	Expected Result	Actual Result	Pass / Fail
_______________________	__________	__________	______
_______________________	__________	__________	______
_______________________	__________	__________	______

Reflection (EN6: Reflect)

What worked, what didn't, what's next?

_______________________________________________________________________________

Why Pseudocode Instead of Code

Pseudocode is one way to explain intent. Annotated source code, screenshots, or flowcharts can also document code development. Explain your team's work and credit outside sources; see the student-centered guidance.

The actual C++ implementation lives in your Git repository, with a commit hash referenced from the notebook entry. Judges can ask to see the repo if they want; they typically don't.

4 of 7

// Section 05

Debug Entry 🐛

Use this when a sensor wasn't working and you traced the cause. Judges love seeing diagnostic reasoning — it's the cleanest evidence of the engineering design process.

What This Entry Captures

The symptom (what was wrong, observed behavior).
Hypotheses (what might be causing it).
Tests run for each hypothesis.
Root cause and fix.
What you'll do differently to prevent it.

Template

Sensor Debug Entry — [SHORT NAME OF ISSUE]

Date

_______________________

Author

_______________________

Sensor

_______________________ (port _____)

Severity

_______________________ (blocks competition / blocks practice / cosmetic)

Time to fix

_______________________ (minutes / hours)

Symptom

What was wrong? Be specific. "Doesn't work" is not a symptom; "Pot reads 0 constantly even when arm moves" is.

_______________________________________________________________________________

When First Observed

Was this a new failure, or had we seen it before? What changed since it last worked?

_______________________________________________________________________________

Hypotheses

What could cause this symptom? List at least three:

#	Hypothesis	How to test
1	_______________________	_______________________
2	_______________________	_______________________
3	_______________________	_______________________

Tests Run

Hypothesis	Test	Result	Conclusion
____	__________	__________	__________
____	__________	__________	__________
____	__________	__________	__________

Root Cause

What was actually causing the symptom?

_______________________________________________________________________________

Fix Applied

What did you change to fix it?

_______________________________________________________________________________

Verification that fix worked: _____________________________________________________

Prevention (EN6: Reflect)

How do we prevent this from happening again?

[ ] Updated build documentation
[ ] Added to pre-match checklist
[ ] Changed mounting
[ ] Code change (assertion / range check)
[ ] Other: ___________________________

Why Debug Entries Are Notebook Gold

Most engineering work is debugging, but most teams don't notebook it. Debug entries hit several rubric criteria simultaneously:

EN1 (Identify): the symptom is the problem you identified.
EN2 (Brainstorm): the hypotheses are alternate explanations you considered.
EN5 (Test): the tests are systematic, hypothesis-driven experiments.
EN6 (Reflect): the prevention plan shows you learned from it.

Even small debugging episodes (5 minutes, simple cause) deserve an entry if they were memorable. They show judges your team thinks systematically, not by trial and error.

5 of 7

// Section 06

Tournament Sensor Log 🏆

Use this at every tournament to capture how sensors performed under real venue conditions. Drives off-season improvements.

What This Entry Captures

Venue conditions (lighting, field state, opponent disruption).
Per-match sensor behavior summary.
Re-calibrations done at the venue.
Failures observed and fixes applied.
Lessons for next tournament.

Template

Tournament Sensor Log — [TOURNAMENT NAME]

Date

_______________________

Venue

_______________________

Lighting

_______________________

Robot version / git commit

_______________________

Pre-Tournament Sensor Checklist (Section 06 of Sensor Roadmap)

[ ] IMU calibrates and reads stable values
[ ] All limit/bumper switches respond correctly
[ ] Potentiometer matches expected angle for known positions
[ ] Optical Sensor sees objects at expected proximity / hue
[ ] AI Vision sees test AprilTag
[ ] GPS reads valid X/Y at known field position

Re-Calibrations Done at Venue

Sensor	What changed	Old value	New value
__________	__________	__________	__________
__________	__________	__________	__________

Per-Match Sensor Notes

Match #	Auton selected	Sensor performance	Issues observed
____	__________	__________	__________
____	__________	__________	__________
____	__________	__________	__________
____	__________	__________	__________
____	__________	__________	__________

Failures & Fixes During Tournament

(For each failure: link to a Debug Entry if substantial; brief inline note if quick.)

_______________________________________________________________________________

Lessons for Next Tournament (EN6: Reflect)

What will we do differently? What new failure modes did we discover?

_______________________________________________________________________________

Tournament Log Tips

Fill in the per-match table during the tournament, not after. Memory fades; numbers don't.
Photograph the venue lighting if it's unusual (very dim, very bright, mixed sources). Useful when comparing GPS / Optical performance across venues.
Log even tournaments where sensors worked perfectly. "Nothing went wrong" is itself a data point.

6 of 7

// Section 07

Student Authorship Tips ✅

Use prompts to describe the work your team actually did, in students' own words.

Student Ownership

Students author the notebook and explain their engineering. Adults or AI must not write entries for them. Follow the GRSF policy guidance.

What These Templates Are (and Aren't)

These templates ARE	Question prompts. Section headings. Field labels. Suggested table structures. The same as a printed lab notebook with section dividers.
These templates are NOT	Pre-written content. Filled-in answers. Anything the team can paste verbatim and submit as their own.

Using a template for structure is the same as using a graph paper notebook with pre-printed grid lines. The grid is provided; the data and analysis are yours.

How to Stay Compliant

Write every answer in your own words. Even if your reasoning is similar to another team's, articulate it yourself.
Don't copy-paste from this guide's prose into your notebook. The body text of these guides is for learning, not for filling in.
Distinguish your work from references. Show your own build and sketches; credit any outside images where used and do not present them as your work.
Use actual measurements. Label estimates and record conditions; never substitute illustrative numbers for a test your team performed.
If you ask AI for help understanding a concept, don't paste the AI's response. Read it, understand it, then write your own explanation in the notebook.

Pseudocode vs. Code

Pseudocode describes what the code does in natural language with light syntax. Allowed in the notebook.
Source code can be documented with annotated excerpts showing intent and development; keep the complete project in version control.
Reference functions such as arm_to_angle() with enough explanation to show their purpose and changes.

Citing Sources

If your team referenced an external resource (a VEX KB article, the PROS docs, a competitor's reveal video), cite it. Examples:

"Per the VEX KB 'Best Practices with the GPS Sensor' article, we mounted the GPS rear-facing at ~10.5 inches."
"The PROS V5 documentation specifies that pros::adi::DigitalIn::get_value() returns 1 when released."

Citations strengthen your notebook by showing you researched. Credit the source where used; attribution does not replace your own engineering or authorship.

Practices That Make Evidence Traceable

Date every entry. Chronology is part of EN's rubric.
Sign every entry. Each team member's entries should be identifiable.
Use a TOC. Update it as new sensor entries are added.
Cross-reference between entries. A debug entry might reference a calibration entry from two weeks earlier. Page numbers help.
Show iteration. Record whether later calibration improved, stayed the same, or worsened, and explain what you did next. Do not assume improvement.

Sample Sensor Entry Topics for the Season

Here are 12 entries that any V5RC team using sensors might write across a season. These aren't mandatory; they're just realistic data points:

Build entry — first IMU mount on Clawbot
Calibration entry — IMU drift baseline
Build entry — switches added to Clawbot arm
Calibration entry — arm pot ranges established
Programming entry — arm preset macros (pseudocode)
Debug entry — pot reads 0 in deadband (early season failure)
Build entry — Optical Sensor moved from Clawbot to comp robot intake
Calibration entry — alliance ring hue tables (game elements arrived)
Tournament log — first competition, sensor performance summary
Debug entry — intermittent switch reading at tournament
Programming entry — vision-corrected auton (if AI Vision used)
Reflection entry — end-of-season sensor stack review

Each one is 1–2 notebook pages. Across the season, that's ~20 pages of high-quality, sensor-specific evidence in your notebook — substantial enough to influence judging awards.

Related Guides

📚

Sensor Onboarding Roadmap

What to notebook in what order

📝

Notebook Pathway

Full notebook setup & rubric

🛠️

Toolchain Onboarding

Git for code that backs your notebook

7 of 7 — Complete!