ERUPT: XR Motion Planning Toolkit

• ERUPT is an XR system for interactive robot motion planning that enables users to dynamically create and reconfigure 3D environments.
• It integrates a Unity/OpenXR frontend with ROS 2 and MoveIt to allow direct manipulation, synchronized planning, and safe trajectory previewing.
• The toolkit underpins both physical robot deployment and collaborative multi-device planning, extending its applications to domains like surgical planning.

Searching arXiv for the cited papers to ground the article. arXiv search query: (Ngui et al., 2 Oct 2025) ERUPT (Qiu et al., 27 Jan 2026) The Extended Reality Universal Planning Toolkit (ERUPT) is an open, ROS 2–based system for interactive robot motion planning in extended reality (XR). It couples a Unity/OpenXR frontend with MoveIt on the ROS side so that operators can author and dynamically reconfigure environments, specify robot goals directly in three dimensions, request plans, inspect trajectories in virtual or augmented reality, and then deploy validated motions to physical robots (Ngui et al., 2 Oct 2025). In the underlying formulation, ERUPT shifts motion planning from a 2D screen-mediated workflow toward a spatial workflow centered on immersive visualization, direct manipulation, and synchronization between XR state and the robot planning scene. A later XR collaboration paper uses the name ERUPT in a broader, generalized blueprint sense for integrating planning, cloud data management, and coordinated visualization across devices; where that broader usage is relevant, it is distinguishable from the robot motion-planning toolkit proper (Qiu et al., 27 Jan 2026).

1. Definition and design rationale

ERUPT was proposed as “an extended reality (XR) system for interactive motion planning” that allows users to create and dynamically reconfigure environments while planning robot paths (Ngui et al., 2 Oct 2025). Its central premise is that immersive three-dimensional XR improves spatial understanding relative to workflows mediated through 2D displays such as RViz, where operators must mentally reconstruct three-dimensional relationships from flat projections and repeatedly change camera viewpoints to evaluate clearances and potential collisions. The toolkit therefore targets settings in which workcells are frequently rearranged, operators need to shape robot behavior with virtual constraints, and full-3D previewing can prevent near-miss collisions or undesired proximity to humans (Ngui et al., 2 Oct 2025).

The design goals stated for ERUPT are operational rather than purely visual. It is intended to support rapid environment reconfiguration, safe previewing of robot motions in a no-risk virtual space, and seamless transition from validated virtual trajectories to execution on physical robots (Ngui et al., 2 Oct 2025). Natural interaction is part of this rationale: users can grab, move, rotate, and resize obstacles in ways analogous to handling real-world objects, and can pose a robot either by manipulating its joints directly or by dragging its end-effector to a desired Cartesian pose. This suggests that ERUPT treats XR not merely as a visualization layer but as an input modality for authoring motion-planning problems.

A distinct but related usage appears in a later medical XR paper, where a “generalizable blueprint for an Extended Reality Universal Planning Toolkit (ERUPT)” is synthesized from a collaborative surgical-planning prototype (Qiu et al., 27 Jan 2026). In that context, ERUPT denotes a modular planning-and-collaboration architecture rather than the specific ROS 2 and MoveIt-based robot toolkit. The shared conceptual thread is end-to-end XR planning with synchronized downstream visualization and execution-related workflows.

2. System architecture and data flow

ERUPT comprises two main layers: an XR frontend implemented in Unity and OpenXR, and ROS 2 nodes that bridge to MoveIt and maintain the planning scene (Ngui et al., 2 Oct 2025). The XR application runs on an HMD, renders the robot and virtual environment, manages interaction logic, and communicates with ROS 2 Jazzy through the Unity ROS-TCP-Connector. The ROS layer exposes planning functionality through MoveIt, synchronizes the planning scene, and can optionally forward trajectories to robot controllers (Ngui et al., 2 Oct 2025).

The system’s data flow is organized around four linked processes. First, environment and robot authoring updates are bidirectional: objects created or modified in XR are tracked by per-object scripts and published through the TCP connector to ROS, while ROS-originated objects and robots are sent to XR so that both sides remain synchronized (Ngui et al., 2 Oct 2025). Second, planning-scene synchronization is handled incrementally through a dedicated ROS node that manages moveit_msgs/CollisionObject updates. The node caches objects already known to XR and transmits only deltas—added, pose-updated, or removed objects—rather than repeatedly sending full-scene messages as the scene grows (Ngui et al., 2 Oct 2025). Third, planning requests are assembled by the XR “planning dashboard” as moveit_msgs/MotionPlanRequest messages containing the chosen start and goal as well as planning parameters, then sent over ROS for MoveIt to solve (Ngui et al., 2 Oct 2025). Fourth, once a preview is accepted, the resulting trajectory can be forwarded to a physical robot controller through MoveIt or another suitable ROS node (Ngui et al., 2 Oct 2025).

The incremental synchronization strategy is technically significant because object resizing is not natively supported in place by MoveIt collision geometry. ERUPT therefore realizes resizing as a “remove” followed by an “add” with new dimensions, and bundles those updates to preserve responsiveness (Ngui et al., 2 Oct 2025). This architecture indicates an emphasis on keeping XR and MoveIt in lockstep while minimizing bandwidth and HMD-side processing costs.

The broader medical-XR blueprint derived in (Qiu et al., 27 Jan 2026) adopts a three-module organization—XR-based immersive planning, cloud-based data management, and coordinated stereoscopic 3D displays—implemented with ThinkPHP plus RBAC for data management and Unity-based synchronization for display coordination. That paper does not describe the robot-planning architecture of (Ngui et al., 2 Oct 2025), but it suggests a plausible architectural generalization of ERUPT-style systems toward multi-client collaboration and versioned plan sharing across devices (Qiu et al., 27 Jan 2026).

3. Spatial interaction, planning requests, and planning-scene semantics

ERUPT emphasizes fluid interaction modalities in which environment editing and robot posing are both first-class operations (Ngui et al., 2 Oct 2025). Environment authoring is mediated through a toggleable wrist menu attached to the left controller. Users can spawn primitive shapes such as boxes, which become collision objects in MoveIt’s planning scene; translate and rotate objects by grabbing them; perform uniform scaling through two-handed grabs; apply axis-specific scaling after selection with the right controller trigger; and delete objects through the same menu (Ngui et al., 2 Oct 2025). All such changes are propagated immediately to ROS and reflected in MoveIt’s planning scene.

Robot interaction is based on URDF-consistent import and manipulation. Robots are imported via the Unity URDF Importer, which preserves consistency with MoveIt’s URDF-based kinematics and collision geometry (Ngui et al., 2 Oct 2025). Operators can pose the robot by rotating individual joints through grab-and-rotate gestures or by dragging an end-effector handle to a Cartesian pose. When the end-effector is moved, ERUPT runs inverse kinematics to compute joint angles that satisfy the target pose, and the resulting configuration can be committed as the start or goal state for planning through dedicated UI controls (Ngui et al., 2 Oct 2025). An additional option allows the virtual robot to “mirror” the physical robot’s state, aligning virtual and real configurations before plan generation (Ngui et al., 2 Oct 2025).

The planning dashboard exposes planner configuration parameters queried from the user’s ROS setup. It allows selection of a MoveIt planning pipeline and planner, as well as specification of maximum planning time and number of attempts (Ngui et al., 2 Oct 2025). XR gesture-defined configurations are translated into MotionPlanRequest fields, specifically start state and goal constraints. More concretely, the request structure includes start_state, goal_constraints, pipeline_id, planner_id, num_planning_attempts, and allowed_planning_time (Ngui et al., 2 Oct 2025). On success, ERUPT displays the planning time and waypoint count and initiates replay; on failure, it surfaces the error code (Ngui et al., 2 Oct 2025).

Planning-scene semantics are expressed through moveit_msgs/CollisionObject operations. The toolkit treats XR-spawned geometry as collision objects and supports both primitives and meshes for collision geometry, although the paper notes that current XR rendering is not photorealistic (Ngui et al., 2 Oct 2025). The synchronization logic follows four operations: add, modify pose, resize, and remove. Add publishes a new collision object with geometry, pose, and ID; modify pose republishes an update with the same ID and a new pose; resize performs remove followed by add with new dimensions; remove publishes a remove operation for the object ID (Ngui et al., 2 Oct 2025). This operational model is central to ERUPT’s ability to maintain a shared planning scene during active manipulation.

4. Coordinate frames, calibration, and XR-to-robot alignment

ERUPT supports both VR and AR deployment, but alignment has special importance in AR because the virtual robot must correspond to a physical counterpart (Ngui et al., 2 Oct 2025). In VR, users may place the imported robot model anywhere in the virtual scene. In AR, ERUPT provides a fiducial-based placement method in which a QR code is placed on a plane such as the ground or tabletop detected by the HMD’s spatial mapping system. The application recognizes the marker and anchors the robot base to that location (Ngui et al., 2 Oct 2025).

The paper frames alignment in terms of rigid transforms in $SE(3)$. Let $T_{world}^{XR}$ denote the XR scene pose with respect to a world or physical frame, and let $T_{world}^{robot}$ denote the robot base pose in that same world frame. The transform from XR coordinates to the robot base frame is then given by

$$T_{XR}^{robot} = T_{world}^{robot} (T_{world}^{XR})^{-1}.$$

This relation ensures that motions previewed in XR correspond to the same poses when executed on the real robot, assuming consistent URDF geometry and accurate fiducial placement (Ngui et al., 2 Oct 2025).

The practical deployment workflow follows directly from this alignment model. The virtual robot is first placed in AR using the fiducial-based method so that its base aligns with the physical robot. The physical robot’s current configuration is mirrored in XR to define the start state. Obstacles, including virtual “no-go” volumes, are then authored or adjusted, the goal is defined by end-effector dragging or joint posing, and the resulting plan is previewed and inspected before execution on the physical robot (Ngui et al., 2 Oct 2025). The demonstrations report accurate correspondence between virtual and real behavior under QR-code alignment and matching URDF geometry, but no quantitative accuracy metrics are reported (Ngui et al., 2 Oct 2025).

By contrast, the medical XR prototype summarized in (Qiu et al., 27 Jan 2026) does not describe registration procedures, coordinate frames, or alignment algorithms. That absence is explicitly noted there, and the proposed inclusion of registration APIs or fiducial-based and algorithmic methods is labeled as a recommendation beyond the paper’s scope (Qiu et al., 27 Jan 2026). This contrast highlights that calibrated XR-to-physical alignment is a concrete technical component of robot ERUPT but not of the generalized medical blueprint.

5. Motion-planning model, visualization, and execution

ERUPT delegates motion generation to MoveIt and thereby inherits the planning pipelines and planners exposed by the user’s MoveIt configuration, commonly OMPL-based planners (Ngui et al., 2 Oct 2025). In the demonstrated workflows, goals are specified either by setting joint-space start and goal states directly or by dragging the end-effector and relying on inverse kinematics to derive a feasible goal configuration (Ngui et al., 2 Oct 2025). The toolkit itself does not implement trajectory optimization, but MoveIt planners respect standard limits and constraints as configured in the underlying planning stack (Ngui et al., 2 Oct 2025).

The paper presents representative formulations typical of MoveIt/OMPL setups. These include joint-space trajectories $q(t) \in \mathbb{R}^n$ subject to velocity and acceleration bounds, a conceptual clearance-aware objective,

$$J = \int_0^T (\lambda_s \lVert \dot{q}(t) \rVert^2 + \lambda_c C(q(t))) \, dt,$$

Cartesian path length

$L = \sum_{k=1}^{K} \lVert x_k - x_{k-1} \rVert_2,$

and a signed-distance collision constraint

$g(q) = d(q) - d_{min} \ge 0.$

ERUPT forwards whatever constraints and tolerances are included in the MotionPlanRequest, with start and goal constraints serving as the primary constraints in the current demonstrations and additional path constraints being possible through the MoveIt API depending on configuration (Ngui et al., 2 Oct 2025).

Visualization in XR is not limited to static rendering. Start and goal states are color-coded—green for start and orange for goal—and a “ghost” robot in cyan replays the planned trajectory as a time-lapse preview so that operators can walk around the scene and inspect clearances from multiple vantage points (Ngui et al., 2 Oct 2025). The interface also shows planning time and waypoint count, exposes error codes when planning fails, and includes a “Stop Replay” control that immediately cancels animation so that requests or environment settings can be iterated rapidly (Ngui et al., 2 Oct 2025). This preview stage is functionally central: ERUPT is designed to let users validate motion in a collision-free virtual twin before sending the same trajectory to a physical system.

Execution closes the loop between XR planning and robotics deployment. Once previewed behavior is satisfactory, trajectories can be executed through MoveIt or sent to external controllers (Ngui et al., 2 Oct 2025). The intended significance is risk reduction in physical workspaces, because collisions are first explored and avoided in a virtual space. The paper’s demonstrations emphasize this workflow qualitatively rather than through benchmark-style quantitative analysis (Ngui et al., 2 Oct 2025).

6. Evaluation, software stack, limitations, and broader interpretations

The published evaluation of ERUPT is qualitative. The paper presents demonstrations showing that the system can reconfigure environments quickly, preview trajectories in immersive 3D to judge clearances and motion quality, and execute vetted trajectories on a physical robot (Ngui et al., 2 Oct 2025). It explicitly does not present a formal user study or benchmark suite, and it does not report numerical values for planning time $T_p$, success rate $S$, path length $T_{world}^{XR}$0, minimum clearance $T_{world}^{XR}$1, or user task completion time $T_{world}^{XR}$2, although these are identified as common evaluation metrics for systems of this class (Ngui et al., 2 Oct 2025). A common misconception would therefore be to treat ERUPT as already validated by controlled human-subjects experiments or standardized robotics benchmarks; that is not supported by the reported results.

The implemented software and hardware stack is described concretely. The XR frontend uses Unity with OpenXR and supports a broad range of modern commercial HMDs and their controllers; AR mode depends on the HMD’s environment scanning and fiducial detection for robot placement (Ngui et al., 2 Oct 2025). The robotics side is based on ROS 2 Jazzy and MoveIt for planning, collision checking, and trajectory execution, with OMPL planners available through the MoveIt setup (Ngui et al., 2 Oct 2025). Communication is handled through the Unity ROS-TCP-Connector, which supports publishing, subscribing, and services but not actions, and this limitation affects possible future integration with action-oriented features such as MoveIt’s Hybrid Planner (Ngui et al., 2 Oct 2025). ERUPT is open-source, and code was released for the final submission, although licensing and repository URL are not specified (Ngui et al., 2 Oct 2025).

The limitations and future-work agenda are correspondingly specific. The lack of action support in the ROS-TCP-Connector constrains dynamic planning features, including planning in environments with moving obstacles and online replanning; the authors plan to add this pathway (Ngui et al., 2 Oct 2025). Additional future directions include exposing deeper planner customization in XR, enabling direct human correction of computed trajectories, improving visual realism, adding hand-tracking, and extending support toward multi-robot workflows, richer physics or haptics, collaborative planning among multiple users in shared XR, learning-based methods that suggest plans or constraints from demonstrations, and teleoperation overlays (Ngui et al., 2 Oct 2025). Because MoveIt requires remove/add for collision-object scaling, native planning-scene support for in-place scaling would improve responsiveness at larger scale (Ngui et al., 2 Oct 2025).

The medical XR prototype in (Qiu et al., 27 Jan 2026) is relevant as a comparative case because it reports actual user-study metrics for an XR planning-and-visualization workflow: for liver surgeons, desktop SUS $T_{world}^{XR}$3 versus XR SUS $T_{world}^{XR}$4 with an improvement of $T_{world}^{XR}$5; for a coordinated stereoscopic-visualization setup, SUS values of $T_{world}^{XR}$6 for desktop, $T_{world}^{XR}$7 for a 3D panel, and $T_{world}^{XR}$8 for the coordinated platform, with one-way repeated-measures ANOVA $T_{world}^{XR}$9 and a post-hoc paired $T_{world}^{robot}$0-test showing the coordinated platform significantly higher than desktop at $T_{world}^{robot}$1 (Qiu et al., 27 Jan 2026). Those results pertain to a surgical-planning system, not to the robot ERUPT toolkit itself. A plausible implication is that the broader ERUPT concept—understood as immersive planning plus synchronized visualization and collaboration—has relevance beyond robot motion planning, but the empirical evidence should not be conflated across domains.

Taken together, the currently documented ERUPT system is best understood as a MoveIt-integrated XR interface for environment authoring, robot posing, trajectory preview, and real-robot deployment, with a broader interpretive extension toward multi-device collaborative planning architectures in other domains (Ngui et al., 2 Oct 2025, Qiu et al., 27 Jan 2026).