Skip to content

VR

Immersive control from a WebXR headset (Quest). Grip squeezes to move — a clutch — and the trigger works that arm's gripper.

The VR page is hosted, not installed

Unlike the rest of the app, VR runs from a hosted web page. There's nothing to install on the headset: you open a URL in the headset's browser and you're in.

This works because the VR drive loop needs no local server — it talks to the robot directly over WebRTC, exactly like any other SDK client.

You don't type a URL into a headset. You generate a handoff link on the laptop and open it on the headset:

https://<vr-domain>/nori/vr?room=<robot>#token=<token>

The token rides in the URL fragment deliberately — fragments are never sent to a server, so the token stays out of server logs. The page scrubs it from the address bar once it's read.

🚧 To write

  • The actual VR domain, once it's assigned.
  • Exactly how an operator generates the handoff link in the app (which page, which button).
  • The on-device checklist: getting the link onto the Quest, browser requirements, what "Enter VR" looks like when it's ready.
  • The controller binding map (DEFAULT_BINDINGS), as a diagram.
  • What the in-VR HUD shows (telemetry, currents, haptics).

Requirements

  • A secure context (HTTPS). WebXR refuses to start otherwise — this is why "Enter VR" is greyed out on a plain-HTTP page.
  • A WebXR-capable browser on the headset.
  • The robot already paired and reachable.

Building your own VR client instead: SDK: VR.

Headset problems: VR troubleshooting.

Apache-2.0