- 1 · Live
- 2 · Effort
- 3 · Pass
- 4 · Fail
We built a lock-out/tag-out trainer on a pressurised line, where valves take sustained effort and spring back if released early, and the line only bleeds down once both ends are shut. Unsafe acts are recorded as faults instead of being prevented. A trainee can therefore complete every step of the procedure and still fail it.
What we tried
- We modelled the panel rather than capturing one, because a procedure needs parts that move and read out, which a capture cannot provide.
- We made valves need about 1.6 s of sustained effort, so closing one is work rather than a click.
- We let unsafe actions happen and recorded them, on the view that a trainer which prevents mistakes teaches nothing.
- We scripted four runs through the scoring to check that faults actually change the outcome.
What we measured
| Measure | Result | Note |
|---|---|---|
| Valve travel, sustained effort | 1.62 s | |
| Spring-back from half-turned to open | 0.45 s | |
| Bleed-down, 5.98 bar to the 0.2 bar safe mark | 4.28 s | |
| Correct run | 5/5 steps, passes | 7.6 s end to end in the browser |
| Locked a live line | 5/5 steps, fails | |
| Recorded a false verification | 5/5 steps, fails | |
| Skipped the lock | 4/5 steps, fails |
What went wrong
- A fully shut valve sprang back open when released, so the line never isolated and never bled down. Shut valves now latch, which is also how a gate valve behaves.
- The briefing panel was built before the confirmation panel but referred to it, so initialisation aborted part-way and the scene came up with no agent and no started procedure. It failed silently.
- Our first scoring counted a run as passed if every step was completed, which let a trainee lock a live line and still pass.
- In the first browser build, signing off a live line was recorded but not allowed, so the demo's "lock a live line" run logged the same fault on every frame, about 230 times, and then locked the line safely once it bled down. Each unsafe act is now recorded once and then allowed to happen.
- The simulation advanced one step per screen refresh, so on a 120 Hz display the valves and the bleed-down would have run at double speed. It now steps at a fixed 1/60 s whatever the display.
What happens next
- Add an alarm and a detent click; the panel currently has no audio, which costs more in feel than anything visual would.
- Confirm the spoken confirmation path with a real microphone; we could only verify the fallback.
- Try the reach, gaze and speech version in a headset, not only the button page.
Built with
- XR Blocks SDK 0.21.1 Apache-2.0
- three.js 0.184.0 MIT
Next experiment
One photo to an avatar that copies you through your webcam →
Want this for your data?