{"id":"9dae6b00-59c5-40c1-9509-8b885d1b5477","arxiv_id":"2508.09606","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"BEAVR provides an open-source, low-cost VR teleoperation pipeline for multiple robot embodiments, with LeRobot-format data recording and compatibility with ACT, Diffusion Policy, and SmolVLA.","lead":"BEAVR is an open-source virtual reality system that lets a human operate different types of robots, from robot arms to hands, and records the demonstrations for training AI policies. It aims to make robot teleoperation cheaper, more standard, and easier to use for research.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The '<35 ms end-to-end' latency claim rests on an undefined 'one-way' metric that numerically tracks the command period, and the 'zero-copy' claim is contradicted by the serializing network design in Appendix A.","rationale":"The reader's weakest assumption—that the latency figure is ambiguously defined and that 'zero-copy' is contradicted by Appendix A—is well founded. I agree with the outcome: the system appears functional and open-source, but the central quantitative performance claim is not yet substantiated. My stress-test sharpens the concern: the reported one-way latencies are numerically almost identical to the command periods (10.1 ms vs. 11.1 ms at 90 Hz; 33.4-33.8 ms vs. 33.3 ms at 30 Hz). This pattern strongly suggests that the 'latency' metric is measuring the control period or receive cadence, not propagation delay through the VR-to-robot pipeline. If true, the comparison in Table VI is comparing a period/interval to other systems' true latency figures, which would invalidate the claimed advantage. I do not see this as grounds for rejection: the system's other contributions—LeRobot-format recording, multi-embodiment integration, public datasets, and policy-learning compatibility—are real and independently valuable. But the headline performance claim should be either rigorously measured and reported with a precise methodology or removed/reworded. Therefore the correct final disposition remains CONDITIONAL, conditional on clarifying the latency metric and either substantiating or retracting the 'zero-copy' claim.","tokens_in":10628,"tokens_out":4946,"duration_ms":59601,"concrete_test":"In the open-source repository, locate the latency-measurement code and instrument the actual end-to-end path: stamp each VR keypoint frame at acquisition in the Detector and record the time when the corresponding robot command reaches the Interface's write to the robot. Run Configuration 2 (XArm7 + LEAP, 90 Hz) for 60 seconds. If the 90th-percentile true end-to-end delay exceeds 35 ms, or if the existing 10.1 ms figure is recovered by computing the inter-message interval rather than this acquisition-to-command latency, then the abstract's 'end-to-end, <=35 ms' and 'zero-copy' claims are not supported. Also grep the code for the 'zero-copy' path; if serialization/deserialization is present in the hot path, the term should be removed or redefined.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"Section VI-D reports 10.1 ms one-way latency at 90 Hz and 33.4-33.8 ms at 30 Hz (Table VI), but the paper never defines how latency was measured. The values are suspiciously close to the inverse control frequencies (11.1 ms and 33.3 ms), suggesting the metric may actually be the inter-message/command interval or a network-layer receive gap rather than operator-to-robot end-to-end delay. The abstract and Contribution (ii) claim 'end-to-end' latency and a 'zero-copy' streaming architecture, yet Appendix A explicitly states that the network module serializes and deserializes Python objects and that publishing threads handle serialization, queuing, and message broadcasting—meaning data are copied at least once. If the reported 'one-way' numbers are only network-transport delays, or are derived from the 1/frequency period, then the headline '<=35 ms end-to-end' claim is unsupported. This matters because Table VI is the primary quantitative evidence for the system's real-time scalability claim and for the comparisons against Vicarios, Bray et al., and 5G URLLC. The issue is not that the latency is high; it is that the measured quantity appears not to be the claimed quantity.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper describes BEAVR, an open-source VR teleoperation system that unifies real-time bimanual control, LeRobot-format demonstration recording, and policy learning across heterogeneous robots (XArm7 with LEAP hand, RX-1 humanoid). The architecture is modular, with detector, operator, and interface processes communicating over ZMQ; it includes coordinate-frame transformations, multi-target DLS IK with anti-collision and temporal smoothing, and a Unity-based VR app. Experiments report success rates for six dexterous manipulation tasks, policy rollouts for ACT/Diffusion/SmolVLA trained on 50 demonstrations, and network performance metrics: near-target control frequencies, sub-millisecond jitter, and claimed <=35 ms one-way latency. Code and datasets are publicly released.","tokens_in":10885,"tokens_out":4059,"duration_ms":44849,"significance":"If the claims withstand scrutiny, this is a useful open-source systems contribution: it lowers the cost of dexterous teleoperation, integrates natively with LeRobot, supports multiple embodiments, and provides public datasets and pretrained policy baselines. The strongest parts are the practical integration across heterogeneous hardware and the reproducible release of code and data. The paper is also transparent about the empirically tuned hand-scaling factor and about baseline numbers copied from other papers. The main value lies in reproducibility and integration rather than algorithmic novelty; the headline latency and zero-copy claims, however, are currently under-supported and need clarification.","major_comments":[{"comment":"The headline '<=35 ms end-to-end' latency claim is not supported by a defined measurement. §VI-D reports 10.1 ms 'one-way' at 90 Hz and 33.4–33.8 ms at 30 Hz, but never states whether this is network transport, an inter-message interval, or the full operator-to-robot control-loop latency. The reported values are suspiciously close to the command periods (11.1 ms and 33.3 ms), suggesting the metric may be a receive gap rather than end-to-end delay. Since Table VI is the primary evidence for real-time scalability and the comparisons with Vicarios, Bray et al., and 5G URLLC, please define the measurement method, report timestamps and full-pipeline or round-trip latency, and state what 'one-way' includes.","section":"Abstract; §VI-D; Table VI"},{"comment":"The 'zero-copy streaming architecture' claim is contradicted by Appendix A, which states that the network API 'serialize[s] and deserialize[s] Python objects' and that publisher threads 'handle serialization, queuing, and message broadcasting.' Serializing/deserializing Python objects necessarily copies data at least once, and ZMQ itself uses internal buffers. Either provide a precise definition of 'zero-copy' and evidence that no data copies occur in the streaming path, or remove/qualify the term. This is not merely terminology: the abstract presents zero-copy as a core architectural contribution.","section":"Abstract; Contribution (ii); Appendix A"},{"comment":"The cross-system comparisons in Table I are not quantitatively valid as presented. The 'Flip cube' baseline for other systems was run in simulation while BEAVR was run on a real robot; the 'Pour' task was modified (LEAP hand instead of gripper, cup instead of sprinkles); OpenTeach numbers are copied from another paper; and n=5 with no error bars or statistical tests. These differences directly explain the completion-time gaps and prevent any claim of parity or superiority. The table should be reframed as a qualitative reference with explicit caveats, or replaced with controlled comparisons under matched task definitions.","section":"§VI-B; Table I"},{"comment":"Success-rate claims rest on very small samples: Table II uses 10 trials per task with no confidence intervals or statistical tests, and Table III evaluates policies on a single task with a single dataset and no multiple seeds. For example, ACT at 100% and human at 100% are indistinguishable given the sample size. This limits the strength of the 'open benchmark suite' claim. Please add at least binomial confidence intervals, justify the trial count, and, for policy learning, report variance across seeds or multiple task instances. The system demonstration is still credible, but the quantitative conclusions are currently over-stated.","section":"§VI-B; §VI-C; Tables II and III"}],"minor_comments":[{"comment":"The name is rendered inconsistently as 'BEAVR', 'BEA VR', and 'BEA VR' in the title/abstract/body. Please standardize.","section":"Throughout"},{"comment":"The phrase 'sub-35 ms RTT-equivalent' in the conclusion is vague and inconsistent with the 'one-way' label in Table VI. Define the intended metric consistently.","section":"Conclusion"},{"comment":"Formatting is inconsistent: '1' versus '1.0', and empty cells use different symbols. Also clarify why Holo-Dex and Any-Teleop have no entries for Pour/Pick-and-Place.","section":"Table I"},{"comment":"The text refers to 'Figures 5 and 4' out of order, and the captions do not specify which configurations are included in the aggregated distributions. Clarify.","section":"Figures 4 and 5"},{"comment":"In the scaling equation, the variables p' and p'' are not explicitly defined as intermediate and final retargeted fingertip positions. A short definition would improve readability.","section":"§IV-B"},{"comment":"The paper uses both 'Meta Quest 3S VR headset' and 'VR glasses'; choose one term for consistency.","section":"§III; §IV-C"}],"recommendation":"major_revision","confidential_remarks":"This is a systems paper whose main contribution is an open-source integration and benchmark. The central functionality appears real and reproducible, but the latency and zero-copy claims need to be either substantiated or substantially qualified before publication. The cross-system performance comparisons in Table I should not be presented as quantitative evidence. Overall, the paper is a reasonable fit for a robotics venues that value open-source systems and datasets, provided the load-bearing claims are tightened."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The real value here is the integration. BEAVR wires commodity VR hand tracking to multiple robot embodiments and writes demonstrations directly into the LeRobot schema, so you can record data and immediately train ACT, Diffusion Policy, or SmolVLA on it. That is actually new relative to OpenTeach and Bunny VisionPro, which are bimanual but not multi-embodiment and don't drop you straight into a standard learning pipeline. The code and datasets are public, the hardware cost is low, and the task results (60–100% success across six real-robot tasks) show the system works end-to-end. The policy rollouts (ACT 10/10, Diffusion 8/10, SmolVLA 7/10) are reasonable evidence of compatibility. These are reproducible artifacts, so I take the system seriously.  The soft spots are real and concentrated in the performance claims. The abstract and Contribution (ii) promise a \"zero-copy streaming architecture,\" but Appendix A describes serializing and deserializing Python objects and publisher threads that queue and broadcast messages. That is at least one copy, so the zero-copy claim is false as written. The bigger issue is latency. The paper reports 10.1 ms one-way at 90 Hz and 33.4–33.8 ms one-way at 30 Hz, but it never defines how latency was measured. Those numbers sit suspiciously close to the inverse control frequencies (11.1 ms and 33.3 ms), which makes me think the metric may be the command period or a network heartbeat rather than operator-to-robot end-to-end delay. If that's true, the headline \"≤35 ms end-to-end\" claim is unsupported. The comparisons in Table I are also softer than they look: tasks are modified (simulation vs real, cup vs sprinkles), sample sizes are tiny, and there are no error bars or statistical tests.  These problems don't invalidate the system, but they prevent full acceptance of the quantitative story. A serious referee should ask for a precise latency definition, a correction or removal of \"zero-copy,\" and at least error bars for the success rates. The paper is for researchers in imitation learning and dexterous manipulation who want a low-cost teleoperation stack that feeds directly into LeRobot. It deserves peer review, not desk rejection. My recommendation: accept with major revision, and make the latency methodology the first thing to fix.","headline":"BEAVR is a genuinely useful open-source contribution to VR teleoperation, but the headline latency and zero-copy claims are shaky enough that the paper should go to peer review with requests for major clarification.","tokens_in":11390,"tokens_out":2032,"would_cite":true,"duration_ms":22161,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"BEAVR is an open-source VR teleoperation system that unifies real-time control, standardized demonstration recording, and policy learning across heterogeneous robots, claiming sub-35 ms end-to-end latency, and evaluates it on six manipulati","keywords":["virtual reality teleoperation","bimanual manipulation","dexterous manipulation","policy learning","imitation learning","LeRobot dataset","multi-embodiment","low-latency control"],"falsifier":"Run the open-source system and measure the full control-loop latency: timestamp a VR hand movement at the headset and the corresponding robot joint actuation at the servo, then compare the difference to the reported 33 ms at 30 Hz and 10.1 ms at 90 Hz. Additionally, inspect the hot path for Python object serialization/deserialization (Appendix A describes such wrappers); if present, the 'zero-copy' claim is contradicted.","tokens_in":10497,"feed_emoji":"🤖","tokens_out":6270,"duration_ms":64050,"temperature":0.7,"pith_summary":"BEAVR is an open-source, modular VR teleoperation system designed to unify real-time bimanual control, synchronized data recording, and policy learning for robots ranging from a 7-DoF arm and a 16-DoF dexterous hand to a full-body humanoid. It records demonstrations directly into the LeRobot dataset schema, enabling immediate training with modern imitation-learning policies. The paper reports end-to-end latency below 35 ms, sub-millisecond jitter, and no measurable degradation when scaling to four effectors. A complete setup—VR headset, humanoid, and dexterous hand—costs roughly $1000, and the system is benchmarked on six real manipulation tasks with success rates between 60% and 100%.","feed_headline":"One VR system drives hands, arms, and humanoids under 35 ms","feed_subtitle":"Open-source BEAVR records demos in a standard format and trains ACT, Diffusion, and SmolVLA policies on them.","key_machinery":"The load-bearing structure is the three-process component architecture (detector, operator, interface) communicating over ZMQ sockets, with each process owning its threads and sockets to avoid data races and allow thread-safe messaging. The operator maps VR hand keypoints to robot targets through a modular homogeneous-transform chain (Y-up VR to Z-up robot, with Gram-Schmidt hand-frame construction and per-finger scaling), feeds a multi-target damped-least-squares IK solver that integrates anti-collision checks, and smooths output with moving-average and complementary quaternion SLERP filters. An asynchronous 'think–act' loop decouples policy inference from real-time action streaming, preser","core_discovery":"We present BEAVR, a modular, hardware-agnostic teleoperation pipeline built from three processes—detector, operator, and interface—that stream hand keypoints from commodity VR headsets through ZMQ messaging, solve multi-target damped-least-squares IK to command dexterous hands and arms, and record synchronized observations and actions directly in the LeRobot dataset schema. Our measurements show one-way network latency of 10.1 ms at 90 Hz and 33.4–33.8 ms at 30 Hz, jitter below 0.9 ms for the arm and 0.22 ms for the hand, and no degradation when scaling from one to four effectors. Policies trained on 50 BEAVR demonstrations—ACT, DiffusionPolicy, and SmolVLA—reach 70–100% success on a pickup-","pith_inferences":["If the modular component split is as clean as described, the same VR interface could likely be reused across different robot hardware and even simulators without re-engineering the operator logic—an extension the paper only suggests implicitly.","Because demonstrations are recorded in a standardized schema, datasets collected by different labs using BEAVR could in principle be pooled to train multi-embodiment policies, though the paper only trains and evaluates single-robot policies.","The reported latency figures come from network-level measurements over 60-second episodes; a full-loop measurement from headset tracking to robot joint actuation would settle whether the sub-35 ms claim truly reflects complete end-to-end delay.","The asynchronous 'think–act' loop implies that policy inference could be offloaded to an edge or cloud node without stalling the real-time control stream, a capability the paper leaves untested."],"forward_implications":["Researchers can record standardized, multi-modal demonstration datasets directly in the LeRobot schema without bespoke glue code, enabling immediate downstream policy training.","The system scales to bimanual and four-effector control at 90 Hz with sub-millisecond jitter, indicating that increasing robot count does not measurably degrade communication performance.","A complete setup with an RX-1 humanoid and LEAP hand costs approximately $1000, lowering the financial barrier to dexterous robot learning.","Policies trained on BEAVR demonstrations (ACT, DiffusionPolicy, SmolVLA) achieve 70–100% success on a pickup-box task, comparable to the human operator's 100% success rate in this experiment.","The open-source release and six-task benchmark suite provide a common evaluation yardstick for VR teleoperation systems and policy learning pipelines."],"supporting_citations":[{"why":"Supplies the LeRobot dataset schema and training pipeline that BEAVR records into and uses for policy learning.","marker":"[3]"},{"why":"Provides the low-cost LEAP Hand hardware and finger-scaling estimates used for IK retargeting.","marker":"[6]"},{"why":"Provides the open-source RX-1 humanoid platform used as a full-body embodiment.","marker":"[13]"},{"why":"Action-Chunking Transformer policy trained on BEAVR demonstrations in the policy evaluation.","marker":"[15]"},{"why":"Diffusion Policy trained on BEAVR demonstrations in the policy evaluation.","marker":"[16]"},{"why":"SmolVLA vision-language-action model fine-tuned on BEAVR demonstrations.","marker":"[17]"},{"why":"Supplies LAN and Wi-Fi teleoperation latency and jitter baselines for comparison.","marker":"[18]"},{"why":"Vicarios VR teleoperation system provides a 40 ms one-way latency baseline that BEAVR compares against.","marker":"[19]"}],"fun_headline_variants":["Open VR teleop for arms, hands, humanoids—sub-35ms","BEAVR: bimanual VR teleop for any robot, under 35ms","VR teleop that records demos for robot policies—open source","One VR system to teleoperate arms, hands, humanoids","Sub-35ms VR teleop: open-source, multi-embodiment, for policies"],"cache_read_input_tokens":2816,"weakest_assumption_plain":"The central performance claim assumes the reported sub-35 ms latency is a true end-to-end operator-to-robot delay, but the paper reports it as a one-way network measurement that may omit VR tracking, IK computation, and robot command execution.","fun_headline_variants_meta":{"raw":{"variants":["Open VR teleop for arms, hands, humanoids—sub-35ms","BEAVR: bimanual VR teleop for any robot, under 35ms","VR teleop that records demos for robot policies—open source","One VR system to teleoperate arms, hands, humanoids","Sub-35ms VR teleop: open-source, multi-embodiment, for policies"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000544,"raw_usage":{"total_tokens":2453,"prompt_tokens":772,"completion_tokens":1681,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":516,"completion_tokens_details":{"reasoning_tokens":1577}},"tokens_in":516,"tokens_out":1681,"duration_ms":14865,"temperature":1.0,"reasoning_tokens":1577,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T20:56:03.995460+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the open-source system and measure the full control-loop latency: timestamp a VR hand movement at the headset and the corresponding robot joint actuation at the servo, then compare the difference to the reported 33 ms at 30 Hz and 10.1 ms at 90 Hz. Additionally, inspect the hot path for Python object serialization/deserialization (Appendix A describes such wrappers); if present, the 'zero-copy' claim is contradicted.","supporting_citations":[{"cited_title":"Lerobot: State-of-the-art machine learning for real-world robotics in pytorch,","cited_arxiv_id":null,"evidence_quote":"Supplies the LeRobot dataset schema and training pipeline that BEAVR records into and uses for policy learning."},{"cited_title":"RX-1: Open-Source Humanoid Robot Platform,","cited_arxiv_id":null,"evidence_quote":"Provides the open-source RX-1 humanoid platform used as a full-body embodiment."},{"cited_title":"A latency composition analysis for telerobotic performance insights across various network scenarios,","cited_arxiv_id":null,"evidence_quote":"Supplies LAN and Wi-Fi teleoperation latency and jitter baselines for comparison."},{"cited_title":"Vicarios: A virtual reality interface for teleopera- tion with a 7-dof robot arm,","cited_arxiv_id":null,"evidence_quote":"Vicarios VR teleoperation system provides a 40 ms one-way latency baseline that BEAVR compares against."}],"review_version":1}