cudanav_real_gpu_stack.md

Real-data all-GPU CudaNav core shadow

This experiment sends one content-addressed real PointCloud2 sequence through all four reusable CudaNav GPU cores in one native process:

PointCloud2 sequence
  -> GPU KISS-ICP pose
  -> rolling GPU voxel map
  -> GPU ESDF and inflated costmap
  -> CUDA MPPI command evaluation

The recorded GNSS poses provide the odometry reference and MPPI path. CUDA MPPI commands are evaluated against the live map but are not applied to the recorded vehicle or a simulator. This is therefore real-data all-GPU shadow evidence, not ROS 2 runtime or closed-loop evidence.

Timed scan contract

The native stack accepts version-1 XYZ sequences for smoke testing and version-2 XYZT sequences for motion-compensated evidence. For version 2, the KISS-ICP stage normalizes each frame's recorded point timestamps, applies the previous scan-to-scan SE(3) motion on the GPU, and passes the same deskewed points to voxel mapping. The report binds the sequence version, number of deskewed frames, point-time-span p95, and deskew GPU time.

Release mode requires a dataset specification with a real scalar per-point time field and unit, independently justified physical scan-span bounds, and require_unambiguous_unit: true. A pre-export admission artifact tests all four supported units, stable schema/frame identity, finite spans, frame ordering, and an optional required integer ring field. The admission database digest, selection, field, unit, and frame count must match the export. Release then requires version-2 export and deskew on every processed frame. The current localization-only Istanbul smoke PointCloud2 is XYZ-only, so it remains valid smoke evidence but is an intentional negative input for the release timing gate. No timestamp is inferred from point ordering.

Run

Build the reusable cores and native runner:

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release \
  --target cudanav_real_gpu_stack_sequence

From a clean commit:

python3 scripts/run_cudanav_real_gpu_stack.py \
  --database build/datasets/cudanav_localization_smoke/rosbag2_2024_09_12-14_59_58_0.db3 \
  --output-dir build/cudanav_real_gpu_stack_smoke \
  --profile smoke

The smoke profile uses 300 frames over 30 seconds. It binds the database, exported sequence, runner binary, stage report, trajectory, log, source commit, and commands by SHA-256 and byte count.

Validate a local result:

python3 scripts/run_cudanav_real_gpu_stack.py \
  --validate build/cudanav_real_gpu_stack_smoke/manifest.json \
  --commit SOURCE_COMMIT

Publish and validate portable evidence:

python3 scripts/run_cudanav_real_gpu_stack.py \
  --publish build/cudanav_real_gpu_stack_smoke/manifest.json \
  --result-id cudanav_real_gpu_stack_YYYY-MM-DD \
  --output-json docs/results/cudanav_real_gpu_stack_YYYY-MM-DD.json \
  --output-markdown docs/results/cudanav_real_gpu_stack_YYYY-MM-DD.md

python3 scripts/run_cudanav_real_gpu_stack.py \
  --validate-portable docs/results/cudanav_real_gpu_stack_YYYY-MM-DD.json \
  --commit SOURCE_COMMIT

Mapping and safety semantics

The 3D mapper retains the complete voxel grid, while its 2D navigation projection uses a declared height band. The native shadow runner keeps odometry X/Y but expresses Z relative to the current estimated LiDAR origin. CudaNav selects [-0.5, 2.0) m in that sensor-relative height frame so road elevation cannot leave the finite voxel grid, ground returns below the robot, and overhead returns do not become planar obstacles. The result records this as mapping.height_frame = estimated_sensor_relative and reports both the largest absolute odometry Z and the number of frames that integrated rays.

Before ESDF inflation, the robot's declared 0.30 m circular footprint is cleared. The ROS Nav2 voxel layer applies the same rule. This prevents the vehicle's own occupied or inflated cell from making every rollout collide; obstacles outside the footprint remain unchanged.

Real scenes can still contain a genuinely blocked local horizon. The quality contract permits at most three all-colliding evaluations in the 31-evaluation smoke profile, but each must produce a safety intervention with linear speed at most 0.05 m/s. Non-blocked evaluations must retain at least a 1% valid rollout ratio. The report preserves the number of all-colliding and retreating evaluations rather than silently removing them.

The 120-second release profile requires timed version-2 scans, deskew on every frame, at least 100 MPPI evaluations, tightens ATE and drift gates to 3 m and 5%, and permits at most six bounded safety interventions. A smoke PASS is not a release-profile claim.

The checked-in smoke result is results/cudanav_real_gpu_stack_2026-07-29.md; its adjacent JSON is the machine-verifiable source.