Skip to main content
Drift treats the open MuJoCo model collection (google-deepmind/mujoco_menagerie) as first-class. Instead of authoring a Go2 from scratch (you don’t want that — the Menagerie model is battle-tested with correct inertias, joint limits, and friction tuning), Drift composes your scene, controllers, sensors, and logging around the Menagerie XML. This guide walks through a one-prompt Go2 standing demo on a small staircase.
Recommended setup: MuJoCo 3.8.1+, Python 3.10+. Drift can clone Menagerie for you on the first run if it isn’t on disk yet.

The prompt

From this prompt (plus likely a tuning follow-up or two), Drift:
  • Clones mujoco_menagerie to a path you confirm if it isn’t on your system already, or asks where it lives if it is
  • Composes go2_scene.xml that <include>s the Menagerie Go2 model and adds the floor + 3-step staircase
  • Spawns the Go2 at the Menagerie keyframe so the feet rest on the ground
  • Writes a run_sim.py that loads the keyframe, applies PD control on all 12 joints, steps the sim for 5 seconds, and logs sensors at 100 Hz
  • Runs the sim, prints the final base pose and any contact issues
  • Drops a DRIFT.md summarising the scene, the controller, and what to tune next

What ends up on disk

go2_scene.xml is intentionally short — most of the model is referenced from Menagerie:
This is the right pattern: a thin scene file that includes a curated robot model, plus only the bits your work actually needs.

What the viewer shows

Open it interactively:
If the gains are sane, you’ll see the Go2 standing in the default pose facing the staircase, joints held by the PD controller. The CSV next to it shows the IMU steady, joint positions near the keyframe targets, and foot contact forces roughly balanced across the four legs. If the robot collapses, that’s a gain tune — see the gotchas at the bottom.

Iterating from here

Each follow-up triggers only what’s needed — no full rebuilds:

Honest scope

Things this guide does:
  • Compose the scene around the Menagerie Go2 model
  • Write a PD hold-pose controller
  • Wire IMU + contact + joint sensors and log them
  • Open the viewer / run headless
Things this guide does not do:
  • Learned locomotion (trot, gallop, recovery from a push) — those are policies you train; Drift can scaffold the training environment but not the policy itself
  • Real-world deployment to a physical Go2 — Drift focuses on simulation
  • Reactive contact-aware planning — the controller here is pose-hold, not a footstep planner
If you have a policy in .pt or .onnx form, ask Drift to wire it in:
That’s a real bridge Drift will build — your policy, our wiring.

Common gotchas

Drift doesn’t assume a fixed Menagerie path. Easiest pattern: tell it the path once and pin it in DRIFT.md so every future prompt uses the same one.
DRIFT.md ends up with:
Future prompts now resolve mujoco_menagerie to that absolute path without you re-stating it.
The default keyframe in Menagerie is calibrated for a flat ground spawn. If you put the Go2 on top of a staircase step rather than at its base, the static pose isn’t stable. Either:
  • Spawn position at (0, 0, 0.30) (in front of the stairs) — what this guide does
  • Or ask Drift to compute a per-step stable stance for the staircase case
Tell Drift the symptom: "the Go2 tips backward in the first 200ms" — it’ll walk the diagnosis.
Two usual causes — Drift will check both:
  • Contact between Go2 feet and the floor is excluded by a <contact><exclude.../></contact> block somewhere — common when including a Menagerie scene file rather than the bare model.
  • The contact sensor names changed between Menagerie revisions. Pin a version in DRIFT.md to avoid surprises.

Next steps

Dual-arm Aloha

Tabletop bimanual demo

Humanoid H1

Standing pose demo with PD control on 19 joints

Building a MuJoCo Scene

The base MuJoCo guide — useful background for everything in Showcase

Project Context

Pin your Menagerie path and conventions so every prompt is consistent