Adds CloudXR runtime auto-launch to teleop scripts#5187
Adds CloudXR runtime auto-launch to teleop scripts#5187rwiltz merged 3 commits intoisaac-sim:developfrom
Conversation
There was a problem hiding this comment.
Code Review — PR #5187: Auto-launch CloudXR runtime and ship device-specific .env profiles
Summary
This PR eliminates the multi-terminal CloudXR setup by auto-launching the runtime from TeleopSessionLifecycle.start() and shipping two device-specific .env profiles (Quest/Pico and Apple Vision Pro). It also promotes isaacteleop~=1.0.0 from an optional extra to a hard dependency. Solid quality-of-life improvement that simplifies the user workflow from 3 terminals + manual env-sourcing down to a single command.
Design Assessment
Good: Clean separation between CloudXRRuntimeCfg (data) and _ensure_cloudxr_runtime (lifecycle), lazy import of CloudXRLauncher, env-var escape hatch (ISAACLAB_CXR_SKIP_AUTOLAUNCH), and proper shutdown in stop(). The --cloudxr_env CLI flag provides a clean override mechanism.
Architecture Impact
- Dependency change:
isaacteleop~=1.0.0becomes a hard install requirement. This means allisaaclab_teleopusers will pull it, even if they only use keyboard/spacemouse teleop. This is a deliberate decision noted in the changelog; worth confirming with the team that the install-size/time trade-off is acceptable. - Blast radius: Limited to teleop workflows. Non-teleop tasks are unaffected. The
CloudXRLauncherimport is lazily deferred behindTYPE_CHECKINGand a runtime conditional, so non-CloudXR paths don't pay import cost.
Implementation Verdict
Well-structured. A few issues noted below — one medium-severity robustness concern, one style point, and one doc nit.
Test Coverage
_ensure_cloudxr_runtime with mocked CloudXRLauncher would verify the skip/launch logic paths. The ISAACLAB_CXR_SKIP_AUTOLAUNCH env-var check and auto_launch=False branches are trivially testable without any GPU/XR hardware.
CI Status
pre-commit: ✅ passlicense-check: ⏳ pendingBuild Base Docker Image: ⏳ pendingBuild Latest Docs: ⏳ pending- No failures at time of review.
Findings
See inline comments.
Greptile SummaryThis PR adds automatic lifecycle management for the CloudXR runtime and WSS proxy during Confidence Score: 5/5Safe to merge — all remaining findings are P2 style/cleanup suggestions that do not affect correctness. The PR is well-scoped, backed by thorough unit tests (env-var skip, idempotency, constructor args, start/stop integration), and the previous P1 concerns from the review thread have been addressed. The two remaining comments are P2: a narrow exception catch in stop() and a copy-paste helper that could drift. session_lifecycle.py (stop() exception handling) and the two entry-point scripts (duplicated _resolve_cloudxr_env) Important Files Changed
Sequence DiagramsequenceDiagram
participant Script as teleop_se3_agent.py
participant Factory as create_isaac_teleop_device
participant Device as IsaacTeleopDevice
participant Lifecycle as TeleopSessionLifecycle
participant CXR as CloudXRLauncher
Script->>Script: _resolve_cloudxr_env("cloudxrjs")
Script->>Factory: create_isaac_teleop_device(cfg, cloudxr_env_file)
Factory->>Device: IsaacTeleopDevice(cfg, cloudxr_env_file)
Device->>Lifecycle: TeleopSessionLifecycle(cfg, cloudxr_env_file)
Script->>Device: __enter__()
Device->>Lifecycle: start()
Lifecycle->>Lifecycle: _ensure_cloudxr_runtime()
Lifecycle->>CXR: CloudXRLauncher(install_dir, env_config, accept_eula=False)
CXR-->>Lifecycle: launcher instance
Lifecycle-->>Lifecycle: _cloudxr_launcher assigned
loop Each simulation frame
Script->>Device: advance()
Device->>Lifecycle: step(anchor_world_matrix_fn)
Lifecycle-->>Device: action tensor
end
Script->>Device: __exit__()
Device->>Lifecycle: stop()
Lifecycle->>CXR: stop()
alt success
CXR-->>Lifecycle: OK
Lifecycle-->>Lifecycle: _cloudxr_launcher = None
else RuntimeError
Lifecycle-->>Lifecycle: retain launcher reference
end
Reviews (4): Last reviewed commit: "Launch the CXR runtime automatiaclly whe..." | Re-trigger Greptile |
AntoineRichard
left a comment
There was a problem hiding this comment.
Thanks @rwiltz for the helping us bringing back XR workflows! There are a bunch of comments from the bots that I think are relevant could you address / answer / close them?
Thanks!
59da18a to
2d4bcda
Compare
|
Tip: Greploop — Automatically fix all review issues by running Use the Greptile plugin for Claude Code to query reviews, search comments, and manage custom context directly from your terminal. |
|
@greptile |
|
@isaaclab-review-bot |
6c234d9 to
86a69fc
Compare
|
I am able to run through the steps then running teleop automatically starts up for me and I can connect Quest3 to it after Start XR. Similar seamless flow to IL 2.3 |
|
LGTM besides the comment that we chatted about. |
92d1e71 to
1f391a8
Compare
|
@greptile |
|
LGTM. Just retested on Quest3 and it was a seamless experience. Nice! |
Description
Auto-launch the CloudXR runtime and WSS proxy when running teleop_se3_agent.py or record_demos.py via new --cloudxr_env and --auto_launch_cloudxr script-level CLI arguments. The default profile is cloudxrjs (Quest/Pico); use --cloudxr_env avp for Apple Vision Pro or --cloudxr_env none to disable.
Add cloudxr_env_file and auto_launch_cloudxr parameters to create_isaac_teleop_device(), IsaacTeleopDevice, and TeleopSessionLifecycle so CloudXR configuration flows from scripts into the session lifecycle without per-environment config boilerplate.
Ship two bundled .env profiles (CLOUDXR_JS_ENV, CLOUDXR_AVP_ENV) and update docs with simplified --cloudxr_env avp / --cloudxr_env cloudxrjs shorthands.
Fixes # (issue)
Type of change
Checklist
pre-commitchecks with./isaaclab.sh --formatconfig/extension.tomlfileCONTRIBUTORS.mdor my name already exists there