Draft REP 158: OpenUSD Conventions for Simulation Asset Interoperability in Open Source Robotics

ROS ROS Ideas
, , , ,
1

Dear ROS Community,

Following the REP-0001:2025 process, I am opening this public discussion thread for Draft REP 158: OpenUSD Conventions for Simulation Asset Interoperability in Open Source Robotics.

The goal of this REP is to define a standardized way to use OpenUSD (Universal Scene Description) so that simulation assets, such as environments and robots, can be built once and run across various simulation and visualization platforms.

I would love to hear your feedback, questions, and ideas on this proposal.

Quick Links

Related Extensions (Not core to this REP, but highly relevant):

Abstract

This REP defines a standard way to use OpenUSD so that simulation assets such as environments and robots can be built once and used anywhere. Our goal is to ensure a single 3D asset works seamlessly across different physics engines (like Gazebo, O3DE, Isaac Sim, Newton, MuJoCo, and Genesis), ROS runtimes, and web visualizers (like glTF). To make this a reality, the REP standardizes how ROS interfaces are represented in USD, establishes clear rules for format conversions, and sets up community registries for extensions and compliant assets.

Motivation

While URDF and SDF serve ROS well, OpenUSD has emerged as a broader industry standard vital for Physical AI workflows and artist-engineer collaboration. However, OpenUSD currently lacks standardized semantics for ROS concepts (e.g., TF trees), and its flexibility permits proprietary extensions that cause vendor lock-in. Rather than replacing existing formats, this REP regulates OpenUSD to prevent fragmentation, standardize ROS interfaces, and promote ecosystem interoperability.

Proposed Functionality

This REP establishes a vendor-neutral OpenUSD profile for robotics through four primary pillars:

  1. Standardized Asset Baseline: Mandates MKS units, ROS-standard coordinates (Z-up), and a modular Extract-Transform-Load (ETL) structure. This cleanly separates visual geometries from neutral physics, while strictly isolating any proprietary simulator extensions into discrete, optional layers.
  2. Declarative ROS Interface Schemas: Introduces engine-agnostic OpenUSD schemas (RosContextAPI, Topics, Services, Actions, and Frames). By declaring intent rather than baking in execution logic, these schemas standardize how simulators handle namespaces, sensor data, and TF tree generation.
  3. Export & Conversion Rules: Guarantees assets can seamlessly down-convert to lightweight formats like glTF 2.0 and URDF. It enforces standard PBR materials (UsdPreviewSurface), web-safe textures, and rigid rules for geometry, instancing, and variant baking.
  4. Ecosystem Tooling & Registries: Creates a canonical community registry for core schemas, plus extension pipelines for sensors, controls, and incubating physics features. It also introduces a native compliance checker to automatically validate and sanitize assets.

How to Participate

Joint the discussion, even if you are new to OpenUSD - this REP is also about interoperable simulation for ROS in general.

  • Does the proposed separation of visual geometries, neutral physics, and simulator-specific layers match your asset workflows?
  • Are the declarative schemas (RosContextAPI, Topics, etc.) flexible enough to map to your existing simulator interfaces?
  • Do you have any suggestions or concerns regarding the proposed export and down-conversion pathways to glTF or URDF?
  • Is this REP compatible with your simulator concepts?

I look forward to your feedback!

16 Likes
Improving Asset Import Workflow for External Models with Textures (FBX, glTF, GLB, USDZ, etc.)
2

This would be perfect, and it’s needed.

My concern is the asymmetry when something isn’t supported, at the visual level could be ignored safely, but at the physical level it may changes behavior. For example when an unsupported extension silently falls back to default, and when a baseline feature like concave mesh collision gets approximated (convex hull / primitive) by engines that for example can’t handle triangle meshes, and that quietly changing contacts. I am curious to know how does the REP expect a sim to signal what it dropped or approximated?

Also what makes this proposal worthwhile for me, is the bundling version usdz which already gives a single-file, drag-and-drop package: adopting it as the standard way to ship ROS sim assets (geometry, textures, physics params in one file) would be a big win for sharing and reproducibility. I’ve been doing something similar for Gazebo with gz-bundle (SDF world + assets in one self-running .sdfz).

1 Like
3

This is a quite elaborate proposal, I haven’t known at all it is being designed :open_mouth:

I haven’t worked with OpenUSD myself too much yet, I just remember that installing the OpenUSD library was not very straightforward because it doesn’t yet have Ubuntu packages (or maybe I just searched wrong).

Do you already have some conforming models to play with?

How would Blender import/export the conforming models? Is that possible? Or which other open tool do you suggest for editing/authoring?

How would asset DBs fit into this proposal? I see that you suggest using the package:// scheme, but what about model DBs like Gazebo Fuel or Omniverse? Would it be possible to compose models that reference assets from these?

How (un)easy it is to programatically create/edit/template USDZ files? I guess it’s just a ZIP with a few text and binary files?

We often have some kind of parametrization of our robots (locations of cameras, antennas etc.). I don’t think it fits the variants concept because the locations are the result of calibration, so the variable thing is not a boolean/set value, but a float. Would the proposed standard support this kind of calibration data entry? Or would we need to keep something similar to our existing Xacro templates to generate the properly calibrated model?

1 Like
4

I will answer first batch of feedback soon, thank you for engagement, @peci1 and @khalidbourr!

5

Hello,

Thank you for this significant step forward in adopting OpenUSD as a standard robotics format. Establishing a common baseline that works seamlessly across different simulators and physics backends is crucial, and this REP provides an excellent and well-detailed foundation for the community !

I do have one architectural question regarding the tight coupling of this REP to ROS specifically.

Is the ultimate intent of this REP to serve strictly as a standard for the ROS ecosystem, or as a general standard for robotics OpenUSD assets?

If the goal is broader robotics interoperability, hardcoding ROS-specific terminology (e.g., RosContextAPI, RosTopicAPI) into the core OpenUSD schema might limit future flexibility. OpenUSD’s core philosophy is engine and ecosystem-agnostic. By tightly coupling the schema to ROS terminology, the assets become less portable to other middleware frameworks (e.g., pure DDS, Zenoh, MQTT, or even custom one).

Instead of directly defining a ROS API, would it be better to consider defining a more abstract layer such as a TransportAPI or MiddlewareAPI (to avoid confusion) for instance ?

In this paradigm, the USD asset declaratively describes what data it produces or consumes, and the simulator’s bridge acts as an adapter, implementing the transport. For example, instead of RosContextAPI, we could define a framework-agnostic MiddlewareContextAPI with generic fields:

  • string middleware:context:namespace
  • int middleware:context:network_domain (which ROS would map to ROS_DOMAIN_ID)
  • token middleware:context:protocol

This approach allows an asset to remain perfectly compliant with the REP while staying fully framework-agnostic.

Are the declarative schemas (RosContextAPI, Topics, etc.) flexible enough to map to your existing simulator interfaces?

Yes, if this REP is strictly intended to be a ROS standard. However, if the vision is a universal robotics standard, I believe we need a more abstract middleware layer that can be implemented by different frameworks without requiring modifications to the underlying USD asset.

Thank you again for all the hard work on this draft!

Cheers,

Esteban

1 Like
6

Summary of a recent working call on physics schemas in REP 158

To keep the conversation open, I want to share a recap of a recent call touching on this REP. It brought together contributors working across OpenUSD/AOUSD, Isaac Sim, Newton, and several robotics and simulation groups (NVIDIA, Disney Research, Google DeepMind, Lightwheel, and Robotec.AI). This is my own summary, so I’d welcome corrections or added context from others who were on it.

The core ROS interface work (RosContextAPI and the related schemas) wasn’t contentious. Most of the time went to a narrower but genuinely open question: how should the REP’s incubating ext_physics extension relate to the existing Newton USD schemas? It also connects to the point @khalidbourr raised earlier about how an engine signals when a feature has been approximated or dropped.

Some framing, because both directions have real merit:

  • The Newton USD schemas move quickly and already capture well-considered solutions to gaps in upstream OpenUSD. Several are written with the explicit intent of being upstreamed, and the newton prefix is largely a practical necessity (a namespace is required) rather than a claim of ownership. Newton also works well as a multi-solver proving ground for deciding whether an attribute is actually general.
  • At the same time, an asset-level schema meant to be consumed by many engines benefits from a neutral name, since an engine-specific prefix on general physics attributes can be confusing in a cross-engine pipeline. ext_physics is an attempt at that neutrality, with the Newton origin of the adapted attributes attributed in the PR. It is explicitly a candidate space, intended to converge into an official physics namespace if and when AOUSD standardizes it.

So the real tension isn’t “Newton vs. ext_physics”. It’s that we don’t yet have a clean way to distinguish, within a shared namespace, what is genuinely engine-specific from what is intended to become a general standard.

Where there seemed to be consensus:

  • General, physics-level parameters (e.g. friction) belong in a neutral, shared schema; clearly solver-specific parameters (Kamino, XPBD, hydroelastic, and similar) should stay under solver-specific names.
  • An engine shouldn’t be required to support parts of a schema it can’t represent. Trivial, well-defined conversions (e.g. period vs. frequency) are fine; what we want to avoid is needing one-to-one vendor translation purely because of namespacing.
  • There’s genuine respect for the deliberateness of the AOUSD process. The interest is in a faster experimental track that still feeds into AOUSD, not in working around it.

Open questions:

  • Classifying individual attributes as “general” vs. “engine-specific” is harder than it looks. Even within the current schemas there are items that could reasonably go either way (for example, a convex-hull vertex limit on mesh collision), and reasonable people will land differently case by case. This is also where @khalidbourr’s concern about silent approximation gets concrete.
  • We don’t yet have an agreed source-of-truth, sync, or conflict-resolution process between the REP’s extensions and the upstream schemas as both evolve.

One idea raised as a possible path forward: rather than inventing an intermediate namespace that might later need renaming, pursue an official AOUSD “landing spot” for schemas-as-proposed - something citable and implementable before a formal release (loosely analogous to referencing and implementing a Python PEP while it’s still in proposal form). A concrete first step could be co-authoring the already closely-aligned mimic schema as a joint proposal, so we converge on one shared implementation rather than parallel forks.

Feedback very welcome, especially from those closer to AOUSD and Newton who can correct or sharpen any of this. The shared goal is a single neutral home for general physics attributes so robotics assets don’t need vendor-to-vendor translation.

2 Likes
7

Welcome to the USD deep end @peci1. These are good questions, and a few touch on things USD handles better than its reputation suggests. Taking them in turn:

Installing / packaging. The “no Ubuntu packages” impression is a bit out of date — pip install usd-core gets you the core libraries and Python bindings on Linux today, and USD also ships inside many DCCs. You don’t need a from-source build to start authoring and validating conforming assets. If you want to build from source though, I work on Ubuntu daily and a build from source works fine for me. If you want precompiled non-python binaries (i.e. not the pypi wheel), there are a few options too, one of which I maintain (NVIDIA’s Apache 2.0 licensed usd-exchange has a usd-minimal flavor which is python free).

Authoring tools / Blender. Blender has native USD import and export, so it’s a reasonable on-ramp. The honest caveat is that round-tripping a specific profile like this REP’s (units, axis, the ETL layer split) depends on how faithfully a tool preserves those conventions — a tooling-maturity question, not a USD limitation. A compliance checker (the REP’s pillar 4) is the right backstop: author wherever you like, then validate against the profile.

Asset DBs (Fuel / Omniverse) and composition. This is where USD shines. Composition — references, payloads, sublayers — is the core mechanism, and asset resolution is pluggable via USD’s Asset Resolver. So yes: you can compose a model that references assets in different databases, and a resolver maps logical asset paths (package://, a Fuel URL, an Omniverse path) to physical locations. Payloads in particular let you compose references to heavy assets without pulling their full contents until needed — very useful for large scenes assembled from multiple sources.

usdz / programmatic editing. A usdz is a (constrained, uncompressed-alignment) zip package, so under the hood it’s an archive — but the right mental model is that you don’t hand-edit the archive. You author with the USD API (Python/C++) or by composition, then package to usdz as a distribution step. Templating/generation happens at the USD layer, not by zip surgery.

Calibration data (your sharpest question). Your instinct is correct: variants are the wrong tool for continuous calibration values like a measured camera or antenna offset — variants model discrete, switchable options, not a calibrated float. The idiomatic USD answer is layered composition rather than template regeneration: author the nominal robot once, then carry per-unit calibration as a thin override layer (a stronger sublayer or session-style layer) holding just the calibrated opinions for that unit. Composition resolves the stronger opinion over the base model non-destructively — so instead of Xacro-style “regenerate the whole model with substituted values,” you keep one canonical asset and stack a small per-robot calibration layer on top. Closer to how calibration actually flows (a delta against nominal), and far less brittle.

On the broader REP: the ETL layering is the right backbone; neutral physics separated from visual geometry, simulator-specific parameters isolated behind explicit prefixed layers, and the down-conversion guarantees (URDF, glTF 2.0 with UsdPreviewSurface) are what make “author once, run anywhere” real rather than aspirational.

I would also note the OpenPBR specification is a higher fidelity option for visual materials. Since USD allows multiple render contexts on the same material, it might be nice to allow OpenPBR (via MaterialX) surface shaders alongside UsdPreviewSurface shaders. Then each converter to another format can opt for the visual fidelity that works best for that target format. I suspect OpenPBR to glTF could get a more faithful visual match than UsdPreviewSurface provides.

Happy to go deeper on any of the composition mechanics if useful.

1 Like
8

Thanks @Renato_Gasoto for a good meeting recap. I’ll add some thoughts here from the Newton & AOUSD Physics perspective, as I participate in both of those working groups. Since the extended-physics schemas are a sidecar to the REP rather than core, I’ll try to keep this as succinct as I can.

One thing worth making explicit, since it’s the crux: why a namespace is required, and therefore why the prefix isn’t cosmetic. In USD, an applied schema’s attributes all share one flat property namespace on the prim. The prefix (physics:, newton:, ros:) is what prevents collisions, tells an engine which contract an attribute belongs to, and records provenance: who owns the meaning. You aren’t allowed to author a schema without one, so the only question is which — and the prefix is a claim about authority, whether you intend it or not.

So my concern with ext_physics: is that it reads as a neutral, USD-standards-level space, but neutrality at that level is something only AOUSD can confer. These are explicitly AOUSD-candidate attributes from the OSRF perspective, which have already diverged slightly from the newton upstream. The honest options are to name the source (newton:), to claim a new ownership namespace (e.g. osrf:), or to wait & land them in AOUSD as official proposals to UsdPhysics, so a neutral physics: (or ext_physics: or prelim_physics:) is earned, not assumed.

The same rule answers @Z3ZEL: RosContextAPI should stay ros:-prefixed, because those are genuinely ROS-domain contracts and ROS is their source of truth. That’s honest, not a portability limit. Generalizing them into a neutral MiddlewareAPI now is the opposite error: a lowest-common-denominator abstraction before any cross-middleware standard exists to back it. The rule is identical both ways, a prefix should name the authority that actually owns the concept.

So a path that’s consistent for everyone: keep ROS interfaces ros:-prefixed; co-author the physics attributes into an AOUSD landing spot (mimic is a natural first proposal) so they converge on a ratified physics:. And if OSRF wants an incubation space before then, name it osrf: (the same honesty as newton: and ros:).

PS. I do think this namespace argument should extend to the CLI tools as well. I’d recommend renaming usd-check to usd-check-osrf (or osrf-usd-check), so it doesn’t get conflated with OpenUSD’s usdchecker CLI or some other org’s validation tooling (several others exist today).

2 Likes
ROS News for the Week of June 22nd, 2026
9

I am bit confused about the difference between OpenUSD and AOUSD, is it a language with same syntax but different semantics, or smth else ?

10

Happy to see the discussion here!
@khalidbourr AOUSD is the governing organization behind OpenUSD (the standard / format).
ext_physics points are valid - I will follow the AOUSD recommendation here of course - please not the Extended Physics PR is an extension to the core (this REP) - I submitted it for completeness but I believe it to a natural step after the core is agreed upon and not a blocker on the core acceptance - if we all agree it is largely independent. I would also love your suggestions on how to improve fidelity degradation handling - the REP intention is to make degradation less painful, but perhaps we can further improve it?

@Z3ZEL these are good points, and the REP does outline ETL pipeline in a way where ROS interfaces are separated out (isolated) - and thus alternative schemas for middleware can be used without a problem. However, I find it problematic to think about a universal middleware layer abstraction - since approaches vary so much.

Is this REP strictly intended to be a ROS standard? Only Chapter 2 is strictly ROS, the other are generic - and chapter 2 doesn’t mandate ROS use: it only tell HOW to include ROS in the asset. So another communication layer can easily build on top of the REP.

@peci1 good question about conforming models. We intend to provide several to start with. The pathway is initial submission (auto-checked for complance), and community contribution of engine-specific optimizations / tweaks (small and leafy). The compliance checker is there (in a
PR) to guide such asset creation.

Let me think more about the remaining questions next week - I am travelling this week.