4.5.0
4.2.0
4.1.0
4.0.0
4.5.0
2023.1.1
2023.1.0-hotfix.1
Other (please specify):
Operating System
Ubuntu 22.04
Ubuntu 20.04
Windows 11
Windows 10
Other (please specify):
GPU Information
Model: A40-48Q
Driver Version: 550.127.05
Topic Description
Detailed Description
I am figuring out how timestamps are set when I use the ROS2CamerHelper node in order to publish images via ROS. I use exactly the setup from the tutorial: ROS2 Cameras — Isaac Sim Documentation
The generated message timestamps are confusing, they don’t seem to reflect what I consider the acutal simulation time.
Steps to Reproduce
Set up a stage like in the tutorial using the graph shortcut.
Make sure the stage’s time codes per second is set to the default 60.
Start the simulation.
Use a terminal with sourced ROS environment and display timestamps like this: ros2 topic echo /rgb|grep sec
Note that timestamps increase by about 1/60 seconds for each message
While pausing the simulation, modify the SDGPipeline graph and print the output of the “Isaac Read Simulation Time” node.
Note that the “Isaac Read Simulation Time” node output seems to represent the frequency set in the physics scene, not the frequency set in the stage’s time codes per second.
Note that the timestamps created in the ROS messages do not reflect the time stepping of the simulation timeline.
hi @bruno.vetter, are you trying to control the timestamp on the ROS messages? The Read Simulation Time node can be useful for checking if there is any discrepancy between the published and simulation timestamp. Is that helpful?
Hello @rchadha, thanks for your suggestion. I modified the SDGPipeline graph to print the output from the “Read Simulation Time” node (printed with info loglevel) next to the simulation time taken from the “Get main timeline” node (printed with warning loglevel).
I have set the USD stage timecodes per second set to 50, while the physics steps per second is not being set, so it should be 60 by default.
Note how the output of the simulation time from the main timeline differs from the output of “Read Simulation Time”.
The main timeline steps are 0.02s as expected, but the weird stepping of “Read simulation time” is what I see in the published ROS messages.
you are correct in noting that IsaacReadSimulationTime node is based on Physics time. This is because the node grabs time from a physics callback. Physics is not guaranteed to run at the same rate as the simulation timeline.
Method A: Aims to set the simulation timeline run rate (Affects time from the OnPlayBackTick node)
Method B: Aims to set physics run rate (Affects time from the IsaacReadSimulationTime node)
Combining both aligns both the outputs from OnPlaybackTick node and IsaacReadSimulationTime (they may be offset by one frame time difference which is expected).
# Change the carb settings. This is not persistent between when stopping and replaying
import omni
import carb
physics_rate = 50 # fps
carb_settings = carb.settings.get_settings()
carb.settings.get_settings().set_bool("/app/runLoops/main/rateLimitEnabled", True)
carb.settings.get_settings().set_int("/app/runLoops/main/rateLimitFrequency", int(physics_rate))
carb.settings.get_settings().set_int("/persistent/simulation/minFrameRate", int(physics_rate))
timeline = omni.timeline.get_timeline_interface()
stage = omni.usd.get_context().get_stage()
timeline.stop()
stage.SetTimeCodesPerSecond(physics_rate)
timeline.set_target_framerate(physics_rate)
timeline.play()
I think I can deal with that. Except the fact that right now I cannot set an arbitrary simulation start time. As the “simulation time” is used as timestamp for published ROS messages and I do not want the ROS timestamps to start with 0, but with a predefined unix time instead.
Is there a reason why the SDG pipelines are set up in this way, using the physics callback and not using the time from the simulation timeline? The reason why this confuses me is that Physics are not necessarily part of a simulation. Our current simulation is animation-driven and does not use any Physx.
Hi @bruno.vetter! There is no particular reason for how the simulation time is set up right now. We are currently working on the feature of using custom time in the ROS2 camera helper node. Please stay tuned!
