XPolicyLab: Unified Policy Integration

• XPolicyLab is a policy infrastructure that standardizes policy interaction between simulation and real-world environments within RoboDojo.
• It integrates modular components such as data converters, model-server wrappers, deployment scripts, and a lightweight WebSocket/MessagePack communication layer.
• The system enables end-to-end evaluation across 42 simulation and 18 real-world tasks, ensuring reproducible and efficient benchmark performance.

Searching arXiv for the cited RoboDojo paper to ground the article in the source publication. XPolicyLab is a policy infrastructure introduced within RoboDojo as a Python package that sits between the environment—simulation or real—and heterogeneous policy implementations, providing a single integration path for training, simulation evaluation, and remote real-world deployment (Chen et al., 5 Jul 2026). Within the RoboDojo framework, it is coupled to a unified sim-and-real benchmark that includes 42 simulation tasks and 18 real-world tasks, and it is intended to let policies be integrated once and then evaluated across Isaac Sim and RoboDojo-RealEval with zero or minimal code changes. The system combines a minimal policy interface, a standard data schema, a unified communication protocol based on WebSocket and MessagePack, deployment scripts, and leaderboard tooling into one end-to-end evaluation stack (Chen et al., 5 Jul 2026).

1. Definition and role within RoboDojo

XPolicyLab is one of the central infrastructural components of RoboDojo. RoboDojo itself is described as a unified sim-and-real benchmark for comprehensive evaluation of generalist robot manipulation policies, motivated by the limitations of existing benchmarks, which are characterized as often relying on simple, short-horizon, or skill-narrow tasks with limited capability coverage and as being conducted only in simulation or only in the real world (Chen et al., 5 Jul 2026). In that setting, XPolicyLab functions as the layer that standardizes policy interaction across both domains.

The package is explicitly positioned between the environment and heterogeneous policy implementations. This placement is consequential because the surrounding benchmark is split across heterogeneous parallel simulation in Isaac Sim and a reproducible real-world evaluation system with remote cloud access, standardized hardware, scene reset, evaluation protocol, and deployment interface. XPolicyLab is therefore not merely a training wrapper or an evaluation script; it is the mechanism through which the same policy package can participate in both the simulation benchmark and RoboDojo-RealEval with minimal adaptation (Chen et al., 5 Jul 2026).

A common misconception in evaluation of robot manipulation systems is that scalable simulation feedback alone is sufficient. RoboDojo’s framing rejects that assumption by stating that simulation enables scalable feedback but misses physical deployment challenges, while real-world evaluation is costly, time-consuming, and difficult to reproduce. XPolicyLab is designed around that duality: it does not replace either simulation or real-world testing, but instead provides a common interface spanning both.

2. Software stack, modular components, and interfaces

The software stack of XPolicyLab is defined by three adjacent layers. The simulation backend is NVIDIA Isaac Sim 4.5 via Isaac Lab, hosting MagicSim’s modular “manager” framework for physics, rendering, scene construction, and asset loading. The real-world platform is RoboDojo-RealEval hardware with standardized bimanual robots—ARX X5, Piper, and Piper X—together with fixed cameras, lighting, and a web-touchscreen interface. XPolicyLab itself is the policy infrastructure connecting these environments to policy implementations (Chen et al., 5 Jul 2026).

Its modular structure comprises four concrete component classes:

Component	Function
Data-converter modules	Transform raw RoboDojo trajectories into each policy’s preferred training format
Model-server wrappers	Expose a small common interface: reset(), update_obs(...), get_action(...)
Deployment scripts and configs	Launch training, local simulation evaluation, and remote real-world evaluation
Communication layer	Provide client-server RPC via WebSocket and MessagePack

The data-converter modules transform raw RoboDojo trajectories consisting of multi-view RGB/D, joint states, end-effector poses, and language into policy-specific formats such as HDF5, LMDB, PyTorch Dataset, and precomputed embeddings. This design allows policies with heterogeneous training pipelines to consume the same underlying trajectories without modifying the benchmark’s upstream data representation.

The model-server wrappers are defined on a per-policy basis and expose a small common interface. The methods named in the specification are reset(), update_obs(o) or update_obs_batch([o_1,\ldots,o_B]), and get_action() or get_action_batch() \rightarrow action chunks. This is the functional core of XPolicyLab’s unification strategy: policies are not required to share an internal architecture, only a common server-side contract.

The communication layer is described as lightweight and uses WebSocket plus MessagePack for client-server RPC between environment and policy. In simulation, Isaac Lab’s VecEnv steps a batch of heterogeneous scenes in parallel, each scene seeded independently by YAML configs, and at each step wraps observations into a dict that is MessagePack-serialized and sent via WebSocket to the policy server. After the policy replies with a batch of action chunks, the actions are unpacked and env.step_batch(...) executes them. In the real world, RoboDojo-RealEval’s local control computer runs a WebSocket client that captures three RGB streams—one head camera plus two wrist cameras—together with robot joint states, packages them as the same observation dict, and queries the policy server through MessagePack over WebSocket. Returned end-effector target poses and gripper commands are passed to Pink inverse-kinematics/motion-planner for execution on the physical robot (Chen et al., 5 Jul 2026).

The canonical data flow is specified as:

1. environment.reset() $\rightarrow$ initial observation
2. policy.reset()
3. Loop:
   • env \rightarrow obs \rightarrow policy.update_obs()
   • policy.get_action() \rightarrow action\_chunk
   • env.step(action) until done
   • observation, reward, done returned

This suggests that XPolicyLab’s abstraction boundary is deliberately narrow: observation transport, policy query, and action return are standardized, while policy internals remain unconstrained.

3. Policy integration workflow

The policy integration workflow is organized as a package-level convention under XPolicyLab/policies/YourPolicyName/. A new policy directory contains model.py, which defines a class YourPolicy(ModelBase) with methods reset(), update_obs, and get_action(...); config.yaml, which lists training and evaluation hyperparameters and model paths; deploy.yml, which describes server ports, GPU requirements, and the Python environment; and the scripts process_data.sh, train.sh, and eval.sh (Chen et al., 5 Jul 2026).

Data conversion is performed through xpolicylab/data_converter.py, with an example invocation that takes --input-dir $ROBO_DOJO_RAW_DATA, writes to --output-dir ./data/YourPolicyName, and specifies a format such as hdf5. Training is then launched through xpolicylab/train.py using --config config.yaml and --data-dir ./data/YourPolicyName. Local simulation testing starts a policy server with xpolicylab/serve.py --config deploy.yml and then runs robodojo_sim_eval.py against a policy host, specifying the task groups generalization memory precision long_horizon open. Real-world deployment uses the same policy server Docker image, which is pushed to RoboDojo-RealEval cloud, after which deploy.yml is updated for the cloud endpoint and the web interface is used to select remote policy server and point to wss://your-policy-url (Chen et al., 5 Jul 2026).

The key property of this workflow is the stated minimal adaptation between simulation and real. The reason given is precise: both clients use the same observation schema, the same reset() and get_action() calls, and the same action-chunk format. A plausible implication is that the benchmark treats sim-to-real transition primarily as a deployment-context change rather than an API change. This does not imply identical performance across domains, but it does imply that the infrastructure is intended to minimize engineering variance unrelated to policy capability.

4. Evaluation pipeline and metrics

XPolicyLab’s simulation evaluation script orchestrates five dimensions: Generalization, Memory, Precision, Long-Horizon, and Open (Chen et al., 5 Jul 2026). For each dimension $d$, it loads YAML task configs $T_d = \{t_1,\ldots,t_{|T_d|}\}$ and spawns a heterogeneous VecEnv in which each parallel worker steps a different task instance. The procedure runs 50 episodes per task, with the specific note that the 12 Generalization tasks each receive 25 “standard” and 25 “random” seeds.

For each episode $e$ and task $i$, the benchmark records

$$\mathrm{success}_{i,e} \in \{0,1\}, \qquad \mathrm{partial\_score}_{i,e} \in [0,\mathrm{MaxScore}_i].$$

It then computes per-task success rate and average score as

$$SR_i = \frac{1}{50}\sum_e \mathrm{success}_{i,e}, \qquad \mathrm{Score}_i = \frac{1}{50}\sum_e \mathrm{partial\_score}_{i,e}.$$

Averages across tasks in each dimension are

$$SR_d = \frac{1}{|T_d|}\sum_{i \in T_d} SR_i, \qquad \mathrm{Score}_d = \frac{1}{|T_d|}\sum_{i \in T_d} \mathrm{Score}_i.$$

Overall metrics are then

$$SR_{\mathrm{overall}} = \frac{1}{5}\sum_d SR_d, \qquad \mathrm{Score}_{\mathrm{overall}} = \frac{1}{5}\sum_d \mathrm{Score}_d.$$

The real-world benchmark uses 18 tasks on three embodiments, each with 10 trials. Hardware conditions are standardized through a fixed table, fixed-pose arms, fixed camera mounts, controlled LED lighting, and opaque curtains around the frame. Scene reset is performed by overlaying the reference layout as a semi-transparent image over the live camera view on the touchscreen, after which the evaluator manually aligns objects until the live scene matches the reference. The measured average reset time is approximately 14 seconds for 5 objects. The execution horizon per task is defined as $1.5\times$ the 90th percentile of demonstration lengths (Chen et al., 5 Jul 2026).

Scoring differs between simulation and real-world evaluation. Simulation uses automatic binary success and partial progress percentage. Real-world evaluation uses three independent human raters under double-blind conditions, and each trial’s score is the mean of the three evaluators. An appeal mechanism is also defined: videos and scores are posted alongside leaderboard entries. These choices indicate that XPolicyLab is paired with a metric regime that separates automatically measurable simulated outcomes from physically grounded but human-judged real-world performance.

5. Integration with RoboDojo-RealEval

RoboDojo-RealEval is the standardized real-world counterpart to the Isaac Sim side of the benchmark, and XPolicyLab is the interface through which policies access it. The hardware architecture consists of a table of $d$0, a frame of $d$1, a white table cover, external black curtains, and three linear LED bars. A collaborative bimanual robot mount uses a steel cross-beam to fix two arms. Visual sensing is provided by two Gemini 305 wrist cameras and one Gemini 335L head camera, all rigidly mounted. The system also includes an integrated workstation box containing control PC, power, and cooling, and a touchscreen panel (Chen et al., 5 Jul 2026).

The cloud-access protocol allows a policy developer either to run a policy server behind a public wss:// endpoint or to push a Docker image to RoboDojo’s cloud cluster. The RealEval client in the lab opens a WebSocket to the developer’s server. All messages use MessagePack, and observations and actions are transmitted as binary MessagePack blobs to minimize latency, which is stated as approximately 10–20 ms round-trip.

Reset synchronization is handled differently in simulation and in the physical system, but with a shared indexing convention. Simulation resets use deterministic seed plus YAML scene sampler. Real resets use human replay via the overlay tool. Both use the same “task name + layout index” convention so policies see the same language/camera-state correspondence (Chen et al., 5 Jul 2026). This suggests that XPolicyLab’s unification is not based on forcing identical reset mechanisms, but on ensuring consistent task identity and observation semantics across domains.

Safety and reliability mechanisms are built into the integrated platform. The touchscreen includes an emergency stop button that halts all motion and zeroes grippers. There is automatic step-limit termination if the horizon is exceeded. All runs are video-recorded, and unsafe episodes are flagged by raters. These provisions situate XPolicyLab within a controlled deployment protocol rather than a purely software-defined benchmark.

6. Leaderboard, data aggregation, and verification

XPolicyLab includes the tooling necessary to collect, aggregate, and publish benchmark results. In simulation, its evaluation script writes per-task JSON lines of the form: $d$2 These records are then aggregated into per-task success-rate and score arrays and then into dimension-level and overall metrics. In the real world, the RealEval client uploads trial videos and final human scores to a central database via HTTPS POST, and per-trial JSON includes embodiment, task, trial index, and trinary scores from each rater (Chen et al., 5 Jul 2026).

Publication is handled through a public leaderboard at RoboDojo-Benchmark.com backed by PostgreSQL with tables Policies, SimResults, and RealResults. The schemas reproduced in the specification define sim_results with fields including policy_id, task_name, dim_name, seed, success, score, and timestamp, and real_results with fields including policy_id, embodiment, task_name, trial, rater1, rater2, rater3, avg_score, and timestamp. Automatic scripts compute means and standard deviations and regenerate leaderboard pages whenever new submissions arrive (Chen et al., 5 Jul 2026).

Verification and anti-gaming are explicit parts of the benchmark design. Hidden-layout verification means that each submission is also run on a small set of unseen scene seeds, and large discrepancies lead to invalidation. A verified track requires open-sourcing the exact XPolicyLab policy package, checkpoint, deploy.yml, and full training and evaluation instructions at publication time. These measures address a recurrent concern in benchmarked policy evaluation: overfitting to known layouts or reproducing reported numbers without releasing the exact deployment artifact.

Within RoboDojo, XPolicyLab is also the mechanism through which 30 policies are integrated and evaluated, establishing a public leaderboard and systematic analysis of current policy performance (Chen et al., 5 Jul 2026). In that sense, it serves both as an interoperability layer and as the operational substrate for benchmark governance.

7. Significance and scope

The significance of XPolicyLab lies in the way it links policy development, simulation diagnosis, and reproducible real-world validation into a single operational pathway (Chen et al., 5 Jul 2026). Its minimal policy interface—reset, update_obs, get_action—combined with a standard data schema and WebSocket/MessagePack communication protocol, reduces the amount of task-specific and platform-specific adaptation needed to move a policy between Isaac Sim and RoboDojo-RealEval.

The system’s scope is broader than evaluation alone. Because data-converter modules transform raw RoboDojo trajectories into formats such as HDF5, LMDB, PyTorch Dataset, and precomputed embeddings, XPolicyLab also mediates training-data compatibility across heterogeneous policy families. Because deployment scripts and configuration files are part of the required package structure, it also standardizes aspects of reproducibility that are often left informal in robot learning benchmarks. And because leaderboard publication is tied to hidden-layout verification and a verified track, it incorporates benchmark administration directly into the infrastructure rather than treating it as an external process.

A plausible implication is that XPolicyLab defines a benchmark-centered software contract for generalist robot manipulation policies: not a claim about what policy architecture is best, but a specification for how such policies are to be trained, served, evaluated, and verified within RoboDojo. In the context of a benchmark that explicitly spans both scalable simulation and costly real-world validation, that contract is the mechanism by which sim-and-real comparability is operationalized (Chen et al., 5 Jul 2026).