this changes yaw handling in a few ways:
- GPS yaw now has a timestamp associated with the yaw separate from
the timestamp associated with the GPS fix
- we no longer force the primary to change to the UBLOX MB rover when
it has a GPS yaw. This means we don't change GPS primary due to GPS
loss, which keeps the GPS more stable. It also increases accuracy
as the rover is always less accurate in position and velocity than
the base
- now we force the primary to be the MB base if the other GPS is a
rover and the base has GPS lock
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
this allows for configuration of moving baseline with either uart1 or
uart2 for the RTCM data. Using uart2 requires an extra cable between
the two modules, but requires less uart bandwidth which is good when
DMA channels are low. Using uart2 also avoids the rtcmv3 parser, which
saves memory