Redundant flight controls give an unmanned aircraft more than one way to perform a control function after a specified fault. That may mean replacing a failed sensor, transferring authority to another flight computer, or redistributing commands among healthy actuators. The benefit depends on the complete surviving path from measurement to aircraft response, including power, communication and the logic that selects which output to trust.

For a UAS designer or buyer, the central question is: which failure can this aircraft tolerate, in which flight phase, and what can it still do afterward? Counting flight-control processors alone cannot answer it. NASA's overview of safety-critical computer systems explains why fault assumptions, containment and redundancy management have to be considered together.

On this page

Trace the complete control path

A flight-control path begins with measurements such as angular rate and acceleration. A state estimator combines observations into estimates of attitude, velocity or position. Control laws compare the desired motion with the estimated motion, then request forces and moments. Control allocation converts those requests into motor or servo commands appropriate to the airframe. PX4 documents this last stage in its control-allocation architecture.

Redundancy can be introduced at several points along that path, with different consequences. Two sensors feeding one processor protect a different boundary from two independently powered processors. Multiple healthy computers still need a usable command route and enough working actuators to change the aircraft's motion.

The anatomy of an unmanned aircraft system places these components alongside the ground station, command link, payload and power system. Keeping those boundaries visible helps prevent a redundant navigation sensor or radio link from being mistaken for a complete backup flight-control system.

Define the required outcome before choosing an architecture. Continued stabilization, a controlled landing and completion of the original mission are different objectives. A fault-tolerant design should say which functions remain available and what operating restrictions follow the fault.

Understand the redundancy architectures

Multiple sensors and estimators

An inertial measurement unit, or IMU, measures acceleration and angular rate. Multiple IMUs allow software to compare inputs or change which measurements it uses. Multiple extended Kalman filter instances, commonly called EKFs, can go further by maintaining separate estimates from different sensor combinations.

PX4's EKF2 documentation distinguishes simple sensor selection from multiple-estimator operation. Its selector compares consistency between instances to help isolate faults such as abrupt bias changes, saturation or stuck measurements. This adds detection opportunities; it does not turn several estimator processes on one CPU into independently powered computers.

Measurement timing and reference frames also matter when judging disagreement. The same aircraft observed at different instants can produce different legitimate values. The sensor-fusion guide explains the timing, calibration and uncertainty issues behind that comparison.

Active and standby controllers

In an active/standby arrangement, one controller has output authority while another is prepared to take over. The design must establish when transfer is justified and keep the standby's state suitable for the transfer.

ArduPilot Copter provides a concrete illustration. Its Standby auxiliary function adjusts controller behavior so control can resume after standby is disabled. The documentation explicitly assigns output and peripheral switching to external circuitry. Enabling standby therefore supplies one part of a redundant design; the integrator still has to provide the authority-transfer path.

Voting and arbitration

Parallel channels can be compared before an output is selected. When two healthy channels agree within defined tolerances, three channels can support majority or middle-value selection that masks one faulty source. That result depends on the assumed fault behavior and the integrity of the selection path. Two disagreeing channels establish that something differs, but need additional diagnostic evidence to identify the usable channel.

NASA's computer-systems overview distinguishes selection from voting and relates their capabilities to assumed failure behavior. A design that tolerates a silent failed source is different from one that tolerates a source transmitting plausible but wrong values. The selector itself, and what receivers do with its result, remain part of the analysis.

Recovery by restarting

A watchdog detects certain failures of execution and triggers a reset. That is a recovery mechanism, with an interruption that the aircraft must survive. ArduPilot's watchdog documentation explicitly says a restart may or may not save a moving vehicle. A watchdog is therefore not evidence of uninterrupted control or successful transfer to another computer.

Design the handover interfaces

The connections between redundant components deserve the same attention as the components. A practical interface review should cover four questions:

  1. What makes data usable? Specify source identity, units, coordinate frame, measurement time, freshness limits and validity indications. A received message needs enough context for the consumer to decide whether it belongs in the current control cycle.
  2. Who can command each actuator? Document authority selection, output inhibition, reset behavior and how a previously failed channel can rejoin. Include the case where both controllers believe they should be active.
  3. What state crosses the handover? Identify the mode, reference values and controller states that must remain consistent. Demonstrate the transition at the actuator output, rather than observing only a healthy-status indicator.
  4. What faults cross the wiring? Trace power feeds, shared buses, connectors and output circuitry. Record where one short circuit or failed interface could affect another otherwise healthy path.

These are engineering review questions synthesized from the estimator, standby and redundancy-management mechanisms above. Their answers belong in an interface specification for the actual aircraft and software versions.

Embention's 2024 Veronte 4x engineering account illustrates the scope involved: it describes three internal autopilot cores, an optional external fourth, individual core power feeds, arbitration using health and state information, redundant communication buses, and separate output banks. The company also says vehicle-level actuators and other critical elements must be considered. This is a manufacturer-described architecture, not proof that any installation has eliminated every single point of failure.

Check what each failure leaves available

Use a failure matrix to connect the advertised redundancy to a demonstrable outcome. The following is an editorial review framework based on the cited architecture, software and actuator documentation; it reports no tested performance or universal acceptance limits.

Failure to examineBoundary under reviewEvidence to request
One sensor stops updatingSensor selection and data freshnessWhich observation is rejected, which replaces it, and whether the estimate remains usable
A sensor sends plausible wrong valuesConsistency monitoring and fault isolationDetection behavior for bias or stuck data, including false rejection of healthy sensors
The active CPU stops executingWatchdog, standby and output authorityThe time history from failure through transfer or restart to usable actuator commands
A power or communication path failsElectrical and communication independenceWhich sensors, computers and outputs remain powered and reachable
An actuator cannot produce its commandControl allocation and physical authorityThe remaining achievable forces and moments, limits and recovery maneuver
Redundant channels share the same bad input or software defectCommon-cause protectionA separately justified recovery or containment strategy for that shared failure

The actuator row is particularly important. Changing computers cannot repair a jammed mechanism or restore a lost motor. PX4 separates control allocation from the core controller because the mapping depends on aircraft geometry. Even where software handles a motor failure, the aircraft still needs sufficient remaining physical control authority. Acceptance should address the actual failed actuator, loading and flight condition.

Account for common causes and performance costs

Redundant channels can fail together when they share a cause. NASA's human-rating requirements, HEOMD-003 Revision B, describe how the same software fault can affect multiple computers and defeat isolation by redundancy management. They also illustrate why physically shared routing can undermine otherwise dissimilar redundant equipment. These are useful engineering examples from a human-spaceflight document, not UAS regulatory requirements.

Dissimilar hardware or software can address particular shared vulnerabilities, but the claimed independence needs a defined scope. Ask which inputs, requirements, configuration tools, power paths and installation features remain common. A different processor label alone is an incomplete answer.

There are costs on both sides of the redundancy decision. Additional hardware brings installation mass, electrical load, wiring and maintenance obligations. Extra estimator instances consume processing resources; PX4 specifically calls for checking CPU and memory utilization on the ground before flight. Budget integration effort as well as hardware: ask the supplier to enumerate supported combinations of healthy, degraded, disconnected and restarting channels, and identify which transitions have been demonstrated.

Detection thresholds introduce another tradeoff. An aggressive decision may reject a healthy path during a transient; a slow decision may leave a faulty path active too long. Define the acceptable aircraft response and evaluate the complete sequence: detect, isolate, select or reconfigure, then restore useful control. No universal handover-time figure applies to every aircraft and maneuver.

Match the architecture to the application

For a multirotor using multiple navigation sensors, the immediate question is whether a sensor failure leaves a usable attitude estimate and a suitable recovery mode. That is a narrower claim than surviving loss of the flight computer. For a dual-controller installation, the review expands to state transfer, switching circuitry and output ownership. These examples describe different integration tasks, not a ranking of autopilot products.

For an aircraft with redundant actuation, the question becomes what forces and moments remain available after a specified actuator failure. In Mousaei and colleagues' tiltrotor study, the researchers analyzed a custom aircraft's achievable force-and-moment combinations and used dynamic control allocation to adapt to actuator failures. They report experimental validation for their configuration. The result supports examining airframe geometry and allocation together; it does not establish equivalent recovery for an arbitrary tiltrotor or multirotor.

For operations that depend on reaching a landing area after a fault, define the necessary navigation, communication, energy and control functions for that recovery. Include the restrictions that apply after transfer: an alternate controller may retain stabilization while requiring a different landing mode or a reduced maneuver envelope. The architecture should be assessed against that specific outcome. The UAS airworthiness and design-assurance explainer provides the broader context for connecting design evidence, operating scope and continued safety.

Ask for a failure-specific demonstration

Before accepting a redundant flight-control claim, request a concise demonstration record for each claimed tolerated failure. It should identify the hardware and software configuration, injected fault, flight condition, detection event, selected control path, actuator response and resulting aircraft behavior. Include the permitted degraded mode and the action required before another flight.

Use simulation and controlled ground facilities to investigate failures before a separately planned flight-test program. A successful reboot on the bench establishes a different result from maintaining control during a demanding maneuver. Ask to see disagreement, stale information, restart and failed output-switching cases as well as clean power-off failures. These are proposed assessment steps, not evidence that a particular aircraft has passed them.

A useful requirement finishes the sentence: “After this fault, this aircraft retains these functions long enough to perform this recovery.” The redundancy architecture, its interfaces and its demonstration should all answer the same sentence.

Sources

Last checked: September 10, 2026.