I programmed our initial Universal Robots UR5e job for tray transfer with a rigid polymer block in a supervised assembly training cell and handed it over to the operators. They can start the saved job, but they need me when a pocket is empty or a run is interrupted.
I suspect the handover omitted recovery decisions, rather than the operators lacking willingness.
A teach-back could reveal where the handover becomes unclear. What do operators understand the restart instruction to mean when they explain it without prompts?
During a discussion, I asked operators to explain the restart wording and received several different interpretations. That gives us a concrete ambiguity in the handover to address.
Use the conflicting interpretations to revise the instruction into condition, permitted action and escalation criteria. After the responsible integrator reviews it, check understanding again through an unprompted teach-back.
@ThomasArcher0364 On my setup, I asked people to find where my guide forced them to guess. That invited corrections instead of making them defend a wrong answer.
@LeoCarter0971 Not if the system can't tell them what's physically happening. Better wording can't create a recovery path for an unknown held-workpiece state.
@TheoCarter1019 I overstated what the documentation can solve. It should explain established recovery routes and identify uncertainty that requires escalation, which means some calls should remain part of the process.
Reviewing the handover notes, I found that startup was only demonstrated with an empty tool. We didn't explain the case where an interruption leaves the workpiece held.
Knowing an index doesn't establish whether the workpiece is held or the destination occupied. Recovery needs a defined way to determine those conditions and an integrator-reviewed action for the result.
On my own cell, changing the index became folklore: ask the person who 'knows the trick'. Replacing that with a defined escalation made the uncertainty visible.