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!

18 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.

2 Likes
11

Thank you for this contribution. I’d love to suggest some ideas for addressing the fidelity degradation, but first I’d like to take the time to fully understand both the core framework and the extension.

1 Like
12

Thanks for this REP, I think that this is very important! I have many questions though.

A canonical repository of open-source, compliant simulation assets is to be established as ros-simulation/openusd-assets. These assets will have payloads hosted independently (e.g. in a dedicated repository such as Hugging Face) and must pass the Compliance Checker.

This is interesting to me. Are robot OEMs encouraged to upload assets there? Is the intention to have these assets distributed to places like the NVIDIA asset library directly from the repo? Or is this just another place to put the same assets? Which payloads would be hosted independently? Mesh data only? What is the reason for having payloads hosted independently?

I also wonder how closely this REP aligns with NVIDIA’s authoring guidelines (which are linked in the REP). I know that NVIDIA employees helped with this REP, but would something following this REP automatically be following guidelines for the NVIDIA asset library, you would just need to pick and choose which layers/payloads to use?

This question may not have a straight answer, but for robot OEMs, would the expectation be that we would run our URDFs through the asset importer and do it that way? Or would we export directly from whatever CAD software to USD and make tweaks afterwards?

Regarding asset importers (I am particularly interested in the URDF asset importer myself)

  • Will the asset importers automatically create the ETL pipeline/different layers? Or will that mostly be done manually?
  • Will asset importers do “extended physics” changes that aren’t natively supported by OpenUSD?
  • Will asset importers automatically change from Euler angles to quaternion?

I guess my real questions is “where does the responsibility of the asset importers end”

My assumption is that a typical 6-axis robot is a “component”. But if a robot has sensors natively built in (cameras, force torque, etc) is that considered to be a “component” or an “assembly”?

Joints that close a kinematic loop (e.g., parallel linkages, four-bar mechanisms) must set physics:excludeFromArticulation = true.

In the case of say a 4 bar mechanism, would just one joint be excluded? How do we know which (passive) joint should be excluded? Or is it arbitrary?

glTF 2.0 is heavily referenced here, but as I mentioned in ROS2 URDF Mesh File Types , is still not standard for URDF (the asset importer doesn’t even support it right now). I like glTF 2.0, and I don’t think that this is a massive problem as it is supported in many ROS 2 workflows, but I just wanted to point it out

Is there a standard for link frames? Specifically, it seems that there are 2 common ways in the ROS 2 world of handling link frames/TF. One has all TFs aligned in the same orientation as the world frame. The other one has the TF based on the DH parameters. Are both of these acceptable?

@peci1 already mentioned this, but it would be good if there were some conforming models that we could look at as reference. Ideally some of these conforming models would include non-standard serial manipulator features, like backlinks, balancers, or mimic joints.

I realize that blender was already recommended, but is there a gold-standard USD editor that won’t have any sort of vendor-specific changes? I know about usdview, but would the typical workflow just be text editing + usdview or what?

1 Like
13

This question may not have a straight answer, but for robot OEMs, would the expectation be that we would run our URDFs through the asset importer and do it that way? Or would we export directly from whatever CAD software to USD and make tweaks afterwards?

@adamdbrw Another question that is sort of implicit to this, but what is the level of mesh granularity that we should target? Is it better to bake the meshes per-link before converting to USD so there are only ~7 meshes (one per link) per USD for a serial manipulator? Or should the USD be more like an assembly, including screws, subcomponents, castings, etc. as different mesh prims under the link? Or is that dependent on whether it is mesh_high? If it is dependent on low/medium/high variants, that may be tedious to maintain, having multiple trees with different structure rather than just different meshes referenced.

1 Like
14

From a perfromance perspective, it is preferrable to combine the meshes to the smallest possible set. But I don’t think there’s a one size fits all guidance.

1 Like
15

I am working on all the feedback together with @zakmat - will post on Monday. This is an excellent discussion, thank you all!

16

Thank you for your great feedback and valuable suggestions. Here is how I address them:

Namespace authority & AOUSD (@akaufman, @Renato_Gasoto, @Z3ZEL):

We will maintain and govern ros: namespace (the new schema). However, to prevent fragmentation, following your suggestions I am dropping the ext_physics layer. We follow AOUSD co-authoring and extension namespaces will reside in vendor layer until adopted. I dropped the extended physics (changed to a draft) and noted the decision in the PR. Also, the REP itself now addresses it through a new PR by @zakmat.

Fidelity, approximations (@khalidbourr, @jimmy-mcelwain)

The concern for silent drops is important and addressed in PR to the REP, submitted by @zakmat.

Great questions from @jimmy-mcelwain:

OEMs are definitely encouraged to contribute - these would be first really interoperable simulation assets, real enablers for working with their products. A functional catalogue can have any number of self-hosted forks, front-end integrations, etc. I picture it can be queried and pulled by open and closed source workloads, human or agentic. Payloads in the registry should be outside, as binary assets (meshes, textures) get heavy and are not suitable for git. We suggested Hugging Face hosting, but this is to be determined with governance. Git hosts only the relatively lightweight logic/kinematics.

  • The REP is meant to be compatible with SimReady NVIDIA guidelines. it introduces new constraints such as isolation of vendor specific attributes to their layers. I believe OSRA and NVIDIA continue to share a common interest in making this seamless.

  • Importers are expected to comprehensively handle declarative parts, structure (layers, hierarchy), and conversions to be REP-compliant. Note that URDFs do not have full sim-ready information in, and at times have behaviors specified as non-standard not-interoperable plugins (e.g. Gazebo ones), so there needs to be some work in filling in the missing information. Only runtime logic is a simulator’s concern. Upstream CAD to USD works, with REP you use layering to add/overlay physics/ROS properties.

  • The exclusion of the articulation should be on the final passive joint closing the loop.

  • Both common ways are compatible with REP. Simulators natively resolve the relative coordinate offsets to publish correct /tf.

  • Compliance checker is out there as a PR (linked in the top post here), reference assets are coming. @Renato_Gasoto I recall we also discussed your team possibly contributing such assets as well, correct? Would be nice to follow the suggestion and have some challenging non-standard features in for at least a couple of assets.

  • I don’t think there is a gold-standard USD editor for right now, but REP adoption would cause any vendor-specific items to land in their own, minimized and isolated layer (if any is needed – see 1.4), making it much less work to add alternatives for the layer, while keeping the entire interoperable bulk.

  • Mesh granularity is handled through 1.3.2 and 3.5 - you can go with baked simplified/ decimated for low/medium and detailed but instance-able (leaves) for high. Apply visual_representation VariantSet strictly on the visual leaf.

PR with suggestion thanks to @zakmat: Address REP-158 peer review by zakmat · Pull Request #30 · openrobotics/reps · GitHub

Compliance checker will be updated with feedback as we continue the discussion.

I would also love to discuss governance. The new Simulation Tools In ROS · GitHub GitHub space has grown considerably, and I would love to ensure we can maintain and advance it further. I imagine a dedicated, new WG for Simulation Interoperability would be great: taking care of the simulation interfaces, this REP and its assets, and selected importers and bridges (not governed otherwise). Thoughts are welcome.

This is valuable, lets keep the discussion going.

1 Like