Issue: when scan-to-map matching fails, the code prints 'No Effective Points!' to stderr and returns WITHOUT (a) a ROS topic/flag consumers can watch, (b) distinguishing 'no input' from 'match failed', (c) any recovery. Downstream (a planner, an autonomy stack) has no way to know the estimate is invalid.
Observed: in a Gazebo sim the odometry froze and then wandered meters while the vehicle sat still, with zero externally visible signal (only repeated stderr lines). Cost hours of debugging.
Location: laserMapping.cpp ~line 750 (the ekfom_data.valid = false path).
Request: publish a health/fitness flag on every failed update (e.g. ekf_valid: false + innovation magnitude, or reuse ekfom_data.valid on an existing diagnostic topic), and consider distinguishing no-input from match-failed.
Repro: run against any point cloud that degrades mid-stream (rate drop or heavy noise); watch /Odometry freeze/wander with only stderr evidence.
Issue: when scan-to-map matching fails, the code prints 'No Effective Points!' to stderr and returns WITHOUT (a) a ROS topic/flag consumers can watch, (b) distinguishing 'no input' from 'match failed', (c) any recovery. Downstream (a planner, an autonomy stack) has no way to know the estimate is invalid.
Observed: in a Gazebo sim the odometry froze and then wandered meters while the vehicle sat still, with zero externally visible signal (only repeated stderr lines). Cost hours of debugging.
Location: laserMapping.cpp ~line 750 (the ekfom_data.valid = false path).
Request: publish a health/fitness flag on every failed update (e.g. ekf_valid: false + innovation magnitude, or reuse ekfom_data.valid on an existing diagnostic topic), and consider distinguishing no-input from match-failed.
Repro: run against any point cloud that degrades mid-stream (rate drop or heavy noise); watch /Odometry freeze/wander with only stderr evidence.