Dedicated CloudXR Runtime#
The teleop examples auto-launch the CloudXR runtime and its WSS proxy through
CloudXRLauncher when they connect, so for the common workflow you never
start the runtime yourself (see 3. Configure CloudXR (optional) in the quick start).
Sometimes, though, you want the runtime running standalone in its own
terminal:
keep the runtime — and the headset connection — alive while you restart your teleop application repeatedly during development,
point OpenXR applications that do not embed
CloudXRLauncherat CloudXR,use launch modes that only the standalone launcher exposes, such as serving the web client locally (
--host-client) or the out-of-band automation flags (--setup-oob,--usb-local).
This page describes that dedicated workflow.
Start the runtime#
With the isaacteleop package installed (including the cloudxr extra,
see 2. Install the isaacteleop pip package), start the CloudXR runtime and WSS
proxy. The first run downloads the CloudXR Web Client SDK and asks you to
review and accept the EULA:
python -m isaacteleop.cloudxr
To bypass the interactive EULA prompt (e.g. for CI or headless runs), pass the flag:
python -m isaacteleop.cloudxr --accept-eula
You should see output similar to:
Figure: CloudXR run output#
Important
Keep this terminal open — CloudXR must stay running for the duration of the
session (Ctrl+C terminates it). Open a new terminal for the
remaining steps.
Also take note of the source ~/.cloudxr/run/cloudxr.env path mentioned
in the output. You will need to source it in
Load CloudXR environment variables.
Optional launch modes#
The launcher supports optional flags that can be combined to control how the headset connects and how the web client is delivered.
Command |
What it does |
|---|---|
|
Plain: headset navigates to GitHub Pages URL over WiFi. |
|
Serves the web client at |
|
OOB hub + CDP automation: opens the browser on the headset and auto-clicks CONNECT over USB adb. Client URL is GitHub Pages. |
|
OOB hub + CDP with client at |
|
All traffic over USB: adb-reverse + coturn TURN relay + loopback
HTTPS. Requires |
--usb-local requires --setup-oob. See
Out-of-Band Teleop Control for full OOB documentation.
Load CloudXR environment variables#
On every start the runtime writes its resolved environment to
~/.cloudxr/run/cloudxr.env (the exact path is printed in the startup
output). Sourcing it points the OpenXR loader at CloudXR — it sets
XR_RUNTIME_JSON along with the NV_CXR_* variables — so any OpenXR
application started from that terminal connects to the dedicated runtime.
Open a new terminal and source the setup script:
source ~/.cloudxr/run/cloudxr.env
Important
Make sure to run the rest of the commands in the same terminal. If you have to open a new terminal, source the CloudXR environment variables again.
Run teleop examples against the dedicated runtime#
The teleop examples under examples/teleop/python/ launch their own runtime
by default. When a dedicated runtime is already running, source the env file
(previous section) and pass --no-launch-cloudxr-runtime so the example
uses the running runtime instead of starting another one:
source ~/.cloudxr/run/cloudxr.env
python examples/teleop/python/gripper_retargeting_example_simple.py \
--no-launch-cloudxr-runtime
Configuration#
The standalone launcher accepts the same configuration flags as the embedded one:
--cloudxr-env-config <PATH>— aKEY=valueenv file of CloudXR runtime overrides, e.g.NV_DEVICE_PROFILE=auto-native. See 3. Configure CloudXR (optional) in the quick start for the list of supported environment variables.--cloudxr-install-dir <PATH>— CloudXR install directory (default:~/.cloudxr).
To inspect the active settings after startup:
cat ~/.cloudxr/run/cloudxr.env