Ubuntu 24.04
Ubuntu 22.04
Ubuntu 20.04
Windows 11
Windows 10
Other (please specify):
GPU Information
Model: L40S
Driver Version: 590.48.01
CUDA Version: 13.1
Topic Description
Detailed Description
When runing six OmniLidar instances with the Ouster OS0_REV7_128ch10hz1024res variants each setup with their own isaacsim.ros2.bridge.ROS2RtxLidarHelper and isaacsim.core.nodes.IsaacCreateRenderProduct instances in an Action Graph (see below).
There appear to be a number of sectors missing from the data, both in the debug rendering within IsaacSim, as well as on the published ROS2 topics. Below is a visualization from RViz2 that includes a 200 ms persistence to the point cloud to more easily show when sectors are missing.
The v6.0.0-dev2 release (March 16) includes several fixes to IsaacCreateRTXLidarScanBuffer that directly address sector drops and broken scans — specifically, scan accumulation was moved from GPU to host by default to reduce resource contention, and a fix was made for running many lidars doing full-scan processing simultaneously. Since you filed this on dev1, could you try updating to dev2 and let us know if the issue persists?
It looks like the problem still persists in 6.0.0-dev2; however, the case where we select the option to publish full scans in the ROS2RtxLidarHelper seems to be running more smoothly and maintains a high publish rate, though I susecpt many of the points within that point cloud are being persisted from frame to frame. I suspect if I were to test a more dynamic scenario, we may see that many of those points are no longer valid. Just a hunch, but I can test this to verify.
@brian.molnar1 Thanks for retesting on dev2 and the update.
Your observation about points being persisted from prior frames is worth investigating — that could indicate the scan accumulation buffer isn’t fully clearing between frames at this throughput level. Testing
in a dynamic scenario (moving objects) would help confirm this.
A few things to try that may help with the sector drops:
Enable per-frame output if not already set — this ensures scan buffers are reset each frame:
--/app/sensors/nv/lidar/perFrameOutput=true
Reduce the number of simultaneous full-resolution lidars — 6× OS0 128ch at 1024 res is ~786K points/frame. Try reducing to 4 or lowering to 512res variants to see if there’s a throughput threshold
where drops stop.
Check if GPU-side processing helps or hurts — you could try re-enabling GPU processing for comparison:
--/app/sensors/nv/lidar/outputBufferOnGPU=true
On an L40S with this workload, GPU-side processing might actually perform better than the host-offload path.
Your dynamic scenario test results would be very helpful — please update here when you have them.
@brian.molnar1 Just checking in — were you able to test the dynamic scenario with full scan mode? Your findings on whether points are being persisted from prior frames would be valuable for the sensor team to investigate further.
Hi @VickNV. Thanks for checking in. I wasn’t able to test yet, but I will have results in a day or two. Unfortunately my efforts got pulled elsewhere the past week. Thank you again for the pointers. Just wanted to give you a quick update to keep this ticket open.
