This moves us towards being able to compile the GPS library without having the MAVLink headers available. We shouldn't need those headers when building for Periph.
If the headers are available then we ensure our values match mavlink so we can do a simple cast from one to the other
The initialisation of the GPS_Fix enumeration is made from the mavlink headers.
We should probably move away from this, converting from our own enumeration to the mavlink enumeration when required (emitting mavlink packets and receiving in AP_GPS_MAV)
This means we don't need the goto to handle the case of a detected GPS,
and it also allows for restructure remove the "else" statements, which
will allow compilinmg out the uBlox driver
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 swaps to using an AP_Enum for the SBAS type, and fixes up the fact
that the prearm/failure reasons should be using the config step, rather
then the init blob index
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
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