RTX Lidar 'get_current_frame()' returns data at inconsistent intervals despite render_dt and scan rate alignment

[aidan073]

I'm encountering a strange issue where 'LidarRtx._current_frame' is not receiving data at the expected rate.

I drive physics and rendering manually. The RTX lidar is set to a 20 Hz scan and I render at 60 Hz, so I expect IsaacCreateRTXLidarScanBuffer to contain a populated point cloud every 3rd render() (20 Hz). Instead, when I poll the buffer at 20 Hz it often reads empty due to desync observable when comparing the current render tick (# of times I've called world.render()) and the recorded render tick numerator in LidarRtx._current_frame.

System

• Isaac Sim 5.1.0, standalone
• Ubuntu Linux on GCP
• GPU RTX Pro 6000 Blackwell, driver 580.65.06
• enable_motion_bvh=True

Sim settings

• physics_rate = 120 Hz, rendering_rate = 60 Hz

Stepping loop

I run physics/rendering as follows, causing world.render() to be called after exactly every 2 world.step() calls under current settings.

def _advance(world, lifecycle, do_render):
    world.step(render=False)
    lifecycle.update_physics(world.get_physics_dt())
    if do_render:
        world.render()
        lifecycle.update_render(world.get_rendering_dt())   # LidarRtx.get_current_frame() in here

Lidar setup

self._lidar = LidarRtx(prim_path=lidar_prim_path)
self._lidar.initialize()
self._lidar.attach_annotator(
    "IsaacCreateRTXLidarScanBuffer",
    outputTimestamp=True,
    outputIntensity=True,
)

• scanType = ROTARY, scanRateBaseHz = 20
• 450 ticks/rev → reportRateBaseHz = 9000
• 128 channels, single return

At 60 Hz render and 20 Hz rotation, a full revolution accumulates over 3 rendered frames, so I expect a populated buffer every 3rd render().

Symptom

Columns: my count of world.render() calls, the rendering_frame numerator (referenceTimeNumerator from /Render/PostProcess/SDGPipeline/PostProcessDispatcher, stored inside LidarRtx._current_frame), its per-render delta, and whether the buffer had points. Logged on every render().

render() call | rendering_frame num | Δnum | buffer has points?
--------------+---------------------+------+-------------------
       9      |         54          |   –  |  yes
      10      |         55          |  +1  |  no
      11      |         56          |  +1  |  no
      12      |         57          |  +1  |  yes
      13      |         58          |  +1  |  no
      14      |         60          |  +2  |  yes
      15      |         60          |   0  |  yes

Longer window from the same run:

render() call | rendering_frame num | Δnum | buffer has points?
--------------+---------------------+------+-------------------
      84      |        129          |   –  |  yes
      85      |        130          |  +1  |  no
      86      |        132          |  +2  |  yes
      87      |        132          |   0  |  yes
      88      |        133          |  +1  |  no
      89      |        134          |  +1  |  no
      90      |        135          |  +1  |  yes
      91      |        136          |  +1  |  no
      92      |        138          |  +2  |  yes
      93      |        138          |   0  |  yes
      94      |        139          |  +1  |  no
      95      |        140          |  +1  |  no
      96      |        141          |  +1  |  yes
      97      |        142          |  +1  |  no
      98      |        144          |  +2  |  yes
      99      |        144          |   0  |  yes

The LidarRtx contains data after the rendering_frame numerator has incremented by 3, but it does not increment in a consistent or aligned manner with world.render() calls.

Questions

1. Is this desync between world.render() calls and the data acquisition expected or a known bug, or is there something I'm lacking/misusing in my setup?

2. Any recommendation on what I should do to minimize this desync if it is unavoidable?

Happy to provide more information if needed, thank you.

[aidan073]

For a bit more detail: I tried caching the point cloud after every render call at 60hz if the buffer had data, then publishing the cached result at 20hz. But since the LidarRtx's data acquisition and my sim/render loop are out of sync, I get partial scans (see screenshot).

I saw some posts suggesting this may be addressed in 6.0, but I'm stuck on 5.1 for now and need a workaround. Are there any app settings that force complete execution of the rendering/data-acquisition pipeline by the time the world.render() call returns? Or alternatively, is there a way to publish to ROS directly from within the OmniGraph SDGPipeline, downstream of the Isaac Create RTX Lidar Scan Buffer node?

[zwdoescode]

Hi @aidan073 ! get_current_frame() is a cached-frame accessor. In 5.1, LidarRtx refreshes _current_frame from an omni.kit.app.GLOBAL_EVENT_UPDATE callback. That callback samples the SDG PostProcessDispatcher reference time and then calls each attached annotator's get_data(). It is not synchronized as "the data for the immediately preceding world.render() call".

The empty rows are expected between complete scans for a 20 Hz full-scan lidar rendered at 60 Hz. The unsafe assumption is using rendering_frame % 3, or the Python render-call count, as the scan clock while polling _current_frame.

For your 5.1 workaround, I would publish downstream of the RTX lidar render product instead of polling LidarRtx._current_frame. For ROS, use ROS2RtxLidarHelper with the lidar render product and fullScan=True for PointCloud2. That keeps the publisher inside the SDG/OmniGraph execution path rather than in a Python loop that can sample a stale cache. For non-ROS capture, use an event-driven Replicator writer or GenericModelOutput consumer attached to the render product and dedupe/process by the sensor payload timestamp.

[aidan073]

Thanks for this answer, really insightful and I should be able to implement that work-around easily.

I just want to be certain I'm understanding the timing correctly, since it might have implications for other sensors I'm using as well. Is it roughly as follows: world.render() kicks off the SDG/render pipeline, which runs async. This render call also triggers the GLOBAL_EVENT_UPDATE callback, which calls the Lidar annotators' get_data() methods, which may or may not have data for the current frame since that SDG pipeline is running async. The partial scans once data has actually been acquired still confuses me though, unless 3 rendered frames at 60hz < 1/20th of a second due to floating point error or something else. I'm guessing my understanding is just incorrect though. Sorry for the troubles.