Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Embed CloudXRLauncher lifecycle inside TeleopSession

Đang mở
#701 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
52/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
python
Lĩnh vực
ar-vr-xr, robotics

Hướng nghiên cứu

Bắt đầu với các entry point TeleopSession và CloudXRLauncher, đồng thời kiểm tra các context manager lồng nhau của ví dụ mcap hiện có. Theo dõi thứ tự khởi động, lỗi kết nối và teardown, sau đó bổ sung coverage cho thấy ownership nội bộ, tùy chọn opt-out đối với launcher bên ngoài và việc cleanup sạch sẽ khi xảy ra lỗi; ví dụ mcap hiện có vẫn phải hoạt động.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Embed CloudXRLauncher lifecycle inside TeleopSession

Context

In the live teleop path, users currently have to set up the CloudXR runtime
launcher and the teleop session as two separate context managers:

​```python
with launcher_ctx as launcher:
if launcher is not None:
print(f"[live] CloudXR runtime started (WSS log: {launcher.wss_log_path})")
print("[live] waiting for headset connection… (Ctrl+C to stop)")

with TeleopSession(config) as session:
    ...

​```

This was raised in review on the mcap-example PR (@aristarkhovNV): the nested
launcher context is extra plumbing the caller shouldn't have to wire up by hand.
Deferring it out of that PR to keep its scope on the mcap example only.

Proposal

Have TeleopSession optionally own the CloudXRLauncher lifecycle so the
common case collapses to a single context manager:

​python with TeleopSession(config) as session: ... ​

TeleopSession.__enter__ would start the launcher (when configured for the
live/CloudXR path) and __exit__ would tear it down, surfacing wss_log_path
and any launcher state via the session object.

Motivation
  • Removes boilerplate and the nested with from every caller.
  • Single ownership point for startup/teardown ordering (launcher must come up
    before the session connects, and tear down after).
  • Centralizes the launcher is not None guard instead of leaking it to callers.
Open questions / considerations
  • Opt-out path: keep the ability to inject an externally-managed launcher
    (e.g. pass launcher=... or manage_launcher=False) for callers that need to
    share one launcher across sessions or control its lifecycle themselves.
  • Backward compatibility: does anything depend on the current two-context
    shape? If so, keep the standalone launcher context working.
  • Failure semantics: if the launcher starts but the session fails to
    connect, ensure the launcher is cleanly torn down (no orphaned runtime).
  • Logging: preserve the [live] CloudXR runtime started (WSS log: …) and
    "waiting for headset connection" messages, moved inside the session.
Acceptance criteria
  • TeleopSession can start/stop the CloudXR launcher internally when configured.
  • Single with TeleopSession(config) works for the live path.
  • An escape hatch exists for an externally-managed launcher.
  • Startup/teardown ordering and failure cleanup are covered by a test.
  • Existing mcap example still works.
Ngôn ngữ chính
Python
Star
412
Fork
97
Merge trung bình
2 ngày 3 giờ
Pull request đã merge (30 ngày)
141

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của NVIDIA/IsaacCapture

Tất cả issue của NVIDIA/IsaacCapture

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.