Migrate NumPy-based computations to CuPy for GPU acceleration

[AlexBarbi]

Summary

Currently all numerical computation in the project (EKF-SLAM, particle filter gas-source estimation, gas distribution map, linear consensus, wind/gas dispersion model) runs on NumPy/SciPy, i.e. CPU-only. Several of these components — especially the per-robot particle filter (large particle counts, repeated likelihood evaluation) and the gas distribution map (grid-based accumulation) — are good candidates for GPU acceleration via CuPy, which mirrors the NumPy API almost 1:1.

Motivation

• Particle filter and GDM updates run per-robot, per-timestep, and scale with particle count / grid resolution — a natural fit for GPU parallelism.
• CuPy is (mostly) a drop-in replacement for NumPy, minimizing the amount of code that needs to be rewritten.
• With multiple robots simulated concurrently (and MPI-based V2V communication via mpi4py), offloading the heaviest array ops to GPU could meaningfully cut simulation wall-clock time.

Proposed Scope

• estimation/ — EKF-SLAM (prediction/update, occupancy grid log-odds updates)
• estimation/ — Particle filter gas-source estimation (likelihood evaluation, resampling)
• estimation/ — Gas Distribution Map (coverage map, weighted-readings map)
• estimation/ — Linear consensus (information-form updates)
• sim/ — Wind model / LBM-based gas dispersion (evaluate whether pylbm internals can be bypassed or complemented with CuPy arrays)
• controllers/ — APF navigation/formation control math (lower priority, likely small vectors)
• viz/ — leave on CPU/NumPy (rendering needs host memory anyway)

Proposed Approach

1. Add cupy as an optional dependency in requirements.txt (CUDA-version-specific wheel, e.g. cupy-cuda12x), guarded so CPU-only installs still work.
2. Introduce a thin array-module abstraction (e.g. xp = cupy if GPU_ENABLED else numpy, or use cupy.get_array_module) so code paths stay agnostic and testable on machines without a GPU.
3. Start with the particle filter and GDM (highest particle/grid-size, most parallelizable), benchmark before/after.
4. Handle host↔device transfers carefully at module boundaries (e.g. before Matplotlib rendering in viz/, before MPI sends in V2V communication, since mpi4py needs host — or CUDA-aware MPI — buffers).
5. Add a config flag (e.g. in config/) to toggle GPU usage on/off at runtime.

Acceptance Criteria

• Selected modules run correctly on both CPU-only and GPU-enabled machines (graceful fallback).
• No change in numerical results/behavior beyond floating-point tolerance.
• Benchmark showing measurable speedup for particle filter / GDM update steps.
• requirements.txt / installation docs updated with CUDA/CuPy setup instructions.
• Existing tests in test/ pass on both code paths.