Skip to main content

Lesson 1.2: Writing Entries That Capture Real Engineering Work


Technical Context

The barrier to good notebook entries is not writing skill. It is that at the end of a three hour build session, everyone is tired and nobody remembers what happened at the start. The solution is a fixed format short enough to fill in during the session.


The Four Part Entry

Every entry answers four questions. Nothing more is required.

Date: 14 Oct        Author: [name]        Subsystem: Intake

PROBLEM
Elements that arrive more than 1 in off center are pushed aside
instead of being drawn in.

WHAT WE TRIED
Added angled funnel walls at 20 degrees from the frame rails,
made from 1/8 in polycarbonate, bolted to the existing intake
mount. 12 trials with the element placed at 0, 1, 2 and 3 in
off center.

RESULT
0 in: 12/12 acquired. 1 in: 12/12. 2 in: 7/12. 3 in: 1/12.
The 2 in failures all showed the element riding up the funnel
wall instead of being pulled down into the rollers.

NEXT
Increase funnel angle to 35 degrees so the wall pushes the
element down as well as inward. Retest at 2 and 3 in.

That takes four minutes to write and it is a complete engineering record. It states the problem, the change, the measurement, and the decision that follows from it.


Why Each Part Matters

Problem forces you to state what you were actually trying to fix. Entries that skip this read as activity logs: "worked on the intake today."

What we tried must include enough detail to reproduce it. Materials, dimensions, angles, and the test conditions. "Added walls" is not reproducible; "1/8 in polycarbonate at 20 degrees" is.

Result is where teams weaken most. It needs numbers and trial counts. "Worked better" is an opinion. "7 out of 12 at 2 inches off center" is data, and it is what makes the next entry meaningful when the number changes to 11 out of 12.

Next is what turns a log into a process. It shows the loop from Module 0 running.

Write it during, not after

Keep the notebook open on the workbench. Fill in Problem and What We Tried before you start testing, while you still know what you are doing and why. Fill in Result as the trials happen. Only Next gets written at the end, and by then it writes itself.


Trial Counts and Honest Numbers

One trial is a demonstration. Ten trials is a measurement. The difference matters because mechanisms fail intermittently, and an intermittent failure is invisible in a single trial.

A practical minimum for FTC work:

QuestionTrials
Does this basically work at all3
Is this good enough to keep10
Is this reliable enough to compete with25 or more

Record the failures individually, not as a total. "3 failures out of 12" tells you less than "failures on trials 4, 5, and 11, all with the element off center to the left," which points at an asymmetry you can go find.

Do not quietly discard bad trials

When a trial fails because someone bumped the robot, write it down as a bumped trial rather than deleting it. Teams that discard inconvenient data end up with a notebook that shows better reliability than the robot has, which is exactly the surprise you do not want at a tournament.


Who Writes

Every student, about their own work. A single designated notebook writer produces a document in one voice describing work they did not do, which judges detect through the missing detail.

A practical rotation: whoever worked on a subsystem that day writes that subsystem's entry before leaving. Ten minutes at the end of each session, everyone at once.


Fill-in-the-Blank Practice

  1. The four parts of a standard entry are Problem, What We Tried, Result, and __________.
  2. Recording that a mechanism "worked better" is insufficient because it is an opinion rather than __________.
  3. Determining whether a mechanism is reliable enough to compete with requires at least __________ trials.
Show answers
  1. Next (the decision or next step)
  2. data (a number with a trial count)
  3. 25 (or more)

Exercise

Run one test on any current mechanism, using the four part format, with at least 10 trials. Record each failure individually with the conditions under which it happened. Then look at the failure list and see whether there is a pattern. There usually is.

Ready to move on?

Sign in with Google to save your progress with Telemark, or continue without saving.

Stuck on this lesson?

Ask about anything on this page. It can see which lesson you have open and which part you are reading.