[kharwarm]

It keeps predicting. During a GPS outage, FusionCore just dead-reckons off the IMU and wheel encoders, so the output stream stays continuous.

Covariance inflates over time as uncertainty builds... there’s no output gating. The Mahalanobis gate is only used on incoming measurements, so it’ll reject bad GPS fixes (like multipath spikes), but it doesn’t suppress the state estimate itself.

If the robot is stationary during an outage, ZUPT kicks in and drift stays close to zero. If it’s moving without GPS, then drift is entirely a function of IMU and encoder quality.... which, for something like a helmet, is probably going to degrade pretty quickly after ~30 seconds.

Your architecture is interesting to me. Letting speed go stale as an intentional safety signal (with the MCU handling crash logic below ROS) makes sense when “wrong but confident” is worse than no signal at all. FusionCore takes the opposite stance: never stop publishing, and let covariance communicate uncertainty to downstream consumers. For a cycling helmet... where false confidence could be dangerous... your approach is probably the safer call. For a robot that needs to keep navigating through something like a tunnel, FusionCore’s approach makes more sense.

Out of curiosity... what does your system do if GPS is lost for more than ~10 seconds while the device is moving? Does the MCU fall back to accelerometer-only crash detection, or does it just wait for GPS to come back?