Added sim clock rules

[ayushgnv]

Added section describing not to apply clock topic api in robot assets in USD.

[asluk]

Review: USD Best Practices Alignment

This is a clean, well-scoped addition that addresses a real composition hazard. The core rule (clock is a simulator concern, not an asset concern) is sound and aligns well with USD's philosophy of separating structure from execution. The suggestions below are refinements, not blockers.

---

Alignment highlights

• Separation of asset vs. runtime concerns — strongly aligned with the Asset Structure Principles emphasis that assets describe structure and intent, not execution behavior. Analogous to the REP's own Section 1.2.5 prohibition on vendor-specific prefabs and runtime composition hacks.
• Composition safety — if every asset carried a clock publisher, composing a multi-robot stage would create N conflicting sources with no clean way to prune them via opinions or deactivation. This correctly identifies and prevents that hazard.

---

Suggestions

1. Clarify absolute topic semantics. The /clock topic is absolute and must not be subject to ros:context:namespace concatenation (Sections 2.1/2.1.1). Consider a parenthetical to make this explicit, e.g.: "...on the absolute /clock topic (this name is not subject to ros:context:namespace concatenation, as it is a stage-global singleton)..." This prevents a future reader from wondering whether it should be namespaced.

2. QoS recommendation. Consider adding a brief QoS note: "Simulators should publish /clock with reliable reliability and transient_local durability to ensure late-joining nodes receive the most recent timestamp." This is standard ROS practice, and the REP already defines QoS attributes in Section 2.4 — leaving it unspecified for the most timing-critical system topic is a gap.

3. RFC 2119 keyword consistency. The second bullet says simulators "must publish... until it is stopped." Consider also specifying paused state behavior: "must publish... and should cease publishing when simulation is paused or reset" to avoid ambiguity about stale timestamps.

4. Minor wording broadening. "Asset USD files must not contain a RosTopicAPI prim that publishes to /clock" — consider "...must not contain any prim that publishes to /clock" in case future schema types could also publish topics.

---

Review performed against the NVIDIA Asset Structure Principles and the existing composition/namespace rules in this REP.

[adamdbrw]

This is a good idea and I would like to bring it further. How about we state it in a manner that also includes simulation interfaces? Perhaps "2.9 Prohibited interfaces"?

I would also like to keep it concise. How about this phrasing?
"Simulator-level interfaces are prohibited in assets to avoid clashes, including:

• /clock topic for simulation time.
• Any interfaces included in the simulation_interfaces package (e.g. spawning, simulation control)"

[adamdbrw]

@asluk just noticed your review as well. I propose this concise phrasing and generalizing to "prohibited interfaces". One could further specify this to include per-node generated ROS interfaces (e.g. parameter services), but I believe that would be slightly too defensive.

Your suggestions about the clock topic are correct, however I would keep specification on how clock should be published out of scope of the REP (just that it's not assets purview).

[ayushgnv]

@adamdbrw I agree with your phrasing on prohibited interfaces.
I am wondering if its generally safe or good practice to directly list the exact packages that we prohibit in standard such as this? In case the package behaviour changes in the future? Should we leave the package name out of it? (Although one could argue that simulator specific unqiue interfaces should not be prohibited, so mentioning a standardized package like simulation_interefaces could be okay).

Which leads to my next question, I dont think theres a statement anywhere that says that interfaces can be defined within the USD asset, but if the simulator doesnt support it, the interface can simply be ignored with an optional warning? @adamdbrw thoughts on whether this needs to be added to the rep as well?