Zero-Install Browser MuJoCo + ONNX Testbed: A New Paradigm for Open Duck Robot Policy Evaluation

Why We Need a Robot Policy Testbed in the Browser

The open-source bipedal robot ecosystem is expanding rapidly, but there's an awkward reality: when you download a community-trained walking policy (.onnx file) from GitHub or Hugging Face, you have no quick way to understand how it will perform in real-world conditions. To verify whether a policy will slip on a 20mm-thick carpet, lose balance near slippers, or trigger fall protection near a table edge, you typically need to set up a local Python + MuJoCo environment—or worse, flash the policy onto a physical robot and test it at your own risk.

According to a Reddit community developer, he built DuckSpace.org—a zero-install browser-based 3D physics testbed specifically serving the Open Duck Mini / Microduck bipedal robot ecosystem. The platform combines the MuJoCo physics engine with ONNX Runtime Web, running at 50Hz directly in the browser. Users can open the webpage and immediately load and test community-contributed locomotion policies and higher-level "brain" modules.

The core pain point this project addresses is real: the community's .onnx locomotion policies and Mind repositories are scattered across dozens of GitHub and Hugging Face repos, corresponding to different servo configurations (Dynamixel XL330, Feetech STS3215, HD-1910, HL-2915), with no unified "try before you flash" entry point.

MuJoCo (Multi-Joint dynamics with Contact) is a physics engine developed by Emika, originally for robotics and biomechanics research, acquired by DeepMind in 2021 and open-sourced. It is known for efficient contact solving and constraint modeling, capable of realistically simulating friction, collisions, joint limits, and other complex contact dynamics—making it the mainstream simulation environment for the reinforcement learning community training legged robot policies. MuJoCo itself is a C/C++ library, typically invoked in a local Python environment via the mujoco package; to run it in a browser, the engine must be compiled to WebAssembly bytecode executable within a sandbox. This means browser-side MuJoCo will inevitably underperform native versions, requiring trade-offs such as lower physics stepping frequency or simplified collision geometry to achieve real-time performance—which is the key background for understanding the testbed's 50Hz operating frequency and precision trade-offs.

What Can Actually Run in the Browser

16 ONNX Locomotion and Trick Policies

The platform currently supports 16 .onnx locomotion policies covering walking, sprinting, forward rolls and recovery, ground pecking, single-leg flamingo balance, and more. These policies follow a unified command contract (e.g., [flag, side, 0] for single-leg balance commands). Users can also upload their own .onnx files to test directly in the browser, providing policy developers with a quick validation channel that requires no local environment.

ONNX (Open Neural Network Exchange) is an open neural network model exchange format initiated by Microsoft and Facebook in 2017, designed to allow models trained in different deep learning frameworks (PyTorch, TensorFlow, etc.) to be loaded across frameworks and platforms. In robotics, developers typically train reinforcement learning policies with PyTorch or JAX, then export them as .onnx files to decouple them from the training framework for easier distribution and deployment. ONNX Runtime Web is Microsoft's JavaScript/WASM inference runtime that can execute ONNX model inference in the browser, supporting WebGL or WebGPU backends. Combining ONNX Runtime Web with browser-side MuJoCo creates a closed loop where both "physics simulation + neural network inference" run entirely client-side, requiring no server or local installation. This is the technical foundation enabling the testbed's "open the webpage and test policies" capability, and explains why community policies use .onnx as the unified distribution format.

Higher-Level "Mind" Console

Beyond low-level locomotion policies, the testbed also integrates interactive consoles for multiple community "brain" modules:

• quack-nav: 2.5D occupancy grid SLAM + A* planner + [351→9] neural network navigation policy + virtual stairs/fall protection;
• DuckBuddy: natural language multi-step route execution + thermal servo model;
• kissqy R17-V167 and fanhao375 duck-echo: Feetech HD-1910 six-policy switcher, action_scale tuning, negative safety voice guard, BPM rhythm head-nodding.

Together, these modules form a complete autonomy demonstration stack from perception to planning to execution, though currently still primarily simulation in virtual environments.

Hardware and Room Perturbations

The testbed allows users to switch servo configuration profiles, adjust carpet thickness, toggle ground obstacles, robot vacuums, cats, and other distractors. These perturbation settings directly address a common need in community feedback—policies that perform well in ideal simulation but fail under minor changes in real environments.

Three Key Questions from the Developer Community

The original poster posed three candid engineering questions to the robotics community, which themselves reveal the core controversies facing browser-based simulation testbeds.

First, is a browser "try before you flash" hub useful to real developers, or just a toy? The answer depends on the testbed's simulation fidelity. While browser-side MuJoCo eliminates installation costs, whether 50Hz operation and simplified contact models can accurately reflect policy behavior on physical robots is the top concern for professional developers. If the sim-to-real gap is too large, the testbed could create misleading confidence.

Second, what features should be added? The author lists several candidate directions: real-time joint torque/phase plots, side-by-side policy A/B comparison, URDF/MJCF inspector, domain randomization sliders (push impulses, friction, motor backlash). Among these, domain randomization sliders and A/B comparison offer the highest value to policy developers—the former enables quick robustness assessment, the latter accelerates policy iteration.

Third, which features feel cluttered or superfluous? This is the key question for product focus. The testbed currently integrates locomotion policies, SLAM navigation, voice interaction, rhythm head-nodding, and multiple other modules—broad in coverage but potentially diluting core value. For a tool centered on "policy testing," whether peripheral features like voice rhythm and thermal servo models should give way to deeper policy analysis tools is worth weighing.

Domain Randomization is a core technique in reinforcement learning sim-to-real transfer: during training, simulation environment parameters (such as friction coefficients, mass, motor delay, sensor noise, external push forces) are randomly perturbed, forcing the policy to learn to work stably across the parameter distribution, thereby narrowing the sim-to-real gap. The "domain randomization sliders" mentioned in the article expose these perturbation parameters as interactive controls, allowing evaluators to manually vary friction, push impulses, or motor backlash and observe the policy's robustness boundaries. Motor backlash refers to the play error caused by gear clearance in transmission, particularly pronounced in low-cost servos (such as Dynamixel XL330, Feetech STS3215), which prevents small commands from being precisely transmitted to joints—a factor often overlooked in simulation but affecting physical performance. Understanding these concepts is essential to judging why domain randomization sliders are considered the highest-value feature for policy developers.

The Real Value and Limitations of Such Tools

From an engineering perspective, DuckSpace.org represents an emerging tool paradigm: leveraging WebAssembly and browser-side inference runtimes to lightweight heavy simulation capabilities that previously required local environments. Its value lies not in replacing local MuJoCo or physical testing, but in lowering the barrier to community participation—allowing policy contributors, robotics enthusiasts, and even potential users to gain intuitive understanding within seconds.

The limitations are equally obvious. Browser-side physics simulation precision is constrained by operating frequency and model simplification; while switching between multiple servo configurations is convenient, dynamic differences across hardware platforms are difficult to fully reproduce in a single simulation; the integration of higher-level Mind modules increases product complexity without necessarily serving the core "policy evaluation" scenario.

For bipedal robot RL policy developers, a truly useful browser testbed should prioritize three things: policy loading and quick playback, adjustable domain randomization parameters, and recorded comparisons between simulation and physical performance. Voice interaction and rhythm head-nodding can serve as demo highlights but should not become the protagonist of the product narrative.

The "candid engineering feedback" the original poster seeks points to a more fundamental question: in the open-source robotics ecosystem, tools should be driven by community needs, not feature accumulation. The next evolution of DuckSpace.org might best begin by answering "what validation actions do policy developers perform most frequently?"

WebAssembly (Wasm) is a binary instruction format that executes at near-native speed in modern browsers, standardized by the W3C, supporting compilation from C/C++, Rust, and other languages. It runs within the browser sandbox with memory safety and cross-platform characteristics, enabling heavy computational libraries (such as physics engines and inference runtimes) that previously required local installation to run directly in web pages. Compiling a C++ engine like MuJoCo to WebAssembly is the key path to achieving "zero-install" in this testbed; however, Wasm's single-threaded execution model, memory limitations, and lack of native SIMD optimization also constitute a natural ceiling on browser-side simulation precision. When evaluating such tools, Wasm's performance constraints must be factored in, rather than simply comparing browser and local MuJoCo simulation results.