More and more teams want to test layouts, traffic flow and tasks in a virtual factory before bringing robots onto a real floor. That virtual factory is a digital twin. Building one quickly shows that gathering the data is harder than rendering it. This article explains, from the official documentation, how OpenUSD solves that problem, then lays out how to carry a twin into robot simulation with Omniverse.
The real obstacle: scattered data
A single factory’s data lives in many tools. The building is in architectural design software, conveyors and equipment in mechanical CAD, robots in manufacturers’ model files, and products in yet another design tool. Converting all of it into one file looks fine at first, but every change to a source means converting again, and it becomes hard to track who changed what.
Robot simulation also needs more than shapes: mass, joints, collision geometry and sensors such as cameras and LiDAR. A digital twin stays usable only if it has a structure that layers data from many sources without damaging the originals and keeps accepting new information on top.
OpenUSD: composing a scene instead of merging files
The OpenUSD documentation describes USD as roughly the fourth generation of “composed scene description” developed at Pixar — the first publicly available software built for exchanging and assembling 3D scenes across tools, and the core of Pixar’s 3D graphics pipeline. Its key concepts:
- Prims and properties — scene elements organized hierarchically, carrying attributes and relationships.
- Layers — file-based containers for scene data.
- Composition arcs — operators such as sublayers, references, payloads, variants and inherits that combine layers and assets; stronger layers override weaker ones.
- Stage — the runtime scene graph that presents the composed result.
- Schemas — standard encodings and APIs for common concepts such as geometry, shading and models.
This structure enables non-destructive editing. The equipment team and the robot team can maintain their own layers, and a simulation-settings layer can sit on top, composing one factory scene.
A small example: placing robot cells in a factory
The snippet below uses the USD Python API to create a factory stage and place a robot cell, kept in its own file, twice by reference.
from pxr import Usd, UsdGeom, Gf
stage = Usd.Stage.CreateNew("factory.usda")
UsdGeom.Xform.Define(stage, "/Factory")
# Place a robot cell stored in its own file, twice, by reference
for i, x in enumerate([0.0, 6.0]):
cell = UsdGeom.Xform.Define(stage, f"/Factory/RobotCell_{i}")
cell.GetPrim().GetReferences().AddReference("robot_cell.usda")
cell.AddTranslateOp().Set(Gf.Vec3d(x, 0.0, 0.0))
stage.GetRootLayer().Save()
When robot_cell.usda changes, every cell that references it picks up the change. In the same way, layout options A and B can be stored as variants and switched to compare traffic flow and cycle times.
The first problem in practice: units and axes
When data from many tools is combined, the most common accident is not geometry but units and axes. Some design tools work in millimeters, others in centimeters or meters, and some treat Y as up while others use Z. Combine them without reconciling these and a robot cell can appear a thousand times too large, or lying on its side.
USD records this information as stage metadata. The metersPerUnit and upAxis values provided through UsdGeom declare each file’s unit and up direction, and conversions are applied when files are composed. At the start of a digital-twin project, fixing the factory-wide reference unit and axis convention, and adding a check that every incoming asset follows it, prevents a large share of later problems. In robot simulation this matters even more, because wrong units also corrupt mass and inertia, which in turn change how simulated robots move and collide.
A second practical habit is naming. Prims are addressed by paths such as /Factory/RobotCell_0, and other layers, scripts and simulation settings refer to those paths. Agreeing on a naming scheme early, for example by line, station and equipment type, keeps references stable as the factory model grows and different teams add their own layers on top of each other.
The standard and the ecosystem: AOUSD and Omniverse
Turning OpenUSD into a formal standard is the job of the Alliance for OpenUSD (AOUSD). Its founding members are Pixar, Adobe, Apple, Autodesk and NVIDIA; as part of the Linux Foundation’s Joint Development Foundation, it aims to provide a written specification of OpenUSD functionality and compatibility.
NVIDIA Omniverse is presented as a set of libraries that use OpenUSD as the scene-data foundation and add rendering, physics simulation, sensors and validation tools. Its listed use cases are industrial facility digital twins, robot simulation and autonomous-vehicle simulation, with Siemens shown for industrial twins and Agility, Apptronik, Fourier and Unitree for robot learning. Where Omniverse sits in the robot development flow is summarized in NVIDIA’s three computers for robotics.
Building a robot-cell digital twin, step by step
- Inventory the data — record where building, equipment, robot and product data lives, its format and the owning team.
- Design the layers — split them by rate of change and ownership (for example: building, equipment layout, robot cells, simulation settings).
- Add physics — give robots and equipment mass, joints, collision shapes and sensors so they become simulation-ready assets.
- Connect robot simulation — test tasks and traffic in a simulator such as Isaac Sim.
- Keep it matched to reality — feed real layout changes back regularly, compare simulation results with measurements, and log the differences.
Skip the last step and the twin soon drifts from reality. Ways to narrow the gap between simulation and the real world are covered in Closing the Sim-to-Real gap.
Where a twin pays off first
Not every use of a digital twin needs the same fidelity. Layout and traffic studies — checking that a mobile robot can reach every station, or that a new cell does not block a fire exit — can start with simple geometry and approximate physics. Robot programming and collision checks inside a cell need accurate robot models and fixtures. Training perception or manipulation policies needs the highest fidelity: realistic materials, lighting and sensor models. Starting with the use case that needs the least fidelity lets a team deliver value early while the more detailed layers are built up over time, and the layered OpenUSD structure means that early work is reused rather than thrown away.