Wiki errors for EK2_GPS_CHECK

Jstroup · June 9, 2025, 5:24pm

I’m having trouble clearing the arming checks because of GPS related warning.

Digging into the documentation, the Wiki page for EK2_GPS_CHECK has errors - so I can’t tell what parameters to check for the problems.

I could simply deselect the checks - but it is much safer to understand which of the parameter(s) is going out of range.

Note for example, the parameter EK2_REQ_HDRIFT is mentioned twice, first for “horizontal position drift” and again for “horizontal speed offset.”

I would like to know the 9 parameters that correspond to to the 9 bits in EK2_GPS_CHECK.

Thanks!

dakejahl · June 10, 2025, 2:05am

What are the warnings? Can you share screenshots/text? It sounds related to [Bug] GPS failure, notify user · Issue #24355 · PX4/PX4-Autopilot · GitHub

Jstroup · June 10, 2025, 1:23pm

Yes, the symptoms described in the bug report sound a lot like what I’m experiencing - except I’m getting them during the pre-arm checks.

Here’s a couple of screen shot examples:

But in addition to these, I’ve also gotten these warnings - sometimes multiple at the same time:

“Height Estimate Not Stable”
“Position Error Estimate”

I’ve gotten these messages with as many as 22 satellites locked.

I didn’t see a solution or work-around in the bug report. Do you have a suggestion?

Also - is it possible to get a correct description of the bitmask meanings for EK2_GPS_CHECK?

Thank you for your help!

dakejahl · June 10, 2025, 9:50pm

It sounds like interference. Can you turn on logging from boot (SDLOG_MODE), upload to px4 flight review, and share the link?

Did you see the param reference?

Jstroup · June 11, 2025, 10:20pm

Thanks @dakejahl -

Yes, I agree, it does sound like interference.

But since I’m new to PX4 (after working 5 years with ArduPilot) it wanted to cover all the possibilities.

Regarding the param reference - as I displayed in the screenshot on my post above, the param reference is wrong for EKF2_GPS_CHECK. It mentions things like “spoofing” (bit 9) that isn’t represented for that parameter in Qgroundcontrol.

And two bit options reference the same thing.

I was hoping someone might take a peek at the codebase and explain what the options really mean - so that whomever maintains the WIKI could correct it.

Thanks!

dakejahl · June 11, 2025, 10:47pm

The parameters at the link above are autogenerated and updated daily, so they will always be in sync. QGC fetches the parameter metadata, but I think at some point this might have broke in QGC v4. Either that or you might need to clear the QGC cache. Right now the maintainers are working on a QGC v5 release, I would recommend using the daily build and if any issues persist posting in the QGC discord channel or on the GitHub. Don has been fixing a ton of issues and is very responsive.

Jstroup · June 12, 2025, 3:27pm

Thank you for taking the time to help me on this - your explanations are really helpful.

Please note that the WIKI for EKF2_GPS_CHECK references EKF2_REQ_HDRIFT for both bit 5 and bit 7 in the bitmask.

If the WIKI is auto generated from the codebase, does that mean there is an error in the codebase?

I tried using my Android Qgroundcontrol app, and this is the display for EKF2_GPS_CHECK:

This has the same error in the description of bit 5 and bit 7, where the reference to EKF2_REQ_HDRIFT is listed twice. But it does show “Spoofing” for bit 9 in the bitmask.

I tried the Windows daily build and this is what it displays:

This has the same error in the description of the bitmask as the stable Windows version of Qgroundcontrol. Note that bit 9 still does not mention spoofing, and the duplicate references on bit 5 and 7.

I realize that this may be a minor problem. Not so minor for me as I’m having difficulty with pre-arm checks because of GPS related errors.

So it would be helpful to me, and as a references to others who look up this thread, if you could look at the codebase and describe exactly what these 10 bits on the bitmask are actually doing.

Then if it makes since to correct this on a daily build or the next stable version, that research will be done to help out the DEV team.

Is there anything else I can do to help?

Thanks!

dakejahl · June 12, 2025, 8:43pm

It does look like EK2_REQ_HDRIFT is used for both of those checks.

If you want to look through the code, the GPS checks happen here:

github.com/PX4/PX4-Autopilot

src/modules/ekf2/EKF/aid_sources/gnss/gnss_checks.cpp

6d1501971


      
          		const Vector3f vel_limit(_params.req_hdrift, _params.req_hdrift, _params.req_vdrift);
          		Vector3f delta_pos(delta_pos_n, delta_pos_e, (_alt_prev - gnss.alt));
          
          		// Apply a low pass filter
          		_lat_lon_alt_deriv_filt = delta_pos / dt * filter_coef + _lat_lon_alt_deriv_filt * (1.0f - filter_coef);
          
          		// Apply anti-windup to the state instead of the input to avoid generating a bias on asymmetric signals
          		_lat_lon_alt_deriv_filt = matrix::constrain(_lat_lon_alt_deriv_filt, -10.0f * vel_limit, 10.0f * vel_limit);
          
          		// hdrift: calculate the horizontal drift speed and fail if too high
          		_horizontal_position_drift_rate_m_s = Vector2f(_lat_lon_alt_deriv_filt.xy()).norm();
          		_check_fail_status.flags.hdrift = (_horizontal_position_drift_rate_m_s > _params.req_hdrift);
          
          		// vdrift: fail if the vertical drift speed is too high
          		_vertical_position_drift_rate_m_s = fabsf(_lat_lon_alt_deriv_filt(2));
          		_check_fail_status.flags.vdrift = (_vertical_position_drift_rate_m_s > _params.req_vdrift);
          
          		// hspeed: check the magnitude of the filtered horizontal GNSS velocity
          		const Vector2f vel_ne = matrix::constrain(Vector2f(gnss.vel.xy()),
          					-10.0f * _params.req_hdrift,

This file has been truncated. show original

And the pre-arm checks are here:

github.com/PX4/PX4-Autopilot

src/modules/commander/HealthAndArmingChecks/checks/estimatorCheck.cpp

6d1501971


      
          		if (!context.isArmed() && ekf_gps_check_fail) {
          			NavModesMessageFail required_modes;
          			events::Log log_level;
          
          			switch (static_cast<GnssArmingCheck>(_param_com_arm_wo_gps.get())) {
          			default:
          
          			/* FALLTHROUGH */
          			case GnssArmingCheck::DenyArming:
          				required_modes.message_modes = required_modes.fail_modes = NavModes::All;
          				log_level = events::Log::Error;
          				break;
          
          			case GnssArmingCheck::WarningOnly:
          				required_modes.message_modes = (NavModes)(reporter.failsafeFlags().mode_req_local_position
          							       | reporter.failsafeFlags().mode_req_local_position_relaxed
          							       | reporter.failsafeFlags().mode_req_global_position);
          				// Only warn and don't block arming because there could still be a valid position estimate from another source e.g. optical flow, VIO
          				required_modes.fail_modes = NavModes::None;
          				log_level = events::Log::Warning;

This file has been truncated. show original

Jstroup · June 12, 2025, 11:15pm

Thank you for investing the time in this.

If bit 5 and bit 7 both respond to the value of EKF2_REQ_HDRIFT then perhaps there’s a mistake in the program logic. You can’t raise one and lower the other. Or maybe there’s something else going on in the code. It’s been a long time since I was a programmer - but I’m pretty sure this represents a problem.

Is it possible to bring it to the attention of the DEV who wrote this to take a look?

And what happened to the option that shows up for bit 9? It would be helpful to know something about the “spoofing” protection being provided.

Lastly - EPH and EPV are not acronyms I’m familiar with. If we’re relying on the codebase to explain how this works in the WIKI, then I’d suggest a bit more information be added to the code for sake of the WIKI.

Also - I tried to go back and edit my mistake of writing “EK2” instead of “EKF2”. The forum wouldn’t let me edit these. As these posts stay as a record for future research by others - do you know if it’s possible to go back and edit this?

Many thanks!

dakejahl · June 15, 2025, 9:21pm

Can you attend the dev call on Wednesday to discuss? This is the best place to get the attention of the developers.

BTW this PR recently went in which relaxes the GPS checks for EKF fusion pre-flight, in case this is related to your issue

github.com/PX4/PX4-Autopilot

[EKF2] Run simplified GNSS checks after initial fix

main ← pr-ekf2_simplified_gnss_checks

opened 08:29AM - 23 May 25 UTC

bresch

+39 -3

requires https://github.com/PX4/PX4-Autopilot/pull/24908 ### Solved Problem …Thresholds of GNSS checks are supposed to be tight enough to make sure the drone starts with a good initial fix. However, currently, degradation of a single metric also stops the fusion (e.g.: high DOP) when other metrics are still good. ### Solution Add a "simplified" list of checks with large (arbitrary) thresholds. Those values can be discussed, but hopefully we can agree on a common value to avoid additional parameters. ### Changelog Entry For release notes: ``` Improvement: Simplified GNSS checks after initial fix ``` ### Test coverage unit tests @haumarco flight tested

Topic		Replies	Views
Distance Sensor faulty readings affecting local position estimate significantly (PX4 v1.11.3) v1.11	1	659	December 20, 2023
PX4 Sync / Q&A: Oct 30, 2024 PX4 Autopilot	0	113	October 29, 2024
PX4 Dev Call: October 14, 2020 PX4 Autopilot	1	464	October 14, 2020
PX4 Sync / Q&A: July 3, 2024 PX4 Autopilot	0	117	July 3, 2024
Frequent local position loss despite good GPS PX4 Autopilot	5	92	May 1, 2025

Wiki errors for EK2_GPS_CHECK

Related topics