In the previous article, we explained the practical steps for EKF tuning. In this article, which is FC15, we will cover the implementation of GPS and INS integration. While we explained the theory in NAV10, this article focuses on the specific settings and implementation for ArduPilot and u-blox.
Selection of u-blox Modules
We will compare u-blox GNSS modules that have a proven track record in ArduPilot.
The u-blox M8N has long been the standard GNSS for drone flight controllers. It supports GPS/GLONASS/Galileo/BeiDou, has a maximum update rate of 10Hz (single GNSS) or 5Hz (multi-GNSS), a CEP of 2.5m, and costs around $15 to $30. It is still installed on many aircraft today, and the ArduPilot driver is mature.
The u-blox M9N is the current standard choice. Compared to the M8N, it has improved reception sensitivity and acquisition speed, a maximum update rate of 25Hz (single GNSS), and improved multi-GNSS simultaneous reception performance. It comes in a small package (2.4×2.4mm LCC), making it easy to integrate into GPS/GNSS modules. The price is $15 to $40.
The u-blox F9P is the highest-performance module with support for high-precision RTK. It supports GPS/GLONASS/Galileo/BeiDou, has a horizontal accuracy of 0.01m+1ppm when RTK is fixed, a maximum update rate of 20Hz, and allows for yaw estimation from two antennas in Moving Baseline mode. The price is $150 to $250. It is widely used in industrial, precision agriculture, and surveying applications, and ArduPilot's RTK support is complete.
As a selection guideline, the M9N is appropriate for standard industrial drones, while the F9P is suitable for precision landing, surveying, and compass-free designs.
Optimizing u-blox Settings
Settings for u-blox modules are performed via the UBX protocol, and ArduPilot automatically sends the optimal settings. However, it is useful to manually check and adjust some settings.
Configure the constellation using u-center (u-blox's configuration tool) or the GPS_GNSS_MODE parameter in ArduPilot. GPS_GNSS_MODE=0 is automatic (ArduPilot selects the optimal settings), 1=GPS+SBAS, 3=GPS+Galileo, 7=GPS+Galileo+GLONASS, etc., specified via a bitmask.
Enabling all constellations (GPS+GLONASS+Galileo+BeiDou) maximizes the number of satellites, but the update rate decreases. With the M9N, the update rate is capped at 5–10Hz when four constellations are enabled. Choose your settings based on whether you prioritize securing the number of satellites in urban areas or prioritizing the update rate.
SBAS (Satellite-Based Augmentation System) is set via the GPS_SBAS_MODE parameter. In Japan and Asia, MSAS/QZSS are available, and horizontal accuracy is improved through differential GPS correction. It is enabled by default (automatic) in ArduPilot.
The update rate is set using the GPS_RATE_MS parameter. By changing it from the default 200ms (5Hz) to 100ms (10Hz), the EKF GPS observation update frequency doubles. For modules M9N and above, 10Hz is the practical upper limit. The F9P supports up to 20Hz.
Use the GPS_SAVE_CFG parameter to confirm the use of the UBX binary protocol. ArduPilot recommends using UBX over NMEA, as it allows for the acquisition of dynamic accuracy information via hAcc and sAcc.
GPS Parameter Settings in ArduPilot
We will systematically organize the GPS-related parameters in ArduPilot.
GPS_TYPE is the setting for the GPS receiver type. For u-blox, set GPS_TYPE=2. In a dual GPS configuration, GPS_TYPE2 must also be set.
GPS_AUTO_CONFIG controls whether ArduPilot automatically configures the GPS receiver at startup. The default is 1 (automatic configuration), where ArduPilot automatically sends the update rate, UBX protocol, constellations, etc.
GPS_MIN_ELEV is the minimum elevation angle for GPS satellites. The default is 5 degrees. Since low-elevation satellites are susceptible to multipath interference, increasing this to 10–15 degrees in urban areas can improve accuracy.
GPS_HDOP_GOOD is the HDOP threshold at which ArduPilot determines the GPS signal quality to be "good." The default is 1.4. Once the value is below this, it is permitted for use in position control.
GPS_DRV_OPTIONS is an additional configuration flag for GPS receivers. Bit 0 forces the use of UBX, bit 1 enables SBAS, and bit 5 optimizes the update rate for GPS+GLONASS combinations, among other settings.
Dual GPS Configuration
This section explains the configuration for installing two GPS units to ensure redundancy in industrial flight controllers.
ArduPilot has two GPS ports: GPS1 and GPS2. Dual GPS is enabled by setting GPS_TYPE=2 (for GPS1) and GPS_TYPE2=2 (for GPS2).
GPS_AUTO_SWITCH sets the switching method when using dual GPS. GPS_AUTO_SWITCH=0 is manual (GPS1 only), 1 automatically selects the one with better accuracy, 2 uses GPS2 only for yaw estimation (in combination with F9P Moving Baseline), and 3 is a blend mode that combines GPS1 and GPS2.
The blend mode (GPS_AUTO_SWITCH=3) integrates position estimates from both GPS units using weighting based on accuracy. While this improves position accuracy and stability compared to a single GPS, note that spoofing resistance decreases if both are placed in the same electromagnetic environment.
Regarding physical placement, positioning the two GPS antennas apart—either front-to-back or side-to-side on the airframe—places them in different electromagnetic environments, which can mitigate the impact of interference on one of the GPS units.
Basics of RTK-GPS Configuration
While this will be covered in detail in FC16, the basics of RTK configuration are summarized here.
ArduPilot's RTK configuration enables F9P RTK mode by setting GPS_TYPE=17 (uBlox moving baseline rover) or GPS_TYPE=18 (uBlox moving baseline base).
The transmission path for RTCM correction data is via MAVLink from the GCS to the aircraft (RTCM injection). RTCM correction data is sent from the Mission Planner's RTK/GPS Inject tab. A common configuration involves receiving RTCM corrections from a ground reference station (a fixed F9P or NTRIP) and forwarding that data to the FC via MAVLink.
GPS_MB1_TYPE is the base GPS setting for Moving Baseline (yaw estimation). When configuring a Moving Baseline with two F9Ps, set GPS1 to Rover mode and GPS2 to Base mode. The longer the distance (baseline) between the two units, the better the yaw accuracy; 30cm or more is recommended.
Evaluating GPS and INS Integration Quality
This section explains how to evaluate the quality of GPS-INS integration using actual logs.
To check GPS signal quality, verify GPS.HDop and GPS.NSats in the logs. HDop < 1.5 and NSats > 12 are indicators of a good state. In environments where HDop > 2.0 persists, the accuracy of GPS-INS integration will degrade.
Continuous evaluation of GPS velocity innovation NKF4.SV was explained previously. As additional context here, if SV is large immediately after takeoff, it may indicate that the GPS update rate is too low. Changing GPS_RATE_MS from 200 to 100 may improve this.
The discrepancy between GPS position and EKF position can be checked as the difference between GPS.Lat/Lng and NKF1.PN/PE. It is normal for the EKF position to transition more smoothly than the GPS position (due to the EKF filtering effect), but if there is a systematic offset, it may be caused by hard-iron calibration or magnetic interference on the airframe.
GPS denial testing is a critical verification item in design. Intentionally block the GPS signal during flight (by disconnecting the hardware antenna or using a shielded box) to check EKF behavior. Since ArduPilot falls back to a mode equivalent to Alt Hold after GPS loss, verify that this behavior matches the design. Simulation in SITL is also effective.
Relationship between GPS_GNSS_MODE and EKF Accuracy
This section summarizes the impact of constellation selection on EKF accuracy.
An increase in the number of satellites has the same effect as an equivalent reduction in the EKF's GPS observation noise R-matrix. GPS position accuracy with N satellites is approximately proportional to CEP/√(N/4). With 20 satellites from GPS+GLONASS+Galileo, a position accuracy improvement of approximately √(20/8) ≈ 1.6 times can be expected compared to 8 satellites from GPS alone.
For optimization in urban canyons, a combination of increasing GPS_MIN_ELEV to exclude low-quality, low-elevation satellites and decreasing GPS_HDOP_GOOD to tighten the HDOP threshold for determining good quality is effective.
Utilizing BeiDou is particularly effective in Japan and the Asian region. BeiDou satellites are frequently observed at high elevations over Asia, and the GPS+BeiDou combination provides a satellite count increase effect similar to GPS+Galileo in Europe.
EKF and GPS Latency Compensation
GPS data latency has a non-negligible impact on EKF accuracy.
The latency of u-blox GPS data is the sum of the receiver's internal calculation time (50–100ms) and the UART transfer time (dependent on baud rate and data volume). When an M9N is connected via a 115200bps UART, the transfer time for a UBX-NAV-PVT message (100 bytes) is approximately 7ms. The total latency is around 50–100ms.
EK3_GPS_DELAY_MS is the parameter for GPS data latency compensation. The default is 220ms. Measuring the actual latency using an oscilloscope or the timestamp of the TX message and setting it to the measured value will improve compensation accuracy.
If compensation is insufficient, NKF4.SV will increase during phases with large velocity changes (rapid acceleration, rapid deceleration). This is a signal that the GPS Delay setting needs adjustment.
Improvements in high-speed communication can be achieved by increasing the GPS UART baud rate from 115200 to 230400 or 460800 to reduce transfer latency. The baud rate can be changed via bit settings in GPS_DRV_OPTIONS.
ARMING Checks and GPS Quality
ArduPilot arming conditions include settings related to GPS quality.
When ARMING_CHECK=1 (default, all checks enabled), GPS-related checks include having a GPS Fix (3D Fix or better), HDOP < GPS_HDOP_GOOD (default 1.4), and number of satellites > 6.
For industrial applications, GPS quality checks can be relaxed by individually disabling them via ARMING_CHECK_GPS_CONFIG. For fully indoor flight (no GPS used), GPS-related checks can be disabled to allow arming, and EK3_SRC should be set to ExternalNav.
Regarding the relationship between flight modes and GPS requirements, even if GPS quality is insufficient, it does not affect ALT_HOLD or STABILIZE, but LOITER, AUTO, and GUIDED cannot be used unless GPS quality is good. EKF3 having the pos_horiz_abs flag set is a prerequisite for these modes.
Implementation Checklist
The following are the confirmation items for GPS-INS integration implementation.
For hardware design confirmation, check if the GNSS antenna is placed at least 10cm away from the FC, if power noise countermeasures are sufficient when the antenna is integrated into the same module as the compass, and if the two antennas in a dual GPS setup are pointing in different directions.
For software configuration confirmation, check if GPS_TYPE is set correctly, if the constellations to be used are set in GPS_GNSS_MODE, if GPS_RATE_MS is set according to the aircraft's application, and if the measured latency is set in EK3_GPS_DELAY_MS.
For operational verification, check if GPS.NSats > 12 and GPS.HDop < 1.5 are achieved in an outdoor open-sky environment, if NKF4.SV is stable at 0.2m/s or less, and if the EKF fallback behavior during a GPS denial test is as designed.
Summary
Practical GPS-INS integration in ArduPilot consists of four elements: u-blox module selection (M9N standard, F9P high-precision), constellation settings (balance between satellite count and update rate), dual GPS redundancy, and latency compensation using EK3_GPS_DELAY_MS. Continuous monitoring of GPS quality via NKF4 innovation statistics and verifying EKF fallback behavior during GPS-denied tests determine the completeness of the implementation. In the next installment, FC16, we will explain RTK-GPS—F9P configuration, RTCM correction delivery, and practical accuracy verification.