Reduce vulnerability of planes to bad GPS data #23010
Conversation
priseborough
force-pushed
the
pr-ekf-gps-check-fix
branch
4 times, most recently
from
d97cc8e to
8c508ab
Compare
|
Does same apply to dual GPS setups where primary GPS starts failing and ardupilot is only looking at the fix status and never changes over to the 2nd GPS unit. When using GPS altitude from primary high precision GPS we have experienced at least 3 crashes just like this:
Cause of loss of lock was antenna or antenna cable damage. GPS Autoswitch never switched over to backup and plane ended up in pieces. |
priseborough
force-pushed
the
pr-ekf-gps-check-fix
branch
from
9178463 to
de8d4a0
Compare
The system response to the fault condition you are describing is not addressed by these changes. Have you raised an issue and provided a log? The GPS selection code relies on the receivers correctly reporting their accuracy. If your primary GPS did report a bad vertical accuracy, then use of the GPS blending feature activated when GPS_AUTO_SWITCH = 2 may have helped. If height accuracy is critical for the GPS use, then GPS_BLEND_MASK should be set to 6 ( or 2) instead of 5 so that reported velocity and vertical position or vertical position only is used as t the criteria for weighting the two solutions. None of this will help if the GPS receiver is reporting good lock status and accuracy, but is outputting bad data as the GPS selector does not sanity check the data. If the GPS' own accuracy reporting cannot be relied on, the EKF can be set up so that each EKF instance (using it's own IMU) will use a separate GPS via the EK3_AFFINITY parameter and relying on the EKF voting/selection algorithm. If you use this feature, make sure your preferred GPS is being used by the EKF instance specified as the primary by the EK3_PRIMARY parameter. |
priseborough
changed the title
|
I've pulled in the patches from #23173 and used the simulated GPS jamming in one of the auto tests. This highlighted a vulnerability whereby of the GPS was providing a jam effected 3-D fix with lots of position error and the EKF was successfully dead reckoning, the DCM would be selected and the planes navigation controller would respond to the jam affected GPS position. This vulnerability has been fixed. |
libraries/AP_AHRS/AP_AHRS.cpp
Outdated
| @@ -1821,13 +1821,14 @@ AP_AHRS::EKFType AP_AHRS::active_EKF_type(void) const | |||
| if (hal.util->get_soft_armed() && | |||
| (!filt_state.flags.using_gps || | |||
| !filt_state.flags.horiz_pos_abs) && | |||
| !filt_state.flags.horiz_pos_rel && | |||
There was a problem hiding this comment.
this is a tricky one. It means that we are trusting the EKF to judge if it can provide a horizontal position. When flying in an area where jamming may be expected then this is obviously a good change. If flying in an area where jamming is not expected then I think it is far more likely that the EKF is wrong and the GPS is right (which is why this whole fallback to DCM logic is there). The EKF does sometimes go bad, either with vibration or bad yaw from GSF (especially if no compass).
Maybe we need an AHRS_OPTIONS bit for when we are flying in an area where jamming is expected?
|
@priseborough I think we need an AHRS_OPTIONS bit that enables protections against GPS interference. For now it would just change the DCM fallback decision, but could be used more extensively later |
|
@priseborough I've added AHRS_OPTIONS in this branch |
priseborough
force-pushed
the
pr-ekf-gps-check-fix
branch
from
c4632c1 to
e459e49
Compare
…city error is bounded
Explicitly test time taken to reset to GPS loss and regain of lock for copter without and plane with dead reckoning assistance.
These changes enable the EKF to use the last observable wind velocity vector estimate to synthesise an airspeed measurement if operating without an airspeed sensor and when all other measurement types that can constrain velocoty drift are lost. This enables the EKF to use dead reckoning to continue after loss of GPS when there is no air speed sensor fitted and without the need to set a default airspeed value. The logic used to fuse a default airspeed value has also been cleaned up and the call to FuseAirSpeed() from inside SelectBetaDragFusion() has been removed. AP_NavEKF3: Fix error in default airspeed observation variance AP_NavEKF3: Enable shadow fusion of airspeed when sensor is disabled
preparing for jamming simulation
this is based on some test logs from using a real jammer in controlled test flights
These changes prevent the EKF from consuming GPS data too soon when it is recovering from jamming if the EKF is able to navigate using dead reckoning.
…iour The AHRS will no longer switch to DCM if the EKF is doing dead reckoning with constrained velocity errors and there is a GPS fix so checking for the "EKF3 Active" message no longer works
the first option is to disable DCM fallback on fixed wing. This is suitable in environments with a high likelyhood of GPS interference
priseborough
force-pushed
the
pr-ekf-gps-check-fix
branch
from
e459e49 to
75bf81d
Compare
|
@tridge I rebased and included your patch for the AHRS_OPTIONS bit to disable the DCM fallback. |
|
@priseborough I've rebased this on master and pushed to this branch: |
|
@priseborough I've opened a new PR for sheparding this through CI: #24899 |
|
Hi |
When GPS interference is severe enough to result in loss of lock, the position and velocity errors can initially large when the interference reduces and the receiver regains lock. The existing code prioritises a fast reset and will use the first 3D fix available. Whilst this may be an acceptable risk if the receiver is doing inertial only dead reckoning with unconstrained velocity drift (eg copters without optical flow), planes using air data have there velocity drift constrained and should wait a few seconds for quality checks to pass.
The following figures show an example of this behaviour where interference during a flight has caused the GPS to lose lock and then it regains lock for one frame but with very large height and velocity errors.
The SITL testing of these changes also revealed that when no airspeed sensor is being used, planes are falling back to dead reckoning using DCM because the EKF was not able to constrain velocity error buildup in the direction of travel. A patch has been added which will continue navigating using the last estimated wind drift to synthesise an airspeed measurement if GPS is lost and airspeed sensor use is disabled or if use of a default airspeed has not been set using bit 7 of FLIGHT_OPTIONS.