MuJoCo Playground links robot simulation with hardware control MuJoCo Playground links robot simulation with hardware control

What does the shared layer actually share?

Playground separates the task from the robot and sensor implementation. Its current overview lists reinforcement learning, teleoperation, system identification and agent-driven manipulation within the same development toolkit. Version 0.2 used JAX; the rebuilt version uses PyTorch with MuJoCo or MuJoCo Warp. That changes the surrounding software stack as well as the examples. The repository keeps the original JAX and MJX environments under a separate RSS 2025 directory. Existing experiments therefore have an identifiable older home instead of silently becoming the new implementation.

How does one task reach a real arm?

The documented SO-101 cube-picking workflow provides a concrete example. A developer trains a vision policy, loads its checkpoint in simulation, then runs the deployment entry point in real mode. The same task layer and trained policy cross that boundary. The instructions also include replaying logged deployment episodes, which makes the resulting behavior available for inspection. Hardware setup comes first in the documented sequence. The public robot list marks SO-101 and YAM Pro for both simulation and real operation; WidowX and Unitree G1 are marked simulation-only.

Where does a language model enter the loop?

The tabletop agent example uses a local HTTP bridge. Each turn supplies robot state and an annotated wrist-camera image to a vision-language model. The model returns a Python plan built from operations such as grasp, place and move until contact. This is a different control path from replaying a trained cube-picking policy. The documentation explicitly warns that generated Python is executed and directly drives the robot. A shared interface makes the transition between environments convenient, while also making the selected execution mode consequential.

Why does the November 8 patch matter?

Version 1.0.1 changes the measurement interface used by its robot devices and moves state updates into explicit lifecycle hooks. The underlying reaf-sim patch addresses a more specific problem: partial resets could duplicate an observation in environments that were not resetting. Its camera devices now return cached frames when measurements are requested, rather than rendering during that read. These changes separate asking for a measurement from advancing state. For a learning system that consumes observation history, repeating an entry changes the input sequence even when the physical scene has not changed.

What can the release establish?

The useful distinction is between reusable software and demonstrated behavior. Playground supplies paired workflows, deployment entry points and examples that connect simulation with supported hardware. Its agent example exposes the additional step where model-generated instructions become actuator commands. The November 8 fixes also show why resets and measurement timing belong in the explanation: task code depends on the observations it receives. Sharing that code gives developers a common place to investigate behavior across environments. It does not make the two environments identical.