A help request should specify the required assistance
Aliases: actionable assistance request · recovery instruction · specific help request
What it is
An actionable robot help request identifies the object, location, desired action, completion condition, and safety prerequisite rather than merely stating “help needed.” It asks for the smallest contribution a person can make instead of requiring a non-expert to diagnose the whole system.
Why it happens
People lack the robot's map, failed node, and sensor evidence. A generic request makes them rebuild context through trial and error. Specific requests translate diagnosis into an observable state change. Over-specific but wrong diagnosis can prompt unsafe action, so uncertainty and refusal remain necessary.
Studying it
Generic alarm, causal explanation, concrete action, and action-plus-safety-boundary can be compared on comprehension, first correct action, recovery time, dialogue turns, hazardous attempts, and refusal. Novices and professionals reveal role fit. Success alone omits labour transferred to the helper.
Where it stops holding
When cause is uncertain, the robot should offer candidates or request observation rather than invent instructions. Energised or disassembly work belongs to authorised staff. Bystanders must be free to refuse, after which the robot remains safe and seeks an alternative.
Applying it
- Include location, object, one action, completion condition, and forbidden region, pointing physically rather than citing an internal identifier.
- Filter by role; novices receive only reversible low-risk actions outside hazardous space.
- Under realistic occlusion and noise, measure first correct action, unsafe action, dialogue turns, and post-action state confirmation.