Add vendor-agnostic wgpu compute backend

[naitikpahwa18]

Summary

This PR removes the CUDA dependency from the multibeam sonar implementation and introduces a modular compute backend architecture. A new WGPU-based compute backend is added along with a CPU reference backend used as a fallback when GPU execution is unavailable.

The sonar sensor was refactored to use this backend interface instead of calling CUDA kernels directly. The WGPU implementation runs the sonar compute stages on the GPU using WGSL shaders, while the CPU implementation preserves the existing physics model for deterministic results.

The build system was updated to remove CUDA requirements and integrate a Rust-based WGPU vendor package. Runtime backend selection is also supported.

Validation

The WGPU backend has been tested on Vulkan; support for Metal and DirectX backends is expected via WGPU but remains untested.

[Copilot]

Pull request overview

This PR replaces the CUDA-dependent multibeam sonar compute pipeline with a modular backend architecture. A WGPU-based GPU backend (using Rust + WGSL shaders) and a CPU reference backend are introduced, selectable at runtime via the DAVE_SONAR_COMPUTE_BACKEND environment variable. The sonar sensor is refactored to use a ComputeBackend interface, and computation is moved to a background thread to avoid blocking the rendering pipeline.

Changes:

• New ComputeBackend abstraction with WGPU (GPU via WGSL shaders + Rust FFI) and CPU implementations, replacing direct CUDA kernel calls
• Background compute thread in MultibeamSonarSensor with snapshot-based decoupling from the render thread, plus consistent timestamping for ROS messages
• Build system migrated from CUDA to a Rust-based wgpu_vendor package with CMake integration, and runtime backend selection via launch arguments

Reviewed changes

Copilot reviewed 26 out of 27 changed files in this pull request and generated 9 comments.

Show a summary per file

File	Description
multibeam_sonar/sonar_compute_backend.hh	New abstract backend interface and data structures
multibeam_sonar/sonar_compute_cpu.cc	CPU backend implementation and backend factory
multibeam_sonar/sonar_compute_wgpu.cc/hh	WGPU backend: C++ wrapper calling Rust FFI with CPU fallback
multibeam_sonar/MultibeamSonarSensor.cc/hh	Background compute thread, snapshot-based pipeline, backend integration
multibeam_sonar/CMakeLists.txt	Removed CUDA, added wgpu_vendor dependency
wgpu_vendor/sonar_wgpu_rust/src/lib.rs	Rust FFI entry point: GPU dispatch, staging readback, CPU FFT fallback
wgpu_vendor/sonar_wgpu_rust/src/pipeline.rs	GPU context singleton: device init, buffer management, pipeline compilation
wgpu_vendor/sonar_wgpu_rust/src/fft.rs	CPU FFT (Cooley-Tukey + Bluestein)
wgpu_vendor/sonar_wgpu_rust/src/shaders/*.wgsl	WGSL compute shaders: backscatter, convert, matmul, FFT
wgpu_vendor/CMakeLists.txt	Rust cargo build integration with CMake
multibeam_sonar_system/CMakeLists.txt	Simplified: removed CUDA conditionals
multibeam_sonar_demo/launch/multibeam_sonar_demo.launch.py	Added compute_backend launch argument
multibeam_sonar_demo/scripts/plotdata.py	Save to file instead of plt.show()
dave_interfaces/CMakeLists.txt	Removed gz-cmake3/gz-msgs10 dependencies
models/.../model.sdf	Debug comment for non-power-of-2 FFT testing

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[arjo129]

My personal recommendation would be to not remove the CUDA backend. Rather at run time have a flag in the plugin to be able to toggle between the two.

[naitikpahwa18]

I’m working on merging the previous CUDA path with the current wgpu one to support that.

[naitikpahwa18]

Addressed in the latest commit, merged CUDA with wgpu and added runtime toggling.