Technical Defense, Portfolio & Learning Roadmap

Ten-minute defense structure

The last product isn’t the hardware; it’s an argument someone else could check, from the problem to the evidence. Give it in ten minutes, even if the only listener is a friend who knows electronics:

1. Problem (1 min): the baseline log: 64 starts, 15 with the collector forgotten or the wrong gate, 11 with extra gates open, 2 clogs; and the checklist that helped but didn’t finish the job.
2. Requirements (1 min): the matrix, with AIR-01 and SAFE-04 called out.
3. Concept (2 min): the three concepts, the scores, the sensitivity check that made the weights the decision, and why the line-voltage half was bought.
4. Evidence (3 min): the airflow check and measured drop speeds; the gate-force and burden calculations; the state machine; the bench, installed, and fault test results; the month’s log against the baseline.
5. Risks and limits (2 min): the hazard list and unplug rule, what still isn’t known, and anything accepted on the punch list.
6. Decision (1 min): the release recommendation and the next experiment.

Label every claim with the kind of evidence behind it: measured (the slide force, idle currents), calculated (Q = V × A, the actuator torque), tested (the drop speeds, the power-blip result), observed (the month’s log), or not yet known (how the actuators hold up over a year). A photo of a tidy controller box is evidence of tidiness, not of safety.

Portfolio dossier

Put the whole project in one folder (or a notebook and a folder) that would let someone rebuild and re-test it:

• the brief, baseline log, and checklist trial;
• the requirements matrix and decision record;
• sketches, the duct layout, and the gate-actuator and burden calculations;
• the wiring diagram, with the line-voltage parts and their ratings;
• the controller code under version control, with the state diagram;
• every test case and its result, the fault campaign, and the month’s log;
• the punch list, lessons learned, and photos.

Stanford’s experimental robotics course ends the same way, with a working demonstration, a presentation, and a written report ¹, and MIT’s machine design course grades the ability to model, build, and then characterize a device against its requirements ². The dossier is where that loop shows.

Lessons learned

Write down what surprised you and what you’d change, while it’s fresh. For example: the dusty slide force was higher than a clean gate’s, so the first servo stalled; one tool’s idle current was closer to its threshold than expected, which caused a false stop during a light cut; two limit switches drifted and needed a sturdier mount. Each lesson says what happened, why the design allowed it, and what the next version does differently. MIT’s design courses treat this reflection as part of the engineering, not a postscript ³.

Honest release recommendation

End with one of these and its conditions:

• Ready for everyday use: every requirement passed and the month beat the baseline.
• Ready after listed fixes: for example, replace the gate that stuck half open and re-run its tests, with the limitation recorded until then.
• Not recommended: the evidence showed the concept can’t meet a critical requirement, so fall back to concept B and labeled gates.

“Not recommended” can be a good capstone result if the evidence is solid; it’s cheaper to learn that from a month of logging than from a year of clogs.

Next

Improvements for a second version: a differential-pressure sensor across the filter to tell when it needs cleaning, a fill sensor in the bin, and logging air speed over time to catch a leak or a clog early.

And the next courses, depending on where the project felt thinnest: fluid mechanics for ducts and fans, electronics and signal conditioning for sensing, controls for the state machine and anything with feedback, machine design for mechanisms, and the industrial automation and robotics courses for the factory-scale version of the same problems.