Skip to content

Added sim clock rules #18

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ayushgnv wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Added sim clock rules #18

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
8f2abc5
Added sim clock rules
ayushgnv Apr 1, 2026
1cde274
Added some small feedback suggestions
ayushgnv Apr 2, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions rep.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -234,6 +234,13 @@ Note: The broadcast frequency of TF frames is an implementation detail left to t
### 2.8 Optical Frames
OpenUSD cameras natively face the -Z axis, whereas ROS optical frames (REP 103) must face +Z. To bridge this without opaque simulator-side rotations, authors must decouple the physical sensor from its optical interface. Authors must create a child UsdGeomXform (e.g., `camera_optical_frame`) rotated 180 degrees around its local X-axis. All RosTopicAPI and RosFrameAPI schemas must be applied exclusively to this optical frame, ensuring deterministic data orientation in RViz.

### 2.9 Simulation Clock
Copy link
Copy Markdown
Member

@adamdbrw adamdbrw Apr 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)"

Copy link
Copy Markdown
Member

@adamdbrw adamdbrw Apr 2, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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).

Copy link
Copy Markdown
Author

@ayushgnv ayushgnv Apr 2, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?


ROS nodes synchronize with simulation time by subscribing to `/clock` and setting `use_sim_time = true`. To ensure all ROS consumers (RViz, Nav2, sensor processors) agree on a common simulation timeline:

* The clock is a simulator-level concern. Asset USD files must not contain any prim that publishes to absolute `/clock` topic, as doing so would produce duplicate or conflicting clock sources when multiple assets are composed.
* Compliant simulators must publish simulation time on the absolute `/clock` topic `rosgraph_msgs/msg/Clock` from the moment simulation begins playing until it is stopped.

---

## 3. Export and Conversion
Expand Down