ArduPilot configures a connected DroneCAN GPS based on its GPS Type.
Given parameter name changes, ArduPilot must be able to configure both new and old AP_Periphs, and new AP_Periphs have to cope with being configured by old ArduPilots.
this allows for redundent RTCM links (eg. WiFi and SiK links for light
show drones) without causing corruption into the GPS.
If the GPS_DRV_OPTION bit is set then we instantiate a separate RTCM3
decoder per mavlink channel, and only inject when we get a full packet
that passes the RTCM 24 bit CRC
Link GPS.Status to AP_GPS::GPS_Status enum
Remove units on fields set to Bytes which are not
Set the unit of GPS.GMS and GRAW.WkMS to ms (no unit specified before).
Change the unit of GPS.HDop and GPA.VDop from m to no-unit.
* Refactor checksum to unique function
* Clear uart before reading data
* Add ack/nack check
* Implement output disable before requesting GSOF data
* Improve debug message to have line number
* Use debug in more code
* Stop delaying in configuration
Signed-off-by: Ryan Friedman <ryanfriedman5410+github@gmail.com>
* Instead of hard coding to COM2, allow users to set it
* The enum is confusing, so this needs a wiki entry
* Use the same port in requestBAUD
* If the user configures an invalid param, send an error
* Add values for the GSOF COM ports
* Fix bug in RS232 being port 3 instead of port 0
* Use set_default for the typical user value when the GSOF driver is run
Signed-off-by: Ryan Friedman <ryanfriedman5410+github@gmail.com>
* This removes magic numbers of hard coding the hardware port and output
rate
* This also fixes configuring the incorrect hardware port
* Now, COM2 (TTL) is configured for GSOF output
* The data rate remains the same as before
Signed-off-by: Ryan Friedman <ryanfriedman5410+github@gmail.com>
when moving baseline is enabled the rover is slaved to the base for
position and velocity, adding no additional useful data. Only the yaw
comes from the rover
users with busy CAN bus often get significiantly lower GPS rates on a
moving baseline rover, preventing arming. This PR relaxes the required
frame rate as the EKF is quite happy with 3Hz yaw and the yaw is the
only data consumed from a moving baseline rover
this allows a lot more drivers to use the GPS_DRV_OPTION but to use
ellisoid height. Particularly useful for DroneCAN GPS modules
using ellisoid height instead of AMSL is useful in some specialised
application
Peter Barker
Andrew Tridgell
Andrew Piper
bugobliterator
Simon Hancock
Ryan Friedman
Michael du Breuil
Gone4Dirt
Mykhailo Kuznietsov