Where you are. You have a capstone, built on a spine, evaluated against a protocol you froze before the results existed. This lesson covers the two weeks after the code works, which are engineering weeks and not paperwork.
The narration you cannot send
You demo it live. Screen share, the arm moving, and you talk over it: watch this one, it misses because the depth camera reads the transparent lid as empty space, third time out of sixty, and the fix is either a different sensor or a different grasp heuristic.
The call goes well. The failures were the best part of it, because you explained them as they happened.
Then someone asks for the link so they can send it to a colleague.
What you send is a repository and a video. Everything you said out loud is gone. What arrives at the other end is an install section, a demo that works, and nothing at all indicating that you ran sixty trials or ever understood the depth camera. The colleague has ten minutes, no context, and possibly a phone. They have to do the narrating, from nothing.
Shipping is building the version that narrates itself.
The idea in one paragraph
Assume a reviewer with ten minutes, no context, and no way to ask you anything. They need four things in a fixed order: what you claim, whether it happened, how often it happened, and where it breaks. Three artifacts deliver that: a README whose first screen carries the claim, one architecture diagram and a results table; a video that is uncut and includes at least one failure; and a limitations section you write before anybody else writes it for you. The counterintuitive part is that the honesty is the load-bearing feature rather than a nice gesture. In a field where every published number was produced by the party being evaluated, an artifact that volunteers its own failure rate is doing something rare, and it is read as competence rather than weakness.
Ten minutes, spent in a fixed order
Wider than the screen; scroll it sideways.
Reviewers do not read your repository. They sample it, in roughly this order, and abandon at the first point that fails to reward them.
The claim, in the first two sentences. The demonstration, because they want to see the thing move before they invest in reading. The numbers, because that is the question a robotics person asks second and the question that separates work from a demo. Then the architecture, because now they care how it is built. Then reproduction, if they are seriously interested. Then limitations, which is where a good reviewer goes deliberately and early.
Your job is to put those six things in that order and make each one findable in under ten seconds.
The first screen
Above the fold, four things and no more. One sentence saying what the system does and what you measured. One image or short animation of it working. The headline number with its denominator and conditions. A one-line index of where to find the video, the results and the limitations.
That is the whole first screen. Everything else scrolls.
One architecture diagram, with rates on it
Draw the system once. Boxes for the components, arrows for the data, and on every arrow the message rate and what the message contains. A robotics reader reads that diagram for rates and interfaces before they read anything else, because rates are where systems die: a policy trained at 30 Hz and deployed at 10 Hz, a planner that returns in 400 ms inside a loop with a 20 ms budget, a camera stream at 15 fps feeding a controller that assumes 30.
Drawing it is also a check on you. If the diagram takes an hour because you keep discovering you are not sure what talks to what, that is a finding about your own system, and it is much better to have it before somebody asks.
The video, uncut
Wider than the screen; scroll it sideways.
One clean take is the format everybody produces and it carries almost no information. It shows that the task is achievable once, which the reviewer already assumed, and it is consistent with any number of attempts behind it, which the reviewer also assumes.
The format that carries information is the run. Fix the camera. Record consecutive trials in the order they happen, including the resets between them, at real speed. Mark each one as it lands. Sixty to a hundred and twenty seconds is enough for a dozen trials at four-times speed with the count on screen, and it says something a clean take cannot: this is what the system does, not what it did once.
Then slow down for one failure and show it at quarter speed, with a caption naming the cause. That single clip is usually the most persuasive thing in the entire project, because it demonstrates that you know why, and knowing why is the thing being assessed.
The number, with its denominator
One table, near the top, broken out by condition. Aggregate rates hide everything worth knowing.
| Condition | Trials | Successes | Rate | 95% interval |
|---|---|---|---|---|
| Bright overhead light, opaque objects | 20 | 17 | 85% | 64 to 95% |
| Dim side light, opaque objects | 20 | 12 | 60% | 39 to 78% |
| Bright overhead light, one transparent lid | 20 | 5 | 25% | 11 to 47% |
| All conditions | 60 | 34 | 57% | 44 to 68% |
Limitations, written before somebody else writes them
Four questions, honestly answered, in a section a reviewer can find.
What can this not do. What conditions does it need. What would break it that you already know about. What did you never test.
The last one is the one people skip and the one that buys the most credibility, because it is the only section in any technical write-up that a reader cannot check and would never expect you to volunteer. “I never tested it with more than one object in the scene” costs you nothing and tells a reader that the rest of the document is probably straight.
What survives contact with a stranger
Wider than the screen; scroll it sideways.
The README, the video and the results table are the minimum. Two more are worth the day each costs.
A replayable recording in a standard container, with a viewer layout that opens onto something meaningful, lets a reviewer scrub through a real episode. It also demonstrates the tooling literacy that robotics interviewers assume rather than test, which the logging lesson covers in detail.
A published dataset, in a standard schema on a public hub, is the single most credible object available to somebody without a robotics job, because it is the artifact a working team would produce. It is also the one thing in your capstone another person can use.
When the number is bad
Suppose the honest result is 45%.
Ship it. A capstone at 45% with a failure analysis that identifies three distinct causes, quantifies how much each one costs, and proposes a specific fix for each, is a stronger artifact than 90% with no breakdown. The first is an engineer reporting on a system. The second is a video.
The temptation at this point is to keep tuning until the number looks respectable, and the calendar says no. What you would learn from another two weeks of tuning is smaller than what you lose by not shipping, and a project that stays private until it is good enough is a project that stays private.
Check yourself
1. A reviewer opens your repository with ten minutes and no context. What do they need, in what order?
The claim, in the first two sentences. Then a demonstration, because they want to see it move before investing in reading. Then the numbers with their denominator and conditions, which is the question that separates work from a demo. Then the architecture, once they care how it is built. Then reproduction, if they are seriously interested. Then limitations, which a good reviewer goes to deliberately. Installation belongs near the end, despite being where every project template puts it.
2. Why does a single clean take of the robot succeeding read badly to an experienced reviewer?
Because it carries almost no information. It shows the task is achievable once, which they already assumed, and it is equally consistent with a 90% system and a 5% system that was recorded thirty times. Editing makes it worse rather than better: a cut hides the interval between trials, which is exactly where a reset, a retry or an unrecorded failure would sit. An uncut run of consecutive trials at real speed, resets included, answers the question the clean take dodges.
3. Your system gets 57% overall. Why is that number nearly useless on its own, and what makes it useful?
Because an aggregate mixes conditions with very different behaviour, and the mixture depends on how many trials you happened to run in each. The breakdown is what carries the finding: 85% on opaque objects under good light, 60% when the light changes, 25% on a transparent lid. That tells a reader the system is sensitive to lighting and fails on transparency, which is a specific, checkable, interesting claim. The aggregate tells them one number whose meaning depends entirely on a mixture they cannot see.
4. Why is “what I never tested” the highest-value line in a limitations section?
Because it is unverifiable by the reader and would never be expected of you, so volunteering it is a costly signal. Everything else in a limitations section could in principle be discovered by somebody running your code. Untested territory could not, which makes it the one place where you are visibly choosing accuracy over impression. Readers use it to calibrate how much to trust the rest of the document, and the calibration goes in your favour.
5. Your capstone honestly evaluates at 45%. What do you do, and why?
Ship it, with a failure analysis that separates the causes, quantifies what each one costs in success rate, and proposes a specific fix for each. That artifact is stronger than an unevaluated 90%, because it demonstrates the thing being assessed, which is whether you can diagnose a physical system rather than whether you can produce a working one. Continuing to tune is the wrong trade: the marginal number is small, the calendar cost is real, and a project that stays private until it looks good stays private.
6. What does drawing the architecture diagram tell you about your own system?
Whether you actually know it. The diagram forces every component, every message and every rate to be named, and the parts you hesitate over are the parts you have not understood. Rates are the specific thing to check, because rate mismatches are how these systems fail quietly: a policy trained at one frequency deployed at another, a planner whose response time exceeds the loop budget, a camera stream slower than the controller assumes. Finding that on your own diagram is much better than finding it in a question you cannot answer.
Do this
Two days of real work, scheduled as two days rather than squeezed into an evening.
1. Write the first screen. One sentence of claim, one image, the headline number with denominator and conditions, and a one-line index. Then look at it on a phone. If the claim is not visible without scrolling, cut something.
2. Draw the architecture once. Components, arrows, and the rate and payload on every arrow. Note every place you hesitated; those are the parts you do not own yet.
3. Record the uncut run. Fixed camera, wall clock in frame, twelve consecutive trials at real speed including resets, sped up in post with the count on screen. Then one failure at quarter speed with a caption naming the cause. No music, no voiceover, no cuts inside a trial.
4. Publish the results table with a row per condition, at least twenty trials each, and an interval on every rate. Bold the aggregate and make sure the breakdown sits above it in the reader’s eye.
5. Write limitations before you show anyone. Four headings: cannot do, requires, would break, never tested. Aim for at least two entries under “never tested”, and resist softening them.
6. Run the cold read. Send the link to somebody technical outside robotics with one instruction: ten minutes, then tell me what it does, how well, and where it breaks. Every question they have to ask you is a defect in the artifact. Fix those, not the code.
What you can now do
You can build the version of your project that works without you present: a README ordered by what a reviewer needs rather than what a template offers, one architecture diagram carrying the rates that decide whether a robot system holds together, an uncut video that shows the run instead of the highlight, a results table whose breakdown is more interesting than its headline, and a limitations section that converts your project’s weakest area into the reason a reader trusts the rest.