GPS/Compass (landing page)¶
Copter/Plane/Rover support integration with GPS, Compass and other positioning technologies:
GPS/Compass¶
- ARK GPS
- ARK TESEO GPS
- Avionics Anonymous GNSS + Compass
- Avionics Anonymous Compass
- Beitain BN-220 GPS / BN-880 GPS + Compass Module
- CUAV Neo v2 Pro DroneCAN GPS
- CUAV Neo 3 Pro DroneCAN GPS
- CUAV Neo 3(M9N) GPS
- CUAV Neo 3X(Water proof) GPS
- CubePilot Here 2 DroneCAN GPS/Gyro/IMU/Baro
- Holybro DroneCAN M8/M9 GPS
- Holybro Micro M9N GPS Module
- Holybro Micro M10 GPS Module
- Holybro Nano Ublox M8 5883 GPS Module
- Holybro M8N (Pixhawk 4) GPS Module
- Holybro M9N GPS Module (UART)
- Holybro M9N GPS Module (DroneCAN)
- Holybro M10 GPS Module
- Holybro DroneCAN RM3100 Professional Grade Compass
- Matek DroneCAN AP_Periph GNSS M10-L4-3100
- Matek SAM-M8Q
- Matek M8Q-CAN/DroneCAN GPS+Compass+Baro+Airspeed I2C port
- mRo GPS, GPS+Compass,RTK, and DroneCAN modules
- mRo Locaton One DroneCAN GPS/Compass
- Qiotek DroneCAN GNSS M10 QMC5883
- Qiotek GNSS M10 QMC5883
- Qiotek DroneCAN RM3100 Compass
- Zubax GNSS 2: GNSS + Compass + Barometer
RTK GPS¶
These GPS can incorporate real time kinematic data, either internally generated or externally provided, to improve the precision of the position estimate from the normal GPS meter range down to the centimeter range (see RTK GPS Correction (Fixed Baseline)). This increased precision also allows for “Moving Baseline” yaw estimates using two devices on a vehicle with certain RTK GPSes (F9P based) or dedicated Moving Baseline GPSes. See GPS for Yaw (aka Moving Baseline).
- ArduSimple RTK GPS
- ARK MOSAIC-X5 RTK GPS
- ARK RTK Base
- ARK RTK F9P
- Blicube RTK GPS (Single Unit Moving Baseline NMEA)
- CUAV C-RTK 9P RTK Receiver
- CUAV C-RTK 9Ps RTK Receiver
- CUAV C-RTK2 PPK and RTK receiver
- CUAV C-RTK2 HP Heading and RTK receiver
- DATAGNSS GEM1305 RTK Receiver
- DATAGNSS NANO RTK Receiver
- Emlid Reach RTK Receiver
- CubePilot HERE 3/3+ DroneCAN RTK GPS/IMU/Compass
- CubePilot HERE 4 DroneCAN RTK GPS/IMU/Compass (see note below)
- CubePilot Here+ RTK Base/Rover Receiver
- CubePilot HEREPRO DroneCAN F9P RTK GPS/Compass
- Freefly RTK GPS Ground Station
- Foxteck AEROFOX F9P-RTK
- Hitec PositionPro GNSS
- Holybro DroneCAN H-RTK F9P Rover
- Holybro DroneCAN H-RTK F9P Helical
- Holybro RTK F9P Family
- Holybro RTK M8P
- Holybro RTK F9P Ultralight
- Holybro RTK ZED-F9P Rover (RM3100 Compass, Barometer, IP66 Waterproof)
- Holybro RTK NEO-F9P Family
- Holybro RTK Unicore UM982 GPS (Dual Antenna Heading)
- Holybro RTK mosaic-H GPS (Dual Antenna Heading)
- LOCOSYS HAWK R1 RTK GNSS / R2 RTK GNSS + Compass
- Qiotek DroneCAN RTK-F9P GPS
- Swift Navigation's Piksi Multi RTK GPS Receiver
- Septentrio AsteRx-m UAS RTK GPS
- Synerx MDU-2000 RTK + LTE GPS
- Trimble BD930 RTK GNSS
- Trimble PX-1 RTX GNSS+INS
Note
a version of firmware for the CubePilot HERE 4 DroneCAN RTK GPS is available here that includes evolving ArduPilot improvements.
Warning
It is important that a GPS be connected to the first SERIALx port that has its SERIALx_PROTOCOL
parameter set to “5” (GPS) since it will stop searching for GPS during bootup if not found on the first port configured for GPS protocol.
Moving Baseline (GPS for Yaw) Capable¶
- Ark RTK GPS <https://arkelectron.com/product/ark-rtk-gps/> Blicube RTK GPS (Single Unit Moving Baseline)
- CUAV C-RTK 9P RTK Receiver
- CUAV C-RTK 9Ps RTK Receiver
- CUAV C-RTK2 PPK and RTK receiver
- CUAV C-RTK2 HP Heading and RTK receiver
- CubePilot HERE 4 DroneCAN RTK GPS/IMU/Compass
- CubePilot HEREPRO DroneCAN RTK GPS/Compass
- Foxteck AEROFOX F9P-RTK
- Freefly RTK GPS Ground Station
- Holybro DroneCAN H-RTK F9P Rover
- Holybro DroneCAN H-RTK F9P Helical
- Holybro RTK F9P Family
- Holybro RTK F9P Ultralight
- Holybro RTK ZED-F9P Rover (RM3100 Compass, Barometer, IP66 Waterproof)
- Holybro RTK NEO-F9P Family
- Holybro RTK Unicore UM982 GPS (Dual Antenna Heading)
- Holybro RTK mosaic-H GPS (Dual Antenna Heading)
- Qiotek DroneCAN RTK-F9P GPS
- Synerx MDU-2000 RTK + LTE GPS
GPS Driver Options¶
Several GPS operating options are provided by the GPS_DRV_OPTIONS parameter. This parameter is a bit mask and allows multiple option selections at the same time:
bit 0: if set, will send RTK correction data from the first GPS directly to the second via the second’s UART port for GPS for Yaw (aka Moving Baseline), instead via the autopilot.
bit 1: if set, enable SBF moving baseline yaw using custom base and GPS_MB1 offsets.
bit 2: if set, use 115.2Kbaud for max serial data rate for those GPSes not capable of higher rates.
bit 3: if set, routes RTK data between two CAN GPSes via CAN instead of via the autopilot.
bit 4: if set, GPS reports altitude in ellipsoid height instead of height AMSL.
GPS Auto Switch¶
When using two GPS units there are a number of switching options that can be selected with GPS_AUTO_SWITCH.
- 0: Use Primary
Always use the primary GPS, this can be either the first or second as set with GPS_PRIMARY
- 1: Use best
Automatically select the best GPS, this is done based on GPS fix status (2D / 3D / rtk) if both GPSs have the same fix status the one with the larger number of satellites is used.
- 2: Blend
Blend is best suited for use with two identical GPS units, see GPS blending
- 4: Use primary if 3D fix or better
Use primary GPS as set with GPS_PRIMARY if it has a 3D fix or better. This should be used when two dissimilar GPS units are used, one high quality primary unit, and a secondary less accurate unit. In this case the high quality GPS will often have a better quality fix even if it has fewer satellites. Using ‘Use best’ in this case would result in using the poorer quality GPS and result in more switching between GPS units. Unlike ‘Use Primary’ this option still allows falling back to the secondary GPS if 3D fix is lost on the primary.
An additional variation with GPS switching is EKF3 affinity and lane switching. An EKF lane can be setup to use either GPS and the whole EKF lane is then switched based on its health. If the GPS_PRIMARY is used for a lane, and GPS_AUTO_SWITCH is enabled, then the lane will use GPS info as determined by the GPS_AUTO_SWITCH setting.
GPS Jamming Mediation¶
Setting the “JammingExpected”, EK3_OPTIONS bit 0, will change the EKF3 behaviour such that if dead reckoning navigation is possible it will require the preflight alignment GPS quality checks controlled by EK3_GPS_CHECK and EK3_CHECK_SCALE to pass again before resuming GPS use if GPS lock is lost for more than 2 seconds (presumably due to jamming). This is to prevent bad GPS data from being used, since the GPS data will be immediately used upon re-lock otherwise and could be corrupt.