Skip to main content
Cyberwave turns every environment into a runnable simulation. Hit Simulate in the editor, or flip the SDK into sim mode: same scene, same twins, same code:
When you’re done, cw.affect("live") points the same code at the real robot. No rewrites, no second SDK, no second environment.

​
Why simulate?

Develop at code speed

Tweak a policy, re-run, see the result in the viewport: no robot, no lab, no waiting on hardware.

CI for robotics

Run the same scene headlessly in CI. Catch regressions in motion planners, perception, and controllers before they ship.

Train models

Use simulation rollouts to train and evaluate VLAs and RL policies on the same twins you’ll deploy on.

Synthetic data

Render camera streams, depth, and joint states from any environment to bootstrap datasets when real-world data is scarce.

​
Simulation engine agnostic

Set up your environment once. Cyberwave handles the export to each backend so you can pick the right tool for the job without re-modeling anything.

Playground

Browser-based, runs on your machine’s compute. Best for fast iteration.

MuJoCo

High-fidelity, contact-rich physics. Best for RL, evaluation, and reproducible sim sweeps.

Isaac Sim

GPU-accelerated photoreal simulation. Coming soon.
Each twin advertises which backends it supports; see Simulator compatibility to control which simulators an asset or twin can participate in.

​
Powered by the twin catalog

There’s no separate “simulation setup” step. Physics, kinematics, sensors, and collision geometry are read straight from the digital twins you dropped into the environment; every twin in the catalog ships with a URDF and inertial data ready to simulate. Add a twin → it’s instantly simulatable. Swap a SO-101 for a UR7e → the physics update on the next run.

​
The two simulators today

Open any environment in the editor and click Simulate in the top bar.

​
Playground: instant browser physics

Playground is a lightweight rigid-body simulator that runs entirely in your browser, using your machine’s compute. There’s nothing to install and nothing to wait for; it’s running the moment the page loads.
  • Fastest feedback loop: change a joint target in code, see the twin move in the viewport.
  • Great for sanity checks: verify motion plans, joint limits, and basic collisions before going live.
  • Works offline from cloud compute: every browser is its own simulator.
Locomotion previews in Playground too. Locomotion and flight commands drive the twin in the browser viewport exactly like the keyboard teleop overlay does, so you can sanity-check a driving/flying script before pointing it at hardware:
Camera previews, including depth. Each camera on a twin gets its own tile in the right sidebar, previewing what that camera sees as you move things around. A depth camera previews as the same grayscale ramp it produces in MuJoCo — near surfaces dark, far ones bright, scaled to the sensor’s own range, with anything past its reach left white. Playground previews are for framing and reach; to pull frames into code or a workflow, run the environment in MuJoCo.

​
MuJoCo: contact-rich physics, your way

Need real grasps, friction, and reproducible RL sweeps? Cyberwave one-click-exports any environment to MuJoCo, two ways:

Export and run anywhere

Download a self-contained MuJoCo scene (XML + meshes) and run it on your laptop, your cluster, or your CI runner. Backed by the environment MuJoCo export API.

Run in the Cyberwave cloud

Kick off a MuJoCo simulation from the editor and stream results straight back into the browser viewport, no local install required.
All twins in the environment must be marked MuJoCo-compatible before a remote run starts; see how the compatibility gate works.

​
Camera playback statistics

Simulation camera panels show video fps. Hover or focus this value for its meaning: it counts received or decoded video frames, which can repeat an older image. It does not measure fresh camera observations or prove real-time control.

​
One simulation per environment

An environment runs one cloud simulation at a time. Starting a new one stops whatever was still running first, so pressing Simulate again always gives you a clean run rather than two robots fighting over the same twin. If a second start arrives while one is already in flight — a second browser tab, a teammate, or an SDK call racing the editor — the API returns 409 naming the simulation that already holds the environment.

​
Speaker and microphone audio in MuJoCo

Speaker and microphone twins work in MuJoCo simulations too. Upload a WAV file as a speaker twin’s audio source in the editor (optionally looping it), start the simulation, and any microphone twin in the same environment hears it — useful for testing audio-based perception (wake words, sound classification) without a physical room. A speaker that’s actively playing shows a small wave animation expanding forward from it in the 3D viewport, so you can tell it’s emitting audio at a glance without opening any panel. The audio format — sample rate, channels, and bit depth — is set per sensor under Sensor Parameters in the asset editor, for microphones and speakers alike. Leave a field blank and it falls back to 48000 Hz, 16-bit, with the channel count taken from the sensor type: audio_stereo is 2 channels and every other microphone type is 1. A speaker falls back to 2, so set channels to 1 for a mono source such as a single warning speaker.

​
Mapping and autonomous navigation in simulation

Mobile twins can build an occupancy map during a MuJoCo run, exactly as they do on hardware. Start the simulation, press Start Mapping, drive the robot around the environment, then press Stop Mapping: the map streams into the viewport while you drive and is saved to the twin when you stop. Once a map is saved, the twin localizes against it and follows waypoints on its own — the same Move Twin and waypoint workflows you use on a real robot, and the same navigation stack running behind them. Send a goal and the robot plans a path, avoids what its lidar sees, and reports progress back to the workflow. On a real Go2, a printed AprilTag recorded during mapping lets the robot find itself on the saved map after a restart. See AprilTag relocalization. Supported today: Unitree Go2 and MiR250 (including the Coesia variant). The MiR250 fuses its front and rear lidars into a single 360° scan, so a single pass down an aisle maps both sides.

​
Runtime profiles, cost, and what each serves

cw.affect(...) picks the runtime and, for MuJoCo, starts the simulation for you:
  • cw.affect("simulation") / "sim" / "mujoco" — starts (or reuses) a MuJoCo run. A MuJoCo simulation is a billable cloud instance (~0.6 credits/hour); selecting it logs the cost. Pass environment_id= / duration= to affect(), or set CYBERWAVE_ENVIRONMENT_ID.
  • cw.affect("playground") — lightweight kinematic runtime, no MuJoCo instance, no cost.
  • cw.affect("live") — real hardware.
Stop a run with sim.stop() (it also stops at its duration):
What each runtime serves:
  • Any sim runtime: pose, joints.
  • MuJoCo only: camera frames, get_video(), depth, point clouds, LiDAR — otherwise SimulationNotRunningError / SimulationLevelError.
  • Any sim runtime: locomotion and flight control surfaces — twin.commands.*, twin.locomotion.*, twin.flight.* and their twin shortcuts (twin.move_forward(), twin.takeoff(), twin.land(), …). In MuJoCo a drone flies under thrust, so it obeys gravity and contacts
  • Not in simulation: the imu and gps sensors — raise NotSimulatedError (live/driver-only). A twin positioned from GPS renders from its saved position in Simulate; see Geo reference.
  • Not available yet: the compass sensor isn’t implemented in any runtime.

​
See simulation in action

Autonomous rover inspection

Build and run an AI-driven inspection mission in a fully simulated environment.

Train a VLA with SO-101

Collect data, train a vision-language-action model, and validate in sim before touching hardware.

Go2: digital to physical

Configure a Unitree Go2 in simulation, then flip the same code onto the real robot.

Sandwich-making robot (SmolVLA)

Train, evaluate, and iterate a manipulation policy with simulation in the loop.