go2_omniverse: a Unitree Go2 and G1 digital twin inside Isaac Sim

A Go2 twin that stands in for the physical dog

abizovnuralem/go2_omniverse is a Python project that gives the Unitree Go2 and the newer G1 a simulated body inside Nvidia Isaac Sim, the simulator that Isaac Lab builds on. The audience is narrow on purpose: robotics engineers who already work in Isaac Lab and want a Unitree quadruped to train policies against, drive from a keyboard, or watch move in step with hardware sitting on the other side of the room. The project description names the pairing directly, Unitree Go2 and Unitree G1 support for Nvidia Isaac Lab, with Isaac Gym and Isaac Sim listed alongside it.

The code is split the way an Isaac Lab user would expect to navigate it. main.py is the entry point, agent_cfg.py holds the reinforcement learning agent settings, custom_rl_env.py defines extra training environments, and terrain_cfg.py together with terrain_generator_cfg.py shape the ground the robot walks on. Scene construction sits in omniverse_sim.py and omnigraph.py. Robot definitions live under robots/, ROS 2 code in ros2.py, and a ROS 2 workspace directory named go2_omniverse_ws sits beside IsaacSim-ros_workspaces/ and Isaac_sim/.

Two launchers cover the two robots, run_sim.sh for the Go2 and run_sim_g1.sh for the G1, with run_sim_humble.sh named for the older ROS 2 Humble target. The licence is BSD-2-Clause, so reuse obligations stay light, though the licence covers this repository's own files and says nothing about the Unitree SDK or the Isaac Sim assets it depends on.

twinbot reads the real dog and drives the simulated one

The most interesting mechanism in this repository is the twinbot mode, launched through run_twinbot.sh. Instead of running a policy, the simulated Go2's joints are driven directly from the physical robot's /lowstate stream, which is forwarded off the Jetson by scripts/twinbot_bridge.py. The result is described as a one to one mirror of the real dog through IMU-aligned kinematic playback, and the writeup behind it lives in docs/TWINBOT_IMU_FIX.md, with twinbot.py and ros2.py at the repository root carrying the implementation.

The project is unusually direct about where the arrow points. Real to Sim, meaning physical robot state entering the twin, is implemented and IMU aligned. Sim to Real, meaning commands travelling back to the robot, goes through the standard Unitree SDK control path and is not a closed, learned loop. The README puts it bluntly, and that limitation is the single most important fact for anyone planning a policy deployment on top of this work.

The practical value of this mode is diagnostic. When a policy destabilises the real machine, a twin that follows the physical joints rather than an internal model gives you a second place to look, with the same scene, the same terrain and the same observation streams.

Running the sim and capturing stills without a screen

There is no pip install line anywhere in the project documentation. The setup detail is delegated to JAZZY.md, which the repository points to for the venv setup and for a plain statement of what is and is not validated. What the badges do pin down is the target platform: Isaac Sim 5.0, Python 3.10 or 3.11, and Linux 64. Anyone arriving on Windows or on a different Python minor version should treat that as a hard stop before spending an afternoon on it.

The first real use is either the twinbot launch or a headless capture. Rendering stills does not need a display, because the capture path renders the Go2 from several angles through an isaaclab Camera render product:

./run_sim.sh --capture 80 --headless --enable_cameras --rendering_mode quality \
    --capture_dir ./media

The capture count is 80 frames, the scene is rendered in the quality RT2 preset, and the frames land in the ./media directory that the repository already contains. Switch to the twinbot script and you get the same quality preset, since run_twinbot.sh launches the quality RT2 render preset with the --rendering_mode quality flag. Expect the run to need an NVIDIA GPU with ray tracing, and expect the first launch to compile shaders, since Isaac Sim does that work at startup rather than handing over a prebuilt scene.

The Isaac Sim 5.x boot fixes that decided the port

Two version specific changes carry most of the engineering weight in this fork, and both are the kind of detail that decides whether a port works at all.

First, ROS 2 bridge libraries are now resolved from isaacsim.ros2.core, because Isaac 5.x moved them out of isaacsim.ros2.bridge, and the code keeps a fallback to the old path. Second, articulation buffers are converted from warp arrays to NumPy before indexing, which the repository attributes to IsaacLab 4.5 and Isaac Sim 6.0 compatibility. Both are the kind of change that reads as a one line diff and costs a day of debugging when it is missing, so a reviewer should look for them in any downstream copy of the project.

The timeline is worth keeping straight. The last push was on 2026-07-01, while the two tagged releases are v0.1.0 from 2024-06-07 and v0.2.0 from 2024-09-02. The repository is not archived, and there is work on it after the last release, but there is no version numbering to follow for the 5.x and Jazzy work, so plan on tracking the default branch rather than pinning a tag. The topics attached to the repository, including isaac-lab, isaac-sim, robot-learning, digitaltwins and unitree-g1, match that untagged working state.

Studio HDRI lighting, RT2 quality and offline path tracing

The rendering changes are the second visible difference between this fork and the upstream project it was forked from. The default scene is lit with Isaac's bundled studio HDRI, that is image based lighting, so the robot's shells catch reflections instead of reading as a flat gray dome. That single change is what makes the hero images in the repository look like a product render rather than a physics screenshot.

Two render paths exist and they are not interchangeable. The interactive path uses the real time RT2 preset, and that is the one used for closed loop work, because a live policy needs frames on time. The cinematic path is deliberately decoupled: record the joint trajectory live, then re-render it offline in RTX path tracing mode. The reasoning given is that live closed loop favours the real time preset, so quality rendering is moved out of the control loop rather than slowing it down. This is the right trade for demos, and the wrong one if you need photoreal frames every control step.

Headless capture is the third path, and it is the one that is easiest to reproduce, since it needs no on-screen window and writes straight into ./media.

The upstream project and the browser-based remote machine

There are two credible alternatives, and both are described in the repository itself rather than invented here.

The first is the upstream project. This repository is a fork of abizovnuralem/go2_omniverse, and the three additions it claims over that base are the real robot digital twin mode, the Isaac Sim 5.x and ROS 2 Jazzy port, and higher fidelity default rendering. If your work is plain Isaac Lab simulation of a Go2 with no physical robot in the loop, the upstream line of development is the shorter path. The fork earns its extra weight only when you want the sim to track hardware, need the 5.x bridge fix, or care about the studio lighting.

The second alternative is not code at all. The README points readers to a cloud service from robolaunch for the case where the local machine cannot run Isaac Sim or Isaac Lab, offering real-time work by connecting to a remote server through a web browser. For a laptop without a ray tracing capable GPU, that hosted path is a different cost model than the fork's own scripts, and it removes the Linux 64 and Python 3.10 or 3.11 constraints from your own machine. It also moves your scenes and policies off local storage, which is a decision to make deliberately rather than by default.

Where the scope stops, and what the licence does not cover

Three limits are worth stating plainly before anyone builds on this.

The loop is not closed. The project says so directly: Sim to Real uses the standard Unitree SDK control path and is not a closed, learned loop, and the README explicitly declines to claim more than that. Any plan that assumes policies trained in this twin will transfer without a separate real robot validation loop is reading more into the project than it offers.

The documentation is thin in places. The README does not document rollback, does not give a dependency pin list, and does not provide an install command; it defers both setup and validation status to JAZZY.md. Treat those two files as required reading rather than optional reading.

The licence covers this code only. BSD-2-Clause applies to the repository's own files. It says nothing about NVIDIA's Isaac Sim and Isaac Lab terms, nothing about the Unitree SDK used on the control path, and nothing about the physical robot you intend to command. Read those terms separately if you plan to ship anything commercially.

Editorial conclusion

Adopt this fork if you need a Unitree Go2 or G1 asset inside Isaac Lab and want the simulated dog to follow the physical one through the lowstate stream. Skip it if your pipeline needs a learned policy to close the loop from simulation back to hardware, or if you need a documented pip install path, because neither exists here. Before committing, check JAZZY.md for what the venv setup actually validates, confirm your Isaac Sim and Isaac Lab versions match the boot fixes described in the repository, and read the scope notes in docs/TWINBOT_IMU_FIX.md to see how the IMU alignment was achieved.

Frequently asked questions

Official sources

1. abizovnuralem/go2_omniverse on GitHub
2. Issues
3. License: BSD-2-Clause
4. README
5. Releases