Hello, to the best of my understanding, setting EKF2_GPS_CTRL to 0, doesn’t mean that EKF-GSF estimator will be deprived by gnss data. Is this correct?
I have run two custom ekf2 instances, one with gnss ctrl and one without and I was very much surprised to see negligible roll, pitch and yaw differences (around 0.1 degrees after a 5 min flight, with calm maneuvers and calm wind).
On the contrary position estimates were as expected (huge deviations).
There was a very brief mention in the 2023, regarding heading sources, talk by @bresch, but I didn’t quite grasped the concept.
Can anyone knowledgeable enough, describe how attitude is estimated in px4 without gnss, with gnss and with dual antenna heading, and the role of magnetometer?
Does EKF-GSF act as an independent source of data fused into main EKF2, alongside magnetometer, gnss dual antenna yaw etc?
Yes, EKF2_GPS_CTRL=0 just stops GPS pos/vel fusion, it doesn’t remove GPS completely. Attitude mainly comes from IMU, with mag or GPS velocity/dual-antenna yaw aiding yaw. That’s why you saw almost no attitude difference. EKF-GSF runs in parallel and provides a yaw source that EKF2 can fuse alongside mag or GNSS heading.
Any suggestions as how to approach safely disabling GNSS fully? Now I have custom params for each EKF2 instance (EKF2_GPS_CTRL and EKF2_HGT_REF). Of course this will be done on an instance NOT controlling the drone
If you really want to run GNSS-free, safest way is set EKF2_GPS_CHECK = 0 and EKF2_GPS_CTRL = 0, and then make sure you’ve got a solid non-GPS height source (baro, rangefinder) and yaw source (mag or external heading). Just keep it on a non-primary EKF2 instance like you said, so the main estimator still has GNSS. That way you can compare the outputs side-by-side without risking control.
I don’t know, I ‘ve tried everything and it seems that the dead-reckoning instance is always on par with the GNSS instance. RTK instance with dual antenna yaw, seems to differ by around 1 degree in yaw, after 3-4’ of flight. Either I don’t get the architecture right, or something else is happening.
I have set a condition in the UpdateGpsSample() of EKF2.cpp.
if (isResearchInstance() && (_params->gnss_ctrl == 0)) {
// Skip passing GNSS data to the EKF core for research (DR) instances
PX4_DEBUG("Research instance %d: GNSS blocked (gnss_ctrl==0)", _instance); } else {
// Normal behavior: provide GNSS sample to EKF core
_ekf.setGpsData(gnss_sample);
}
Looks like your check in UpdateGpsSample() is still after the GNSS sample is created, so the EKF sees it unless you skip the hand-off completely. If you really want that instance “blind” to GNSS, you’ll need to block it at the feed-in point (before setGpsData()) rather than just tweaking gnss_ctrl.
Well after research on the matter, I think this is close to truth about yaw estimation:
In case of gnss denial, yaw estimation isn’t really affected if we have our mag enabled (EKF2_MAG_TYPE). That is why both aforementioned instances have similar results.
If we manually disable the magnetometer or it is evaluated as unreliable, then the already-running composite yaw from EKF-GSF will be fused into the main EKF2 estimator.
This EKF-GSF, multi hypothesis algorithm can run ONLY when gnss velocities are available.
So in practice attitude estimation is barely affected by loss of gnss, given we have good magnetometer readings.
The real issue is what to do when in magnetic disturbances environment AND no gnss available…
Pretty much right — with mag healthy, yaw barely drifts even if GNSS drops. If mag goes bad and GNSS is gone too, then you’re out of luck since GSF needs GNSS vel. That’s the real weak spot: no GNSS + disturbed mag = no solid yaw source.
