Building a MuJoCo IDE for the Unitree G1

Cybernetic IDE started from a practical irritation: robotics software work often splits across too many surfaces.

You write code in one editor. You start a simulator from a terminal. You watch a viewer in another window. You keep protocol notes somewhere else. Then you ask an agent to help and it has to infer the real state from fragments.

That is workable for experts. It is a poor product boundary.

For the Unitree G1 work, we wanted the first milestone to feel more like ordinary software development. Open a Python file. Start the local runtime. Put the G1 MuJoCo scene beside the code. Send commands through a Unitree-shaped API. Inspect the result without leaving the workspace.

The current build is intentionally narrow. It is not claiming to be a complete G1 robotics studio yet. It proves the boundary: user code can sit beside a live MuJoCo scene, and the IDE can own enough simulator lifecycle and viewer state to make that loop useful.

What we built

Cybernetic IDE is a robotics-focused fork of Zed. The inherited editor gives us a fast native workspace, panes, tasks, command palette actions, and a large amount of language tooling. The Cybernetic layer adds a robot viewer and a local Unitree G1 simulation path.

The first G1 milestone has four main pieces:

• crates/cyber_robot_viewer/: a Robot Viewer workspace item embedded in the editor.
• overlays/unitree-g1-mujoco-protocol/: a Python MuJoCo renderer and control server.
• overlays/unitree-g1-mujoco-container/: a Docker Compose wrapper around the local G1 runtime.
• overlays/unitree-g1-sdk-shim/: a small Python facade shaped like the Unitree SDK2 client API.

That split matters. The UI should not know how to drive every low-level simulator detail. The protocol container should not know about editor panes. The SDK shim should let user code keep a recognizable Unitree shape while the backend moves from the bootstrap bridge toward official SDK2 and CycloneDDS topics.

The embedded viewer talks to local endpoints for status, camera state, visual frames, and simulator commands. It renders cached camera frames from MuJoCo and sends lightweight camera commands for orbit, pan, zoom, reset, pause, resume, step, and refresh.

The example in the screenshot is deliberately plain Python. One script probes the simulator through a Booster-like WebSocket and HTTP envelope. Another uses a Unitree SDK2-shaped facade to raise the G1's right hand:

from unitree_sdk2py.core.channel import ChannelFactoryInitialize
from unitree_sdk2py.g1.arm.g1_arm_action_client import G1ArmActionClient, action_map

ChannelFactoryInitialize(0, "cyber-sim")

arm = G1ArmActionClient()
arm.SetTimeout(10.0)
arm.Init()
arm.ExecuteAction(action_map["right hand up"])

Right now, that high-level call maps to a transitional MuJoCo pose command. The user-facing shape is the part we want to preserve. The backend can become more faithful without making every example script learn a new product API.

Why put the simulator inside the IDE?

The embedded viewer is not about novelty. It removes guesswork.

When code and simulation are separate, the developer has to manually keep track of which runtime is active, whether the scene matches the file they are editing, which port is connected, and whether a command changed the robot or merely returned success.

Putting the viewer in the workspace gives the IDE a small but valuable contract:

• The Robot Viewer knows whether the simulator is connected.
• The code pane and simulator pane can be arranged together.
• Tasks can launch demos from the same workspace.
• Status and camera frames are visible while code changes.
• Agent workflows can inspect a live visual target instead of trusting text logs alone.

That last point is important for us. Cybernetic Physics is not only building robotics UI for humans. We are building workflows where agents operate simulators, write helper code, inspect evidence, and save artifacts. An IDE with an embedded simulator becomes a better target for those workflows than a pile of terminal commands.

Use cases

The first useful use case is simulator-backed SDK development.

A developer can sketch G1 control code against a Unitree-shaped Python API and immediately check the result in MuJoCo. That is safer than starting with hardware and faster than bouncing between editor, terminal, and viewer windows.

The second use case is integration testing for robotics tools.

If a workflow needs to prove that a script can start a simulator, connect to it, send commands, and observe state, Cybernetic IDE gives that test a concrete surface. The test can operate files and tasks, then use the viewer and protocol endpoints as evidence.

The third use case is agent-assisted robotics work.

Agents are better when the environment gives them durable handles. A script path, a simulator endpoint, a viewer pane, and a task command are all handles. They let an agent repair code, run a demo, inspect the scene, and leave behind a trace that a human can audit.

The fourth use case is sim-to-real staging.

We are not treating the current pose bridge as the final robot transport. The intended next layer is the official Unitree SDK2 and unitree_mujoco DDS shape: simulator sessions on a safe domain, physical sessions on a hardware-selected interface, and explicit gates between the two. Keeping the user code close to SDK2 now makes that transition less disruptive.

What is intentionally missing

The honest status is that Cybernetic IDE has a good first G1 MuJoCo development loop, not a complete robot operations console.

It does not yet expose full Unitree DDS telemetry in the viewer. It does not yet send real locomotion, posture, hand, or low-level joint commands through official SDK2 topics. It does not yet have the broader panels you would expect in a mature robotics studio: topic graphs, service calls, parameter tables, process health, logs, robot inventory, saved profiles, or hardware safety state.

Those omissions are useful constraints. They keep the first milestone from pretending to be finished.

The next architecture step is a UnitreeG1Provider runtime sidecar. The IDE should talk to that sidecar, not directly to DDS from UI code. The sidecar can own simulator versus hardware transport, lifecycle, telemetry, command validation, and safety gates. The editor remains the workspace. The provider owns the robot invariant.

The product boundary

The product shape we want is simple:

code workspace
  -> local or cloud simulator runtime
  -> embedded viewer
  -> SDK-shaped user API
  -> traceable workflow or task
  -> saved artifact or reviewed result

That shape gives humans a useful development loop and gives agents a surface they can operate without guessing.

Cybernetic IDE is early, but the first milestone already changes the feel of the work. The G1 scene is not somewhere else. It is beside the code. The command path is visible. The runtime has a name. The screenshot is not a mockup. It is the current loop: write code, run the G1 MuJoCo harness, inspect the robot, and keep tightening the boundary until the simulator and real robot paths can share the same user-facing API.

That is the reason to build an IDE here. Not because every robotics tool needs to be inside one window, but because the right window can make the control loop legible.