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
This does not yet:
- validate the receiver configuration
- manage timing out stale GPS heading info
- relPosNormalized usage isn't clear, which may defeat the STRICT_LENGTH_CHECK
The NMEA GPHDT sentence can be used to determine the vehicles bearing
instead of a compass even when the vehicle is stationary. This type
of GPS is normally very expensive and does the bearing using some sort
of phase ambituity algorithm.
See discussion here:
https://github.com/ArduPilot/ardupilot/issues/7331
we were getting some uninitialised variables. While it only showed up in
AP_SbusOut, it means we can't be sure it won't happen on other objects,
so safest to remove the approach
Thanks to assistance from Lucas, Peter and Francisco
This fixes the MAVLink reporting for unknown dops, and avoids the situation where a GPS driver could report a worse DOP then we could handle.
Also corrects an apparent error in the HIL_GPS MAVLink message, where we would always select the unknown dop value rather then provided DOP.
This commit adds:
- New driver for SBPv2
--- Support Piksi Multi, Swift Navigation's multi-band multi-constellation GPS
--- Proper parsing of SBP flags
--- Instant response to Piksi status changes (no more timeouts)
--- Support for Piksi Multi as a Single-Point-Positioning GPS or only onboard GPS
--- Incorporates horizontal and vertical accuracy estimates, and vdop.
- Updates driver for SBPv0
--- Continue support for previous Piksi
- Dispatches correct driver based on SBP version.
This includes these changes:
RATE_MS, RATE_MS2 parameter description Range minimum reduced to 50
_blend_health_counter is reset to 0 if blending is disabled
GPS_MAX_RECEIVERS is replaced with GPS_BLENDED_INSTANCE where appropriate
simplify all_consistent functions check of number of receivers
calc_blended_weights fix for initial check of how many receivers we have
remove unnecessary setting of GPS last time when blending fails
remove RebootRequired from AUTO_SWITCH param description
backends become friends so they can continue to access parameters held in frontend
get_rate_ms made private because only used by frontend
Also moved static arrays higher in cpp file
highest_supported_status will always return FIX_3D for blended or invalid instance
setHIL_Accuracy checks instance is 2 or less
send_mavlink_gps2_raw uses num_instances variable directly to avoid confusion with num_sensors
If the user sets a non-zero value of the delay it will be used in preference over the default value for that GPS type.
If the GPS type is unknown and the parameter is set to zero, then a default delay of 1 sample period will be used (eg 200ms for 5Hz).
