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 tunnel comes up automatically and the status turns green (Controller over USB); the tab’s Connect button is a manual fallback / reconnect.
3

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 before connecting.
4

Authorize the USB certificate

The USB link uses wss://localhost:8000, whose self-signed certificate is a separate origin from the host cert you already approved. Until it’s approved the app runs on Wi-Fi and shows WiFi fallback — USB link down with an Authorize USB certificate button — tap it and proceed past the warning (equivalently, open https://localhost:8000 in the headset browser and proceed). The status then flips to controller over cable.
5

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.