Maryland FIRST RoboticsHow to Document Your Team’s Engineering Notebook for Judges
An engineering notebook is the team’s record of how a robot moved from an idea to a tested design. At a Maryland FIRST event, it gives judges reliable evidence during interviews: which students were responsible for each part, what alternatives were considered, and why the final mechanism, code or strategy was chosen. A polished magazine is less useful than a clear chain of decisions.
Good documentation is not a transcript of every conversation. It is a concise account of objectives, design options, tests, failures and revisions. The same principles suit Australian teams, although local habits matter: mentors often call the build season “the build”, while formal notebook entries still need plain English, complete sentences and evidence a stranger can follow.
Show the Engineering Story
Begin with a problem tied to game objectives, robot requirements or team safety. State measurable constraints such as payload, clearance, cycle time, battery limits or reliability. A judge should understand the requirement before seeing the solution, so avoid beginning with a parts list or a photograph of the finished robot.
Record the path from requirement to choice. For a drivetrain decision, include the options considered, the criteria used, the selected design and its trade-offs. Computer-aided design images, calculations, photographs and short code excerpts can support the account, but captions must explain why each item matters.
Show how the team learned. Preserve early sketches, prototype data and unsuccessful attempts, then link each lesson to a later change. “It did not work” has little value; “the roller slipped in three of five tests, so we widened the contact surface” creates useful evidence. FIRST event handbooks and program rules differ across FRC, FTC and FLL, so confirm the required notebook or portfolio format for the division you enter.
Build a Traceable Engineering Record
Use dates, entry titles, version numbers and team conventions consistently. A monthly design review, daily build log and test record may sit in one digital notebook or a linked set of files. Add a contents page, page references and bookmarks for major subsystems. Never silently overwrite an old design: mark it superseded and retain it where it explains the decision path.
Keep the evidence close to the claim. Put the setup, test input, expected result and observed result beside the conclusion, and identify who ran the test. Store large datasets in a labelled appendix, not as unexplained screenshots. If the event requires a physical copy, print a readable backup in the usual A4 format used in Australia; if it accepts a digital notebook, test navigation in the presentation environment judges will use.
Maryland teams can confirm current arrangements for the Chesapeake event through the Chesapeake Regional event details. Australian clubs often combine support from local engineering firms, school-community appeals and community grants, so sponsor proposals can fund robot parts, travel and testing. Teams based in cities such as Melbourne, Brisbane, Canberra and Perth may also budget for interstate travel; those details belong in the season timeline, not buried in the final notebook.
Make Every Page Easy to Navigate
Use a predictable layout: summary, requirements, subsystem designs, tests, iterations, code references, safety and reflections. Headings should describe content rather than simply say “Design”. Number figures, add short captions and provide a link or page number for supporting data. Reserve colour for emphasis, not as the only way to distinguish information.
Use this comparison while revising weak entries:
| Evidence | Weak entry | Judge-friendly entry |
|---|---|---|
| Requirement | “Robot broke” | “Drive slipped during payload turns, so the grip surface changed” |
| Design choice | Parts collage | Alternatives, selection criteria, chosen option and trade-off |
| Test | Photo of completed robot | Setup, input, expected result, observed result and action |
| Iteration | Only the final drawing | Earlier sketch linked to the revision prompted by test evidence |
| Ownership | A list of team names | Roles connected to design reviews, changes and presentations |
| Reflection | “We won” | Effect on design, remaining limitation and next engineering step |
After revising, ask a teammate who was not in the original subsystem to find one example for each requirement. If they cannot locate it quickly, improve the index, wording or cross-reference. Judges may have limited time and may move between a robot, a screen and the notebook. The document should let them verify a claim without turning the interview into an archive hunt.
Write for an international audience by spelling out abbreviations, using month names and showing units. Australian teams normally work in SI units and may use dates such as 13 March, while some Maryland documents use US customary measures and numeric month forms. Provide a conversion or both units when a value affects design or safety; consistency within each experiment matters just as much as the numeric value.
Run a Judge-Ready Final Check
Turn the notebook into an interview tool. Give each student responsibility for explaining one subsystem, then run a mock interview that moves from requirement to design, test and revision. A five-minute walkthrough exposes missing evidence, conflicting drawings and pages that look neat but do not explain a choice. Test the same route judges are likely to take.
Design for different readers as well. Use high-contrast headings, legible type, descriptive captions and colour-independent labels. If a team parent or mentor has age-related macular degeneration, Retina AMD information can help them understand the condition; any event accommodation should still be arranged directly with organisers. Clear design helps everyone at the judging table, including judges working under time pressure.
Before freezing the file, complete these checks:
- Every major design has a requirement, rationale and test result.
- Revisions retain dated evidence linking the old and new approaches.
- Team roles show genuine student ownership rather than a list of names.
- Links, bookmarks, printed pages and required submission formats work.
Treat one failed check as a release blocker, not a minor blemish. A missing safety test or an unreadable appendix can weaken an otherwise strong interview. Record what changed, who checked it and the final approval date so the published version has an audit trail.
Turn Preparation into a Strong Judging Conversation
A notebook does not replace the team. It gives each student a shared evidence base for answering questions about trade-offs, failures and what they would change next. If a verbal answer differs from the written record, pause and check the requirement or test rather than improvising. Judges value a precise “the evidence is on page 18” more than a confident claim with no support.
Build the final review around the event, not a generic template. Confirm the submission deadline, interview format, division requirements and any event-specific instructions, then rehearse until the team can move smoothly between its robot and notebook. The Maryland FIRST community and Australian clubs can use different travel or sponsorship arrangements, but both benefit from the same disciplined record of student engineering.
Make the next team meeting the deadline: assign a notebook owner, close every release-blocker check, export a backup and publish the approved version before the event. Then walk into the judging room ready to explain not only what your robot does, but the evidence behind every meaningful design decision.