Lesson 1.2: Writing Entries That Capture Real Engineering Work
Technical Context
Notebook entries are hard to reconstruct at the end of a long build session. Use a fixed, short format and fill it in while the work is still underway.
The Four Part Entry
Start every entry with four questions.
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, including materials, dimensions, angles, and test conditions. "Added walls" is too vague. "1/8 in polycarbonate at 20 degrees" can be reproduced.
Result needs numbers and trial counts. "Worked better" does not say how much better or under what conditions. "7 out of 12 at 2 inches off center" gives the next version a result to beat.
Next is what turns a log into a process. It shows the loop from Module 0 running.
Keep the notebook open on the workbench. Fill in Problem and What We Tried before testing, then record Result as the trials happen. Write Next at the end using the result you just measured.
Trial Counts and Honest Numbers
One successful trial shows that the mechanism can work. Repeated trials give you an estimate of reliability and expose intermittent failures.
A practical minimum for FTC work:
| Question | Trials |
|---|---|
| Does this basically work at all | 3 |
| Is this good enough to keep | 10 |
| Is this reliable enough to compete with | 25 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.
When a trial fails because someone bumped the robot, mark it as a bumped trial instead of deleting it. Keeping excluded trials visible prevents the team from overstating reliability and lets another reader understand how the result was calculated.
Who Writes
Have students document their own work. They know the dimensions, failed attempts, and small decisions that a designated writer may miss.
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
- The four parts of a standard entry are Problem, What We Tried, Result, and
__________. - Recording that a mechanism "worked better" is insufficient because it is an opinion rather than
__________. - Determining whether a mechanism is reliable enough to compete with requires at least
__________trials.
Show answers
- Next (the decision or next step)
- data (a number with a trial count)
- 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?
Only mark complete if you genuinely understand the material. Your progress will be saved in this browser.
Stuck on this lesson?
Ask about anything on this page. It can see which lesson you have open and which part you are reading.