Skip to main content
By default the Quest streams controller pose to the robot over Wi-Fi. On some networks the headset’s Wi-Fi power-save buffering holds pose packets and releases them in bursts, adding ~150 ms gaps between updates that show up as stair-stepped, laggy arm motion. Quest over USB moves the active pose link onto a USB cable via an adb reverse tunnel, so the link is wired and deterministic — while keeping Wi-Fi as an automatic standby if the cable drops.
USB carries controller poses only. Camera video still streams over the LAN — WebRTC can’t cross the adb TCP forward — so you connect to the robot’s address as usual and the cameras keep working over Wi-Fi/Ethernet. USB just takes over the pose link.
When USB is selected, the headset sends every pose frame over both the cable and Wi-Fi with one logical producer id and sequence. The robot accepts whichever copy arrives first and discards the duplicate globally. USB normally wins because it is lower-latency; if the cable drops, the next Wi-Fi copy is accepted immediately with no reconnect, and a restored cable naturally wins again when its copies arrive first. Delayed copies can never rewind controls or enter the jitter buffer.

One-time setup

1

Enable Developer Mode on the Quest

  1. Open the Meta Quest mobile app on your phone, with your headset connected.
  2. Go to Menu → Devices → select your headset → Headset Settings → Developer Mode, and toggle it on (you may be prompted to create a free Meta “organization” first).
  3. Restart the headset.
This is the same Developer Mode used for remote teleop.
2

Confirm adb is installed on the robot machine

Nothing to do after a one-command install — axol provision sets up adb and the Quest udev rule for you. On a development install, run axol provision once.

Connect and drive

1

Plug the headset into the robot machine

Use a data-capable USB-C cable from the headset to the machine running axol serve (the one wired to the robot).
2

Authorize and connect from the control panel

In the control panel, the Quest tab under General settings shows the headset state. The first time, accept the Allow USB debugging? prompt in the headset (check Always allow from this computer). Once authorized, the tunnels come up automatically and the status turns green (Controller over USB); the tab’s Connect button is a manual fallback / reconnect.
3

Confirm the tunnel on localhost

In the headset browser, open https://localhost:8001 — the control panel, reached over the cable — and proceed past the certificate warning. If the panel loads, the tunnel is up. This works while nothing else is running, and it also lets you drive the panel from the headset.
Do this before anything else. The browser’s override is per-origin (scheme + host + port), so accepting :8001 does not cover :8000 — the USB pose link gets its own approval in a later step. Reaching the panel on localhost is what proves the cable path works, and it is the origin that is always available.
4

Enable USB in the VR app

Open the VR app at axol.almond.bot, enter the robot’s address as usual, and tick Quest over USB. The USB panel and its Authorize USB certificate button appear immediately, before you connect.
5

Authorize the USB certificate

The USB link uses wss://localhost:8000. It serves the same certificate you just saw on :8001, but the browser’s approval is per-origin, so this port needs its own. Until it’s approved the app runs on Wi-Fi and shows WiFi fallback — USB link down. Tap Authorize USB certificate and proceed past the warning (equivalently, open https://localhost:8000 in the headset browser). The status then flips to controller over cable.
Port 8000 only exists while a teleop or data-collection operation is running — the VR server is started and stopped with the operation, not by axol serve. Start the operation from the control panel first, otherwise the certificate page cannot load and the poses stay on Wi-Fi.
6

Enter VR

Press Enter VR and teleoperate as usual. You don’t have to wait for the USB link — Wi-Fi drives the arm until the cable comes up, then the robot switches to the wired stream automatically.
If the Quest settings tab shows unauthorized, re-accept the prompt in the headset. If it shows no device, replug the cable and confirm Developer Mode is on. A flaky cable is the most common cause of a link that won’t come up.

Next steps

Web Control Panel

Where the Quest settings tab lives and how connections work.

VR Interface

The WebXR app, camera views, and connection details.

Quest Without Wearing It

Keep the headset awake headless — the same cable also disables the proximity sensor.