NavCore-Pixhawk v2.0.0 — SR-ESKF & Aviation-Grade Safety

[ARYA-mgc]

This is a major upgrade from v1.0.0. The biggest change is the core filter — I rewrote the ESKF to use Square-Root covariance factorization, which means the covariance matrix can never go numerically unstable during long GPS-denied flights. Previously we were using eigenvalue clamping as a hack to keep things stable, that's gone now.
Added RAIM integrity monitoring so the system can detect and exclude bad GPS measurements instead of blindly trusting them. Multi-Hypothesis Tracking handles the case where GPS jumps after a long outage — instead of trusting the jump immediately, the filter maintains shadow hypotheses and picks the best one.
On the sensor side, magnetometer now does continuous RLS hard/soft-iron calibration during flight, and there's a basic Terrain Relative Navigation module using the Livox point cloud matched against a DEM.
Quaternion integration was upgraded from first-order Euler to RK4, which reduces attitude drift at high angular rates. Measurement updates now use iterated EKF (IEKF) for nonlinear sensors like UWB and tight GPS.
Test suite expanded to 30+ tests including Monte Carlo validation, GPS outage recovery metrics, and NEES/NIS filter consistency checks.

---

This discussion was created from the release NavCore-Pixhawk v2.0.0 — SR-ESKF & Aviation-Grade Safety.

[john-max-cyber]

Great work on v2.0.0. The SR-ESKF upgrade is a solid move - eigenvalue clamping was always a workaround so replacing it properly is the right call RAIM and MHT together is a smart combo for handling GPS jumps after long outages RK4 integration and IEKF for nonlinear sensors are good improvements too. One question - what DEM resolution are you using for the TRN module with the Livox point cloud? Curious how it holds up at different altitudes. Overall a very clean release, the NEES/NIS checks in the test suite are a nice touch.

[ARYA-mgc]

Thanks @john-max-cyber , glad you liked the release. The SR-ESKF was long overdue eigenvalue clamping worked but it was always a hack tbh. For the TRN module were running a 30m DEM with the Livox point cloud works reliably between 50-150m AGL. Outside that range correlation quality drops off so RAIM+MHT handles the reacquisition instead. And yeah the NEES/NIS checks actually catched a couple subtle bugs we missed with regular unit tests so was definitely worth adding. Cheers!

[john-max-cyber]

Nice to hear that! Good luck with the UAV project, the nav stack should fit perfectly for professional work. When you run the tests pay close attention to the noise params in the config, a little tuning there makes a big difference in real flight performance. Looking forward to seeing your results. In bocca al lupo!

[ARYA-mgc]

Thanks @john-max-cyber ! . Yeah I will definitely spend some time to tuning the noise params in the config before the real flights,Really appreciate the tip Will share the flight logs once we getting it in the air.

[RealRockefeller]

Really impressive jump from v1 the SR-ESKF is the right call, eigenvalue clamping was always a hack that masked the real problem rather than solving it. RAIM + MHT together is a solid combo, especially for urban or tunnel re-acquisition scenarios where native GPS trust just breaks things. Curious how the MHT hypothesis cap holds up on the Pi4 under full sensor load and with the RLS mag calibration running continuous, are you using a forgetting factor to handle hard-iron shifts mid-flight? The NEES/NIS test coverage is a nice touch too, most projects skip that and just report RMSE. What DEM resolution are you targeting for TRN?

[ARYA-mgc]

Yeah the MHT hypothesis cap holds up fine on the Pi4 because we offload the heavy stuff like point cloud and MHT to a ThreadPoolExecutor so it dont block the 100Hz loop. For the mag calibration were actually using EMA with a 60 second time constant instead of full RLS, its lighter and handles hard-iron shifts mid flight pretty well. And for TRN were targeting 30m DEM resolution with the Livox point cloud, works good for our typical mission altitudes around 50-150m AGL.

[RealRockefeller]

Couple of follow-up questions how are you handling DEM pre-loading, is the relevant tile cached in memory before takeoff or fetched on the fly? And on the TRN matching side, what's the algorithm — ICP, NDT, or something custom? Curious how it performs when the terrain is relatively flat and feature-sparse

[ARYA-mgc]

We preload the DEM tile into memory before takeoff based on the mission area, no fetching on the fly since that would be way too risky for latency on the Pi4. For the matching were using terrain cross-correlation not ICP or NDT, basically comparing the Livox point cloud elevation profile against the cached DEM grid and finding the best offset. Its simpler and faster then ICP for this usecase. On flat terrain honestly it struggles, when theres not enough elevation variation the correlation surface gets ambiguous and the confidence drops. In those cases the filter basically ignores TRN and falls back to RAIM+MHT for GPS reacquisition or VIO if thats available.

[RealRockefeller]

@ARYA-mgc sounds solid, can you walk us through the flight test flow for v2?

[ARYA-mgc]

Hey @RealRockefeller, the flight test flow involves multiple steps. I'm currently occupied with ongoing internship work and the team is at full bandwidth right now. We'll make sure to document and share the complete flow before end of this month!

[ashwinr-act-cit]

Amazing work on getting v2.0.0 out, Arya! The shift to SR-ESKF and dropping the eigenvalue clamping is a massive stability win for the core filter.

I was looking at the compute load you mentioned regarding the Pi4 handling the MHT and TRN point cloud processing via the ThreadPoolExecutor. Since we know that STM32 microcontrollers are highly effective for deterministic, high-frequency execution compared to ESP-series chips or handling everything on a single SBC, have you considered offloading some of the tight-loop sensor ingestion? Pushing the RK4 quaternion integration or the 100Hz EMA mag calibration down to a dedicated STM32 co-processor could free up valuable overhead on the Pi4 for the shadow hypotheses and terrain cross-correlation.

Happy to help stress-test the telemetry handling or run some simulations with this new stack if you need an extra set of hands!

[ARYA-mgc]

Thanks @ashwinr-act-cit! We want to finish SITL and flight testing first. So far the Pi4 is handling the load fine. We will look into STM32 offloading later if needed. Appreciate the suggestion!