This fixes a configuration problem with SBF unit's where sometimes we
fail to detect the GPS unit continously, until it's been manually
configured. This was tested by doing a hard reset to the GPS unit.
This also now accepts a set of defines from the hwdef, or build
environment, which allows us to specify extra config options.
Also add a static assert and some docs on the fact that blending only
works with 2 actual recievers at the moment
Also a small optimization to not call get_rate_ms() twice
if the accuracies reported are very low then we can do a division by
zero and this results in a constraining NaN for GPS vertical velocity
filter in NavEKF3_core::calcGpsGoodToAlign
this improves the display on the GCS when the GPS has not yet been
found. This is particularly important after a reboot, as otherwise the
GCS may display stale information from the previous boot
this detects GPS data lag, and if 5 samples in a row are lagged by
more than 50ms beyond the expected lag for the GPS then we declare the
GPS as unhealthy.
This is useful to detect users who have asked for more data from the
GPS then it can send at the baudrate that is being used. The case that
led to this path was a F9 GPS with GPS_RAW_DATA=1 at 115200 baud. In
that case the UART data is quickly lagged by over 1s
when you have a moving baseline pair of ublox GPS modules and the
rover GPS does not have full fixed RTK lock on the base GPS then we
should not use it as our primary GPS as it's position and velocity can
be badly affected by the attempts of the GPS to gain a fixed lock.
This was observed in a flight with two F9P GPS, where the GPS velocity
data from the rover GPS went way off when it lost full RTK lock. It's
status stayed at 4, so it was selected as the primary GPS
Peter Barker
Michael du Breuil
Patrick José Pereira
E Thomas
Michael Oborne
Andrew Tridgell
Ari Krupnik
Hwurzburg
Dr.-Ing. Amilcar do Carmo Lucas
Iampete1
murata
Donione
yaapu
Siddharth Purohit
Tom Pittenger