EVA-Client: A Unified Framework for Deployment, Evaluation, and Data Collection on Real Robots

Heqing Yang, Yang Yi, Liyao Wang, Linqing Zhong, Donglin Yang, Ruipu Wu, Zitong Bai, Fengjiao Chen, Manyuan Zhang, Linjiang Huang, Si Liu

A unified, robot-agnostic client for deploying, debugging, and collecting data for manipulation policies on physical hardware.

How can we unify the fragmented, ad-hoc processes of robot policy deployment, real-time debugging, and data collection into a single, latency-aware framework?

Deploying trained robot policies is currently a fragmented process of one-off scripts, making it difficult to reproduce results or compare different inference strategies on physical hardware. EVA-Client provides a decoupled, modular architecture that sits between any policy server and any robot, standardizing the deployment loop through a single configuration surface. The framework unifies inference strategies, data collection, and scored evaluation into one codebase, allowing researchers to treat physical runs as reproducible, auditable data sources for future training.

Paper Primer

EVA-Client acts as a thin, component-decoupled client that abstracts away the differences between robot hardware, transport middlewares, and inference strategies. By organizing the system into five narrow-interface layers—transport, robot description, policy client, inference strategy, and front-end—it allows users to swap components via configuration files rather than code changes.

The core mechanism hinges on a unified control loop that decouples the robot's execution rate from the policy's inference rate. It manages the resulting temporal discrepancies using a latency-aware buffer that blends overlapping action chunks, ensuring smooth motion even when inference latency varies.

Unified deployment and evaluation across heterogeneous hardware.

The framework supports a diverse set of serial-arm manipulators (Franka, UR5e, Galaxea R1-lite, AgileX Piper, AgiBot G2, ARX R5) using a single, robot-agnostic PyRoki-based inverse kinematics solver. Enables switching between inference strategies (e.g., synchronous, asynchronous prefetch, temporal ensembling, Real-Time Chunking) via a single configuration flag to compare performance on the same physical robot.

Why does this framework exist if training stacks like LeRobot or OpenPI already exist?

While training stacks have consolidated model abstractions and data formats, they typically leave deployment and physical evaluation as per-model "glue" code. EVA-Client provides the missing infrastructure to standardize the real-robot side of the iteration loop.

What is the scope of the robot support provided by this framework?

EVA-Client is currently designed for serial-arm manipulators. Other morphologies, such as humanoids or mobile bases, are not yet supported, and non-ROS robots currently require a middleware-specific image source for camera integration.

The Deployment Gap in Robot Learning

Current robot deployment tools are fragmented, making real‑robot policy rollout cumbersome and error‑prone.

Deploying a trained robot policy remains a fragmented, manual process: integration, real‑time execution, and physical evaluation are tightly coupled, which hampers reproducibility, debugging, and systematic comparison across platforms.

The lifecycle spans from model design through robot‑specific integration, runtime debugging, data collection, and iterative evaluation, each step feeding the next.

The fragmentation of current robot deployment tools hinders reproducible research and rapid iteration.

Introducing EVA-Client

We introduce EVA-Client, a unified interface that streamlines the entire manipulation policy lifecycle.

EVA-Client consolidates the fragmented steps of real‑robot policy deployment into a single, inspectable client. It exposes every stage—from signal ingestion to robot actuation—so developers can debug, iterate, and evaluate without rewriting per‑policy scripts.

EVA-Client is a thin software layer that sits between a policy server and robot hardware, turning abstract action streams into concrete robot commands while keeping the whole deployment loop visible.

**Figure 1.** EVA-Client across the manipulation-policy lifecycle. A left-to-right view of the broader pipeline around EVA-Client, spanning connected robot embodiments, data collection, external policy training, deployment, and real-robot evaluation. (1) Embodiment: physical serial-arm platforms outside EVA-Client, namely AgileX Piper, ARX R5, Franka, UR5e, AgiBot G2, and Galaxea R1-lite, connect to one robot-agnostic backend through a single description class each (Section 4). (2) Data collection: a human teleoperates the robot while EVA-Client captures each demonstration, quality-checks it, and replays it for inspection, then exports it in the LeRobot format as training-ready data (Section 7). (3) Policy training: external frameworks such as openpi (Black et al., 2026), StarVLA (Ye et al., 2026a; Community, 2026), GROOT (NVIDIA et al., 2025), and Dream-Zero (Ye et al., 2026b) consume the collected data and return a checkpoint; EVA-Client trains no models itself. (4) Deployment: EVA-Client serves the trained checkpoint on real hardware, using inference scheduling, overlap smoothing, and inverse kinematics to turn action chunks into a smooth command stream rather than the jerky pause-and-go of naive synchronous execution (Section 6). Bottom band, real-robot evaluation: the deployed policy is scored on physical robots under a standardized, fully logged protocol (Section 8). EVA-Client covers the client-side data collection, deployment, and evaluation workflows; robot embodiments and policy training remain external.

EVA-Client serves as the unified interface for the entire policy lifecycle, turning deployment into a continuous, debuggable process.

System Architecture and Middleware

EVA-Client orchestrates signals and robot commands via layered middleware and a chunk‑blending inference strategy.

EVA-Client does not reinvent robot middleware; it leverages existing ROS/ROS2 infrastructure while adding a thin orchestration layer that connects policy sources to robot execution.

ROS and ROS2 are the de‑facto communication backbones that shuttle sensor streams and actuator commands between robot components.

Why does EVA‑Client rely on ROS instead of a custom communication layer?

ROS already implements robust, time‑synchronized publish‑subscribe semantics and a large ecosystem of drivers. Reusing it lets EVA‑Client focus on deployment logic rather than reinventing low‑level transport, and it guarantees compatibility with existing robot stacks.

The strategy turns overlapping policy‑generated action chunks into a single smooth command stream, decoupling the policy query frequency from the fixed control‑loop rate.

How does this inference strategy differ from simple periodic polling of the policy?

Periodic polling would issue a new command only when the policy is queried, causing gaps or abrupt jumps if the query interval does not align with the control step. The chunk‑blending strategy fills every control step with a weighted combination of overlapping predictions, yielding smooth, continuous motion even when queries are sparse or irregular.

At t = 0 ms the first chunk covers steps 0–3 (values 0.2→0.8).

At t = 300 ms a second chunk arrives covering steps 3–6 with values [0.5, 0.7, 0.9, 1.0].

Step 3 (t = 300 ms) now has two contributions: 0.8 from the first chunk and 0.5 from the second. Weighted average (0.8·0.6 + 0.5·0.4) ≈ 0.68.

Steps 4–6 use only the second chunk values 0.7, 0.9, 1.0.

The resulting command stream fed to the robot is [0.2, 0.4, 0.6, 0.68, 0.7, 0.9, 1.0], smooth despite the irregular query timing.

This example shows that overlapping chunks automatically smooth transitions; the newest chunk gradually overrides older predictions without abrupt jumps.

**Figure 2.** Where EVA-Client sits in the deployment pipeline. EVA-Client mediates between signal sources and robot execution. Left: signal sources include trained policy systems such as openpi (Black et al., 2026), StarVLA (Ye et al., 2026a; Community, 2026), GROOT (NVIDIA et al., 2025), and Dream-Zero (Ye et al., 2026b), as well as human teleoperation. Model-based sources receive instructions and observations from EVA-Client and return actions or action chunks; teleoperation provides actions directly. Center: EVA-Client exposes this process through Debug, Collect, and Evaluation workflows. Right: robot execution backends turn actions into robot commands and return synchronized observations over ROS 1/2 or ZMQ before reaching the robot hardware (Section 4). The source and execution sides remain narrow and replaceable, so a new policy source, teleoperation source, or robot backend can be added without rewriting the whole deployment stack.

All workflows share the same five‑layer stack—transport, robot description, policy client, inference strategy, and CLI/web—so a change in one layer (e.g., swapping ROS 2 for a ZMQ mock) does not ripple through the others.

Declarative Deployment Configuration

How declarative configuration unifies robot deployment across diverse backends.

The EVA‑Client framework treats deployment as a reproducible configuration problem, letting the same description run on any supported robot or simulator without code changes.

Instead of writing imperative scripts that hard‑code robot IDs, backends, and policy URLs, the system reads a single YAML file that declares *what* to run and *where* to run it.

Step 1: EVA‑Client loads the YAML and builds a RobotDescription object for the Piper.

Step 2: The ROS1 backend is instantiated; its buffers are sized according to the default staleness window.

Step 3: The policy client connects to http://localhost:8000 and receives joint‑space actions.

Step 4: The control loop runs at 30 Hz, feeding actions to the ROS1 joint‑command topic.

Step 5: A user runs the same binary with “--backend ZMQ” to switch to the simulated backend; the configuration file remains unchanged.

This example shows that the entire deployment—including robot type, communication layer, and policy server—can be swapped by editing a single file or passing a flag, eliminating brittle code edits.

How does declarative deployment differ from a typical script‑based launch?

Script‑based launches embed robot identifiers, backend choices, and policy URLs directly in code, so changing any of them requires editing and recompiling the script. Declarative deployment moves all those choices into a data file; the runtime reads the file and wires the components automatically, so retargeting is a matter of editing data, not code.

Transport backends act as interchangeable adapters that translate raw sensor streams and command messages between the EVA‑Client core and the underlying hardware or simulator.

A robot description object is a declarative manifest that lists the robot’s actuators, sensors, and kinematic model, allowing EVA‑Client to treat any robot uniformly.

Action spaces separate the policy’s output format from the robot’s command format, letting policies emit end‑effector poses while the robot may be driven in joint space.

Continuous IK treats each frame of an action chunk as an independent least‑squares problem, warm‑started from the previous solution, to keep joint trajectories smooth.

Operation Model and Inference

Inference strategies reconcile model latency with smooth robot motion.

When a policy emits a horizon of actions while the robot must act continuously, latency creates overlapping chunks that can conflict at their boundaries. The inference strategy decides how often to request new chunks, which stale actions to keep, and how to merge overlaps into a smooth trajectory.

**Figure 3.** The EVA-Client web console across its usage modes. A single browser interface drives the whole deployment. A persistent tab bar selects among five tabs, namely the three primary usage modes Debug, Collect, and Eval, plus a Replay tab and a read-only Result viewer (Section 8); a status bar reports the active robot, transport, session state, and per-call inference latency. Every mode shares the same layout: a left control panel, a center Viser-based (Yi et al., 2025) 3D scene rendering the live dual-arm state and executed trajectories, and, on the right, the time-synchronized camera streams, one overhead and two wrist views, that form each observation frame. This 3D scene also doubles as the rendering target for the open-loop and sim-to-real modes. (a) Debug: selects the execution mode (REAL/SIM/STEP) and inference strategy, then runs the policy, here in open-loop simulation, with control/inference rates and the latency cap $k_{max}$, the maximum number of stale actions to discard (Section 6), exposed as tuning fields. (b) Collect: records a teleoperated episode into a training-format dataset, then replays it for pass/fail QC with a free-text note (Section 7). (c) Eval: runs the scored-trial protocol of Section 8, with a model label, a per-trial success tally, and a milestone checklist scored live. (d) Result: the read-only result viewer, showing per-checkpoint statistics and side-by-side checkpoint comparison (Section 8). The Replay tab reuses the same open-loop viewer to review recorded episodes: dataset replay (Section 4) and Collect quality control (Section 7). The same console thus spans inspection, data collection, and evaluation without leaving the page.

Instead of waiting for each inference call to finish before moving the robot, the system keeps a buffer of overlapping action chunks and blends them on the fly, turning latency into a smooth command stream.

At $t=0$ the controller executes $0.0$ from $A(0)$.

At $t=1$ the overlap begins: blend $0.5$ (old) with $0.8$ (new) → $0.65$.

At $t=2$ blend $1.0$ (old) with $1.2$ (new) → $1.1$.

At $t=3$ the buffer now holds $A(1)$; execute $1.5$ (new chunk’s first non‑overlap step).

Linear blending preserves continuity while gradually shifting weight to the freshest prediction, preventing sudden jumps that would destabilize the robot.

How does this differ from a naïve FIFO buffer that simply discards old actions?

A FIFO buffer would drop the overlapping tail outright, causing a discontinuity at the chunk boundary. Linear‑overlap blending instead interpolates between the old and new predictions, yielding a smooth transition even when latency varies.

Choose synchronous execution for debugging or when the policy is fast enough that pauses are negligible; otherwise pick an asynchronous strategy—linear‑overlap blending for smooth, low‑latency control, or a more sophisticated temporal ensemble when predictive consistency across many steps is critical.

Handling Inference Latency

Buffering smooths stale actions by trimming and linearly blending incoming chunks.

The robot often executes several control steps before a newly predicted action chunk arrives, leaving the early actions in that chunk stale. Latency‑aware Buffering fixes this by trimming and smoothly blending the overlapping portions of successive chunks.

When a new prediction arrives late, we discard the part that has already been executed and then linearly blend the remaining overlap so the robot’s trajectory stays continuous.

Trim: remove the first $\min(2,3)=2$ actions from $A_{\text{new}}$, yielding $A'_{\text{new}} = [\mathbf{b}_2,\mathbf{b}_3,\mathbf{b}_4]$.

Overlap window: $L = \min(|A_{\text{old}}|,|A'_{\text{new}}|) = \min(5,3)=3$.

Compute linear weights: $w_0=1$, $w_1=0.5$, $w_2=0$.

Blend: $\mathbf{c}_0 = 1\cdot\mathbf{a}_0 + 0\cdot\mathbf{b}_2$, $\mathbf{c}_1 = 0.5\cdot\mathbf{a}_1 + 0.5\cdot\mathbf{b}_3$, $\mathbf{c}_2 = 0\cdot\mathbf{a}_2 + 1\cdot\mathbf{b}_4$.

Resulting blended segment $[\mathbf{c}_0,\mathbf{c}_1,\mathbf{c}_2]$ replaces the first three actions of $A_{\text{old}}$; the remaining actions $\mathbf{a}_3,\mathbf{a}_4$ are kept unchanged.

Trimming removes actions that would have already been executed, and the linear blend guarantees a gradual handoff, avoiding sudden jumps in the robot’s motion.

**Figure 5.** Two asynchronous smoothing strategies on a shared timeline. Both panels read left-to-right in time, with successive inference calls stacked top-to-bottom; each call starts from an observation (marked Start Inference in (a), Policy Query in (b)) and returns only after an inference delay, so consecutive chunks overlap in time. (a) Asynchronous prefetch with linear-overlap blending: when a new chunk arrives, its leading actions (disposed) are dropped to compensate for the steps already executed during the inference delay. The overlap window (fused) is linearly blended between the Previous Action and the new prediction, and the remaining fresh tail is appended unchanged. (b) ACT-style temporal ensembling: rather than discarding earlier predictions, every chunk that covers the current control timestep contributes to the executed action. At each ensemble slice the overlapping predictions are combined by an exponentially weighted average over all chunks active at that instant into the executed Ensemble Action (red). Following ACT, the weighting favors earlier (older) predictions; with the default decay the weights are nearly uniform.

Latency‑aware buffer update – trim, blend, and append.

Action Blending and Data Collection

We compare smoothing, naive replacement, and RTC to see how each affects real‑time control.

Older inference predictions are given higher weight so the robot’s action reflects a temporally smoothed view of past estimates.

How does this weighting differ from a standard exponential moving average?

In a typical EMA the most recent value gets the largest weight, whereas here the oldest predictions are up‑weighted; the decay factor works in reverse, preserving early estimates instead of discarding them.

The simplest baseline discards any blending and directly uses the most recent chunk, indexed by global time, to compensate for latency.

Why does this baseline help isolate the effect of smoothing?

Because it removes the weighted averaging step, any performance change observed when re‑introducing the buffer can be attributed solely to the smoothing mechanism.

RTC shifts the latency compensation into the model: the client sends the previously committed action chunk forward by the measured latency and pads the tail, letting the server generate a chunk consistent with what is already being executed.

How does moving the latency shift to the server differ from client‑side buffering?

The server now generates predictions that are already aligned with the delayed execution timeline, reducing the amount of post‑hoc blending the client must perform; the client only needs to apply a simple shift and padding.

All three smoothing strategies emit three parallel action streams that are fully logged, enabling offline inspection of each method’s effect on latency and control.

Collect mode records human‑teleoperated episodes directly into a training‑ready dataset, using the same console and transport stack as deployment.

Each frame stores a synchronized pair of measured robot state and commanded action, enabling replay and supervised learning.

Episodes are saved in the LeRobot format, matching the on‑disk layout EVA‑Client reads for offline replay.

After recording, each episode is automatically inspected for consistency; problems are flagged but not discarded.

**Figure a.** Table tennis, a high-dynamics task. A Piper arm returns a ball, shown as a filmstrip whose frames advance left-to-right, top-to-bottom. The task stresses real-time responsiveness: under synchronous execution the pause-and-go stall keeps the arm from tracking the fast ball, so the rally does not get going in our deployment, whereas the rally shown here runs under asynchronous scheduling. EVA-Client keeps the control loop running while inference proceeds in a background thread, using latency-compensated chunk scheduling so that fast, reactive motions stay aligned with live observations.

Systematic Evaluation

Systematic evaluation and exhaustive logging turn subjective robot runs into reproducible records.

Evaluating robot checkpoints has traditionally relied on a handful of runs and a vague impression, which cannot be reproduced or audited.

EVA‑Client turns this into a systematic subsystem: every trial is scored against explicit milestones, persisted with video links, and aggregated into per‑scene statistics.

**Figure b.** Cloth folding, a long-horizon stability task. The same Piper arm folds a cloth on a tabletop, progressing spread → folded; the filmstrip frames advance left-to-right, top-to-bottom. The task stresses temporal coherence over many steps: EVA-Client blends overlapping action chunks into a smooth command stream, keeping the trajectory stable across the extended sequence. This fold runs under asynchronous execution, whose overlap blending keeps the long-horizon trajectory stable.

Multiple checkpoints can be evaluated in a single session; switching the active model transparently re‑targets the policy endpoint and re‑runs warm‑up, ensuring identical scene conditions for fair comparison.

The read‑only web viewer consumes only the persisted logs, offering side‑by‑side checkpoint comparison, per‑scene breakdowns, and direct links from each scored trial to its video.

Moving from a subjective impression to a systematic, logged evaluation makes robot performance auditable and comparable.

Debugging and Execution Modes

Describes the debugging and execution modes and their inference techniques.

This section enumerates the debugging and execution modes supported by EVA‑Client and explains the inference techniques that enable real‑time chunk‑based control.

**Table 1.** Debugging and execution modes. Modes progress from safe and fully observable open-loop simulation to fully real-time execution on hardware. Evaluation (Section 8) runs on top of these modes; data collection (Section 7) reuses the same console and backends.

Each mode defines how much of the robot’s control loop runs in simulation versus on the real hardware, and whether the policy is stepped chunk‑by‑chunk or continuously.

Chunk‑based policies emit a horizon of actions, so the system must schedule overlapping predictions and blend them to keep the robot moving smoothly.

The progression from simulation to real‑time hardware execution provides a safe path for debugging and scaling robot policies.

Read the original paper

Open the simplified reader on Paperglide

Browse all simplified papers