RTX rotary lidar completes a full scan far slower than configured scanRateBaseHz, even using the writer (not polling) publish path

[agniva22]

I have an RTX rotary lidar configured for scanRateBaseHz = 5.5 (RPLIDAR A1-equivalent), publishing to ROS2 using LidarSensor(...).attach_writer("RtxLidarROS2PublishLaserScan", ...) - the writer/SDG path, not get_current_frame() polling.

What I'm expecting: a full LaserScan message roughly every 0.18s (5.5 Hz).

What I observed: a full scan completes roughly once every 2–8 seconds, means, 10–40× slower than configured. Camera and odom on the same scene run fine at their configured rates (~29 Hz, 60 Hz respectively) at the same time, so it isn't general render starvation.

Things I've tried, none of which changed the result:

1. Explicitly setting omni:sensor:tickRate to equal omni:sensor:Core:scanRateBaseHz.
2. Enabling /rtx/rendering/perSensorTickTlas — no measurable change, and the "MotionBVH for lidar model not enabled" warning still printed even with it set True, suggesting the setting isn't taking effect at all from this call site.
3. Replacing my custom sensor config with Isaac's own real vendor asset (Slamtec_RPLIDAR_S2E.usd) instead of a generic template - identical slow throughput.

Environment I'm using: Isaac Sim 6.0.0, /rtx/hydra/supportMultiTickRate = True.

Related but likely distinct: #674 describes a similar-sounding symptom, but its root cause was polling using get_current_frame() racing the render loop, I'm not polling, so that fix doesn't apply here. Is there another known cause for a full-scan completion rate this far below the configured scanRateBaseHz?

[zwdoescode]

@agniva22 Isaac Sim 6.1 has released. Have you tried it and see if the issue is reproducible?

[agniva22]

@zwdoescode Yes, tried it but same bug, unchanged on 6.1.0:

scan: ~0.5 Hz (still ~10x below the configured 5.5 Hz)
image: ~20.5 Hz (normal)
odom: ~60 Hz (normal)
Getting 6.1 running required fixing three unrelated things first (noting here in case useful to anyone else):

1. Missing cattrs package in the bundled Python environment.
2. The bundled PyTorch inside extsDeprecated/omni.isaac.ml_archive fails to load (undefined symbol against the system's CUDA runtime). Reinstalling torch, doesn't fix it, since the bundled copy still takes priority on sys.path.
3. With the bundled torch removed, isaacsim.core.deprecation_manager calls app.shutdown() on any failed torch import by default. Worked around by passing --/app/stubgen/enabled=true as a kit launch argument (must be a launch arg, not a runtime carb.settings call, the failure happens during SimulationApp()'s own construction, before any later Python code runs).

None of that touched the actual lidar throughput though, thus, identical symptom to 6.0.0. Is there anything else worth checking on the multi-tick rendering side specifically, given perSensorTickTlas and matching tickRate/scanRateBaseHz also made no difference?

[zwdoescode]

@agniva22 Thanks for testing with 6.1. I reproduced a similar ~0.5 Hz result in a small 6.1 test using the Slamtec S2E and the ROS writer path.

The key detail was the attribute readback: scanRateBaseHz is a uint in this build. Requesting 5.5 produced scanRateBaseHz=5, while tickRate remained 5.5. That combination yielded complete raw lidar scans and ROS messages every 2 simulated seconds. Setting both to 5 restored a scan every 0.2 simulated seconds.

Could you print these on the actual OmniLidar prim after all configuration overrides?

for name in (
    "omni:sensor:Core:scanRateBaseHz",
    "omni:sensor:tickRate",
    "omni:sensor:Core:accumulateOutputs",
):
    attr = prim.GetAttribute(name)
    print(name, attr.GetTypeName(), attr.Get())

As a diagnostic, try integer scanRateBaseHz=5 and tickRate=5.0 before starting the sensor, and derive the writer's scan metadata from those readbacks. This is a tested 5 Hz workaround, not an exact 5.5 Hz configuration. The multi-tick documentation requires those rates to match.

Also, perSensorTickTlas is separate from Motion BVH. For standalone Python, configure SimulationApp with enable_motion_bvh=True at startup; changing the TLAS setting alone does not establish that Motion BVH is enabled.

If scanRateBaseHz and tickRate read back as the same value—for example, both are 5—but scans are still slow, please share your minimal sensor/stepping/writer script and timestamp samples.