Section 396 of 440
Complete canonical tutorial. This reader section contains the same teaching body as PWR-214 · Shared autonomy. Open the Power dossier.
PWR-214 · SUPERVISED full tutorial
Share a bounded task with automation while keeping mode, disagreement, override and degraded control visible
The corridor simulator displays MANUAL, AUTO or SHARED while the person commands direction and automation may slow or steer around foam obstacles. Compare all three modes, record intent conflicts and override delay, then practise assistance loss. Safe handling here does not establish shared control of a real mobility or manipulation device.
1 · Permission and limits
Know exactly what you may do
2 · Get ready
Gather what you need and check the starting conditions
What you need
- Declared Shared autonomy fixture: A wheelchair-style simulator travels a marked virtual corridor. The person commands direction; automation may slow or steer around foam obstacles. A bright mode label shows MANUAL, AUTO or SHARED.
- Setup aid for Make mode visible: Verify decision allocation, mode indicator, limits, override, logs and fallback.
- Shared autonomy log: Task success, intent errors, override latency, workload, collisions and failure recovery versus manual, autonomous and shared control; retain Shared autonomy errors, assistance, stop and fallback.
- Shared-autonomy evidence grid: use “Shared control of a medical robot with haptic guidance” and the BCI mobile-robot shared-control study to record person command, automation contribution, mode display, disagreement, override and outcome. Use the NIST Privacy Framework to define who may inspect command traces. The supplied corridor remains a simulator, and the qualified team controls mode changes and degraded-assistance tests.
Before you start
- Obtain qualified clinical-engineering supervision and participant consent for the exact simulator or approved device.
- Verify decision allocation, mode indicator, limits, override, logs and fallback.
- Start check for Shared autonomy: Every decision has a human or machine owner.
- Top-of-sheet stop for Shared autonomy: Stop for mode uncertainty, unexpected intervention, repeated intent error, failed override, lost link or limit breach.
3 · The method
Follow these steps in order
- Allocate decisions explicitly
The team writes that the person chooses destination and may stop; automation may slow and propose obstacle avoidance within the corridor.
Why: Every decision has a human or machine owner.
Check: Every decision has a human or machine owner.
- Make mode visible
Check the persistent mode label, transition sound or vibration and current override control.
Why: The learner can identify the mode without guessing from motion.
Check: The learner can identify the mode without guessing from motion.
- Set bounds and fallback
Engineers configure speed, corridor, obstacle clearance, stop, manual/degraded mode and safe state.
Why: The simulator cannot leave the declared envelope.
Check: The simulator cannot leave the declared envelope.
- Record manual baseline
Complete the corridor in manual mode and log time, path error, interventions, workload and collisions.
Why: Shared performance has a matched comparator.
Check: Shared performance has a matched comparator.
- Run shared mode
The learner states destination, automation proposes path changes and the learner confirms or overrides according to the protocol.
Why: Each machine intervention and human response is logged.
Check: Each machine intervention and human response is logged.
- Name disagreements
When automation steers right but the learner intends left, say “conflict,” stop or override and record whose evidence controlled the result.
Why: Intent error is not hidden inside successful arrival.
Check: Intent error is not hidden inside successful arrival.
- Practise degraded control
The team removes automation assistance; the learner uses the approved manual or alternative fallback or stops in safe state.
Why: Loss of automation does not cause continued uncontrolled movement.
Check: Loss of automation does not cause continued uncontrolled movement.
- Compare all modes
Review task success, intent errors, override latency, workload, collisions and agency in manual, auto and shared conditions; participant chooses next step.
Why: Shared mode is not declared best from completion alone.
Check: Shared mode is not declared best from completion alone.
4 · Worked example
See the whole method used once
Scenario
A wheelchair-style simulator travels a marked virtual corridor. The person commands direction; automation may slow or steer around foam obstacles. A bright mode label shows MANUAL, AUTO or SHARED.
Walkthrough
- The team writes: learner chooses the blue destination; automation may slow or propose a route; learner owns stop.
- The learner identifies SHARED mode and completes the corridor manually first with one wall contact.
- In shared mode, automation slows before the foam obstacle and the learner accepts the route change.
- At the next marker automation steers right while the learner chose left; the learner says “conflict” and overrides within two seconds.
- The team removes assistance; the learner moves to the marked safe bay using approved manual control.
- The review compares path, contact, override time, workload and reported agency across modes.
Result
The learner completes the simulator route and handles one intent conflict and one assistance loss. This does not establish safe shared control for a real mobility or manipulation device.
5 · Right and wrong
Compare correct or safer execution with the common wrong version
| Moment | Right / safer | Wrong / riskier | Why it matters |
|---|---|---|---|
| Decision rights | State what person and automation each control. | Let the system infer all goals silently. | Hidden allocation makes errors and responsibility unclear. |
| Mode awareness | Use a persistent label and transition cue. | Infer mode from how the device feels. | Mode confusion delays override; this distorts the shared-control corridor. |
| Disagreement in shared-control corridor | Stop, label conflict and log it. | Treat automation correction as always right. | Intent inference can be wrong even when the route completes. |
| Degraded mode | Rehearse manual/alternative fallback or safe stop. | Assume automation will remain available during the shared-control corridor. | Assistance loss can create abrupt workload and control gaps. |
6 · Common mistakes
Spot the error and apply the correction
| Mistake | Fix |
|---|---|
| Let the system infer all goals silently. | Put destination, motion and stop ownership on one card. |
| Infer mode from how the device feels. | Confirm mode before every start and transition. |
| Treat automation correction as always right. | Preserve user intent and inspect the trigger. |
| Assume automation will remain available. | Test a planned transition under supervision. |
7 · Practice
Turn the steps into a usable skill
First session
- Shared-control corridor visit: A wheelchair-style simulator travels a marked virtual corridor. The person commands direction; automation may slow or steer around foam obstacles. A bright mode label shows MANUAL, AUTO or SHARED.
- Visible mode and override: Make mode visible: Check the persistent mode label, transition sound or vibration and current override control.
- Matched manual route: Record manual baseline: Complete the corridor in manual mode and log time, path error, interventions, workload and collisions.
- Logged shared intervention: Run shared mode: The learner states destination, automation proposes path changes and the learner confirms or overrides according to the protocol.
- Assistance-loss transition: Practise degraded control: The team removes automation assistance; the learner uses the approved manual or alternative fallback or stops in safe state.
Repeat plan
The clinical-engineering team sets mode order, repetitions and progression. Use one matched route per mode with rest; repeat only after intent errors, overrides, workload and agency are reviewed.
Progress when
- Every decision has a human or machine owner.
- The learner can identify the mode without guessing from motion.
- The simulator cannot leave the declared envelope.
- Mode is correctly identified, intent conflicts are logged, override meets the protocol time, degraded mode reaches safe state and shared control improves the agreed outcome without unacceptable agency loss.
Do not progress when
- Do not continue while this error remains: Let the system infer all goals silently.
- Pause until this correction works: Confirm mode before every start and transition.
- This Shared autonomy stop ends the block: Stop for mode uncertainty, unexpected intervention, repeated intent error, failed override, lost link or limit breach.
8 · Check the result
Measure what changed
Task success, intent errors, override latency, workload, collisions and failure recovery versus manual, autonomous and shared control
How: Configured fixture: A wheelchair-style simulator travels a marked virtual corridor. The person commands direction; automation may slow or steer around foam obstacles. A bright mode label shows MANUAL, AUTO or SHARED. The provider logs “Make mode visible”, every “Run shared mode” result, the “Practise degraded control” response and Task success, intent errors, override latency, workload, collisions and failure recovery versus manual, autonomous and shared control. Mark MANUAL, AUTO or SHARED on every route row, then log the person’s command, automation correction, override, assistance loss, collision and workload; an improvement counts only within a clearly named mode.
Good result: Mode is correctly identified, intent conflicts are logged, override meets the protocol time, degraded mode reaches safe state and shared control improves the agreed outcome without unacceptable agency loss.
This does not prove: Boundary for Shared autonomy: “Task success, intent errors, override latency, workload, collisions and failure recovery versus manual, autonomous and shared control” describes only A wheelchair-style simulator travels a marked virtual corridor. The person commands direction; automation may slow or steer around foam obstacles. A bright mode label shows MANUAL, AUTO or SHARED. It cannot establish “The robot always knows what the user wants”.
Self-check
- Without the example, demonstrate: Every decision has a human or machine owner.
- Find the fault in this attempt: “Let the system infer all goals silently.” Apply “Put destination, motion and stop ownership on one card.”; what changes?
- What evidence in the completed record shows that this is wrong: “Infer mode from how the device feels.”?
- Shared autonomy stop decision: Stop for mode uncertainty, unexpected intervention, repeated intent error, failed override, lost link or limit breach.
9 · Stop, adapt or get help
Keep the safety boundary practical
Stop and get help
- Stop for mode uncertainty, unexpected intervention, repeated intent error, failed override, lost link or limit breach.
- Stop for collision, pain, dizziness, distress, loss of balance, visual/sensory overload or unsafe fatigue.
- Do not use the lesson in public, clinical or hazardous settings or change autonomy level outside the responsible team.
Accessibility and adaptations
- Provide mode through combined visual, audio and tactile cues and an accessible override.
- Use slower simulation, larger corridor or step mode while keeping decision-rights and failure checks.
10 · Evidence and limits
Why these instructions are here
- primary research
Registered support for Shared autonomy: “Shared control of a medical robot with haptic guidance”. It bears on Task success, intent errors, override latency, workload, collisions and failure recovery versus manual, autonomous and shared control inside the Shared autonomy fixture. It does not validate “The robot always knows what the user wants”.
Shared control of a medical robot with haptic guidance - primary research
Constraint for Shared autonomy, drawn from “Continuous shared control of a mobile robot with brain–computer interface and autonomous navigation for daily assistance”: Studies were small or used nondisabled participants; intent inference, slower travel and failure-state agency remain unresolved.
Continuous shared control of a mobile robot with brain–computer interface and autonomous navigation for daily assistance - official guidance
Privacy design for Shared autonomy: minimise approved data in “A wheelchair-style simulator travels a marked virtual corridor. The person commands direction; automation may slow or steer around foam obstacles. A bright mode label shows MANUAL, AUTO or SHARED.” Keep Shared autonomy provenance and access visible before interpreting Task success, intent errors, override latency, workload, collisions and failure recovery versus manual, autonomous and shared control.
NIST Privacy Framework: A Tool for Improving Privacy Through Enterprise Risk Management, Version 1.0
Limits
- Shared autonomy boundary: interpret “Task success, intent errors, override latency, workload, collisions and failure recovery versus manual, autonomous and shared control” only for A wheelchair-style simulator travels a marked virtual corridor. The person commands direction; automation may slow or steer around foam obstacles. A bright mode label shows MANUAL, AUTO or SHARED.
- A successful result does not establish “The robot always knows what the user wants”.
- Shared autonomy limiting finding: Studies were small or used nondisabled participants; intent inference, slower travel and failure-state agency remain unresolved.
- No perfect-performance claim for Shared autonomy: the evidence register does not make “Task success, intent errors, override latency, workload, collisions and failure recovery versus manual, autonomous and shared control” universal, consequence-free or flawless in A wheelchair-style simulator travels a marked virtual corridor. The person commands direction; automation may slow or steer around foam obstacles. A bright mode label shows MANUAL, AUTO or SHARED.
- Scope remains Shared autonomy: A wheelchair-style simulator travels a marked virtual corridor. The person commands direction; automation may slow or steer around foam obstacles. A bright mode label shows MANUAL, AUTO or SHARED. Recheck the comparator, support and “Task success, intent errors, override latency, workload, collisions and failure recovery versus manual, autonomous and shared control” after any configuration change.
Open the complete canonical research register
- Primary empirical supportLimiting / contraryShared control of a medical robot with haptic guidance
Linfei Xiong; Chin Boon Chng; Chee Kong Chui; Peiwu Yu; Yao Li · 2017 · Primary research
- Primary empirical supportLimiting / contraryContinuous shared control of a mobile robot with brain–computer interface and autonomous navigation for daily assistance
Baoguo Xu; Deping Liu; Muhui Xue; Minmin Miao; Cong Hu; Aiguo Song · 2023 · Primary research
- Primary empirical supportLimiting / contraryAssistive Robotic Manipulation through Shared Autonomy and a Body-Machine Interface
Siddarth Jain; Ali Farshchiansadegh; Alexander Broad; Farnaz Abdollahi; Ferdinando Mussa-Ivaldi; Brenna D. Argall · 2015 · Primary research
- Primary empirical supportLimiting / contraryEvaluation of semiautonomous navigation assistance system for power wheelchairs with blindfolded nondisabled individuals
Vinod Sharma; Richard C. Simpson; Edmund LoPresti; Mark Schmeler · 2010 · Primary research
- Limiting / contraryOfficial boundary contextNIST Privacy Framework: A Tool for Improving Privacy Through Enterprise Risk Management, Version 1.0
National Institute of Standards and Technology · 2020 · Official standard
- Limiting / contraryOfficial boundary contextCybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions
United States Food and Drug Administration · 2026 · Official guidance
Read the complete evidence interpretation on the Power dossier.
Tutorial delivery controls
Learn, adapt, troubleshoot and resume
Progress is saved only in this browser on this device.
Step-by-step learner mode
Each activity includes its success check, a nearby accessible alternative and an “I’m stuck” correction path. Alternatives preserve the target where possible; when they change the task, Titan labels them as related rather than equivalent.
Allocate decisions explicitly
The team writes that the person chooses destination and may stop; automation may slow and propose obstacle avoidance within the corridor.
Every decision has a human or machine owner.
Every decision has a human or machine owner.
I’m stuck on this step
Reset: Re-read this authored instruction — “The team writes that the person chooses destination and may stop; automation may slow and propose obstacle avoidance within the corridor.” — and its success check, then attempt only this step.
Possible snag: Let the system infer all goals silently.
Correction: Put destination, motion and stop ownership on one card.
Possible snag: Assume automation will remain available.
Correction: Test a planned transition under supervision.
Stop / get help: Stop for mode uncertainty, unexpected intervention, repeated intent error, failed override, lost link or limit breach.
Make mode visible
Check the persistent mode label, transition sound or vibration and current override control.
The learner can identify the mode without guessing from motion.
The learner can identify the mode without guessing from motion.
I’m stuck on this step
Reset: Re-read this authored instruction — “Check the persistent mode label, transition sound or vibration and current override control.” — and its success check, then attempt only this step.
Possible snag: Infer mode from how the device feels.
Correction: Confirm mode before every start and transition.
Stop / get help: Stop for mode uncertainty, unexpected intervention, repeated intent error, failed override, lost link or limit breach.
Set bounds and fallback
Engineers configure speed, corridor, obstacle clearance, stop, manual/degraded mode and safe state.
The simulator cannot leave the declared envelope.
The simulator cannot leave the declared envelope.
I’m stuck on this step
Reset: Re-read this authored instruction — “Engineers configure speed, corridor, obstacle clearance, stop, manual/degraded mode and safe state.” — and its success check, then attempt only this step.
Possible snag: The result from “Engineers configure speed, corridor, obstacle clearance, stop, manual/degraded mode and safe state.” does not yet meet this declared check: The simulator cannot leave the declared envelope.
Correction: Return to the start of “Set bounds and fallback”, reduce complexity or pace, and repeat only the part needed to satisfy: “The simulator cannot leave the declared envelope.”
Stop / get help: Stop for mode uncertainty, unexpected intervention, repeated intent error, failed override, lost link or limit breach.
Record manual baseline
Complete the corridor in manual mode and log time, path error, interventions, workload and collisions.
Shared performance has a matched comparator.
Shared performance has a matched comparator.
I’m stuck on this step
Reset: Re-read this authored instruction — “Complete the corridor in manual mode and log time, path error, interventions, workload and collisions.” — and its success check, then attempt only this step.
Possible snag: The result from “Complete the corridor in manual mode and log time, path error, interventions, workload and collisions.” does not yet meet this declared check: Shared performance has a matched comparator.
Correction: Return to the start of “Record manual baseline”, reduce complexity or pace, and repeat only the part needed to satisfy: “Shared performance has a matched comparator.”
Stop / get help: Stop for mode uncertainty, unexpected intervention, repeated intent error, failed override, lost link or limit breach.
Run shared mode
The learner states destination, automation proposes path changes and the learner confirms or overrides according to the protocol.
Each machine intervention and human response is logged.
Each machine intervention and human response is logged.
I’m stuck on this step
Reset: Re-read this authored instruction — “The learner states destination, automation proposes path changes and the learner confirms or overrides according to the protocol.” — and its success check, then attempt only this step.
Possible snag: The result from “The learner states destination, automation proposes path changes and the learner confirms or overrides according to the protocol.” does not yet meet this declared check: Each machine intervention and human response is logged.
Correction: Return to the start of “Run shared mode”, reduce complexity or pace, and repeat only the part needed to satisfy: “Each machine intervention and human response is logged.”
Stop / get help: Stop for mode uncertainty, unexpected intervention, repeated intent error, failed override, lost link or limit breach.
Name disagreements
When automation steers right but the learner intends left, say “conflict,” stop or override and record whose evidence controlled the result.
Intent error is not hidden inside successful arrival.
Intent error is not hidden inside successful arrival.
I’m stuck on this step
Reset: Re-read this authored instruction — “When automation steers right but the learner intends left, say “conflict,” stop or override and record whose evidence controlled the result.” — and its success check, then attempt only this step.
Possible snag: Treat automation correction as always right.
Correction: Preserve user intent and inspect the trigger.
Stop / get help: Stop for mode uncertainty, unexpected intervention, repeated intent error, failed override, lost link or limit breach.
Practise degraded control
The team removes automation assistance; the learner uses the approved manual or alternative fallback or stops in safe state.
Loss of automation does not cause continued uncontrolled movement.
Loss of automation does not cause continued uncontrolled movement.
I’m stuck on this step
Reset: Re-read this authored instruction — “The team removes automation assistance; the learner uses the approved manual or alternative fallback or stops in safe state.” — and its success check, then attempt only this step.
Possible snag: The result from “The team removes automation assistance; the learner uses the approved manual or alternative fallback or stops in safe state.” does not yet meet this declared check: Loss of automation does not cause continued uncontrolled movement.
Correction: Return to the start of “Practise degraded control”, reduce complexity or pace, and repeat only the part needed to satisfy: “Loss of automation does not cause continued uncontrolled movement.”
Stop / get help: Stop for mode uncertainty, unexpected intervention, repeated intent error, failed override, lost link or limit breach.
Compare all modes
Review task success, intent errors, override latency, workload, collisions and agency in manual, auto and shared conditions; participant chooses next step.
Shared mode is not declared best from completion alone.
Shared mode is not declared best from completion alone.
I’m stuck on this step
Reset: Re-read this authored instruction — “Review task success, intent errors, override latency, workload, collisions and agency in manual, auto and shared conditions; participant chooses next step.” — and its success check, then attempt only this step.
Possible snag: The result from “Review task success, intent errors, override latency, workload, collisions and agency in manual, auto and shared conditions; participant chooses next step.” does not yet meet this declared check: Shared mode is not declared best from completion alone.
Correction: Return to the start of “Compare all modes”, reduce complexity or pace, and repeat only the part needed to satisfy: “Shared mode is not declared best from completion alone.”
Stop / get help: Stop for mode uncertainty, unexpected intervention, repeated intent error, failed override, lost link or limit breach.
Correct versus incorrect execution
These accessible process diagrams are built from the tutorial’s own right/wrong teaching. They are not anatomical illustrations and do not add technique beyond the canonical tutorial.
State what person and automation each control.
Let the system infer all goals silently.
Use a persistent label and transition cue.
Infer mode from how the device feels.
Stop, label conflict and log it.
Treat automation correction as always right.
Rehearse manual/alternative fallback or safe stop.
Assume automation will remain available during the shared-control corridor.
Method-structure checklist
10 of 10 structural checks present
- Ordered, Power-specific instructions — present
- Every activity has a success check — present
- Materials or supplied records are declared — present
- Measurement or assessment rule is present — present
- Tutorial-specific troubleshooting is present — present
- Stopping or escalation boundary is present — present
- Every activity has an adjacent alternative — present
- Correct-versus-incorrect comparison is present — present
- Evidence context is bound to the Power record — present
- Planning metadata is present — present
The method-readiness band and presence checklist assess tutorial presentation and are separate from evidence quality for the underlying Power. They are automated editorial aids, not human approval.
Manual editorial sign-off: Pending. This tutorial must not display a human-approved state until an identified editor signs the exact content hash.