How GNSS-Aided Inertial Navigation Works in Commercial Drones

On this page

• The propagate-and-update cycle
• What the estimator is actually estimating
• Loose, tight, and deeper coupling
• Why time alignment matters
• Frames, mounting, and lever arms
• How the filter decides whether to trust GNSS
• Initialization and observability
• What better GNSS does and does not fix
• Installed-system verification

The propagate-and-update cycle

An aided inertial estimator repeats a cycle with two different cadences.

Propagation: At each IMU increment, the estimator uses measured angular motion to update orientation. It transforms measured specific force into the navigation frame, accounts for gravity, and integrates the result into velocity and position. It also propagates an uncertainty model. Bias, noise, scale-factor error, timing error, and uncertain initial conditions make that uncertainty grow.

Measurement update: When a GNSS observation becomes available, the estimator predicts what the receiver should have measured from its current state. It compares prediction with observation, evaluates the difference against expected uncertainty, and then accepts, down-weights, or rejects the update. An accepted update corrects position and velocity directly and can also improve attitude and inertial-bias estimates through modeled relationships.

NASA's short INS/GPS integration tutorial develops this sequence from inertial measurements through dead reckoning and a Kalman-filter update. Its worked example is deliberately simplified and two-dimensional. It is useful for the mechanism, not as a performance model for a three-dimensional commercial drone.

The word fusion sometimes hides this structure. A Kalman filter does not blindly average GNSS and inertial positions. It uses a dynamic model and a measurement model to estimate how much each observation should change the state and its covariance. If the models, timestamps, frames, noise assumptions, or installation parameters are wrong, mathematically valid software can still produce a poor navigation result.

What the estimator is actually estimating

A useful commercial-drone navigation state normally extends beyond latitude, longitude, and altitude. Depending on the implementation, it may include:

• three-dimensional attitude;
• velocity and position in a defined navigation frame;
• gyroscope and accelerometer biases;
• magnetic-field and magnetometer-bias states;
• barometer bias or terrain height;
• wind or airspeed-related states;
• GNSS receiver clock terms in a tightly coupled design; and
• covariance or another representation of uncertainty.

These are estimates, not independent sensor readings. Some are directly observable from a measurement under suitable geometry. Others become observable only through vehicle motion and the way an error affects multiple measurements. For example, GNSS velocity during sufficiently informative motion can help the filter distinguish yaw error from horizontal accelerometer bias. Hovering in place may provide much less information for that distinction.

The VectorNav GNSS/INS primer describes how an accelerometer error enters velocity and position integration and how GNSS position and velocity can constrain those errors. It is a manufacturer educational source. Its conceptual relationship applies broadly; its product-related accuracy examples are not treated here as universal UAS performance.

An estimator should also report whether states are initialized, aided, valid, or recently reset. A position number without age, frame, uncertainty, source, and status is an incomplete interface for flight-mode logic.

Loose, tight, and deeper coupling

Coupling describes where GNSS information enters the combined estimator. The terms are useful only when the actual measurement path is documented.

Many small-drone autopilots use a loosely coupled pattern: a separate GNSS receiver publishes position, velocity, time, and quality, and the flight computer's estimator fuses those outputs. A module sold as an integrated GNSS/INS may perform tight coupling internally and export only the combined solution. Either can be appropriate. The practical questions are who owns each validity decision, which raw evidence is logged, and how the downstream autopilot detects a degraded or reset solution.

Tight coupling is not automatically more accurate, safer, or suitable for every mission. It can use information that a stand-alone receiver solution would discard, but it also expands the verified software and measurement-model boundary. Ask which signals and constellations participate, which corrections are applied, which error states are estimated, and which integrity assumptions the claimed behavior requires.

The FAA's active AC 20-138D record includes guidance that distinguishes stand-alone or loosely coupled inertial integration from tightly coupled INS/GNSS integration. The circular concerns airworthiness approval of conventional aircraft positioning and navigation systems. It is not a small-UAS approval route, but it is authoritative evidence that coupling level changes the integration and assurance problem.

Why time alignment matters

The estimator must apply a measurement at the time the physical observation was valid, not merely when a message arrived. GNSS signal processing, receiver output scheduling, serial transmission, middleware, buffering, and task scheduling all add delay. IMU acquisition and filtering add their own delay.

Consider a drone moving at 15 meters per second. A 100-millisecond timing error corresponds to 1.5 meters of travel before considering turns or acceleration. That arithmetic is an illustration, not an allowable limit. During rotation, an antenna offset from the estimator reference point also has a velocity that must be evaluated at the correct time.

Specify at least five separate timing properties:

1. sensor sample time;
2. device timestamp and its clock domain;
3. measurement-processing delay;
4. message arrival time and variable transport delay; and
5. estimator output time or prediction horizon.

PX4's EKF2 navigation documentation provides a concrete implementation example. It buffers sensor data, performs fusion on a delayed horizon, and propagates the state forward with IMU data for use by current control loops. It also exposes sensor-delay configuration. This does not mean every PX4 configuration is correctly timed; it shows the kinds of mechanisms an integration review should find.

A pulse-per-second signal or hardware timestamp can align clocks, but only if the complete path uses it correctly. A high message rate does not repair an old or inaccurately timestamped observation. Timing should be measured end to end under processor, bus, logging, and communications loads representative of the installed aircraft.

Frames, mounting, and lever arms

The IMU senses motion at its physical location and along its physical axes. The GNSS antenna observes motion at its phase center. The flight controller may define position and velocity at the IMU, center of gravity, or another vehicle reference point. These locations are not interchangeable during rotation.

A lever arm is the measured vector between reference points, expressed in a declared coordinate frame. If an antenna is mounted away from the IMU, aircraft rotation creates antenna velocity even when the chosen vehicle reference point has no translational velocity. A filter that assumes the points are coincident can interpret that rotational motion as a navigation inconsistency.

PX4's official GNSS/compass mounting guidance gives a useful installed example: it documents receiver offsets relative to the vehicle center of gravity and explains why uncompensated rotational motion can cause accurate GNSS velocity to disagree with the estimator. The exact parameter names and reference point are implementation-specific; the physical effect is general.

Close these geometry items explicitly:

• IMU axes relative to the defined vehicle body frame;
• GNSS antenna phase center relative to the estimator output point;
• additional antenna baseline and orientation for GNSS-derived heading;
• sensor mounting tolerance and structural movement;
• sign, units, axis order, and coordinate-frame convention; and
• whether the published position refers to the antenna, IMU, center of gravity, or another point.

Measure offsets on the as-built aircraft. A drawing coordinate or nominal CAD location is not enough if brackets, payloads, antenna ground planes, or service changes alter the installation.

How the filter decides whether to trust GNSS

Receiver status is one input to the decision, not the whole decision. Satellite count, fix type, dilution of precision, reported accuracy, correction status, signal quality, and data age can gate initial use. Once fusion begins, the estimator also compares measurements with its inertial prediction.

The difference between an observed measurement and its predicted value is commonly called an innovation or residual. The filter evaluates that difference relative to predicted measurement uncertainty. A large innovation may indicate bad GNSS, a bad inertial prediction, incorrect timing, wrong sensor geometry, underestimated noise, or a real state change the model did not capture.

Acceptance logic creates a tradeoff. A narrow consistency gate can reject valid measurements during aggressive dynamics or a poorly modeled condition. A wide gate can accept a plausible but harmful jump. Inflating assumed noise can make the solution look statistically consistent while reducing how strongly useful measurements correct it. Threshold changes need evidence, not just a flight that stops raising warnings.

Good integration exposes:

• receiver-reported quality and correction state;
• measurement age and selected GNSS source;
• position and velocity innovations and their test ratios;
• aiding acceptance, rejection, timeout, and recovery events;
• estimated uncertainty before, during, and after a transition;
• state resets or origin changes; and
• the flight modes and downstream consumers affected.

The system must address misleading information as well as missing information. A cleanly absent GNSS message can be easier to handle than a smoothly biased position that passes superficial quality checks. Multi-sensor agreement is evidence only when the sensors do not share the same error source.

Initialization and observability

Before a full GNSS-aided navigation state is usable, the estimator needs initial attitude, position, velocity, time, and sensor-bias information within defined limits. It may estimate gyro bias while stationary, use gravity for initial tilt, establish position and velocity from GNSS, and obtain heading from a magnetometer, dual GNSS antennas, motion, or another source.

Initialization is not a single “GPS lock” flag. A receiver can have a position while the vehicle heading remains uncertain. An estimator can have a valid attitude while global position is not initialized. Preflight logic should tie each flight mode to the specific states and quality it needs.

Observability also changes with motion. A stationary vehicle offers good evidence for some bias and gravity relationships but little for others. Straight-line motion may not separate all heading, wind, and bias errors. Deliberate excitation can make states observable during testing, but an operational aircraft may not be able to repeat those maneuvers during every recovery.

Document how long alignment is expected to take, which conditions can prevent it, what the operator sees, and whether moving initialization is supported. Test hot start, cold start, stored-state use, loss and restoration of aiding, and restarts after the aircraft has changed position.

What better GNSS does and does not fix

Multi-frequency, multi-constellation, differential, real-time kinematic, or precise-point techniques can improve particular GNSS error terms under their required conditions. They do not remove inertial bias, vibration, clock, mounting, frame, lever-arm, software, or fault-management errors.

Centimeter-level position claims can make neglected integration terms more visible. If the receiver reports a precise antenna position while the estimator assumes that position is the vehicle center, rotation can dominate the claimed measurement precision. If correction data becomes stale, a solution label may change before the downstream system responds.

Separate these questions:

• accuracy: how close the estimate is to the defined truth reference;
• precision or repeatability: how tightly results cluster;
• availability: how often the required output can be produced;
• continuity: whether it remains available through the operation;
• integrity: whether unsafe or misleading output is detected and indicated within the required time; and
• latency: how old the information is when it reaches the consumer.

A high-accuracy receiver specification does not establish the other five. Nor does a fused solution prove that common GNSS dependencies have been removed. The installed architecture may feed GNSS position, velocity, or time into multiple functions that appear independent.

Installed-system verification

Component data sheets and estimator simulation are necessary evidence, but they do not close the installed navigation boundary. Build a verification matrix that connects each requirement to the exact aircraft configuration, method, expected result, captured data, and acceptance authority.

NASA's integrated UAS CNS architecture report separates navigation sources, inertial propagation, updates, and vehicle-system feedback. It is a research architecture, not a mandated commercial-UAS design. Its value here is the end-to-end view: navigation evidence must reach the guidance, control, health, operator, and recordkeeping functions that consume the solution.

Tests should include more than total GNSS removal. Exercise delayed measurements, plausible position ramps, velocity disagreement, correction loss, antenna masking, poor geometry, receiver restart, stale time, inconsistent dual receivers, and restoration after a long outage. Confirm not only estimator output but also mode eligibility, operator indication, control response, and logged cause.

The GNSS-loss operating guide carries those findings into aircraft-type contingencies, operator indications, and guarded recovery. If analysis shows the unaided interval is limited by the inertial measurement source, the commercial UAS IMU selection guide provides the component requirement and evidence gate.

An integration gate for commercial UAS

A GNSS-aided INS is ready for an aircraft configuration only when its contract is closed across measurement, estimation, and use. At minimum, approve:

1. the required navigation states and their reference frames;
2. the GNSS and inertial measurements actually fused;
3. sample timing, clock alignment, latency, buffering, and prediction;
4. sensor orientation, antenna phase center, lever arms, and output point;
5. initialization and aiding conditions;
6. measurement uncertainty, consistency gates, rejection, and recovery logic;
7. valid, degraded, unaided, reset, and unavailable state definitions;
8. downstream flight-mode, operator-display, and logging behavior;
9. redundancy and common-cause boundaries; and
10. verification evidence for the installed hardware, software, configuration, payload, and operating envelope.

This gate prevents a common category error. GNSS plus an IMU is a parts list. GNSS-aided inertial navigation is a timed, calibrated, monitored estimator whose outputs and transitions have been verified in the aircraft that will use them.

Frequently asked questions

Does a GNSS-aided INS keep working when GNSS is lost?

It can continue inertial propagation, but position and velocity uncertainty grow without sufficient aiding. The useful duration depends on the sensors, estimator, initialization, motion, environment, other observations, and the mission's error limits. It is not established by the GNSS/INS label.

Is tightly coupled GNSS/INS always better than loose coupling?

No universal ranking is valid. Tight coupling can use lower-level observations and partial satellite geometry, while loose coupling offers a clearer receiver solution boundary. Required performance, integrity, interfaces, software assurance, logging, and verification determine the appropriate architecture.

Why does an estimator need both GNSS position and velocity?

They constrain different parts of the propagated state. Velocity can reveal motion disagreement promptly and can help estimate attitude or bias under suitable dynamics. Position constrains accumulated displacement. The exact benefit depends on measurement quality, timing, geometry, and the filter model.

Is RTK the same as inertial navigation?

No. RTK is a GNSS positioning technique that uses corrections and carrier-phase information under defined conditions. An INS propagates attitude, velocity, and position from inertial measurements. A system can fuse RTK-capable GNSS with an INS, but each function retains its own dependencies and failure modes.