AP_NavEKF3: ensure EK3 does not read GPS when disabled #27195
Conversation
| @@ -542,6 +542,11 @@ void NavEKF3_core::readGpsData() | |||
| // check for new GPS data | |||
| const auto &gps = dal.gps(); | |||
|
|
|||
| if (frontend->sources.getPosXYSource() != AP_NavEKF_Source::SourceXY::GPS) { | |||
There was a problem hiding this comment.
Although it's unusual a user could enable only altitude or only velocity (xy or z) while not using xy position so I think we need a more fine grained method to disable it. Also remember that even if the active source isn't GPS, it is still possible if EK3_SRC_OPTIONS = 1 (Fuse all velocities) that GPS velocities from another source set (e.g. not the active source set) could be used.
| @@ -230,7 +230,8 @@ bool NavEKF3_core::getPosNE(Vector2f &posNE) const | |||
| // In constant position mode the EKF position states are at the origin, so we cannot use them as a position estimate | |||
| if(validOrigin) { | |||
| auto &gps = dal.gps(); | |||
| if ((gps.status(selected_gps) >= AP_DAL_GPS::GPS_OK_FIX_2D)) { | |||
| if (frontend->sources.getPosXYSource() == AP_NavEKF_Source::SourceXY::GPS | |||
There was a problem hiding this comment.
One concern is that the position may jump as the user changes between source sets. So a source set that includes GPS will show the latest GPS position but if the user then switches back to external nav, it'll jump back to the last good position estimate.
I actually agree with this change or something like it. I've always thought it odd that the EKF3 sometimes reports the raw GPS position instead of the EKF position. We already report the raw GPS position to the GCS so I'm not sure we really need to report it again through the EKF. That's probably too big a change for the GCSs to absorb though.
There was a problem hiding this comment.
I actually agree with this change or something like it. I've always thought it odd that the EKF3 sometimes reports the raw GPS position instead of the EKF position. We already report the raw GPS position to the GCS so I'm not sure we really need to report it again through the EKF. That's probably too big a change for the GCSs to absorb though.
Resolving that problem is complicated by the fact that the EKF can return a position estimate even when it is feeling ill. It will do this if it has ever managed to get an origin (i.e. be happy with where it is), and when the GPS is not capable of providing a location.
What that means is that never returning a GPS from the EKF would mean changing the interface we use onto the backends to be more complicated. e.g. "EK3 give me a location". What, you can't do that? OK, "GPS, what about you?" Really?! OK, "EK3, please give me your best guess". I don't think it will be all that pretty.
There was a problem hiding this comment.
... you can't really use the data if getLLH returns false; if it has never seen an origin and the GPS isn't giving a location then false really means that it hasn't given you anything at all. This is the sort of case you might end up flying to 0,0
tridge
force-pushed
the
pr-ek3-disable-gps
branch
from
7f42611 to
41fce38
Compare
this allows for a change of source set to disable use of GPS. Otherwise the GPS will still be used even when the source set had no GPS enabled
This came up while testing dead-reckoning, where the vehicle was flying on EKF2 and we wanted EKF2 to retain GPS. We used a lua script to change EKF3 source set and expected that to stop the use of GPS for EKF3