You spent the shift on the warehouse floor working out why a mobile robot kept stopping in the same aisle. Somewhere around lunch you finally understood it. By Friday you will remember that you understood it but not quite how. The most reliable fix I know is to write a short teaching note for a newcomer to robotics operations while the details are fresh. This checklist audits a draft of that note, item by item, so that the lesson survives both your own memory and the next shift change.

Before you write: capture the raw facts

Teaching notes fall apart when the facts underneath are fuzzy. Spend five minutes jotting down these items first, with no polishing.

• What did the robot do, in words a visitor could picture? (“It slowed and stopped at the third rack, then waited.”)
• What was the first thing you suspected, and why?
• What did you check, in order, and what did each check show?
• Which check changed your mind?
• What did you change, and did the behaviour actually stop?

If you cannot answer the last one with confidence, mark it. An unverified fix belongs in the note labelled as unverified.

Audit 1: Is the opening a symptom, not a theory?

Start from what could be seen or measured. Newcomers cannot search for your conclusion, but they can recognise a symptom. A line such as “the robot paused at the same place every cycle, and nothing appeared in the error list” is something another operator might actually type into a search box.

Audit 2: Did you explain the one concept the problem depends on?

Most floor problems rest on a single idea: how a sensor reading becomes a decision, how a map is updated, how a path planner treats a blocked cell. Pick that idea and explain it in two or three plain sentences, as if to a new technician. Teaching it forces you to check your own grasp. If you are working with navigation hardware, a refresher such as an overview of how sensors feed an industrial robot’s decisions can help you find the simplest honest wording.

Audit 3: Does the sequence follow what a newcomer would try first?

You probably investigated in a messy order. The note should present the shortest sensible path: look here first, then here. Keep the dead ends, but move them to a short section called “what did not help”, because they save the next person time and reassure them that confusion is normal.

Audit 4: Is every claim marked as seen, tested or assumed?

Go through the draft with three coloured pens, or three letters in the margin. “Seen” means you watched it happen. “Tested” means you changed one thing and observed the result. “Assumed” means you inferred it. A note full of assumptions is not worthless, but readers deserve to know which is which, and you will be surprised how many lines you thought were tested turn out to be assumed.

Audit 5: Is anything unsafe or off-limits missing?

Robots share space with people. If your lesson involves entering a working zone, resetting equipment or bypassing a sensor, state plainly that your site’s safety procedures take precedence over anything in the note, and never suggest overriding a safety function. The teaching note is a supplement to proper training, not a replacement.

Audit 6: Could an outsider identify the site?

Strip names of customers, rack identifiers, layout details and anything contractual before the note leaves your team. Describe the pattern rather than the place. A warehouse layout that mentions “aisle three” is fine; a layout that identifies a specific client is not. Pattern-level lessons from automated guided vehicles, such as those discussed in a plain guide to automated guided vehicles in warehouses, travel well precisely because they are generic.

Audit 7: Does it end with a one-minute check?

Finish with something the reader can do quickly to confirm they are facing the same issue: compare a log timestamp, view a sensor reading, watch the robot approach the spot. This turns an anecdote into a tool.

Audit 8: Did a beginner try to follow it?

Hand the draft to a newer colleague and ask them to restate the problem and the fix in their own words. Wherever they hesitate, your wording is the issue. Rewrite and repeat. Two rounds is usually enough.

Audit 9: Is it filed where people can find it?

A note that nobody can find does not teach anyone. For internal material, use your team’s shared space with a title that matches the symptom. For general lessons that are safe to share, a public blog is an option. MyBlogPad puts every blog on a subdomain of its own, takes Google logins, lets several people post and calls itself free to begin, so a robotics team can keep a shared learning blog without building a site.

The checklist in one view

1. Capture facts before you write.
2. Open with a visible symptom.
3. Explain the one idea the problem rests on.
4. Arrange steps in the sequence a newcomer would attempt.
5. Mark every claim as seen, tested or assumed.
6. Keep safety rules above the note.
7. Remove anything that identifies the site.
8. End with a one-minute confirmation check.
9. Test it on a newcomer, then file it where it can be found.

Why it is worth the twenty minutes

Writing the note is cheap. Rediscovering the same lesson on a night shift with a stalled robot and a waiting order queue is not. The hidden benefit is for you: every audit item makes you check whether you really understood the cause. More than once I have started a note convinced the problem was solved and finished it knowing I had only found a workaround. That discovery, made at the desk instead of the aisle, is the whole point of teaching what you just learned.