Add GetBatchRayIntersectionFromLastStepFeature for CPU lidar

[apojomovsky]

🎉 New feature

This PR is 1 out of 3 that implement: gazebosim/gz-sensors#26

Summary

Add GetBatchRayIntersectionFromLastStepFeature, a new gz-physics feature that accepts all rays for a sensor in a single call and returns all results at once.

The dartsim implementation bypasses DART's raycast() wrapper, which allocates a temporary btCollisionObject + btShape per ray and calls btCollisionWorld::rayTest() directly.

To reach the underlying btCollisionWorld* without patching DART (where BulletCollisionGroup::getBulletCollisionWorld() is protected), a thin subclass GzBulletCollisionGroup bridges the protected method via inheritance, and GzBulletCollisionDetector::createCollisionGroup() is overridden to produce instances of it.

A batch API was chosen over modifying the existing per-ray GetRayIntersectionFromLastStep to avoid a silent behavior change to a public API, provide independent test coverage, and establish a clean boundary for future batching (e.g. GPU).

Only the Bullet collision detector supports raycasting in dartsim. Non-Bullet detectors (ODE, FCL, native DART) emit a one-time gzwarn and return NaN results.

Test it

colcon build --merge-install --packages-select gz-physics \
  --cmake-args '-DBUILD_TESTING=ON'
colcon test --packages-select gz-physics \
  --ctest-args -R COMMON_TEST_simulation_features_dartsim

Checklist

• Signed all commits for DCO
• Added a screen capture or video to the PR description that demonstrates the feature
• Added tests
• Added example and/or tutorial
• Updated documentation (as needed)
• Updated migration guide (as needed)
• Consider updating Python bindings (if the library has them)
• codecheck passed (See contributing)
• All tests passed (See test coverage)
• Updated Bazel files (if adding new files). Created an issue otherwise.
• While waiting for a review on your PR, please help review another open pull request to support the maintainers
• Was GenAI used to generate this PR? If so, make sure to add "Generated-by" to your commits. (See this policy for more info.)

Generated-by: Claude Opus 4.6

Disclaimer: The code here was reviewed, tested, and profiled by hand by the author.

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by and Generated-by messages.

[j-rivero]

Thanks for the PR !

Not a big expert in physics but let me ask some questions and raise some proposals for the idea:

I somehow miss an API clean way of knowing if there was a hit or not in Ray, it is not documented anyway in the code. I assume that the user needs to check for NaN probably in fraction but I think that NaN has its own problems for some floating point comparisons.

With some help from Claude, how about something like?
https://gist.github.com/j-rivero/5a96bf40b33f0468366dbea82d431ffc

[apojomovsky]

Thanks for the PR !

Not a big expert in physics but let me ask some questions and raise some proposals for the idea:

I somehow miss an API clean way of knowing if there was a hit or not in Ray, it is not documented anyway in the code. I assume that the user needs to check for NaN probably in fraction but I think that NaN has its own problems for some floating point comparisons.

With some help from Claude, how about something like? https://gist.github.com/j-rivero/5a96bf40b33f0468366dbea82d431ffc

This was actually a great suggestion, thank you. It was implemented as part of my last update, PTAL.

[peci1]

Thanks for doing all the hard work!

How difficult would it be to run the lidar in the more realistic non-zero-scan-duration way? I.e. only capturing a bunch of azimuths at once each timestep and composing the pointcloud from these time-advancing chunks? This would really help with debugging/simulating lidar deskewing nodes...

[apojomovsky]

Thanks for doing all the hard work!

How difficult would it be to run the lidar in the more realistic non-zero-scan-duration way? I.e. only capturing a bunch of azimuths at once each timestep and composing the pointcloud from these time-advancing chunks? This would really help with debugging/simulating lidar deskewing nodes...

Thanks! Worth noting I did most of this with AI assistance, so take my intuition here with a grain of salt.

The batch API already accepts arbitrary subsets of rays, so in principle you could cast different azimuth slices at different physics steps. The needsRaycast per-step gating is already in place too. So the gz-physics side might not need changes, but I honestly haven't thought through the orchestration and pointcloud assembly side at all. If you want to explore it, the CpuLidar system (that we will hopefuly be merging into gz-sim soon) could be a good place to start.

[j-rivero]

IMHO, is good to go technically. Will require the design and architecture overview from @scpeters or @azeey but it is a great work Alexis.