Skip to main content

Building a Physics-Accurate Digital Twin of G1

Duration: 60 min · Level: Intermediate · Module: 7. Simulation & Digital Twins · Focus: digital-twin, URDF, Isaac-Sim, modeling

A digital twin is not a screensaver. It is a live, physics-accurate simulation of the real G1, synchronized in real time from sensor data, that earns its keep three ways: it visualizes what the robot is doing, it predicts when components will wear or fail, and — most valuable during development — it lets you pre-test policies in a faithful copy before you ever risk the hardware. A twin is only as useful as it is accurate, so this lesson is about closing the gap between the model and the metal: getting the geometry, the inertia, the actuators, and the sensors right, then keeping the twin in sync with reality.

From URDF to USD: getting G1 into the twin​

G1 ships its kinematics and geometry as a URDF (Unified Robot Description Format) — the ROS-standard XML that describes links, joints, visual meshes, and collision shapes. Isaac Sim does not consume URDF natively; it lives in USD (Universal Scene Description), the Omniverse scene format. So the first step of every twin is a URDF → USD conversion.

Isaac Lab wraps the Isaac Sim URDF importer in a converter script you can run from the command line:

./isaaclab.sh -p scripts/tools/convert_urdf.py \
  /path/to/g1.urdf \
  source/isaaclab_assets/data/Robots/G1/g1.usd \
  --merge-joints \
  --joint-stiffness 0.0 --joint-damping 0.0 \
  --headless

On Windows swap isaaclab.sh for isaaclab.bat. The converter writes an instanceable USD — geometry stored once and referenced many times — which is exactly what you want when you spin up thousands of parallel copies for training. Watch the collision geometry: the importer can build collision shapes from the visual meshes, but the default approximation (convex_hull) wraps each mesh in its convex envelope, which is wrong for any concave part. Switch to convex_decomposition for links where concavity matters, or your twin's contacts will lie to you.

Inertial parameters: the difference between a model and a twin​

This is where most twins quietly fail. A URDF's mass and inertia tensors are usually nominal — pulled from CAD or estimated — and the measured values for each link differ by 5–20%. Twenty percent inertial error is enough that a policy which balances perfectly in the twin tips over on hardware, because the twin's idea of how the robot's mass swings around each joint is simply wrong.

The fix is system identification: measure the real parameters rather than trusting the CAD. The classic technique is swing experiments — let a link or limb pendulum freely about a joint, record the oscillation, and back out the true mass distribution and inertia tensor from the dynamics of the swing. You do this per link, then overwrite the nominal values in the model. This is unglamorous, hours-long lab work, and it is the single highest-leverage thing you can do to make a twin trustworthy. Identify inertia before you tune anything else, because every downstream model inherits its errors.

Actuators and sensors: modeling the parts that aren't rigid bodies​

Rigid-body physics handles the skeleton. The twin's fidelity then depends on two things physics-by-default ignores: how the motors actually produce torque, and how the sensors actually perceive the world.

Actuator modeling. A real motor is not an ideal torque source. Its output is shaped by current limiting (it cannot exceed a peak current), back-EMF (the faster it spins, the less torque it makes at a given voltage), and thermal derating (sustained load heats the motor and the controller throttles it to protect the windings). Add these to the twin so commanded torque maps to delivered torque the way it does on hardware. Skip them and the twin will happily execute torques the real G1 cannot, and your "validated" policy will saturate its motors the moment it runs.

Sensor simulation. The policy and the state estimator see the world through sensors, so the twin must corrupt its perfect ground truth the way real sensors do — using noise models pulled from the manufacturer datasheets, not guesses. Concretely: IMU noise (bias and white noise on the gyro and accelerometer), camera calibration error (intrinsics that never perfectly match the lens), and encoder quantization (joint angles readable only to the encoder's finite resolution). A twin that feeds the estimator noise-free state is testing an estimator that will never exist.

Keeping the twin live: the state-estimation bridge​

A static, accurate model is a simulator. What makes it a twin is synchronization: the real robot's onboard SLAM produces a live pose estimate, and that estimate streams into the twin to update its state so the virtual G1 mirrors the physical one in real time. The hard constraint is latency — keep the round trip under 50 ms for the synchronization to be useful. Past that, the twin lags far enough behind reality that you are visualizing the robot's recent past, which is worse than useless for any closed-loop or safety purpose. Budget the bridge like a control loop: estimate, transmit, and apply within the 50 ms window, and measure it rather than assuming it.

What a good twin buys you​

With geometry, inertia, actuators, sensors, and the sync bridge all in place, the twin pays back across G1's lifecycle:

  • Policy pre-testing — run a new locomotion policy in the twin first; if it saturates a motor or destabilizes, you learn it in software, not on a robot that falls.
  • Predictive maintenance — track simulated load and the thermal/wear models to anticipate joint wear patterns and service a joint before it fails in the field.
  • Training and procedures — use the twin to train maintenance technicians on the correct repair steps without tying up real hardware.

Putting it into practice​

Build a G1 twin you would actually trust, one fidelity layer at a time.

  1. Convert G1's URDF to USD with convert_urdf.py, then audit collision shapes — switch concave links to convex_decomposition.
  2. Identify inertia for at least three major links via swing experiments and overwrite the nominal URDF values; record the percent change per link (expect 5–20%).
  3. Model the actuators — add current limiting, back-EMF, and a thermal-derating model so commanded torque maps to deliverable torque.
  4. Add sensor noise to the IMU, cameras, and encoders using datasheet figures, not guesses.
  5. Close the loop — stream onboard SLAM pose into the twin and measure end-to-end latency; confirm it stays under 50 ms, and decide one concrete use case (pre-test, maintenance, or training) the twin is now good enough to serve.

Key takeaways​

  • A digital twin is a live, synchronized physics model — its value is visualization, predictive maintenance, and pre-testing policies before hardware.
  • Every twin starts with URDF → USD conversion (convert_urdf.py); mind the collision approximation — convex_hull is wrong for concave links.
  • Inertial accuracy is the make-or-break step: nominal vs. measured inertia differs 5–20%, so identify the real parameters via swing experiments before tuning anything else.
  • Model the parts rigid-body physics ignores — actuator dynamics (current limiting, back-EMF, thermal derating) and sensor noise from datasheets (IMU, camera, encoder).
  • A twin becomes "live" only with a state-estimation bridge (SLAM → twin) under 50 ms latency; beyond that it visualizes the past, not the present.

← Previous: 7.2 Domain Randomization: The Bridge from Sim to Real

Part of Module 7: Simulation & Digital Twins.