lidar_processor is the ROS 2 wrapper that consumes raw TF-Luna readings (100 Hz, single-axis distance), applies smoothing and outlier rejection, and emits the policy-ready feature at the policy’s lower rate (typically 10 Hz).
The naming is a slight historical artifact — “lidar” is a stretch for a 1D ToF rangefinder. We use the term because that’s what the sensor manufacturer calls it, and because the node would naturally extend to handle real 2D lidar input if/when we add one. For now, it’s “the node that turns noisy 100 Hz distance samples into one clean number the policy can use.”
Current status: in design. The current RL training stack uses TF-Luna readings directly via MAVROS rangefinder topics, with smoothing done inside the policy observation builder. Promoting this into a dedicated node makes sense once we have a second use of the same processed signal (e.g., SLAM and the RL policy both consuming smoothed distance) — at that point the duplicated smoothing logic should live in one place.
Planned interfaces:
- Input:
/drone/tf_luna_down(sensor_msgs/Range, 100 Hz). - Output:
/drone/lidar/processed— smoothed value with staleness/validity flags, at the policy rate.
Planned smoothing:
- Outlier rejection on samples deviating > 3σ from a 10-sample rolling median.
- Sample-validity check (drop samples where TF-Luna reports
amp < 100oramp == 0xFFFF) — see the TF-Luna driver for the underlying health logic. - Optional EMA smoothing with α tunable from a launch parameter.
Where to go next
- TF-Luna sensor — the physical layer
- TF-Luna driver — the embedded firmware side
- RL observation space — the policy-side consumer of this signal