These nodes sit between the raw sensor drivers and the policy. Their job is to take a noisy, high-rate stream of raw readings (TF-Luna at 100 Hz, VL53L0X array at 25-30 Hz, optical-flow frames, optional camera data) and produce a clean, policy-ready feature vector at the rate the policy actually uses (typically 10 Hz).
Two nodes live here in the current design. lidar_processor takes the 1D rangefinder stream, applies smoothing, and presents the policy with the observation feature it expects. camera_vision is reserved for when (and if) we add an RGB camera payload — currently a placeholder; the indoor rangefinder stack doesn’t depend on a camera, so this is future scope.
There’s deliberately no “fusion” node here — that work happens upstream in ArduPilot’s EKF3 (see EKF3 multi-sensor fusion). These ROS 2 sensor-processing nodes operate on the output of EKF3 plus the raw rangefinder streams, not on raw IMU data. The split matters: EKF3 runs on the flight controller (fast, deterministic); ROS 2 nodes run on the companion PC (flexible, slower).
Contents
Auto-generated from child entries during build (update-indexes.mjs).