---
title: 'ERUPT: XR Motion Planning Toolkit'
url: https://www.emergentmind.com/topics/extended-reality-universal-planning-toolkit-erupt
type: topic
---

# ERUPT: XR Motion Planning Toolkit

Searching arXiv for the cited papers to ground the article.
arXiv search query: 2510.02464 ERUPT 2601.19303
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 [2510.02464]. 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 [2601.19303].

## 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 [2510.02464]. 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 [2510.02464].

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 [2510.02464]. 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 [2601.19303]. 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 [2510.02464]. 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 [2510.02464].

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 [2510.02464]. 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 [2510.02464]. 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 [2510.02464]. Fourth, once a preview is accepted, the resulting trajectory can be forwarded to a physical robot controller through MoveIt or another suitable ROS node [2510.02464].

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 [2510.02464]. 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 [2601.19303] 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 [2510.02464], but it suggests a plausible architectural generalization of ERUPT-style systems toward multi-client collaboration and versioned plan sharing across devices [2601.19303].

## 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 [2510.02464]. 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 [2510.02464]. 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 [2510.02464]. 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 [2510.02464]. An additional option allows the virtual robot to “mirror” the physical robot’s state, aligning virtual and real configurations before plan generation [2510.02464].

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 [2510.02464]. 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` [2510.02464]. On success, ERUPT displays the planning time and waypoint count and initiates replay; on failure, it surfaces the error code [2510.02464].

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 [2510.02464]. 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 [2510.02464]. 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 [2510.02464]. 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 [2510.02464].

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 [2510.02464].

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 [2510.02464]. 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 [2510.02464].

By contrast, the medical XR prototype summarized in [2601.19303] 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 [2601.19303]. 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 [2510.02464]. 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 [2510.02464]. The toolkit itself does not implement trajectory optimization, but MoveIt planners respect standard limits and constraints as configured in the underlying planning stack [2510.02464].

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 [2510.02464].

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 [2510.02464]. 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 [2510.02464]. 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 [2510.02464]. 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 [2510.02464].

## 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 [2510.02464]. 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 $L$, minimum clearance $c_{min}$, or user task completion time $U_t$, although these are identified as common evaluation metrics for systems of this class [2510.02464]. 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 [2510.02464]. 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 [2510.02464]. 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 [2510.02464]. ERUPT is open-source, and code was released for the final submission, although licensing and repository URL are not specified [2510.02464].

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 [2510.02464]. 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 [2510.02464]. Because MoveIt requires remove/add for collision-object scaling, native planning-scene support for in-place scaling would improve responsiveness at larger scale [2510.02464].

The medical XR prototype in [2601.19303] 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 $38.44\pm16.90$ versus XR SUS $76.25\pm13.43$ with an improvement of $+98.36\%$; for a coordinated stereoscopic-visualization setup, SUS values of $63.60\pm20.70$ for desktop, $72.20\pm14.50$ for a 3D panel, and $81.00\pm13.80$ for the coordinated platform, with one-way repeated-measures ANOVA $F(2,18)=4.119, p=0.034$ and a post-hoc paired $t$-test showing the coordinated platform significantly higher than desktop at $p=0.036$ [2601.19303]. 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 [2510.02464] [2601.19303].

Source: https://www.emergentmind.com/topics/extended-reality-universal-planning-toolkit-erupt