The open source framework decouples hardware, inference, and logging, then routes every test run back into the training set, pushing the curation bottleneck onto human operators.
A new open-source framework called EVA-Client proposes to compress the slowest part of robot learning: the gap between running a trained manipulation policy on a real arm and turning that run into training material for the next iteration. The framework, released as a preprint on arXiv, makes every evaluation run double as a data collection event, recording full rollouts in training-ready format alongside exhaustive logs (arXiv preprint).
The contribution worth naming is what the paper calls the eval-as-training loop. Conventional robot policy pipelines separate two questions: "does this policy work?" and "what new examples should we add to the training set?" EVA-Client collapses that handoff. A side-by-side viewer lets the engineer inspect the rollout, decide what to keep, and feed it back into the next training round, all without leaving the framework. The paper's falsifiable claim is specific: decoupling execution into Debug, Collect, and Eval workflows, and routing every Eval run's output back into Collect, changes the iteration speed or data quality of embodied policy development in a measurable way. That is the claim downstream labs will test.
The architecture that enables the loop is component-decoupled. Robot backends, inference strategies, and transport middlewares form an orthogonal grid: adding a new arm or a new inference approach touches only its own layer, instead of forcing edits across the codebase. The project consolidates the major real-time inference strategies used in robot learning, including synchronous and asynchronous execution and ACT-style temporal aggregation, a technique that averages predictions across adjacent timesteps to smooth out control jitter. The HTML version of the paper truncates mid-sentence on this technique's details, so the framework's coverage of newer strategies should be checked against the repository before adoption (paper HTML).
Three workflows sit on top of the decoupled architecture. Debug exposes policy execution in inspectable form so engineers can see what went wrong. Collect captures demonstrations and rollouts in training-ready format. Eval runs the policy and, by design, produces the same artifacts as Collect, so the boundary between testing and gathering data disappears. Modes range from open-loop simulation, where the policy sees recorded observations rather than live sensor feeds, to continuous real-time control on a physical arm. Because the workflows share a common logging and storage layer, an engineer who finds a failure mode in Debug can promote that rollout into Collect with one operation rather than rerunning it through a separate pipeline (project page).
That routing only helps if the engineer can tell signal from noise. The paper offers the comparison viewer as that filter rather than an automated curation step, so the cost lands on the operator. For labs already drowning in policy rollouts, that is a feature. For labs without someone willing to watch the videos, it is a new kind of backlog. Either way, the bottleneck moves from data plumbing to human judgment, which is the second-order effect the framework does not address.
The code is released at github.com/Noietch/EVA-CLIENT, and the project page describes EVA-Client as infrastructure sitting between the policy server and physical hardware. Because the paper is a preprint without independent benchmarks of adoption or field deployments, the most defensible read is that EVA-Client is a plausible answer to a real iteration-speed problem, not yet a measured one. Watch for community forks, integration with widely used policy servers, and any third-party benchmark comparing iteration cycles against the conventional eval-then-collect handoff.