The airframe carries the vehicle. The propulsion system moves it. The avionics system knows where it is, decides what to do next, and executes those decisions with enough precision and reliability that the mission is completed and the vehicle returns. Avionics is the nervous system of an unmanned vehicle — and like a nervous system, it is most visible when it fails. This module covers the architecture of a production-quality avionics system: the components, how they interact, and the design decisions that determine whether the system behaves predictably under normal conditions and gracefully under abnormal ones.

The avionics stack

A complete UAS avionics system consists of several layers, each with a distinct function. Understanding the layers separately is essential to designing the system coherently — confusion about which layer is responsible for a given function leads to designs where critical functions are either duplicated unnecessarily or omitted entirely.

The flight controller is the central processor: it reads sensors, runs the control algorithms, and outputs commands to the actuators. The sensor suite provides the raw measurements the flight controller needs to estimate the vehicle state. The navigation system fuses sensor data into a continuous state estimate — position, velocity, attitude, and attitude rate. The communication system links the vehicle to the ground control station for command uplink and telemetry downlink. The power system provides regulated, conditioned power to each subsystem. The payload interface connects mission equipment — cameras, sensors, transponders — to the avionics bus. All of these must be designed together; optimizing any one layer in isolation without considering its interfaces to the others produces an integrated system that underperforms the sum of its parts.

Autopilot platform selection

The autopilot is the hardware platform on which the flight controller runs. The choice of autopilot determines the available sensor interfaces, the processing power for running complex estimation and control algorithms, the software ecosystem, and the certification path for any application where regulatory approval is required.

The Cube/Pixhawk ecosystem (CubePilot — CubeOrange, CubeBlue, CubeOrange+) is the most widely used open-source autopilot platform in serious UAS development. The carrier board architecture separates the vibration-isolated IMU stack from the user-configurable I/O interfaces, allowing the same core autopilot to be adapted to a wide range of vehicle types through carrier board customization. The platform runs ArduPilot or PX4 firmware, both of which are mature, well-documented, and supported by large developer communities. The CubeBlue is the NDAA-compliant variant with US-sourced components, appropriate for US government programs. The CubeOrange+ adds a dedicated AI coprocessor for edge processing applications. Across the projects documented in the portfolio, the Cube platform has been used on fixed-wing, multirotor, VTOL, USV, and AUV programs — its adaptability is a genuine engineering advantage.

The Micropilot platform targets professional and commercial applications requiring higher certification levels and more deterministic real-time behavior than open-source platforms provide. It is a closed-source system with professional technical support and a documented reliability record in demanding programs. The all-additive Group-2 UAV used the Micropilot autopilot specifically because the program required professional-grade reliability assurance for a vehicle that was to be demonstrated to a defense customer.

Custom autopilot development — writing flight control software from scratch on a general-purpose embedded processor — is appropriate only for programs with highly specific requirements that no existing platform can meet, and with the engineering resources and schedule to develop and validate the software to the required standard. For the overwhelming majority of UAS programs, the correct answer is to use a mature platform and configure it for the application rather than developing from scratch.

Autopilot selection criteria Select the autopilot on the following criteria in order: certification requirements (if a specific standard is mandated, the platform must support it); sensor interfaces required (CAN, UART, SPI, I2C — confirm the hardware supports the sensors you need before committing); processing headroom for planned mission complexity; NDAA compliance requirement; and community/support availability for rapid troubleshooting. Do not select an autopilot because it is the most capable platform available. Select it because it is the most appropriate platform for the specific mission.

The sensor suite

The sensor suite provides the raw measurement data from which the navigation system constructs the vehicle state estimate. Each sensor has a specific role, characteristic errors, and failure modes that must be understood to design the sensor fusion architecture correctly.

The Inertial Measurement Unit (IMU) measures the vehicle's linear acceleration (accelerometer) and angular rate (gyroscope) in the body frame. It has no position information — it can only integrate to estimate position and attitude change over time. Integration errors accumulate: accelerometer bias produces velocity error that grows linearly with time, and position error that grows as the square of time. An IMU alone is useful for attitude stabilization on timescales of seconds; it is useless for navigation on timescales of minutes without external position correction.

The GNSS receiver (GPS, GLONASS, Galileo) provides position and velocity in the global reference frame, with typical accuracy of 1–3 m CEP for standard receivers and 2–5 cm with RTK correction. GNSS provides good position accuracy but poor short-term dynamic response — the update rate (typically 5–10 Hz) and latency are insufficient for high-bandwidth attitude control. GNSS and IMU are complementary: the IMU provides the high-rate, low-latency measurements needed for control; the GNSS provides the absolute position reference that prevents the IMU errors from accumulating without bound.

The barometric altimeter measures air pressure to estimate altitude. It is independent of GNSS and provides continuous altitude reference even in GNSS-denied environments, but it drifts with weather changes and is susceptible to pressure disturbances from the vehicle's own airflow. The magnetometer measures the local magnetic field to provide heading reference, but is susceptible to magnetic interference from motors, current-carrying wires, and nearby ferrous structures — proper isolation and in-flight calibration are essential. The pitot-static airspeed sensor measures differential pressure to derive indicated airspeed — essential for fixed-wing aircraft to maintain flight above stall speed, but susceptible to blockage by insects, moisture, and ice in adverse conditions.

Sensor fusion and the Extended Kalman Filter

No single sensor provides a complete, accurate, low-latency state estimate. Sensor fusion combines the measurements from multiple sensors, accounting for their individual error characteristics, to produce a state estimate that is more accurate and more reliable than any individual sensor could provide. The standard algorithm for this task in UAS avionics is the Extended Kalman Filter (EKF).

The EKF maintains a probabilistic estimate of the vehicle state — position, velocity, attitude, sensor biases — and updates that estimate each time a new sensor measurement arrives. At each update step, the filter weighs the new measurement against the uncertainty of the current state estimate and the known error characteristics of the sensor. A measurement from a high-accuracy, low-noise sensor (RTK GPS at 2 cm accuracy) is weighted heavily. A measurement from a high-noise sensor (a barometer during a dynamic maneuver) is weighted lightly. The result is a fused state estimate that converges toward the truth more reliably than any single sensor.

The practical consequence for avionics design: every sensor that feeds the EKF must have accurately characterized error statistics — noise standard deviations, biases, drift rates — and those statistics must match the actual sensor behavior in the operating environment. Incorrect noise parameters cause the EKF to either trust bad measurements too much (causing position jumps) or ignore good measurements too much (causing slow convergence). Proper EKF tuning is as important as sensor selection.

What happens to state estimation when GPS is lost
At GPS loss, the EKF continues to propagate the state estimate using IMU data only.
Accelerometer bias causes velocity error to grow at the bias rate — typically 0.01–0.05 m/s per second for a quality MEMS IMU.
After 30 seconds of GPS denial with a 0.02 m/s² accelerometer bias, velocity error is ~0.6 m/s and position error is ~9 m and growing quadratically.
The barometer continues to bound vertical position error. Horizontal position is unconstrained without GPS or an alternative horizontal position sensor.
Design implication: a vehicle expected to operate in GPS-denied environments must have an alternative horizontal position sensor — optical flow, radar altimeter, visual odometry, or terrain following — to prevent horizontal position divergence.

Flight modes

Flight modes define the level of automation provided to the operator for a given phase of flight. Understanding what each mode does — and more importantly what it does not do — is essential for designing a vehicle that behaves predictably across its intended operational envelope.

Manual / Acro: The autopilot passes stick inputs directly to the control surfaces with no stabilization. The pilot controls the vehicle attitude directly. Used during development testing and by experienced pilots for performance envelope expansion. Not appropriate for operational deployments where the operator may not be a skilled pilot.

Stabilize / Attitude: The autopilot maintains the commanded attitude — if the pilot releases the sticks, the vehicle levels itself. The autopilot is stabilizing attitude but not controlling position or altitude. The vehicle will drift in wind unless actively corrected by the pilot.

Altitude Hold: The autopilot maintains commanded altitude using the barometer and, where available, GNSS altitude. The pilot controls lateral position. Useful for payload operations where altitude must be consistent.

Loiter / Position Hold: The autopilot maintains both altitude and horizontal position. The vehicle holds its position in GPS coordinates, correcting for wind drift automatically. The pilot makes small corrections by stick input. This is the standard operational mode for most ISR and inspection missions.

Auto / Mission: The autopilot executes a pre-planned waypoint mission without pilot input. The operator monitors the mission from the GCS and intervenes if required. All of the BVLOS operations in the portfolio were conducted in this mode.

Return to Launch (RTL) / Return to Home: The autopilot commands the vehicle to climb to a safe altitude, navigate back to the launch point, and land or loiter. Triggered manually or automatically by a failsafe condition.

GPS-denied autonomy

GPS denial — whether from jamming, spoofing, multipath in urban canyons, or ionospheric interference — is a real operational risk for any UAS deployed in a contested or complex environment. A vehicle that cannot navigate without GPS is a vehicle that can be rendered non-operational by an adversary with inexpensive, commercially available jamming equipment.

Optical flow is the most widely used alternative horizontal position sensor for low-altitude GPS-denied operations. A downward-facing camera measures the apparent motion of the ground surface, and the autopilot uses this measurement to estimate horizontal velocity and maintain position. Optical flow requires adequate ground texture (it fails over featureless surfaces like water or snow) and adequate lighting (it degrades at night). The range is limited by the camera field of view and altitude — typical operational range is 0–40 m altitude.

Terrain-following using a downward-facing rangefinder (LiDAR or radar altimeter) maintains a constant height above ground rather than a constant altitude above sea level. In terrain with varying elevation, terrain-following is more meaningful operationally than GNSS altitude hold. It is also useful in the GPS-denied descent phase — if GNSS is lost at altitude and the vehicle must descend and land, a terrain-following rangefinder provides the altitude reference needed for a safe landing.

At the tactical level, the AFRL Group-2 AI swarm program integrated NVIDIA Jetson Nano companion computers running visual odometry — estimating vehicle motion from camera images using feature tracking rather than GPS — specifically to enable coordinated swarm operations in environments where GPS coordinates cannot be assumed to be reliable.

Inertial Navigation Systems

An Inertial Navigation System (INS) is more than an IMU. Where an IMU provides raw sensor measurements — acceleration and angular rate — an INS integrates those measurements through a navigation algorithm to produce a continuous, self-contained solution for position, velocity, and attitude. The critical distinction is that an INS provides absolute navigation output without any external reference. It is this self-contained capability that makes INS the foundation of GPS-denied navigation in demanding programs — and it is the quality of the gyroscope at the heart of the INS that determines how quickly that self-contained solution degrades over time.

The gyroscope's drift rate — measured in degrees per hour (°/hr) — is the governing parameter. Every degree per hour of gyro drift produces a position error that grows as the square of time in a pure INS. A gyroscope with 1 °/hr drift produces approximately 1.5 km of position error after one hour of pure inertial navigation. A gyroscope with 0.001 °/hr drift produces approximately 1.5 m of error after the same period. The difference between these performance levels is the difference between a MEMS gyroscope and a navigation-grade fiber optic gyroscope — and the difference in cost is two to three orders of magnitude.

Fiber optic gyroscopes

A fiber optic gyroscope (FOG) exploits the Sagnac effect: light traveling in opposite directions around a closed fiber optic loop experiences a phase shift proportional to the rotation rate of the loop. Measuring this phase shift gives a rotation rate that is independent of acceleration, temperature (within limits), and mechanical wear — because there are no moving parts. FOGs are stable, reliable, and capable of very low drift rates: tactical-grade FOGs achieve 0.01–1 °/hr; navigation-grade FOGs achieve 0.001–0.01 °/hr.

The practical consequence for GPS-denied navigation: a tactical-grade FOG-based INS maintains position accuracy of approximately 1–15 m per minute of GPS denial, depending on the specific grade. A navigation-grade FOG INS maintains position accuracy of approximately 0.1–1 m per minute. For a tactical UAS expected to operate in a GPS-denied environment for 5–15 minutes — the duration of a jamming event during ingress, for example — a tactical-grade FOG INS provides operationally useful position accuracy throughout that window. A MEMS-based system would accumulate hundreds of meters of position error in the same period.

The trade-offs are cost, size, and weight. A tactical-grade FOG INS costs $5,000–$50,000 depending on performance level, weighs 0.2–1 kg, and consumes 2–10 W. These parameters are manageable on a Group-2 or larger system. On a Group-1 vehicle where the total avionics weight budget may be under 200 g, a FOG INS is often not feasible, and the design must accept greater GPS-denied degradation.

Ring laser gyroscopes vs. fiber optic gyroscopes Ring Laser Gyroscopes (RLGs) use the same Sagnac effect as FOGs but with two counter-rotating laser beams in a sealed glass block rather than a fiber coil. RLGs achieve slightly better noise characteristics than FOGs at equivalent price points and are found in aviation-grade and strategic-grade INS platforms — the inertial reference units in large manned aircraft and in precision-guided munitions. For UAS applications, FOGs have largely displaced RLGs at the tactical and navigation grade levels because the fiber coil format is more compact, less fragile to shock and vibration, and easier to integrate into tight airframe volumes.

MEMS gyroscopes and their limitations

MEMS (Micro-Electro-Mechanical Systems) gyroscopes use vibrating mechanical structures — tuning forks, resonating rings — to detect the Coriolis force induced by rotation. They are manufactured on silicon wafers using semiconductor fabrication processes, giving them extremely low cost (under $10 in volume), very small size, and low power consumption. These are the gyroscopes in the IMU inside every Pixhawk, Cube, and consumer flight controller.

Their limitation for GPS-denied navigation is drift rate. Consumer-grade MEMS gyroscopes drift at 1–10 °/hr or more. Tactical-grade MEMS, with careful compensation and temperature calibration, achieve 0.1–1 °/hr. Even at the best achievable MEMS performance, position error in pure inertial navigation becomes operationally significant in under two minutes. MEMS-based INS is appropriate for bridging brief GPS outages — a few seconds to tens of seconds — and for attitude reference in GPS-aided navigation where the GPS continuously bounds the accumulated error. It is not appropriate as the sole navigation source for extended GPS-denied operations.

GPS-INS coupling architectures

Because even the best INS drifts over time, and because GPS provides an absolute position reference that prevents that drift from accumulating without bound, the standard architecture in serious UAS programs couples the GPS and INS together rather than relying on either alone. The coupling architecture determines how tightly the two sources are integrated and how well the combined system survives GPS degradation.

In a loosely coupled architecture, the GPS receiver produces a position and velocity solution independently, and the INS produces a position and velocity solution independently. The EKF combines the two outputs, weighting them by their respective accuracies. This is simple to implement and tolerates GPS receiver failures gracefully, but it performs poorly when fewer than four GPS satellites are visible, because the GPS receiver itself cannot produce a valid solution below four satellites.

In a tightly coupled architecture, the EKF receives raw GPS pseudorange measurements directly from the receiver rather than processed position solutions, and fuses them with the INS solution at the measurement level. This allows the system to use GPS measurements from as few as one or two satellites — maintaining some GPS aiding even when full position solution is not possible. The AFRL swarm program used tightly coupled GPS-INS on each airframe specifically to maintain navigation performance in the urban canyon test environment where satellite visibility was intermittent.

In a deeply coupled (or ultra-tightly coupled) architecture, the INS aides the GPS receiver's tracking loops directly, allowing the receiver to maintain signal lock under jamming conditions that would cause a standalone receiver to lose lock entirely. This is the architecture used in precision-guided munitions and the most capable tactical UAS — it is also the architecture that makes jamming-resistant navigation possible without resorting to alternative sensors entirely.

GPS spoofing is a different threat from jamming Jamming denies GNSS — the receiver gets no signal and the autopilot detects the loss and triggers its failsafe. Spoofing sends a false GNSS signal that the receiver accepts as valid, feeding false position and velocity data to the EKF without triggering any alarm. A spoofed vehicle flies confidently to the wrong location. Detection requires either cross-referencing GNSS position against an independent position source (optical flow, INS, radar) or monitoring for statistically improbable position jumps. For programs operating in contested environments, cross-checking GNSS against at least one independent position source is not optional.

Redundancy design

Redundancy is the provision of backup systems that allow the vehicle to continue operating when a primary system fails. Effective redundancy design requires identifying the single points of failure in the system — components whose failure causes mission loss or vehicle loss — and adding redundant paths for each one that the mission criticality justifies.

For the sensor suite, the standard on a professional UAS is dual IMU (typically two independent IMU chips on the flight controller, or a second external IMU), dual GNSS receivers on different antenna locations, and a backup barometer. The dual IMU allows the EKF to detect a failed IMU by comparing the two measurements and flagging the one that diverges from the fused estimate. A single bad IMU in a single-IMU system produces a flight control failure; in a dual-IMU system, the bad IMU is identified and excluded while the good one continues to provide measurements.

Power redundancy is the most consequential single point of failure in most UAS designs. The flight controller must be powered from a source that survives the failure of the main propulsion battery — either a dedicated backup battery, a regulated supply from a secondary power source, or a power module with integrated battery backup for the avionics rail. A flight controller that loses power when the propulsion battery fails is a design that accepts total vehicle loss as a consequence of a power anomaly.

INS as a navigation redundancy layer

The INS — and in particular a FOG-based INS — provides the most operationally meaningful form of navigation redundancy for programs that must survive GPS denial. Where dual GNSS receivers provide redundancy against receiver hardware failure, they provide zero redundancy against jamming or spoofing — both receivers see the same RF environment. An INS is independent of the RF environment entirely. A vehicle with dual GNSS and a FOG INS can lose both GPS receivers to jamming and continue navigating with bounded position error for a period determined by the INS grade.

The layered redundancy architecture that results from combining all available navigation sources is the most robust configuration achievable in practice. Three independent horizontal position sources — dual GNSS (for normal operations), a FOG INS (for GPS-denied periods), and optical flow or terrain-referenced navigation (for low-altitude GPS-denied operations) — provide the EKF with measurements that can individually fail, be jammed, or be spoofed without causing a complete navigation failure, because the remaining sources are independent and the EKF can detect and exclude the anomalous measurement.

Navigation redundancy layers by GPS-denied duration 0–30 seconds GPS denied: MEMS IMU integration bridges the gap with acceptable position error. Suitable for brief signal interruptions. 30 seconds–5 minutes GPS denied: tactical-grade MEMS INS (0.1–1 °/hr) with optical flow for horizontal bounding maintains operationally useful accuracy. Suitable for urban canyon transit. 5–30 minutes GPS denied: tactical-grade FOG INS (0.01–0.1 °/hr) required for bounded position error in the single-digit-meter range. Suitable for contested environment ingress. 30+ minutes GPS denied: navigation-grade FOG INS (0.001–0.01 °/hr) or deeply coupled GPS-INS with alternative aiding required. Suitable for strategic missions in heavily contested airspace.

The INS grade selection, therefore, is not a standalone avionics decision — it is derived directly from the GPS-denied duration requirement in the mission requirements document written in Module 01. A program whose CONOPS includes "must maintain navigation accuracy within 10 m for up to 15 minutes of GPS denial" has specified a tactical-grade FOG INS as a system requirement, whether or not the word "FOG" ever appears in the requirements document. The engineering team must recognize this implication and size the INS accordingly, within the weight and cost budget established by the system-level trade.

Failsafe logic design

Failsafe logic defines what the vehicle does when something goes wrong. It is as important as the primary flight control design, and it receives far less engineering attention than it deserves. A vehicle with excellent normal-operation behavior but poorly designed failsafes will eventually be lost to a scenario the designer didn't think through.

The primary failsafe conditions to design for are: datalink loss (RC signal loss or GCS connection loss); low battery voltage; GNSS signal loss; and autopilot health anomaly. Each condition requires a specified response that is appropriate for the vehicle, the mission, and the operating environment. The responses are not universal — the correct response to datalink loss for a BVLOS fixed-wing ISR vehicle (continue the pre-planned mission, then RTL at completion) is completely different from the correct response for a multirotor inspection vehicle over a populated area (immediately loiter and attempt to re-establish link; RTL if no link after 30 seconds; land if battery falls below minimum).

Failsafe design example: tactical fixed-wing over contested environment
Datalink loss: continue the current waypoint mission — do not RTL immediately, as the vehicle is likely in a jamming environment and RTL would fly it back through the jamming source. After mission completion, climb to safe altitude and return via pre-planned alternate route.
Low battery (first threshold, 20% remaining): complete the current waypoint leg, then navigate directly to the recovery area. Alert operator.
Low battery (critical threshold, 10% remaining): override mission, navigate directly to the nearest pre-designated emergency landing area. No further autopilot intervention required from operator.
GNSS loss: switch to INS-only navigation. Continue mission for up to 5 minutes. If GNSS not recovered, execute the GPS-denied return procedure using compass and barometer to navigate to the approximate recovery area. Alert operator.
Autopilot health anomaly (IMU disagreement): switch to backup IMU. Alert operator. If both IMUs fail, execute immediate glide descent to the nearest open area.

Power architecture

The power system is the foundation of avionics reliability. Voltage transients, brown-outs, and noise from the propulsion system corrupt sensor measurements, reset microcontrollers, and trigger false failsafe conditions. The power architecture must isolate the avionics from these disturbances while providing the voltage regulation each subsystem requires.

The standard architecture separates the propulsion power bus (high current, subject to large transients during motor acceleration) from the avionics power bus (low current, requiring clean, stable voltage). A power module with integrated current and voltage sensing provides the flight controller with the battery monitoring data needed for low-battery failsafe logic. Each high-current load — servos, the GCS datalink transmitter, the EO/IR payload — draws current spikes that must not propagate to the autopilot and sensor power rails. Separate BECs (Battery Eliminator Circuits) or dedicated voltage regulators for the autopilot, the payload, and the communications system are the standard solution.

For long-range or BVLOS operations, where the cost of losing the vehicle is high, a dedicated backup battery for the avionics rail — separate from the main propulsion battery — provides the power bridge needed to survive a propulsion battery failure or disconnection event. This backup battery must be sized to provide enough power for the vehicle to execute its failsafe return procedure: at minimum, 10–15 minutes of avionics power at the full avionics load.