Automatic PX4FLOW switch

Would it be possible to create new EKF_GPS_TYPE “GPS + PX4FLOW”.
Using GPS for navigaton and loiter when there is strong GPS signal and automaticly switch to PX4FLOW for loiter when GPS is useless… ?

Thank you


Since Copter 3.4 EKF fuses GPS and optical flow data, which means it will use the best information from both. If the GPS data isn’t good enough it won’t use it and rely on flow data.

Concerning the auto fall back, will the EKF will automatically switch from these states:

0 : use 3D velocity & 2D position from GPS
1 : use 2D velocity & 2D position (GPS velocity does not contribute to altitude estimate)
2: use 2D position
3 : no GPS (will use optical flow only if available)

So , depending how the GPS is degrading , will it switch from 0 to 1 to 2 and finally switch to no GPS (3) and the exclusively use the Optical Flow ?

And then when the GPS Signal is restored , does it do a progressive fusion in order no to ‘‘jump’’ ?

Please note that I am planning to experiment with this on EK3 and report back.


You are getting into details of the EKF I’m not completely sure about. But I think that it doesn’t work that way - either it uses GPS or not, but it uses information from the GPS to know how good velocity and position from it are, which then have an impact on the fusion process.

And yes, when GPS is restored it will start using GPS again.

@OXINARF Fair enough, thanks for your fast answer :smile:

The EKF’s do not fall back through steps 0 to 2 as described above. They will use GPs and flow data simultaneously if both are available and the combination of GPS data used is always 3D velocity and 2D position unless the EK2/3_GPS_TYPE or EK2/3_ALT_SOURCE parameters have been modified.

The EKF2 and EKF3 needs a minimum reported GPS quality before it starts using GPS, but once it starts using GPS, it will continue to use it as long as there is a 3D lock but does adjust weighting according to the receivers reported accuracy.

Because there have been some changes in code over the past few months that could have modified behaviour, I have just run the following test on current master a pixhawk+px4flow+ lidarlite+UBlox8 combo:

  1. Enabled EKF2 and 3, set the EK*_ IMU_MASK parameters to 1 and AHRS_EKF_TYPE to 3.
  2. Set the GPS_DELAY to 100
  3. Set GPS_TYPE to 0 to disable GPS
  4. Rebooted and waited for both EKF’s to report they were in relative position mode and using optical flow.
  5. Set the home position to current location so that an absolute position estimate could be monitored over MAVLINK
  6. Walked the test setup a few metres and back to the start point
  7. Set GPS_TYPE = 2 and waited for both EKF’s to report they were using GPS
  8. Repeated 6)
  9. Set GPS_TYPE = 0 and repeated 6)
    10 Set GPS_TYPE = 2

This test showed that each time GPS was gained the EKF’s local position reset to match the GPS, but when GPs was lost it continued to dead-reckon using optical flow. It also showed that optical flow fusion was used at all times and that the behaviour of EKF2 and 3 was identical. Here are the EKF2 and 3 optical flow and GPS position innovations from the test:

Here is the local position:

Both EKF’s also reported the same solution status:


Thanks Paul for this very informative and detailed explanation, funny how it sound so simple when its explained by the EKF master :wink:
I really appreciate that you took the time to document the steps of your test procedure , this valuable information should be be added to the wiki.

I think there is a significant problem in real life with the OF fallback. I’m testing gps jammer’s and AC’s ability to continue mission with OF when GPS navigation is jammed. In my tests, even if the OF works prefectly, the GPS jamming causes high velocity variance and sends EKF into failsafe (Land or Althold)… I’m trying to figuring out how can we prevent it (beside using gps only for position and not for velocity…)

There is some interest on the jammer since few days :wink:

Have you tried tweeking the GPS noise measurement (either on EK2 or EK3) :

Maybe a solution would be using a Companion Computer to ‘‘probe’’ the critical frequency using a SDR receiver and force t the OF mode when it sense an abnormal noise level ?

Good idea, I’ll test the EK2_POSNE_M_NSE tweaking,
For forcing, there is no need for a companion computer and SDR, we already have a powerfull RF analyzer on board (It’s the M8N Gps… :D, jamInd contains actual CW jamming levels…)

Thanks !

Hi @Eosbandi
Would you be able to take a look at Thank you very much

1 Like