Drone and UAS autonomy stacks

Scope and source discipline

This note covers the autonomy stack that enables a drone or uncrewed aircraft system (UAS) to sense, map, plan, and control itself without a direct human pilot. It does not treat autonomy as a single software program; it treats it as a layered stack: sensing/perception, state estimation and mapping, planning, control, and safety/failsafes.

Source discipline used here:

• Tier 1 for technical/performance/IP claims: granted patents, peer-reviewed papers with DOI, standards-body documents, and regulator technical assessments.
• Tier 2 for adoption/operating context: company engineering docs, product pages, SEC filings, and named manufacturer documentation. Company self-reported figures are marked as such.
• Prohibited SEO content farms, anonymous benchmark sites, AI-generated summaries, and unretrievable primary sources are not used.

Where a number is manufacturer self-reported or otherwise not independently verified, it is labeled. Where a load-bearing claim rests on one family of evidence, it is tagged [SINGLE-SOURCE]. A patent is evidence of recorded claims, not proof of performance or commercial viability.

What the autonomy stack actually is

A practical UAS autonomy stack has at least five functional layers. The open-source PX4 flight-stack documentation and ArduPilot Copter architecture documentation both describe this separation in engineering terms [S1][S2].

2.1 Sensing and perception

The stack ingests cameras, inertial measurement units (IMUs), barometers, GNSS, optical flow, LiDAR, radar, and sometimes thermal sensors. Perception converts raw sensor data into obstacle detections, depth maps, object classifications, and local terrain structure. This is a compute-heavy, latency-sensitive stage.

The FAA’s UTM Concept of Operations v2.0, a regulator technical assessment, explicitly describes the need for the UAS to detect non-cooperative intruders and to remain clear of other aircraft; that is a load-bearing requirement for any beyond-visual-line-of-sight autonomy claim [S5].

2.2 State estimation and mapping

The drone must estimate its own pose and velocity and build a local map for obstacle avoidance. In GPS-denied or GPS-degraded environments, visual-inertial odometry, LiDAR SLAM, or radar SLAM is used. This is where “autonomous flight in GPS-denied environments” claims become testable.

2.3 Planning

Planning includes:

• global path planning from launch to goal;
• local trajectory generation around obstacles;
• behavior-level switching between modes such as return-to-home, orbit, or hover.

A peer-reviewed trajectory-generation method is described in Mellinger and Kumar’s 2011 IEEE ICRA paper, “Minimum snap trajectory generation and control for quadrotors” [S8]. The paper formulates trajectory generation as an optimization over position and yaw derivatives, minimizing the fourth derivative (“snap”) of the position path. This is a foundational peer-reviewed reference for smooth, dynamically feasible quadrotor trajectories.

2.4 Control

The generated trajectory is converted into low-level attitude, rate, and motor commands. PX4’s controller diagrams and ArduPilot’s Copter code overview both describe cascaded control loops: outer position/velocity loops feed inner attitude/rate loops, with motor mixing at the final stage [S1][S2]. The autonomy claim is only as good as the controller’s ability to track the trajectory under wind, degraded sensors, and payload changes.

2.5 Safety and failsafes

Geofencing, low-battery return-to-home, loss-of-command-link behavior, and manual kill switching are part of the autonomy stack because they constrain autonomy and are audited by regulators. The FAA’s BVLOS operations page states that beyond-visual-line-of-sight operations generally require specific approval and safety case [S6].

Source map for this note

The following source categories are used:

No prohibited source classes are used.

Technical feasibility: evidence-bound claims

4.1 The patent layer: claims, not performance

A useful legal moat example is US Patent 9,334,052 B2, accessible through Google Patents [S9]. The patent was granted on 2016-05-10 and describes methods and systems for controlling an unmanned aerial vehicle based on user input and flight-envelope constraints. The bibliographic record is the primary source of the patent grant.

The important distinction: this patent is evidence of recorded claims, not proof that a commercial drone passed a sense-and-avoid certification or that the described method works at scale. Any “moat” conclusion must use patent prosecution history, family size, forward citations, or actual enforcement, not the existence of a grant alone.

4.2 Peer-reviewed trajectory generation

Mellinger and Kumar 2011 [S8] is a peer-reviewed IEEE conference paper with DOI 10.1109/ICRA.2011.5980409. The paper demonstrates minimum-snap trajectory generation for quadrotor aggressive maneuvers. It is a foundational technical source. Because it is a conference paper, it is peer-reviewed but not a journal article; the technical claim is still Tier 1, but a journal-grade replication or field validation would be stronger.

4.3 Open-source stack documentation

PX4’s controller diagram page [S1] describes the PX4 multirotor control architecture as cascaded loops: position controller, velocity controller, attitude controller, rate controller, and mixer. ArduPilot’s Copter code overview [S2] similarly organizes flight modes and controllers. These are engineering documentation, not independent performance benchmarks, but they are precise about architecture.

Cross-check: the PX4 documentation and Mellinger-Kumar paper are different institutions; the controller architecture described in PX4 aligns in kind with the trajectory/control decomposition in the paper. That is two independent lineages for the general “trajectory + control” decomposition, though not for any specific performance number.

4.4 Regulator technical constraint

FAA’s UTM ConOps v2.0 [S5] treats UAS autonomy as a capability embedded in a broader airspace management system. It emphasizes that UAS operators must meet “strategic separation” and, where applicable, “tactical separation” with approved means. This is a Tier 1 regulator technical document. It does not certify a specific vendor stack, but it establishes why autonomy claims must be tested against a safety case rather than marketing language.

Company technical claims vs. SEC filing risk factors

The tension between marketing autonomy and filed risk disclosures is visible in several UAS-adjacent public companies.

• AeroVironment’s SEC filings discuss its UAS product portfolio, government procurement, and the regulatory environment as material risks [S10]. The company’s investor-facing materials generally emphasize defense UAS capabilities, while the filed risk factors frame those capabilities as dependent on government budgets, Federal Aviation Administration approval, and export-control regimes.
• Kratos Defense and Security Solutions builds attritable autonomous UAS, such as the Valkyrie program. Its SEC filings make clear that its UAS business is tied to government contracts and program timing; sales are not recurring software royalties [S11].
• Red Cat Holdings, which sells the Teal 2 drone, presents autonomy and night-operations capabilities in investor materials, but its SEC filings disclose continuing losses, limited operating history, dependence on government customers, and the need for continued financing [S12].
• Ondas Holdings, through American Robotics, markets automated BVLOS drone operations; its SEC filings disclose that BVLOS approvals and commercial adoption are regulatory and execution risks [S13].

Cross-reference finding: Marketing materials tend to describe autonomy as product capability; SEC filings describe autonomy in the context of FAA approval, contract dependence, and limited commercial scale. These are not necessarily inconsistencies, but they are different evidentiary standards. For investment claims, the SEC risk language is the stronger statement because it is a fiduciary/liability-facing disclosure, not a promotional document.

Worked quantitative calculation: onboard compute vs. endurance

This is a derived example using a formula, inputs, and sensitivity. It is not a vendor benchmark.

Formula:

\[

T_{\text{endurance}} = \frac{E_{\text{battery}}}{\bar{P}_{\text{total}}}

\]

Where:

• \(E_{\text{battery}}\) = usable battery energy, Wh
• \(\bar{P}_{\text{total}}\) = average total power draw, W

Baseline inputs:

• DJI Mavic 3 Intelligent Flight Battery energy: 77 Wh [S3], manufacturer self-reported.
• DJI Mavic 3 maximum flight time: 46 minutes [S3], manufacturer self-reported.
• Derivation: \(\bar{P}_{\text{baseline}} = 77\ \text{Wh} / (46/60\ \text{h}) = 100.4\ \text{W}\).

This baseline average power is derived, not independently measured. It includes the drone’s own autonomy stack, motors, sensors, and flight profile.

Add NVIDIA Jetson AGX Orin compute module:

NVIDIA’s Jetson AGX Orin product page lists configurable power from 15 W to 60 W [S4], self-reported. For this calculation, assume a midpoint config of 30 W.

Step 1: new total average power:

\[

\bar{P}_{\text{new}} = 100.4\ \text{W} + 30\ \text{W} = 130.4\ \text{W}

\]

Step 2: new endurance:

\[

T_{\text{new}} = \frac{77\ \text{Wh}}{130.4\ \text{W}} = 0.591\ \text{h} = 35.5\ \text{minutes}

\]

Step 3: reduction:

\[

46\ \text{min} - 35.5\ \text{min} = 10.5\ \text{min}

\]

\[

\frac{10.5}{46} = 22.8\%

\]

Sensitivity:

• 15 W compute: \(T = 77 / 115.4 = 0.667\ \text{h} = 40.0\ \text{min}\), a 13.0% reduction.
• 30 W compute: 35.5 min, a 22.8% reduction.
• 60 W compute: \(T = 77 / 160.4 = 0.480\ \text{h} = 28.8\ \text{min}\), a 37.4% reduction.

Limits: This assumes the 46-minute DJI figure is the correct baseline average power at 77 Wh and that adding the module does not change the flight profile or battery temperature behavior. It also assumes the module draws its TDP continuously. This is a first-order energy budget, not a flight-test result.

Parameter table

Contradictions and source-bound claims

Contradiction 1: “full autonomy” vs. regulatory approval

Several company materials describe “autonomous” flight, but FAA BVLOS documentation makes clear that BVLOS operations are not generally permitted as a default and require approval or waiver [S6]. A drone that can fly autonomously technically may still be legally uneconomical to operate without FAA approval.

Contradiction 2: patent breadth vs. performance proof

US 9,334,052 B2 records autonomy-related control claims [S9]. A granted patent is not evidence that the claimed method meets civil aviation safety standards or that it was ever deployed at scale. The patent supports a legal-moat hypothesis, not a performance moat.

Contradiction 3: autonomy compute vs. endurance

Adding a high-power autonomy computer improves onboard processing but reduces endurance. The worked calculation above shows a 22.8% endurance reduction at 30 W added compute relative to the DJI Mavic 3 self-reported baseline. The tension is structural: more onboard autonomy requires more energy, unless the overall mission profile is engineered around that trade-off.

Unit economics / business model

Who monetizes this technology and how:

• Compute vendors sell the silicon for edge autonomy. NVIDIA sells Jetson modules for robotics and autonomous machines; pricing is not disclosed at product level in a way that allows margin isolation [S4].
• Integrated drone OEMs such as DJI monetize autonomy as part of a complete drone product. DJI’s Mavic 3 spec sheet advertises autonomous flight modes and flight-time figures [S3], but DJI does not publicly break out autonomy software as a separate license.
• Defense UAS primes such as AeroVironment and Kratos monetize autonomy through government contracts and system sales, not necessarily through per-drone software licenses [S10][S11].
• BVLOS service operators, such as Amazon Prime Air, monetize autonomy through delivery operations after obtaining FAA authorization [S14].

No reliable public product-level margin data for autonomy stacks was available in the sources reviewed. Any margin figure would need needs primary source validation. The value capture appears to flow primarily to integrated OEMs and compute vendors; pure autonomy-software-only business models are less represented among US-listed public companies examined here.

Disconfirming Evidence

The drone/UAS autonomy-stack investment or technology thesis would be wrong if:

• FAA broad BVLOS waivers and type certifications do not materialize, keeping autonomy stacks in line-of-sight markets only [S6].
• Government UAS programs, especially defense contracts at AVAV, KTOS, RCAT, and ONDS, are cut, delayed, or shifted to lower-margin services [S10][S11][S12][S13].
• Onboard autonomy compute creates an endurance or thermal penalty large enough to make BVLOS missions uneconomic, worsening the derived 22.8% penalty at 30 W [S3][S4].
• Autonomy vendors cannot demonstrate sense-and-avoid reliability to FAA or international regulators, so the patent claims remain legal artifacts rather than deployable technology [S5][S9].
• A dominant open-source stack such as PX4 or ArduPilot commoditizes the control layer so thoroughly that proprietary “autonomy” differentiators do not sustain unit pricing [S1][S2].

If any of these disconfirming trends appear in primary regulatory filings, certification records, or customer disclosures, the moat and commercial-margin assumptions should be revised downward.