ArduPilot
External_AHRS: SBG - Implement an EKF as GNSS mode and add several improvements
- External_AHRS: SBG - Fix gps_week value computation
- External_AHRS: SBG - Fix GPS fix type handling
- External_AHRS: SBG - Improve EKF Nav status handling
- External_AHRS: SBG - Fix velocity accuracy computation
- External_AHRS: SBG - Implement an EKF as GNSS mode
- External_AHRS: SBG - Implement get_variances function
- External_AHRS: SBG - Change SbgLogXxxData to SbgEComLogXxx
- AP_RTC: Fix month assignement
What is the motivation for EKF as GNSS?
According to this thread that is problematic.
Hello @tpwrules, The goal is to take advantage of both SBG INS performances in dead reckoning situation to provide reliable position and EKF3 to provide navigation and piloting capabilities.
I think there might be a misunderstanding here. I don't understand your statement that the EKF3 provides "navigation and piloting capabilities", those are handled at other layers of ArduPilot. The EKF3 is purely the AHRS, it computes and provides position information to the rest of the system.
ArduPilot's use of external AHRS supports two major modes. It can either replace EKF3 for flight (AHRS_EKF_TYPE = 11), or it can use raw sensor data from the external AHRS (e.g. GNSS and/or IMU) to feed into EKF3 (EAHRS_SENSORS).
Can you help me understand why the former mode does not cover your use case of leveraging SBG dead reckoning capabilities? It is already supported by ArduPilot.
The proposed split mode of feeding SBG EKF data into EKF3 as if it were raw data is where problems arise. In both modes the same flight control algorithms are used.
Thank you for the clarification. I agree that I expressed myself poorly. I fully understand that EKF3 is an AHRS, and what I meant to highlight is simply its high level of configurability, which many of our users value.
We are fully aware that injecting the SBG EKF navigation output as if it were GNSS data in EKF3 can lead to inconsistencies, and we understand why this approach is problematic from an estimation standpoint. That said, this integration path is something several of our users explicitly request, as they want EKF3 to remain active while still benefiting from the robustness of our dead-reckoning solution.
If needed, we are completely willing to include a clear warning or limitation note for this mode to ensure users understand its implications and potential risks.
We are fully aware that injecting the SBG EKF navigation output as if it were GNSS data in EKF3 can lead to inconsistencies, and we understand why this approach is problematic from an estimation standpoint. That said, this integration path is something several of our users explicitly request, as they want EKF3 to remain active while still benefiting from the robustness of our dead-reckoning solution.
OK, so there's one other major drawback in that you lose the redundancy that feeding raw GPS data into ArduPilot's EKF3 gives you. If your offboard estimator goes insane EKF3 won't be able to save you. It's possible that if the system running ArduPilot has multiple viable IMUs that using affinity may mitigate this problem - the primary EKF core fusing the already-fused position and the second core fusing raw GPS measurements.
If needed, we are completely willing to include a clear warning or limitation note for this mode to ensure users understand its implications and potential risks.
Since last week we agreed to consume similar pre-fused data from another GPS/ExternalAHRS vendor we can't reject this request. We'd be very interested in flight logs with a good external ground truth running the two cores I outline above!
@peterbarker
We fully acknowledge the loss of redundancy that comes with feeding pre-fused navigation data instead of raw GNSS measurements into EKF3. This is one of the main reasons why this mode is not the one we usually recommend. That said, from a customer-integration perspective, this approach significantly simplifies the setup on the autopilot side and reduces system complexity. It also provides practical benefits in the field, such as maintaining a usable fallback solution if the INS <--> autopilot link is temporarily disrupted.
Regarding the request for flight logs, we would be happy to support such validation efforts, but we cannot share customer logs due to confidentiality constraints.
I've added the corresponding documentation in the already open PR https://github.com/ArduPilot/ardupilot_wiki/pull/7035
We already run EKF even when EAHRS is selected including possibility of feeding some or all EARS sensor to an internal EKF core. Documentation doesn't suggest that automatic failover to internal EKF is implemented. It isn't, there is FR for it #25947
IMHO it would be better to implement the failover.
@LupusTheCanine
That failover feature is indeed very interesting, and we will certainly look into it once it becomes available. In the meantime, we already have customers successfully using the “SBG EKF as GNSS + EKF3” approach we are proposing.
One practical constraint for some of our users is that our INS cannot fully initialize on the ground when operating with a single antenna, whereas EKF3 can. Since not all customers can install a dual-antenna setup, the combined mode provides a workable solution: EKF3 initially runs on standard GNSS, and once the vehicle is in motion and the SBG EKF has accumulated enough dynamics to initialize, they switch to the SBG EKF as GNSS mode. This workflow is the reason why the hybrid approach remains relevant for a subset of use cases.