Here’s the information for our next May Meeting where we’ll talk about common sensors in underwater projects: sonars! Here are the details:
“This project focuses on building a GPU-accelerated SONAR simulation plugin for Gazebo that works across different hardware, instead of being tied to CUDA and NVIDIA GPUs. It replaces the existing CUDA-based approach with a wgpu-based pipeline, making it easier to run on systems using Vulkan, DirectX, or Metal. The goal is to keep performance high while making the plugin more portable and easier to integrate with Gazebo and ROS 2.”
Agenda:
Latest news from Open Robotics about Gazebo - Addisu Tadesse, Intrinsic.
As always, the meeting will be recorded and posted to the community meetings playlist on the GazeboSim YouTube channel. Check out the playlist for past meetings!
Be sure to subscribe to the Gazebo community calendar to receive invitations to the meeting every month.
This is really impressive work! The WGPU-based approach for sonar simulation is exactly the kind of modern, cross-platform solution the Gazebo community needs.
I have a question: do you see a path to extend this WGPU architecture beyond just sensors (lidar, camera, sonar) to become a full alternative rendering backend to OGRE2?
For users with high-fidelity rendering requirements—who currently have to rely on OGRE2’s limitations—having a native WGPU backend would be a game-changer.
I understand this is a significant architectural effort, but with the gz_wgpu_rt_lidar and now this sonar work, the building blocks seem to be falling into place. Is this on the roadmap, or is the current focus strictly on sensor simulation for now?
Would love to hear your thoughts on the feasibility and what would be needed to make this happen.
@Ayrton-Sheng Improving the rendering quality is a roadmap item for Gazebo M. There’s some early exploratory work to use Bevy as an external renderer using this design. @shash1300 (who wrote gz-wgpu-rt-lidar had started working on it, but I’m not sure if he has the cycles anymore. We also have a branch on gz-sim for protyping the idea of an external renderer (in C++ for now) in gz-sim/external_renderer at external_renderer · gazebosim/gz-sim · GitHub. If you or anyone else is interested in working on this, please let us know.
@Ayrton-Sheng@azeey : A few years ago, for Gazebo classic, I was writing a simple raycasting-based LiDAR simulation plugin for Gazebo because it popped out with low-effort from my research: GitHub - uos/rmagine_gazebo_plugins: Ray Casting-Based Range Sensor Simulation in Gazebo using Rmagine · GitHub . It supported OptiX for NVIDIA GPUs and Embree for CPUs as computing backends (I also measured the really nice runtime properties of ray casting for LiDAR simulation in a paper). But I didn’t have time to write a full rendering backend out of them. At that time, the existing OptiX backend was also very experimental. I was thinking that for the development of such “special” sensors it may help if Gazebo supported not just selecting single rendering backend but many instead. Then, per sensor, one could select a rendering backend. Once this is possible, each rendering backend doesn’t need to support every sensor. This would make it a bit easier to start writing one. Because right now, when writing a new rendering backend, one needs to support all available sensors in order to be really usable. I am not into the current development of Gazebo, but a year ago this was still valid: Inaccurate GPU Lidar · Issue #2743 · gazebosim/gz-sim · GitHub
Are there any efforts toward making rendering backend selection configurable per sensor? If this is out of scope, I can move it to a separate topic. But it has very much to do with the recent discussion here.
@amock for this specific project the authors completely bypass gz-rendering. It turns out gz-sim’s ECS is very nice for extracting data you want without the complexity of singletons that one finds in the ogre backend. This is the same approach used by Robotec’s RGL Lidar, and my and @shash1300 's wgpu lidar. The nice thing is with wgpu you can explicitly allocate lidars to specific gpus if you want to and select backends on the fly.
@arjo129, Thank you for the quick reply! From your explanation it seems like you can add me to the list of bypassers . I was syncing an embree/optix scene (IAS+GAS) with the entities of Gazebo inside a system plugin. I could then spawn many lidars all raycasting on the same acceleration structure.
I think wgpu is a great choice, especially for the Gazebo project. I am looking forward to what’s coming next.
Date: 2026-05-27T16:00:00Z
Place: Virtual at Google Meet, sign up for our Lu.ma event to get updates and reminders.
Event: Calendar event. Luma Link
Topic: Sonar sensors
Agenda: Everyone is welcome to add items to the agenda
Luma Sign Up (add to your calendar and get reminder emails).
. I was syncing an embree/optix scene (IAS+GAS) with the entities of Gazebo inside a system plugin. I could then spawn many lidars all raycasting on the same acceleration structure.