[Feature Request] API to set the simulation-time origin (start time / offset)

[camopel]

Summary

Isaac Sim's simulation time is hardcoded to begin at 0.0, and there is no supported API to set a start time or apply an offset. For ROS 2 users this means /clock and every sensor message stamp begin at the Unix epoch (1970), so recorded rosbags carry timestamps that cannot be correlated with real-world events or external logs.

Use case

We run a standalone Isaac Sim application publishing ROS 2 sensor data (/clock, joint states, IMU, lidar, GNSS, cameras) to downstream nodes running with use_sim_time=true, and record it to rosbag for later analysis. Because simulated recordings start in 1970 while everything else we compare them against carries true wall-clock time:

• Timestamps cannot be lined up with external logs or test-run records.
• Tooling that assumes epoch-realistic time (dashboards, time-range queries, side-by-side bag comparison) cannot correlate the two sources.
• A bag's own file metadata (recorded in system time) disagrees with the message stamps inside it.

Real wall-clock stamps (useSystemTime) are not a substitute: those stop agreeing with /clock whenever real-time factor != 1, which breaks every use_sim_time consumer. What is missing is the ability for the existing coherent simulation timebase to simply start at a chosen epoch.

Why this is not achievable today

1. Simulation time is derived from a PhysX-owned step counter with no setter.

PluginInterface.cpp:696-698:

uint64_t stepCount = g_physicsSimulationInterface->getSimulationStepCount(context.simulationId);
g_simulationTime = static_cast<double>(stepCount) / static_cast<double>(stepsPerSecond);

getSimulationStepCount is the only accessor; there is no corresponding setter.

2. ISimulationManager exposes no offset or start-time control.

All time-related Python bindings are read-only (get_simulation_time, get_simulation_time_monotonic, get_simulation_time_at_time, get_current_time). The only mutators are reset, set_callback_iter, and the notice-handler toggles. resetOnStop=False yields monotonic-across-restart time, but still starting from zero.

3. Zero is re-applied unconditionally at several lifecycle points.

g_simulationTime = 0 appears in onStop, onAttach, plugin initialisation, and the reset path, so the origin is cleared on every stage attach or stop.

4. IsaacReadSimulationTime's referenceTimeNumerator / referenceTimeDenominator inputs are not an offset.

They act as a rational-time lookup key into TimeSampleStorage (getSimulationTimeAtTime) for multi-tick render alignment.

5. The clock is wired independently into each sensor and ROS OGN node, so there is no single place where an origin could take effect.

Simulation time reaches ROS as a timeStamp input consumed separately by each publisher — ROS2PublishClock, ROS2PublishJointState, ROS2PublishImu, ROS2PublishTransformTree, ROS2PublishImage, ROS2PublishCameraInfo, and any additional application-side publishers. Each is a distinct graph connection to IsaacReadSimulationTime. Since correctness requires that /clock and all sensor stamps share exactly one timebase, an origin has to hold across every one of those connections simultaneously — a value applying to some publishers but not others places one topic ~56 years from the rest, causing TF extrapolation failures and message_filters synchronisation that never fires.

6. The camera path is handled specially and does not go through the application's graph at all.

Camera publishing is driven by the SDG / Replicator writer registry rather than user-authored action-graph nodes. At writer-attach time, isaacsim.ros2.nodes/python/impl/extension.py:207 hardwires its own time source into the connection template, per render product:

SyntheticData.NodeConnectionTemplate(f"IsaacReadS{time_type[0]}",
    attributes_mapping={f"outputs:s{time_type[0]}": "inputs:timeStamp"})

This time node is created internally by the extension, is separate from the one in the user's graph, and is not exposed as a configuration point. Camera stamps and the latched CameraInfo therefore originate from a time source structurally outside the reach of anything an application can configure — which is why the origin needs to be a platform-level concept rather than a per-graph one.

Request

A supported way to set the simulation-time origin, applied centrally within Isaac Sim so that every consumer of simulation time — the OGN ROS publishers and the SDG camera / CameraInfo path alike — inherits the same origin automatically, keeping /clock and all sensor stamps coherent by construction. Ideally settable before play(), preserved across attach/stop/reset, readable back for reproducible replay, and defaulting to the current zero-based behaviour so existing setups are unaffected.

Version: Isaac Sim 6.0.1 (Kit 110)

[zwdoescode]

Thanks for the write-up — the source references made this straightforward to check, and I want to confirm up front that all six of your technical points are accurate on 6.0.1. Specifically:

• PluginInterface.cpp:696-698 derives simulation time from the PhysX step count, and getSimulationStepCount has no setter.
• ISimulationManager's only mutators are reset, setCallbackIter and the two notice handler toggles; all eight time accessors are read-only.
• g_simulationTime = 0 is applied unconditionally at :775 (onStop), :795 (onAttach) and :870-871 (reset/init).
• referenceTimeNumerator/Denominator are a RationalTime lookup key into getSimulationTimeAtTime, not an offset.
• The camera path does bake its own time node into the writer registration, inside /Render/PostProcess/SDGPipeline.

I also measured what happens if an application tries to close the gap itself, because your point 5/6 argument is the crux of the request. I published /clock from an action graph and /camera_info through the SDG writer path, then read the actual stamps over ROS 2:

setup	/clock	/camera_info	gap
stock	0.083	0.083	0.017 s (coherent, in 1970)
offset the action graph only	1786968000.083	0.083	~56.6 years

So your concern is valid — a partial offset is strictly worse than the 1970 baseline, and it fails exactly the way you predicted.

I went one step further and tried to reach the SDG path. The writer registry is patchable: rewriting the time template in WriterRegistry._writer_init_params successfully repointed 19 ROS 2 writers, and the offset node really is created in the pipeline. What blocks it is type resolution — SyntheticData._activate_node_rec applies a template's static attributes at node-activation time, before OmniGraph resolves the union type of omni.graph.nodes.Add.inputs:b, so the attach fails with "Tried to get the value from an unresolved attribute", and CameraInfo stops publishing entirely. Setting it later does not work either; the attribute is still an unresolved TfToken well into playback. Closing that half would require a custom OGN node with concrete-typed attributes in a custom extension — per application, for something every ROS 2 user needs.

I am filing this internally as a feature request with the analysis attached.

In the meantime, my suggestion is to not offset inside the graph. Record as-is and apply a single uniform offset downstream, rewriting both the bag's receive timestamps and the in-message header stamps. That keeps /clock and every sensor stamp on one timebase, which is the property that actually matters for your use_sim_time consumers.

Internal ticket: IREQ-472