XROps: XR Operations & Immersive Analytics

• XROps is a workflow- and operations-centric framework for extended reality systems, blending immersive analytics with dynamic, real-time control.
• It combines web-based authoring, server orchestration, and device-level rendering to achieve low-latency, adaptable performance.
• XROps leverages architectural decomposition and dataflow models to support immersive analytics, teleoperation, and scalable XR deployments.

Searching arXiv for papers on XROps and closely related XR operations frameworks. XROps is used in contemporary XR research in two closely related senses. In the paper "XROps: A Visual Workflow Management System for Dynamic Immersive Analytics" (Jeon et al., 14 Jul 2025), it denotes a web-based authoring system that allows users to create immersive analytics applications through interactive visual programming, manage the full lifecycle of immersive analytics applications, and modify the workflow on-the-fly with immediate feedback. In a broader XR systems literature, the same term functions as an operational perspective on how XR platforms are designed, deployed, monitored, and evolved across XR-specific operating systems, client/server runtimes, teleoperation stacks, and ROS-native operational interfaces (Braud et al., 2022, Caetano et al., 6 Aug 2025, Zhao et al., 31 Jul 2025, Coloma et al., 2024, Fresnillo et al., 2024). Taken together, these usages frame XROps as a workflow-centric and operations-centric approach to extended reality systems.

1. Conceptual scope and lineage

The most explicit formalization of XROps appears in immersive analytics. There, the name is stated to be inspired by DevOps and MLOps, with the goal of bringing automated, integrated lifecycle management to XR and immersive analytics workflows (Jeon et al., 14 Jul 2025). The system is organized around four design principles: R1 – Simple authoring, R2 – Adaptable to existing workflow, R3 – Support various data types, and R4 – Dynamic workflow management. These principles are intended to lower the technical barrier associated with Unity or Unreal, low-level programming, 3D coordinate systems, XR APIs, and device SDKs, while avoiding the rigid build–deploy–verify loop that characterizes many earlier XR toolchains.

The term is not yet used uniformly across the literature. In DiOS, XROps appears as an interpretive lens over an XR-specific operating system, emphasizing environment understanding, specialized hardware, networking, interaction, display, and privacy as OS primitives rather than application middleware (Braud et al., 2022). In XARP Tools, it denotes operational practices around a client/server XR framework in which XR devices become programmable from Python and callable by AI agents or Model Context Protocol clients (Caetano et al., 6 Aug 2025). In XRoboToolkit, it refers to a full-stack XR–robot teleoperation system whose architecture separates XR-side interaction and rendering, streaming and middleware, control, and robot or simulation layers (Zhao et al., 31 Jul 2025). In ROS-based robotics interfaces and lunar rover teleoperation, the same perspective emphasizes unified operational control, observability, modular configuration, and human-in-the-loop safety (Fresnillo et al., 2024, Coloma et al., 2024).

A plausible implication is that XROps is less a single standardized subsystem than a family of operational abstractions for XR: authoring, deployment, observability, policy, low-latency execution, and lifecycle control.

2. Architectural decomposition

The XROps immersive analytics system adopts a three-part architecture consisting of WebUI, Server, and XR Device (Jeon et al., 14 Jul 2025). The WebUI is a web-based 2D interface implemented with React and Rete.js; the Server is a Python-based API server containerized with Docker; and the XR Device is an HMD such as HoloLens 2 or HTC Vive running a pre-built XROps app. Communication is split across RESTful HTTP APIs between WebUI and Server, and HTTP plus TCP/IP streaming between XR Device and Server. Each XR device has a scheduler on the server, acting as a task queue; devices periodically poll their scheduler for new visualization specs.

This decomposition recurs in adjacent XROps-oriented systems. XARP Tools separates a server-side Python layer for logic, AI, and orchestration from a client-side XR runtime for rendering, device I/O, and responsive, low-latency user interaction, with a JSON-based protocol over WebSockets as the communication layer (Caetano et al., 6 Aug 2025). XRoboToolkit separates an XRoboToolkit-Unity-Client built on OpenXR, a XRoboToolkit-PC-Service (C++) and Python bindings, a XRoboToolkit-Robot-Vision component, and a XRoboToolkit-Teleop-Sample-Python controller stack (Zhao et al., 31 Jul 2025). DiOS generalizes the pattern to the operating-system level by placing Environment Understanding, Specialised Chips Drivers, Network, User Interaction, Display, and Privacy alongside conventional OS services (Braud et al., 2022).

Across these systems, the shared architectural thesis is that XR rendering and low-latency sensing stay close to the device, while orchestration, processing, or higher-level policy often move to a server, middleware layer, or operating-system substrate. In operational terms, XROps is therefore strongly associated with explicit separation of concerns and stable interfaces between XR clients and backend services.

3. Workflow, dataflow, and resource models

In the immersive analytics formulation, XROps models applications as a directed acyclic graph (DAG). Conceptually, a workflow is written as $G = (V, E)$, where $V$ is the set of nodes and $E \subseteq V \times V$ is the set of directed edges that pass data from outputs to inputs (Jeon et al., 14 Jul 2025). Node categories are Device, Input, Processing, and Rendering; interaction is part of the workflow semantics. The workflow is reactive: changing a node’s configuration, receiving new sensor input, or requesting a refresh re-executes the relevant subgraph and updates the XR or desktop view with immediate feedback.

The node system is unusually broad. Input nodes support tabular, mesh, image/volume, and environmental/sensor data. Processing nodes include data processing, position processing, sensor processing, and encoding. Position processing supports Target-link, Axis-link, and Object-link, while sensor processing includes Gesture Recognition, Marker Tracking, Generate Spatial Anchor, and Using Raw Sensor Data. Rendering can target desktop/WebGL or XR devices through a modified DXR grammar inspired by Vega-Lite (Jeon et al., 14 Jul 2025).

Related XROps-oriented systems elevate similar dataflow ideas into systems primitives. DiOS argues that the feature points, world model, semantic areas, and recognised objects are shared resources, and that the physical-digital world model should be treated as a shared OS resource accessed by all applications (Braud et al., 2022). XRoboToolkit uses a single JSON object at 90 Hz for tracking data, with OpenXR-style pose semantics such as

$[x, y, z, q_x, q_y, q_z, q_w],$

and a 26-joint hand skeleton following OpenXR’s reference (Zhao et al., 31 Jul 2025). XARP defines capabilities such as read, write, see, and head_pose, exposing them as Python methods, agent tools, and MCP tools through the XRApp abstraction (Caetano et al., 6 Aug 2025).

This suggests that XROps frequently treats XR applications not as monolithic binaries, but as dataflow graphs or capability graphs over stable resource contracts: device keys, schedulers, tool declarations, shared world models, or versioned schemas.

4. Runtime operation, latency, and observability

A central operational concern in XROps is low-latency execution. DiOS states XR guidelines of $\ge 60$ FPS, 2K–4K resolution, and motion-to-photon latency $< 20$ ms, and argues that these are required to avoid misalignment between physical and virtual objects and to preserve immersion (Braud et al., 2022). Its proposed response is a shift from an interrupt-driven task scheduling model to a steady-state, sensor-driven pipeline, together with accelerator-aware drivers and distributed offload support. The same networking component is expected to choose between retransmission (ARQ) and forward error correction (FEC) and to obtain a better trade-off between temporal quality, spatial video quality, and end-to-end delay through an adaptive hybrid NACK/FEC method.

XRoboToolkit provides concrete latency measurements for XR teleoperation. Using a precise LED panel setup and dual-view recording, it reports mean latency and standard deviation of 121.5 ms and 6.01 ms for Open-TeleVision, 82.0 ms and 6.32 ms for XRoboToolkit (ZED–PICO), and 100.5 ms and 3.12 ms for XRoboToolkit (PICO–PICO) (Zhao et al., 31 Jul 2025). Its streaming architecture also runs tracking at 90 Hz, with hand tracking at 60 Hz but aligned with the 90 Hz JSON stream.

Observability is equally prominent. The ROS-based operational UI paper describes a web-based, ROS-native operational UI implemented as a Vue.js single-page application with ROSBridge and roslibjs, exposing launchers, manual control, alarms, sensor dashboards, configuration panels, video streams, and process control (Fresnillo et al., 2024). Module status is represented by a state machine with Inactive, Transitioning, Active, and Incomplete. In XARP, the technical report does not specify logging, monitoring, or metrics, but it explicitly identifies connection lifetime, tool call success and failure, and latency of see, read, write, and head_pose as natural operational metrics in an XROps stack (Caetano et al., 6 Aug 2025).

The operational pattern is therefore twofold: deterministic or measured latency on the data path, and explicit, user-facing instrumentation on the control path.

5. Interaction, privacy, safety, and policy

XROps research repeatedly treats interaction and policy as system-level concerns rather than application add-ons. DiOS places User Interaction and Display at the same architectural level as Environment Understanding and Privacy, and states that with a single physical world to share between applications, the OS needs to decide which application may display content over each area of the physical world and which areas may not be overlaid with content (Braud et al., 2022). It further introduces a privacy enforcement layer between sensors and applications on the input side, and between applications and outputs on the output side, with responsibilities that include protection of spatial data, bystander privacy, and output policies such as preventing occlusion of critical real-world signs or moving vehicles.

The immersive analytics XROps system handles interaction through gesture-based manipulation, filtering, selection, and detail-on-demand within the XR device, but keeps authoring in the 2D WebUI (Jeon et al., 14 Jul 2025). The literature also shows XROps in safety-critical and human-in-the-loop settings. XRoboToolkit uses tracking confidence, grip-based engagement, and QP-based inverse kinematics with explicit constraints

$$l \leq \mathbf{C}(\mathbf{q}) \dot{\mathbf{q}} \leq u$$

to enforce joint limits and velocity bounds (Zhao et al., 31 Jul 2025). The ROS UI paper keeps safety logic in a dedicated ROS safety node, while the interface visualizes alarms and publishes only reset or update requests (Fresnillo et al., 2024). In lunar rover teleoperation, XR and AI are used to improve obstacle recognition and route planning; the study reports that XR teleoperation reduced cognitive load and increased perception of the environment relative to 2D teleoperation (Coloma et al., 2024).

A common misconception is that XROps concerns only deployment mechanics. The literature instead places privacy, spatial access control, output minimization, alarm handling, and constraint-aware interaction within the same operational envelope.

6. Application domains and operational exemplars

The XROps immersive analytics system is demonstrated through three substantial scenarios: sports data analysis using basketball shot data for LeBron James, medical data analysis for AR surgical guidance with pre-operative CT scans and live depth maps, and biological data analysis involving a roughly 4 GB confocal microscopy volume for neuron tracing and region-of-interest exploration (Jeon et al., 14 Jul 2025). These scenarios are significant because they combine file-based inputs, live XR sensor data, scientific processing, registration, and immersive rendering inside one user-editable workflow.

XARP extends the scope of XROps toward human and AI developers. Its three operating modes are library mode, agent toolkit mode, and MCP mode, and its reference implementation uses FastAPI, smolagents, fastmcp, and LMStudio (Caetano et al., 6 Aug 2025). The same capabilities can be exposed as Python methods, callable tools for an AI agent, or MCP tools for an external AI ecosystem. This makes XR devices operationally comparable to other tool endpoints in multi-agent or LLM-based systems.

XRoboToolkit demonstrates XROps in robot teleoperation and data collection. Its integrated pipeline logs 100 demonstrations of a bimanual carpet-folding task at 50 FPS, recording 14-D robot joint states, 14-D position control commands, and three RGB streams at 424×240 from two wrist-mounted D405i cameras and one overhead D435i camera (Zhao et al., 31 Jul 2025). The resulting dataset is used to fine-tune the $\pi_0$ VLA model with Low-Rank Adaptation for 80k training steps, batch size 16, and action horizon 50 frames; the reported autonomous result is 100% success in 30 minutes of continuous operation with about 30 seconds per autonomous episode.

Other operational exemplars broaden the domain further. The lunar rover system organizes Rover, ROS PC, and XR PC into a sensing → perception/mapping → AI detection → XR visualization → human control → actuation pipeline (Coloma et al., 2024). The ROS-based web UI is customized and tested in four industrial use cases involving two UR5 collaborative robots, two KUKA LBR iiwa, UR5 + Doosan M0609, and a single UR5, with deployment targets ranging from PC and tablet to smartphone (Fresnillo et al., 2024).

7. Evaluation, limitations, and open problems

The immersive analytics XROps paper evaluates usability with $N = 12$ participants and reports a System Usability Scale average of 71.67, with training time of 17 min 54 s ± 6 min 33 s, task T1 time of 16 min 35 s ± 9 min 11 s, and task T2 time of 10 min 16 s ± 6 min 23 s (Jeon et al., 14 Jul 2025). Participants highlighted visual programming, Vis Linking, and real-time analytics as strengths, while also noting unfamiliarity with visualization grammars, the limited flexibility of visual programming relative to arbitrary code, and fatigue from switching between the 2D WebUI and XR view.

The broader XROps literature also exposes substantial unresolved issues. DiOS is explicitly architectural and does not present an implemented system or quantitative evaluation; its claims about latency, efficiency, and privacy remain hypothetical and require concrete implementation and evaluation (Braud et al., 2022). XARP presently implements only the minimal toolset read, write, see, and head_pose, supports only a Meta Quest client and a web client, and provides no performance benchmarks or usability study (Caetano et al., 6 Aug 2025). XRoboToolkit notes limitations around whole-body tracking standardization, underactuated hands, and simulator diversity (Zhao et al., 31 Jul 2025). The ROS UI paper identifies security gaps such as the absence of TLS or secure WebSockets and does not address multi-robot fleets in depth (Fresnillo et al., 2024).

Across papers, recurrent open problems include scalable world-model management at city or planet scale, formalizing policy languages for spatial and output control, performance isolation and QoS between multiple XR applications, richer scientific visualization, multi-user synchronization, and better debugging and graph management for large workflows (Braud et al., 2022, Jeon et al., 14 Jul 2025). This suggests that XROps remains an active, still-consolidating research area rather than a closed operational doctrine.