Chapter 1: The Five Link Types

Every drone in the air right now is using between one and five simultaneous radio links. Most operators can name two. This chapter covers all five.

The Problem Nobody Talks About

A racing quad has two links — RC control and video. Simple. But the moment you add GPS return-to-home, you've added a third (telemetry). Add a companion computer with a mesh radio and you're at four. Add a payload camera with its own downlink and you're at five.

Each link has its own frequency, its own protocol, its own antenna, its own failure mode, and its own opinion about which direction the drone should go. When they disagree, things get interesting.

Understanding the five link types is the foundation of everything else in this handbook. If you don't know what's talking on your drone, you can't diagnose why it stopped talking.

The Five Links

Link 1: Manual Control (RC)

What it does: Carries stick commands from the pilot to the flight controller. The link that keeps a human in the loop.

Protocols: ELRS (ExpressLRS), CRSF (TBS Crossfire), GHST (IRC Ghost), SBUS (FrSky), IBUS (FlySky), PPM (legacy).

Frequencies: - 2.4 GHz — most common (ELRS 2.4, CRSF, Ghost, FrSky ACCST) - 900/868 MHz — long range (ELRS 900, Crossfire, FrSky R9) - Sub-GHz proprietary — tactical (IRONghost dual-band)

What you need to know: - This is the only link where latency matters in milliseconds. ELRS at 500 Hz has ~2 ms latency. SBUS is ~6 ms. At 250 Hz freestyle, you won't feel the difference. In a racing final, you might. - Loss of this link triggers failsafe. Every FC firmware handles failsafe differently. Know yours before you need it. - ELRS and Crossfire use serial protocols (CRSF wire format) that carry bidirectional telemetry inside the RC link. This blurs the line between Link 1 and Link 2 — your RC receiver is also a telemetry radio. This is efficient but means RC loss also kills your telemetry.

Common problems: - RC and video on the same frequency band (both 2.4 GHz) causing desense. Solution: different bands, or physical antenna separation. - Wrong UART baud rate in FC configurator — CRSF wants 420000, not 115200. - ELRS binding phrase mismatch after firmware update.

Link 2: Telemetry / Command & Control (C2)

What it does: Bidirectional data link between the drone and a ground station. Carries flight data down (position, battery, attitude) and commands up (waypoints, parameter changes, mode switches).

Protocols: MAVLink v2 (ArduPilot, PX4), MSP (Betaflight, iNav), LTM (Lightweight Telemetry), FrSky S.Port/F.Port.

Transport options: - Embedded in RC link — CRSF/ELRS carry MAVLink or custom telemetry inside the control channel. No separate radio needed. - Dedicated telemetry radio — SiK (3DR), RFD900x, MicroHard P900. Separate frequency, separate antenna, separate failure mode. - WiFi — ESP32 bridge, companion computer WiFi, mesh radio backhaul. - Cellular — LTE modems for beyond-visual-line-of-sight (BVLOS).

What you need to know: - MAVLink is the lingua franca for autonomous platforms. If you're running ArduPilot or PX4, everything speaks MAVLink. If you're running Betaflight, everything speaks MSP. If you're running a mixed fleet, you need both. - Telemetry bandwidth matters more than telemetry latency. You don't need millisecond position updates on the ground — 1-10 Hz is fine. But you do need all the data fields to arrive intact. - Dedicated telemetry radios (RFD900x, SiK) are point-to-point. They don't scale to multiple drones without a mesh layer on top.

Common problems: - MAVLink stream rate misconfigured — too high floods the link, too low makes the GCS look frozen. Start with SR0_POSITION=2, SR0_EXTRA1=4, adjust from there. - SiK radio firmware mismatch between air and ground units. - UART conflict — telemetry and GPS both assigned to the same UART.

Link 3: Video Downlink

What it does: Sends camera feed from the drone to the pilot's goggles or ground station monitor. The link that lets you see.

Technologies: - Analog 5.8 GHz — lowest latency (~1 ms glass-to-glass), degrades gracefully (static, then snow, then nothing). Still dominant in FPV racing and tactical ops where latency kills. - DJI digital — DJI O3, O4, Vista, Air Unit. Low latency (~20-28 ms), good image quality, locked ecosystem. No third-party interop. - HDZero — digital, ultra-low latency (~15 ms), open ecosystem, lower resolution than DJI. Popular with racers going digital. - OpenHD / WFB-ng / OpenIPC — open-source digital video over commodity WiFi hardware (RTL8812AU/EU). Higher latency (~80-120 ms), fully open, hackable, configurable. The platform for custom builds. - Walksnail (Avatar) — Caddx/Walksnail digital system. Competes with DJI on image quality, runs on Artosyn AR8030 chip.

What you need to know: - Video is almost always 5.8 GHz. This means it's on the same band as 5 GHz WiFi, some mesh radios, and the 5.8 GHz ISM band that everyone assumes is uncontested. In practice, 5.8 GHz is crowded. - Analog video uses 40 channels across 5.8 GHz. At a race event with 8 pilots, frequency management is a real operational problem. At a tactical deployment with multiple teams, it's a coordination requirement. - Digital video links (DJI, HDZero) are frequency-hopping or wideband. They're harder to interfere with but also harder to coordinate. You can't just "pick a channel" the way you can with analog. - The RTL8812AU chip that OpenHD/WFB-ng depends on has been discontinued by Realtek. The RTL8812EU replacement does NOT support monitor mode in the same way. This is slowly killing the open-source digital FPV ecosystem. OpenIPC is moving to other solutions.

Common problems: - 5.8 GHz video transmitter (VTX) too close to 2.4 GHz RC antenna causes receiver desense. Minimum 10 cm separation, more is better. - VTX power set too high for proximity flying — at 800 mW you're heating the VTX and potentially interfering with your own RC. 25-200 mW is enough for most LOS operations. - Wrong VTX table in Betaflight — mismatched power levels, missing channels, or wrong band assignments.

Link 4: Payload Data

What it does: Carries data from a mission payload — mapping camera, multispectral sensor, LiDAR, SAR, SIGINT receiver, delivery mechanism confirmation. Distinct from the FPV video feed (Link 3).

Technologies: - Ethernet (wired, on companion computer) - USB (camera to companion) - WiFi (payload-specific AP) - Dedicated RF downlink (separate frequency, separate antenna) - Store-and-forward (record on board, download after landing)

What you need to know: - Most consumer and racing drones don't have Link 4. It shows up on commercial mapping drones, agricultural platforms, and defense ISR platforms. - Payload data is usually high bandwidth and tolerant of latency. A mapping camera generates gigabytes per flight — you're not streaming that in real time. You're storing it and downloading after landing. - When payload data IS streamed (tactical video from a gimbal camera, SAR data, EW sensor output), it competes for bandwidth with telemetry and video. This is where mesh radios with QoS become important — prioritize C2 over payload, always. - The companion computer is the integration point. Payload connects to companion via USB/Ethernet/GPIO. Companion decides what goes down the RF link and what gets stored.

Common problems: - Payload drawing too much power from the FC's 5V/12V rail. Payload should have its own BEC or regulated supply. - USB bandwidth contention between payload camera and companion computer's other USB devices. - Payload data timestamps not synchronized with flight controller timestamps. Use GPS time or NTP on the companion for correlation.

Link 5: Mesh / Swarm Coordination

What it does: Drone-to-drone communication for fleet operations. Position sharing, intent coordination, task allocation, sensor data relay. The link that turns individuals into a team.

Technologies: - ESP-NOW — Espressif peer-to-peer, 2.4 GHz, ~250 byte packets, no infrastructure needed. Good for ground operations (Tooth mesh, pre-flight sync). Not suitable for in-flight swarm at range. - WiFi mesh (batman-adv / 802.11s) — Linux-based mesh networking. Doodle Labs, Silvus, and Persistent Systems all use this under the hood (yes, your $5,000 Silvus StreamCaster is running OpenWRT with batman-adv). Range 1-50 km depending on radio and power. - MANET (Mobile Ad-hoc Network) — military-grade mesh with frequency hopping, anti-jam, encryption. Persistent Systems MPU5, Silvus at higher tiers, Harris/L3Harris. $10,000-50,000 per node. - MAVLink over mesh — any of the above carrying MAVLink messages between platforms. Each drone gets a unique system ID (1-254). Standard MAVLink messages (GLOBAL_POSITION_INT, HEARTBEAT) become the swarm awareness layer.

What you need to know: - Most drones don't have Link 5. It's the last link to be added and the first to be cut when budget or weight is tight. - Mesh radios that claim "50 km range" are telling you the radio range, not the mesh range. Mesh adds overhead. Real throughput across 3 hops is typically 30-50% of single-hop throughput. - The dirty secret of tactical mesh: Doodle Labs is OpenWRT on Atheros/Qualcomm WiFi silicon running batman-adv. Silvus is similar with their own MAC layer. Persistent Systems MPU5 is the most custom but still builds on standard radio architectures. They're not magic. They're well-engineered WiFi radios in ruggedized enclosures with good antenna design and custom firmware. - Mesh network planning is its own discipline. Node placement, antenna orientation, channel assignment, traffic prioritization — these matter more than the radio's datasheet specs.

Common problems: - Mesh radio on 2.4 GHz interfering with 2.4 GHz RC link. Solution: different bands (mesh on 900 MHz or 5 GHz). - batman-adv OGM (Originator Message) interval too high, causing stale routing. Default 1 second is fine for slow-moving platforms. Fast-moving drones may need 250 ms. - IP address conflicts in the mesh. Use a consistent addressing scheme: 10.0.0.{system_id} with system_id matching MAVLink ID.

How They Interact

The five links are not independent. They share spectrum, share power, share the FC's limited UARTs, and share the operator's limited attention.

Frequency Deconfliction

The rule: no two links on the same band within the same airframe unless they're designed to coexist. ELRS 2.4 GHz and an ESP32 WiFi AP on the same drone will fight. ELRS 900 MHz and an RFD900x telemetry radio will fight. Plan your frequency layout before you build.

UART Allocation

A typical F405 flight controller has 3-6 UARTs. They get consumed fast:

Running out of UARTs is one of the most common integration problems on F4-class FCs. Solutions: use soft serial (limited baud rate), upgrade to an H7 FC (more UARTs), or use a companion computer to multiplex multiple data streams over a single UART.

Power Budget

Every link has a radio that draws power. Every radio has an amplifier that draws more power. On a 5-inch FPV quad with a 1300 mAh 6S battery, your total electronics budget (FC + ESCs + radio + VTX + GPS + receiver) is typically 2-5W continuous. Adding a mesh radio at 1-2W is significant. Adding a companion computer at 3-10W changes your flight time.

Know your power budget before you add links.

The Operator's Decision

Not every drone needs all five links. Most don't. The right number of links depends on the mission:

More links = more complexity = more things to break = more things to diagnose. Add links because the mission requires them, not because the hardware supports them.

Next

• Chapter 2: Frequency Bands and Regulatory Reality — the rules that govern where your links can operate, and the gaps between the rules and reality.
• Chapter 8: UART Layout and Why It Matters — the practical constraint that limits how many links you can actually use.

Every link you add is a complication. Know what it costs before you add it.

Chapter 2: Frequency Bands and Regulatory Reality

The regulations tell you what you're allowed to do. The physics tell you what will actually work. They don't always agree.

The Bands That Matter

Drone operations live in a handful of frequency bands. Here's where everything sits and why.

900 MHz (902–928 MHz in the US, 868 MHz in EU)

What lives here: Long-range RC links (ELRS 900, TBS Crossfire), telemetry radios (RFD900x, SiK, MicroHard P900), some mesh radios, LoRa, and a surprising amount of industrial IoT.

Why it matters: Sub-GHz propagation is king. 900 MHz bends around obstacles, penetrates foliage, and reaches farther per milliwatt than any other band you'll use. A 100 mW ELRS 900 link will outrange a 1 W 2.4 GHz link in most real-world environments.

Regulatory: - US: ISM 902–928 MHz, up to 1 W conducted + antenna gain (FCC Part 15.247) - EU: 868 MHz band, 25 mW ERP with duty cycle limits (ETSI EN 300 220) - The EU/US split is the single biggest cross-border problem in drone operations. 900 MHz hardware built for the US market doesn't work in Europe, and vice versa. ELRS handles this with region-specific firmware builds. Many other systems don't.

What the regulations don't tell you: The 900 MHz ISM band is shared with utility meters (smart grid AMI), industrial SCADA, agricultural sensors, and LoRaWAN gateways. In urban environments, the noise floor at 900 MHz can be 20+ dB higher than rural. Your range will be shorter in the city.

2.4 GHz (2400–2483.5 MHz)

What lives here: Most RC links (ELRS 2.4, Ghost, ACCST, IBUS), WiFi (802.11b/g/n/ax), Bluetooth, ZigBee, microwave ovens, baby monitors, wireless cameras, mesh radios, and roughly half of all wireless devices ever manufactured.

Why it matters: 2.4 GHz is the default for everything. It's globally harmonized (same band everywhere), license-free, and supported by every chip on the market. If you don't know what frequency to use, you use 2.4 GHz. So does everyone else.

Regulatory: - Global ISM band, generally 100 mW–1 W EIRP depending on jurisdiction - FCC: up to 1 W conducted, 4 W EIRP with directional antennas (Part 15.247) - EU: 100 mW EIRP (ETSI EN 300 328) - Japan: 10 mW/MHz (effectively limits wideband signals)

What the regulations don't tell you: 2.4 GHz is a war zone. At any given moment at a race event, fly-in, or urban deployment site, you're sharing spectrum with: - Every phone's WiFi and Bluetooth - Every laptop's WiFi - Every smart home device - Other pilots' RC links - Nearby mesh radios - The microwave in the food truck

The saving grace is that modern protocols (ELRS, Ghost, CRSF) use frequency hopping, which spreads the signal across the entire band and makes them resilient to narrowband interference. But when the entire band is congested, even FHSS degrades.

The 2.4 GHz deconfliction problem: If your RC link is 2.4 GHz AND your mesh radio is 2.4 GHz AND your companion computer's WiFi is 2.4 GHz, you have three transmitters on the same band in the same airframe. Even with different channels and different protocols, the front-end receivers will desense each other. The fix is simple: put at least one of them on a different band.

5.8 GHz (5725–5875 MHz)

What lives here: Analog FPV video, digital FPV video (DJI, HDZero, Walksnail), 5 GHz WiFi (802.11a/n/ac/ax), some mesh radios, radar, and weather services.

Why it matters: 5.8 GHz is the FPV video band. Virtually every drone with a camera transmits video on 5.8 GHz. The band has enough bandwidth for analog and digital video, and the higher frequency means smaller antennas.

Regulatory: - ISM 5.725–5.875 GHz in most jurisdictions - FCC: 1 W conducted (Part 15.247) - EU: 25 mW EIRP (yes, really — ETSI EN 300 440). Most VTX modules shipped into the EU are technically non-compliant at any setting above 25 mW. - The broader 5 GHz UNII bands (5.15–5.35, 5.47–5.725 GHz) are used by WiFi but have DFS (Dynamic Frequency Selection) requirements due to radar coexistence. DFS can force your radio to change channels mid-flight. Not ideal.

What the regulations don't tell you: - 5.8 GHz has significantly higher path loss than 2.4 GHz. In free space, 5.8 GHz loses ~7.7 dB more than 2.4 GHz at the same distance. In practice this means roughly half the range per milliwatt. You compensate with power and antenna gain. - 5.8 GHz does not penetrate foliage, buildings, or terrain well. If you fly behind a tree, your video will break before your RC link does (assuming RC is on 2.4 GHz or 900 MHz). - At FPV race events, analog 5.8 GHz channel management is critical. 40 channels sounds like a lot until 8 pilots are in the air and their harmonics are stepping on each other. Digital systems (DJI, HDZero) are wideband and harder to deconflict — they don't fit neatly into the 40-channel system.

Sub-GHz Below 900 (433, 315, 169 MHz)

What lives here: LoRa long-range, some RC systems (FrSky R9 at 433 MHz in some regions), key fobs, garage door openers, tire pressure monitors, and very long-range telemetry.

Why it matters: Lower frequency = better propagation = longer range. 433 MHz LoRa links can reach 10+ km with tiny antennas and milliwatts of power. But bandwidth is measured in kilobits, not megabits.

Regulatory: - 433 MHz ISM: 10 mW in EU, not ISM in the US (amateur band, requires ham license for non-ISM use) - 315 MHz: US ISM for low-power devices - 169 MHz: EU smart meter band, very restricted

When you'd use it: Very long-range telemetry (LoRa), sub-floor FHSS detection (listening, not transmitting), or interoperability with existing infrastructure on these bands.

Military and Licensed Bands

L-band (1–2 GHz): Some tactical mesh radios (Doodle Labs HelixL+S). Military satellite. GPS (L1 at 1575.42 MHz, L2 at 1227.60 MHz). No ISM access — requires licensing or government authorization.

S-band (2–4 GHz): Overlaps 2.4 GHz ISM. Some military radar. Weather radar. Tactical links.

C-band (4–8 GHz): Doodle Labs C-Band radios, satellite downlinks, some military comms. Requires licensing in most jurisdictions.

You don't need to operate on these bands unless you're working with military or government platforms. But you do need to know they exist because: (a) military radar on S-band and C-band can overwhelm your receivers, and (b) GPS signals on L-band can be jammed or spoofed, affecting your drone's navigation.

The Gap Between Rules and Reality

What Operators Actually Do

The regulatory framework assumes static, ground-based transmitters in controlled environments. Drone operations are none of those things.

In practice: - FPV pilots routinely fly 600–800 mW VTX power despite EU limits of 25 mW - Long-range operators use 900 MHz at full power in countries where the band allocation is ambiguous - "1 W EIRP" limits are rarely enforced at hobby flying fields - Military operators have blanket spectrum authority in their operational areas and don't worry about ISM band rules

This handbook doesn't tell you to break the rules. It tells you the rules exist, what they are, and acknowledges that the enforcement reality differs from the regulatory text. Know your jurisdiction's rules. Make your own informed decisions.

Frequency Coordination at Events

At any gathering of more than 4-5 pilots:

1. Assign video channels before anyone powers up. Analog 5.8 GHz has 40 channels across 6 bands (A, B, E, F, R, L). Use non-adjacent channels. Band F (Fatshark / IRC) and Band R (RaceBand) are the most common for events.

2. Separate RC bands. If half the pilots are on 2.4 GHz ELRS and half are on 900 MHz Crossfire, that's actually ideal — no RC interference between the two groups.

3. Power down when not flying. A VTX broadcasting 800 mW on the ground creates more interference than one in the air at 200m, because ground-level signals have direct paths to every other receiver in the pit area.

4. Know your VTX table. Betaflight's VTX table maps power levels and channels for your specific VTX hardware. Verify it matches reality — misconfigured VTX tables can put you on the wrong channel or the wrong power level.

Frequency Coordination for Fleet Operations

At a commercial or tactical deployment with multiple drones:

1. Map all five links for each platform. Build a frequency plan before the operation, not during it.

2. Separate bands where possible. RC on 900, telemetry on 2.4, video on 5.8, mesh on a different 5 GHz channel. The more band separation, the less self-interference.

3. Document what's transmitting. If you're operating near other teams, other companies, or military assets, knowing exactly what frequencies you're using — and at what power — prevents problems and demonstrates professionalism.

4. Plan for interference. If your operation is near an airport, military base, or large venue (stadiums use a LOT of 2.4 and 5 GHz), your range predictions from a clean test site are optimistic. Budget a 50% range reduction in congested spectrum environments.

Quick Reference: Band Comparison

The universal trade-off: lower frequency = longer range and better penetration but less bandwidth. Higher frequency = more bandwidth but shorter range and worse penetration. Everything in RF engineering is a version of this trade-off.

Next

• Chapter 3: Antennas for People Who Aren't RF Engineers — how to choose, orient, and not break your antennas.
• Chapter 1: The Five Link Types — frequency deconfliction in the context of a complete drone system.

The spectrum is a shared resource. Know what you're transmitting, where, and at what power. The drone next to you is sharing the same resource.

Chapter 3: Antennas for People Who Aren't RF Engineers

The antenna is the most important and least understood component on your drone. A $200 radio with a bad antenna loses to a $30 radio with a good one.

The One Rule

Match your antenna to your link.

That's it. Everything else in this chapter is explaining what that means and how to do it.

What an Antenna Does

An antenna converts electrical signal into radio waves (transmit) and radio waves back into electrical signal (receive). It doesn't amplify — it shapes. An antenna with "5 dBi gain" isn't creating energy. It's focusing the energy that's already there into a narrower pattern, the same way a flashlight focuses light from a bulb into a beam.

More gain = narrower beam = longer range in one direction, shorter range in every other direction.

This is the fundamental trade-off in antenna selection. There is no antenna that's better in all directions. There are only antennas that trade coverage pattern for range.

Antenna Types You'll Actually Use

Dipole / Whip

What it is: A straight stick. The stock antenna on most receivers, telemetry radios, and mesh radios.

Pattern: Donut-shaped. Good coverage in all horizontal directions, weak directly above and below the antenna axis.

Gain: 2–5 dBi

When to use it: Default choice for anything where you don't know which direction the other radio will be. RC receivers, telemetry, mesh nodes on drones that fly in all orientations.

Orientation matters: A vertical dipole radiates horizontally. A horizontal dipole radiates vertically. On a drone, the receiver antenna should point down or sideways — NOT parallel to the frame. Two antennas at 90 degrees to each other (antenna diversity) covers all orientations.

Patch Antenna

What it is: A flat rectangle. Common on GPS modules, some directional links, and video receivers.

Pattern: Directional — strong in front, weak behind. Like holding up a book and only hearing what's in front of it.

Gain: 6–14 dBi depending on size

When to use it: On the ground station pointing at the drone. GPS antennas (patch facing sky). Video receiver antennas in goggles (facing forward). NOT on the drone itself unless you know exactly where the ground station will be.

The goggle antenna mistake: Many pilots fly with stock goggle antennas (usually small omnis) and wonder why they get video breakup at 500m. Replacing one goggle antenna with a directional patch that points toward the flying area can double or triple video range with no change to the drone.

Helical Antenna

What it is: A coil of wire. Comes in two types: normal-mode (small, used as compact omni) and axial-mode (larger, highly directional, used for long range).

Pattern: Axial-mode helix is a focused beam — high gain, narrow coverage. Normal-mode is similar to a dipole.

Gain: 8–15+ dBi (axial mode)

When to use it: Ground-station tracking antenna for long-range operations. Paired with an antenna tracker that points it at the drone. Not practical on the drone itself (too large, too directional).

Pagoda / Lollipop / Stubby

What it is: Compact circular-polarized antenna. The standard FPV video antenna on both the drone and the goggles.

Pattern: Roughly omnidirectional with circular polarization.

Gain: 1–3 dBi

When to use it: 5.8 GHz FPV video. Both the VTX antenna on the drone and the receiver antenna on the goggles should be circular polarized and the same handedness (both RHCP or both LHCP). Mixing handedness costs you ~3 dB (half your signal).

Why circular polarization for video: When a linearly polarized signal bounces off a surface (multipath), its polarization can rotate. If your receive antenna is linear and the signal arrives at the wrong angle, you lose it. Circular polarization doesn't have this problem — it receives equally regardless of rotation. The trade-off is ~3 dB less gain than an equivalent linear antenna.

PCB / Ceramic Chip Antenna

What it is: A tiny antenna printed on the circuit board or bonded as a ceramic chip. Found inside ESP32 modules, Bluetooth devices, GPS modules, and small receivers.

Pattern: Roughly omnidirectional but with significant nulls depending on PCB ground plane and nearby components.

Gain: -2 to 2 dBi (often negative gain compared to an ideal isotropic radiator)

When to use it: When size and cost matter more than range. The ESP32-C6 on a Tooth uses its built-in PCB antenna for mesh communication at short range. For anything beyond 100m, use an external antenna via the U.FL/IPEX connector if available.

Polarization

Radio waves vibrate in a specific orientation. If the transmit antenna sends vertically polarized waves and the receive antenna is oriented horizontally, you lose ~20 dB of signal. That's the difference between a clear link and no link.

The rules: - Linear antennas (dipole, whip): orient both the same way. Both vertical, or both horizontal. On a drone that changes orientation constantly, this is hard — which is why diversity (two antennas at 90 degrees) helps. - Circular polarized antennas (pagoda, lollipop): match handedness. Both RHCP or both LHCP. Don't mix. - Cross-polarization loss: linear TX → circular RX (or vice versa) costs ~3 dB. Not ideal but survivable.

Connectors

The small connectors used in drone antennas are fragile. Know them.

The U.FL problem: U.FL (also called IPEX or MHF) connectors are rated for about 30 connect/disconnect cycles. After that, the spring contact weakens and the connection becomes intermittent. Every time you unplug and replug a U.FL antenna, you're using one of those 30 cycles. On a racing drone that gets rebuilt weekly, this matters.

Fix: Don't disconnect U.FL antennas unless you have to. Route the antenna wire so it stays connected during maintenance. If a U.FL connection becomes intermittent (video cuts out when you flex the cable), replace the pigtail — the connector is worn out.

Antenna Placement on a Drone

Where you put the antenna matters as much as which antenna you choose.

Do

• Mount RC receiver antennas pointing away from the frame at 90 degrees to each other (diversity). The classic "V" shape with antenna tubes works.
• Mount GPS antenna on top of the frame with a clear view of the sky. No carbon fiber between the GPS patch and the satellites.
• Mount the VTX antenna where it won't get hit in a crash. Rear-facing on a standoff is common.
• Keep transmit antennas (VTX, mesh radio) as far from receive antennas (RC receiver, GPS) as physically possible on the frame.

Don't

• Don't run antenna wires parallel to power wires. Motor current creates magnetic fields that induce noise in antenna cables.
• Don't let antenna wires cross each other at sharp angles.
• Don't fold or kink antenna wires. The coax impedance changes at the bend and reflects signal back instead of radiating it.
• Don't mount antennas inside a carbon fiber enclosure. CF attenuates RF. If the antenna is inside a CF tube, you're losing signal.
• Don't forget the ground plane. A 900 MHz dipole needs a ground plane (the FC, the frame, or a dedicated ground plane element) to radiate properly. Hanging in free space with no ground reference, it underperforms.

Range Estimation (Quick and Dirty)

You don't need to calculate a full link budget to estimate range. Here's the shortcut.

Start with the manufacturer's claimed range. Divide by 3. That's your real-world range with obstacles, interference, and non-ideal antenna placement.

If you're doing better than 1/3 of claimed range, your setup is good. If you're doing worse, check antenna orientation, connections, and interference from other on-board transmitters.

If you need more range: 1. Better antenna on the ground station (cheapest improvement) 2. Higher VTX/radio power (easy but wastes battery) 3. Better antenna on the drone (limited by weight/size) 4. Lower frequency band (900 MHz instead of 2.4 GHz) 5. Higher gain directional antenna with tracker (most effective, most complex)

The order above is also the order of cost-effectiveness. A $15 directional antenna on your goggles does more for range than a $50 amplifier on the drone.

The Antenna You Already Have

Before buying new antennas, check the ones you have:

• Is it the right band? A 5.8 GHz antenna on a 2.4 GHz radio is a $0 dummy load. It will not work. At all. This sounds obvious but it happens.
• Is it connected? Flex the cable gently at the connector. If the signal changes, the connection is bad.
• Is it damaged? A cracked antenna element, kinked coax, or corroded connector all kill performance.
• Is it oriented correctly? Rotating an antenna 90 degrees can cost 20 dB. Try different orientations before buying a new antenna.

Long-Range Antenna Setups (What Actually Gets You 20km)

When you see someone post a 20km flight on a wifibroadcast system like OpenHD, they're not using stock dipoles. They're using a high-gain directional antenna on the ground pointed at the drone, usually with an antenna tracker. The drone side stays omni.

This is the same principle as TV broadcasting. The TV tower has a high-power omnidirectional transmitter. Your house has a directional antenna (the dish, the yagi on the roof) pointed at the tower. One side broadcasts everywhere, the other side listens in one direction very well. Wifibroadcast systems work identically.

Stock Antennas: Set Realistic Expectations

The math is simple. Every 6 dB of additional antenna gain roughly doubles your range. Going from a stock dipole (3 dBi) to a panel array (18 dBi) adds 15 dB — that's about 5.6× the range. 3 km × 5.6 = ~17 km.

OpenHD's own range calculations (from openhdfpv.org/hardware/antennas, assuming -93dBm Rx sensitivity and 10dB link margin) confirm this:

Their FAQ states it directly: "1–3km is easy to achieve, even with low power WiFi cards and the antennas that come with them. Carefully chosen WiFi cards, antennas, and optionally an antenna tracker should put 20km+ within reach."

Air Side: Stay Omnidirectional

The drone changes orientation constantly — banks, turns, pitches. A directional antenna on the drone would lose link every time it turns away from you. Use omnidirectional antennas:

• Cloverleaf / Skew-Planar (RHCP): 2-3 dBi, circular polarized. Better multipath rejection than linear dipoles. The standard upgrade from stock.
• Pagoda (RHCP): 3-5 dBi, still mostly omni. Slight gain improvement over cloverleaf.
• Stock dipole: Works fine under 2 km. Replace for anything serious.

Use matching polarization on both ends — vertical/vertical or horizontal/horizontal. Cross-polarization costs 3 dB (half your power). RHCP circular polarization works for multipath rejection but most wifibroadcast community setups use linear vertical since the common directional ground antennas (panels, yagis) are linear vertical.

Ground Side: This Is Where Range Comes From

Antenna Trackers

Once your ground antenna exceeds ~10 dBi, the beam is narrow enough that you need to physically point it at the drone. An antenna tracker does this automatically using the drone's GPS position from the telemetry stream.

Dual Antenna Diversity (Best Practice)

Run two antennas on the ground: one omni + one directional on a tracker. The receiver picks the strongest signal per packet.

This gives you reliable close-range coverage (omni catches the drone overhead, behind you, during takeoff/landing) AND long-range capability (directional catches it at 15km). No switching, no manual pointing for nearby flights.

Most wifibroadcast systems (OpenHD, Ruby) support antenna diversity natively — plug in two adapters and it works.

Next

• Chapter 4: Link Budgets Without the Math — estimating range from specs without a calculator.
• Chapter 1: The Five Link Types — which antenna goes with which link.

The best antenna is the one that's pointed the right way, connected properly, and on the correct frequency. Everything else is optimization.

Chapter 4: Link Budgets Without the Math

A link budget tells you whether your radio link will work at a given distance. You don't need a calculator. You need to understand three numbers and three things that kill them.

The Three Numbers

Every radio link has three numbers that determine whether it works:

1. Transmit Power (How loud you're shouting)

Measured in milliwatts (mW) or dBm. More power = more range, up to a point.

The key insight: Doubling your power only gets you ~40% more range (because radio signal falls off with the square of distance). Going from 100 mW to 200 mW doesn't double your range — it adds about 40%. Going from 100 mW to 1000 mW (10x power) roughly triples your range. Power is an expensive way to buy range.

2. Receiver Sensitivity (How well you can hear a whisper)

Measured in dBm (negative numbers — more negative = more sensitive). This is how faint a signal the receiver can still decode.

The key insight: Receiver sensitivity improves when you lower the data rate. ELRS at 500 Hz (fast, for racing) has worse sensitivity than ELRS at 50 Hz (slow, for long range). This is why long-range modes exist — they trade update rate for range.

3. Link Margin (How much room you have before it breaks)

Link margin = (transmit power + antenna gains) - (path loss) - (receiver sensitivity)

If the margin is positive, the link works. If it's negative, it doesn't. The bigger the positive margin, the more resilient the link is to fading, interference, and obstacles.

Comfortable margins: - 10 dB: Works in clean conditions, fragile in the real world - 20 dB: Handles moderate interference and some obstacles - 30 dB+: Robust link, will survive urban environments and bad days

The Three Things That Kill Links

1. Distance (Path Loss)

Radio signals get weaker with distance. In free space (no obstacles), the signal drops by 6 dB every time you double the distance. That means at twice the distance, you have one quarter the signal power.

Free-space path loss at common frequencies:

Read this table like this: at 1 km on 2.4 GHz, the signal is 80 dB weaker than when it left the transmitter. If you started with 20 dBm (100 mW) transmit power and 0 dBi antennas, the signal arriving at the receiver is 20 - 80 = -60 dBm. If your receiver sensitivity is -112 dBm, your margin is 52 dB. Plenty.

At 10 km, the same setup gives you 20 - 100 = -80 dBm arriving signal. Margin is 32 dB. Still fine in free space.

But you're not in free space.

2. Obstacles (The Real Range Killer)

Free-space path loss is the theoretical minimum. Everything else makes it worse:

The single biggest factor in real-world range is line of sight. If you can see the other antenna, the link probably works. If you can't, it might not. Every obstacle between the two antennas subtracts from your margin.

This is why 900 MHz outperforms 2.4 GHz in obstructed environments — lower frequencies diffract around obstacles better. A 900 MHz signal bends around a tree that a 5.8 GHz signal bounces off of.

3. Interference (The Urban Tax)

Every other radio on your frequency subtracts from your link margin by raising the noise floor. In a clean rural environment, the noise floor might be -110 dBm. In a city, it could be -90 dBm. That's 20 dB of margin you just lost to other people's WiFi.

The fix isn't more power (that raises the noise floor for everyone). The fix is: - Different frequency band (if possible) - More directional antennas (which reject interference from the sides) - Lower data rate (which improves receiver sensitivity) - Better antenna placement (which avoids self-interference)

The No-Math Range Estimate

You don't need to calculate path loss. Use this:

Step 1: Find the manufacturer's claimed range for your radio link.

Step 2: Apply the environment factor:

Step 3: That's your expected range.

Example: ELRS 900 MHz at 100 mW claims 30 km range. - Open field: 30 × 0.7 = 21 km. Reasonable. - Suburban: 30 × 0.4 = 12 km. Realistic. - Urban: 30 × 0.2 = 6 km. About right. - These are LOS (line of sight) estimates. Flying behind a hill or building cuts range further.

How Antennas Change the Budget

Antenna gain is free range. A 6 dBi antenna on the ground station adds 6 dB of margin, which effectively doubles your range compared to a 0 dBi antenna, without increasing power or changing anything on the drone.

Both ends count. If you add 3 dBi on the drone antenna AND 3 dBi on the ground station antenna, you get 6 dB total improvement. But adding gain on the ground station is usually easier (no weight constraint, can use larger antennas, can use a tracker).

The practical limit: On the drone, you're limited to small, lightweight, roughly omnidirectional antennas (2–5 dBi). On the ground, you can use a directional patch (8–14 dBi) or helical (10–16 dBi) on a tracker. The ground antenna is where you get the most range improvement per dollar.

Putting It Together: Example Link Budgets

FPV Racing Quad (Short Range)

RC Link (ELRS 2.4 GHz, 250 mW, 500 Hz):
  TX power:            24 dBm
  TX antenna:          2 dBi (dipole on drone)
  RX antenna:          2 dBi (dipole on TX)
  Path loss at 500m:  -74 dB
  Arriving signal:     24 + 2 + 2 - 74 = -46 dBm
  RX sensitivity:     -108 dBm (ELRS 500 Hz)
  Margin:              62 dB  ← massive, no problems

Racing at 500m with ELRS has 62 dB of margin. You could fly behind buildings and through moderate obstacles and still be fine. RC is not your range bottleneck.

Video Link (Analog 5.8 GHz, 400 mW):
  TX power:            26 dBm
  TX antenna:          2 dBi (pagoda)
  RX antenna:          2 dBi (pagoda on goggles)
  Path loss at 500m:  -82 dB
  Arriving signal:     26 + 2 + 2 - 82 = -52 dBm
  RX sensitivity:     -85 dBm (analog threshold for usable image)
  Margin:              33 dB  ← healthy

At 500m, analog video has 33 dB of margin. At 2 km it drops to about 21 dB. At 5 km, about 7 dB — you'll see static. Video is always the range bottleneck on an FPV quad, not RC.

Long-Range Survey (5 km)

Telemetry (RFD900x, 1W, 900 MHz):
  TX power:            30 dBm
  TX antenna:          3 dBi (dipole on drone)
  RX antenna:          6 dBi (directional on GCS)
  Path loss at 5 km:  -85 dB
  Arriving signal:     30 + 3 + 6 - 85 = -46 dBm
  RX sensitivity:     -121 dBm (SiK at 64 kbps)
  Margin:              75 dB  ← enormous

RFD900x at 5 km in open terrain has 75 dB of margin. Even in heavy suburban with 25 dB noise floor elevation and 15 dB of foliage, you still have 35 dB of margin. This is why RFD900x is the standard for long-range telemetry.

Quick Reference: What Uses Your Margin

Next

• Chapter 3: Antennas — how antenna gain and placement affect these numbers.
• Chapter 1: The Five Link Types — which links are range-limited and which aren't.

Range is not a single number. It depends on what's between you and the drone. The link budget tells you how much you can afford to lose before the link breaks.

Chapter 5: The Four Firmwares

There are four flight controller firmware ecosystems that matter. Each one is the right choice for somebody and the wrong choice for somebody else. This chapter helps you figure out which.

The Landscape

All four are open-source. All four run on STM32 flight controllers. All four are actively developed. None of them are going away.

Betaflight

What it does well: Rate-mode acrobatic flight. Sub-millisecond gyro loop. The tightest, most responsive flight controller stack for manual piloting. If you're flying FPV by hand and you want the sticks to feel like an extension of your body, Betaflight.

What it doesn't do: Autonomous anything. No waypoint missions, no GPS hold (angle mode with GPS rescue is a failsafe, not a flight mode), no companion computer integration beyond MSP bridge, no offboard control. Betaflight assumes a human is flying at all times.

Protocol: MSP v2. Binary request/response over serial. Simple, fast, well-documented. Every message has a function code and a payload. Read PID values, write PID values, download blackbox, read sensor state. No streaming — you ask, it answers.

Configuration: Betaflight Configurator (Chrome app) or CLI. The CLI is powerful — diff all gives you a complete delta from defaults, dump all gives you everything. Most experienced operators work in CLI.

Typical platforms: 5-inch freestyle quads, 3-inch cinewhoops, racing drones, micro quads, FPV wings (with limitations).

Community: Massive. Largest FPV firmware community. Fast development cycle. Frequent releases. Sometimes too frequent — breaking changes between minor versions are common.

When to choose it: Your primary control input is a human with a transmitter. You need the best possible manual flight feel. You don't need autonomous modes, waypoints, or programmatic control.

iNav

What it does well: GPS navigation on everything. Multi-rotor, fixed-wing, VTOL, rovers, boats. If it moves and you want it to follow waypoints or hold position, iNav probably supports it. iNav is what Betaflight would be if Betaflight cared about navigation.

What it doesn't do: It doesn't have ArduPilot's depth of autonomous mission planning or PX4's companion computer integration. It's a step up from Betaflight toward autonomy, but it's not a full autopilot stack.

Protocol: MSP v2 with extensions. Same wire format as Betaflight, but with additional messages for navigation, waypoints, and mission planning. iNav also supports MSP2_COMMON_SETTING for named parameter access — cleaner than Betaflight's CLI-only approach for many settings.

Configuration: iNav Configurator (forked from Betaflight Configurator, same Chrome app pattern). CLI is similar but not identical to Betaflight — don't assume commands transfer 1:1.

Typical platforms: Long-range FPV with GPS return, survey wings, fixed-wing platforms, VTOL (tiltrotor, tailsitter), autonomous boats, GPS-guided multicopters.

Community: Smaller than Betaflight, deeply knowledgeable. Fixed-wing and VTOL support is stronger than any other open-source option except ArduPilot.

When to choose it: You need GPS navigation and you're coming from the FPV world. You want something more capable than Betaflight but less complex than ArduPilot. You're building a fixed-wing or VTOL and don't want to learn the ArduPilot parameter universe.

ArduPilot

What it does well: Everything. Multi-rotor, fixed-wing, helicopter, rover, submarine, boat, antenna tracker, blimp. ArduPilot is the Swiss Army knife of autopilots. It has more flight modes, more parameters, more sensor support, and more mission planning capability than any other open-source firmware.

What it doesn't do well: Simple. ArduPilot has ~1,200 parameters. The learning curve is real. The documentation is extensive but assumes you know what you're looking for. If you just want to fly a 5-inch quad freestyle, ArduPilot is overkill.

Protocol: MAVLink v2. Binary message protocol with system/component addressing. Every device on the network has a system ID (1-254) and component ID (1-254). Messages are published, not requested — you tell the FC what stream rates you want and it sends them continuously. Bidirectional: commands go up, telemetry comes down.

Configuration: Mission Planner (Windows), QGroundControl (cross-platform), MAVProxy (command-line). Parameter tree is deep — learning which parameters matter for your platform takes time. The ArduPilot wiki is your primary reference.

Typical platforms: Commercial survey drones, delivery platforms, research vehicles, defense platforms, agricultural sprayers, any platform that needs full autonomous mission capability.

Community: Large, technical, welcoming. Strong contributor base. Excellent wiki. Monthly developer calls. The go-to choice for academic and government research.

When to choose it: You need real autonomous capability. Waypoint missions, sensor integration, companion computer support, multiple flight modes, or you're building something that isn't a standard multicopter. ArduPilot probably already supports your platform.

PX4

What it does well: Companion computer integration, research workflows, defense applications. PX4 was designed from the ground up for programmatic control. The uORB publish/subscribe internal bus, the uXRCE-DDS bridge to ROS2, and the clean offboard control API make it the natural choice when a computer is flying the drone and a human is supervising.

What it doesn't do well: Community hand-holding. PX4's documentation assumes a higher baseline than ArduPilot's. The parameter set (~900 parameters) is smaller than ArduPilot's but the naming convention is less intuitive. Hardware support is narrower — PX4 cares less about supporting every FC board and more about supporting the ones that matter for its target users.

Protocol: MAVLink v2 (same as ArduPilot, different dialect extensions). Additionally supports uXRCE-DDS for high-bandwidth sensor telemetry to companion computers, replacing the older microRTPS bridge.

Configuration: QGroundControl (primary), PX4 CLI via MAVLink shell. No equivalent to ArduPilot's Mission Planner.

Typical platforms: Research drones, defense autonomous systems, companion-compute-heavy platforms, anything running ROS2, platforms that need VTOL transition.

Community: Smaller than ArduPilot, more academic/defense-focused. Strong institutional backing (Dronecode Foundation, Auterion). Development is faster on core features, slower on edge-case platform support.

When to choose it: You're integrating with ROS2 or a companion computer. You need offboard control APIs. You're building for defense or research. You want a clean software architecture that's designed for programmatic control first and manual control second.

Cross-Firmware Reality

The Split

The FPV world runs Betaflight and iNav. MSP protocol. Configurator apps. CLI dumps. Rate mode. Manual piloting with optional GPS backup.

The autonomous world runs ArduPilot and PX4. MAVLink protocol. GCS applications. Parameter trees. Mission planning. The human supervises, the computer flies.

These two worlds are converging. Betaflight quads are getting GPS rescue and companion computers. ArduPilot platforms are getting acro mode and FPV video. But the protocol split (MSP vs. MAVLink) remains the fundamental divide.

Any tool that wants to work across the whole spectrum — which is what Wingman does — needs to speak both languages fluently.

Switching Firmware

Changing firmware on an existing platform is possible but not trivial. The major challenges:

• Parameter translation: Betaflight PID 44 is not the same as ArduPilot ATC_RAT_RLL_P 0.135. The numbers are in different units, different scales, different ranges. Translation requires understanding both systems.
• UART reassignment: Each firmware has its own UART allocation conventions. Moving from Betaflight to iNav may require remapping every serial port.
• Sensor calibration: Accelerometer, gyro, and compass calibration doesn't transfer. Re-calibrate everything.
• Failsafe behavior: Different firmwares handle RC loss, GPS loss, and battery failsafe differently. Understand the new behavior before you fly.

Quick Reference

Next

• Chapter 6: MSP Protocol — how to talk to Betaflight and iNav from anything with a serial port.
• Chapter 7: MAVLink Protocol — how to talk to ArduPilot and PX4 from anything with a network connection.

No religious wars. Use what works for your mission. Switch when the mission changes.

Chapter 6: MSP Protocol — The Betaflight/iNav Language

MSP is a question-and-answer protocol. You ask the FC a question (send a request with a function code). It answers (sends a response with the data). No streaming, no subscriptions, no surprises.

What MSP Is

MSP (MultiWii Serial Protocol) is the serial communication protocol used by Betaflight and iNav. It's been around since the MultiWii days and has evolved through several versions. The current version is MSP v2, which supports 16-bit function codes and CRC8 checksums.

MSP is simple by design. It runs over any serial connection (UART, USB, TCP, Bluetooth) at any baud rate. There are no connection handshakes, no sessions, no state. Send a request, get a response.

Packet Format

MSP v2 Request (outgoing)

Byte:  0     1     2     3     4-5       6     7-8       9..N     N+1
       $     X     <     flag  func_id   0x00  payload   payload  crc8
       0x24  0x58  0x3C  0x00  [16-bit]  0x00  size[16]  [data]   [crc]

MSP v2 Response (incoming)

Byte:  0     1     2     3     4-5       6-7       8..N     N+1
       $     X     >     flag  func_id   size      payload  crc8
       0x24  0x58  0x3E  0x00  [16-bit]  [16-bit]  [data]   [crc]

Same structure but with > (0x3E) instead of < (0x3C).

The Messages That Matter

Identity

These are the first messages to send on any new connection. They tell you what firmware is running, what version, and what hardware it's running on.

Auto-detect pattern: Send MSP_FC_VARIANT. If you get "BTFL", it's Betaflight. If "INAV", it's iNav. If no response within 2 seconds, it's not an MSP firmware (try MAVLink).

PID Tuning

Each value is 0-255. The FC interprets these differently by firmware version (scaling factors change between BF 4.3 and 4.4, for example). Always record the firmware version alongside PID values.

Rates

Rate payload format depends on the configured rate type (Betaflight rates, Actual rates, KISS rates, Quick rates). Read rates_type from the RC tuning response to know how to interpret the values.

Filters

Battery

Blackbox

Blackbox download is the most bandwidth-intensive MSP operation. At 115200 baud, downloading 2 MB of flash takes ~3 minutes. At 921600 baud (via ESP32 bridge), it takes ~20 seconds.

Motor Control

MSP_SET_MOTOR bypasses the PID controller and directly sets motor outputs. Props must be removed when using this. This is for motor direction testing, not flight.

EEPROM

Always send MSP_EEPROM_WRITE after SET commands. Without it, your changes are lost on the next reboot.

Write Safety Pattern

Never write to an FC without this sequence:

1. Read the current value (snapshot before)
2. Show the diff to the operator (before vs after)
3. Get approval (operator confirms)
4. Write the new value via MSP_SET_*
5. Read back to verify the FC accepted it
6. Compare read-back to what you wrote
7. EEPROM write after all changes in the batch
8. Log every change with timestamp, old value, new value

Step 5 is critical. Some FC firmware versions silently clamp values to valid ranges. If you write P=200 and read back P=150, the FC clamped it. Your operator needs to know.

Practical Tips

Baud rate: MSP works at any baud rate, but the FC UART must be configured to match. Betaflight defaults MSP-configured UARTs to 115200. You can change this in the Ports tab. For blackbox download speed, 921600 is recommended.

Timeout: If you send a request and don't get a response within 100 ms, the FC didn't understand it (wrong function code, wrong firmware version, or the UART isn't configured for MSP). Retry once, then try a different approach.

Versioning: MSP function codes and payload formats change between firmware versions. A message that works on BF 4.4 may not exist on BF 4.2. Always detect the firmware version (MSP_FC_VERSION) before sending version-specific messages.

Multiple MSP ports: An FC can have multiple UARTs configured for MSP simultaneously. This is useful for connecting both a configurator and a companion computer. Each port operates independently.

MSP over WiFi: The ESP32 bridge (Tooth, SpeedyBee adapter) wraps MSP in TCP. The byte stream is identical to serial — the same parser works on both USB and TCP transport. The only difference is the connection setup.

Next

• Chapter 7: MAVLink Protocol — the other language, for ArduPilot and PX4.
• Chapter 8: UART Layout — where to put your MSP connections.

MSP is simple. That's its strength. Ask a question, get an answer. No handshakes, no state, no negotiation. The protocol stays out of the way so you can focus on the data.

Chapter 7: MAVLink Protocol — The ArduPilot/PX4 Language

MAVLink is a publish-subscribe protocol. You tell the FC what streams you want, and it sends them continuously. You send commands when you need something done. Both directions flow at the same time.

What MAVLink Is

MAVLink (Micro Air Vehicle Link) is the communication protocol used by ArduPilot, PX4, and their ecosystems. It's been the standard for autonomous drone communication since ~2009.

Unlike MSP (request-response), MAVLink is a streaming protocol. The FC continuously publishes telemetry at configured rates, and the GCS/companion sends commands as needed. Both directions are independent — you can receive telemetry while sending a command.

MAVLink v2 is the current version. v1 is deprecated but still supported for backward compatibility. Always use v2 for new development.

Packet Format (MAVLink v2)

Byte:  0     1     2     3     4       5       6       7-9       10..N    N+1..N+2
       0xFD  len   seq   sys   comp    msg_id  msg_id  msg_id    payload  crc16
       magic             id    id      [24-bit LE]               [data]   [checksum]

System and Component IDs

Every device on a MAVLink network has a system ID and component ID.

System ID: Identifies the vehicle. Drone 1 = system 1, Drone 2 = system 2. GCS is typically system 255. In a swarm, each drone must have a unique system ID.

Component ID: Identifies a subsystem within the vehicle. - 1 = Autopilot (the FC) - 100 = Camera - 154 = Gimbal - 191 = Companion computer (Wingman uses this) - 250 = GCS

Why this matters: When you connect to a mesh with 10 drones, you'll receive MAVLink messages from all of them. The system ID tells you which drone sent each message. If two drones have the same system ID, you can't tell them apart. This is one of the most common mistakes in multi-vehicle setups.

Setting the system ID: - ArduPilot: SYSID_THISMAV parameter - PX4: MAV_SYS_ID parameter

The Messages That Matter

HEARTBEAT (msg_id = 0) — The Keepalive

Every MAVLink device sends HEARTBEAT at 1 Hz. It's how devices discover each other and know the connection is alive.

Fields:
  type          = vehicle type (2=quadrotor, 1=fixed wing, etc.)
  autopilot     = firmware (3=ArduPilot, 12=PX4)
  base_mode     = armed/disarmed flag (bit 7)
  custom_mode   = current flight mode (firmware-specific number)
  system_status = boot/calibrating/active/critical/emergency

Auto-detect pattern: Send a HEARTBEAT with system ID 255 (GCS). Wait for a response. Read the autopilot field: 3 = ArduPilot, 12 = PX4. This is the equivalent of MSP_FC_VARIANT for the MAVLink world.

No heartbeat = dead link. If you stop receiving heartbeats from a drone for > 5 seconds, the link is lost. ATAK and QGC both use this to mark connections as stale.

Parameter Protocol

MAVLink parameters are named floating-point values. ArduPilot has ~1,200. PX4 has ~900.

Full parameter pull: 1. Send PARAM_REQUEST_LIST 2. FC streams PARAM_VALUE messages (one per parameter) 3. Track received indices — if any are missing after the stream ends, request them individually with PARAM_REQUEST_READ

A full pull of ~1,200 ArduPilot parameters at 115200 baud takes 5-15 seconds depending on link quality.

Writing a parameter: 1. Send PARAM_SET with param_id (name) and param_value 2. FC responds with PARAM_VALUE confirming the new value 3. If the confirmed value differs from what you sent, the FC rejected or clamped the value

Parameters persist across reboots (stored in EEPROM/flash). No separate save command needed, unlike MSP's MSP_EEPROM_WRITE.

Telemetry Streams

Request telemetry streams by sending REQUEST_DATA_STREAM or SET_MESSAGE_INTERVAL.

Key telemetry messages:

Setting stream rates (ArduPilot):

SR0_POSITION=2      # GLOBAL_POSITION_INT at 2 Hz
SR0_EXTRA1=4         # ATTITUDE at 4 Hz
SR0_EXTRA2=2         # VFR_HUD at 2 Hz
SR0_RAW_SENS=1       # RAW sensor data at 1 Hz
SR0_RC_CHAN=5         # RC channels at 5 Hz

SR0_* parameters control stream rates for serial port 0 (usually TELEM1). Replace 0 with the port number for other connections.

Setting stream rates (PX4): PX4 uses SET_MESSAGE_INTERVAL command to set per-message rates.

Commands

MAVLink commands are sent via COMMAND_LONG or COMMAND_INT and acknowledged via COMMAND_ACK.

Arm command:

COMMAND_LONG:
  target_system = 1    (drone's system ID)
  command = 400         (ARM_DISARM)
  param1 = 1.0          (1=arm, 0=disarm)
  param2 = 0.0          (0=normal, 21196=force arm — dangerous)

Wait for COMMAND_ACK. Result 0 = accepted. Result 4 = denied (pre-arm checks failed). Result 5 = in progress.

Mission Protocol

Upload waypoint missions to the FC:

1. Send MISSION_COUNT (number of waypoints)
2. FC requests each with MISSION_REQUEST_INT
3. Send each MISSION_ITEM_INT
4. FC confirms with MISSION_ACK

Download existing mission: 1. Send MISSION_REQUEST_LIST 2. FC sends MISSION_COUNT 3. Request each with MISSION_REQUEST_INT 4. FC sends each MISSION_ITEM_INT

Offboard Control (PX4)

PX4's offboard mode lets the companion computer directly command position, velocity, or attitude setpoints:

SET_POSITION_TARGET_LOCAL_NED:
  x, y, z = position in local NED frame (meters)
  vx, vy, vz = velocity (m/s)
  type_mask = which fields are valid

Requirements for offboard mode: 1. Companion must stream setpoints at > 2 Hz (PX4 requires continuous updates or it exits offboard mode) 2. RC switch must be set to offboard mode 3. Vehicle must be armed

This is the control path for Wingman L3 (Delegate) autonomous operations on PX4.

ArduPilot vs. PX4: MAVLink Differences

Both speak MAVLink v2, but they differ in important ways:

Implication for tools: Any tool that works across both ArduPilot and PX4 (QGroundControl, MAVSDK, Wingman) must handle these differences. The MAVLink wire format is identical — the interpretation of mode numbers, parameter names, and command behaviors differs.

Practical Tips

Always send heartbeats. Your GCS or companion must send HEARTBEAT at 1 Hz to the FC. If the FC doesn't receive GCS heartbeats, it may trigger GCS failsafe (ArduPilot: FS_GCS_ENABLE).

Monitor packet loss. MAVLink packets have a sequence number. If you see gaps in the sequence, you're losing packets. At > 5% loss, the link is degraded. At > 20%, it's unreliable for commands.

Don't flood the link. Sending commands faster than the FC can process them causes buffer overflow and dropped messages. One command at a time, wait for COMMAND_ACK before sending the next.

Use MAVSDK or pymavlink, not raw parsing. MAVLink has 300+ message types with varying payload formats. Writing a parser from scratch is an error-prone waste of time. MAVSDK (for control) and pymavlink (for analysis) handle the parsing.

Test with SITL. Both ArduPilot and PX4 have Software-In-The-Loop simulators that emulate a real FC over a simulated MAVLink link. Test your companion software against SITL before connecting to real hardware.

Next

• Chapter 6: MSP Protocol — the simpler alternative for Betaflight and iNav.
• Chapter 8: UART Layout — where MAVLink connections go in the FC's serial port map.

MAVLink is a conversation. The FC talks continuously. You listen and speak when you have something to say. The protocol handles the rest.

Chapter 8: UART Layout and Why It Matters

You will run out of UARTs before you run out of ideas. Planning the layout before you build saves hours of rewiring later.

What a UART Is

A UART (Universal Asynchronous Receiver/Transmitter) is a serial port. Two wires: TX (transmit) and RX (receive). Every device that talks to the flight controller — RC receiver, GPS, telemetry radio, companion computer, ESC telemetry, Bluetooth module, mesh radio — needs a UART.

The flight controller has a fixed number of UARTs. Once they're allocated, they're gone. Adding another device means either freeing a UART or getting a different FC.

How Many UARTs You Actually Get

"Usable" is lower than "hardware" because: - One UART is typically dedicated to USB (VCP/CDC) for configurator access - Some UARTs share pins with SPI (used for gyro, OSD, flash) and can't be used - Some UARTs have inverted-only pads on the PCB (for SBUS) and can't be repurposed without hardware modification

Check your FC's documentation for which UARTs are actually available on pads. The schematic may show 6 UARTs, but if only 4 have TX/RX pads on the board, you have 4 usable UARTs.

The Standard Allocation

For a typical FPV quad with GPS and telemetry:

That uses 4 of your ~5 usable UARTs and you haven't added a companion computer, mesh radio, or Bluetooth module yet.

What Eats UARTs

Every peripheral that communicates over serial needs its own UART. Here's the complete list of things that might want one:

Strategies When You Run Out

1. CRSF Telemetry Passthrough

If your RC receiver uses CRSF protocol (ELRS, Crossfire, Ghost), it already has a bidirectional link to the transmitter. You can send telemetry data (battery, GPS, attitude) through the RC link instead of using a separate telemetry radio.

Saves: 1 UART (the one that would have gone to a telemetry radio)

Trade-off: Telemetry bandwidth is limited to what CRSF can carry (basic flight data, not full MAVLink). If you need full MAVLink telemetry (parameter editing, mission upload), you still need a separate radio.

2. Soft Serial

Betaflight and iNav support "soft serial" — bit-banging a UART on any GPIO pin. It works for low-baud-rate devices.

Saves: 1 hardware UART

Trade-off: Limited to ~19200 baud reliably. Not suitable for CRSF (420000), GPS at high rate, or MAVLink. Good for: SmartPort telemetry, serial LED, low-rate telemetry.

3. Companion Computer as Hub

Instead of connecting multiple devices to the FC, connect them to a companion computer and use one UART between the companion and FC.

Before (4 UARTs on FC):
  FC UART1 ← RC receiver
  FC UART2 ← GPS
  FC UART3 ← Telemetry radio
  FC UART4 ← Mesh radio

After (2 UARTs on FC):
  FC UART1 ← RC receiver
  FC UART2 ← Companion computer (MAVLink)

  Companion ← GPS (USB)
  Companion ← Telemetry radio (USB or Ethernet)
  Companion ← Mesh radio (Ethernet)

Saves: 2+ UARTs on the FC

Trade-off: Adds weight, power consumption, and complexity. The companion computer becomes a single point of failure for everything except manual RC control.

4. I2C Instead of Serial

Some peripherals (compass, barometer, rangefinder, optical flow) are available in both serial and I2C versions. I2C uses a shared bus — multiple devices on the same two wires (SDA, SCL).

Saves: 1 UART per device moved to I2C

Trade-off: I2C is slower than serial and can have bus contention issues with multiple devices. But for low-bandwidth sensors, it's fine.

5. DMA and UART Sharing (Advanced)

On STM32H7 FCs, DMA (Direct Memory Access) allows the CPU to handle UART traffic more efficiently. Some advanced configurations use UART inversion and protocol detection to share a single UART between two devices that take turns.

This is fragile, FC-specific, and not recommended unless you know exactly what you're doing.

The UART Planning Template

Before building, fill this out:

Platform: _______________
FC: _______________
MCU: _______________
Available UARTs: _______________

| UART | Device | Protocol | Baud Rate | Required? |
|------|--------|----------|-----------|-----------|
| 1    |        |          |           |           |
| 2    |        |          |           |           |
| 3    |        |          |           |           |
| 4    |        |          |           |           |
| 5    |        |          |           |           |
| 6    |        |          |           |           |

Devices that didn't get a UART:
  _______________ → moved to I2C / soft serial / companion / dropped

UARTs remaining after allocation: ___

If you fill this out and you're already at zero remaining UARTs before adding the companion computer you wanted, you need a different FC or a companion-as-hub architecture.

Platform-Specific UART Maps

Typical F405 (4 usable UARTs)

UART1 → USB VCP (configurator) — not available for peripherals
UART2 → RC Receiver (CRSF @ 420000)
UART3 → GPS (UBX @ 115200)
UART4 → Available
UART5 → Available
UART6 → ESC Telemetry (if DShot bidirectional)

Two free UARTs (4 and 5) for telemetry radio, companion, mesh, or Bluetooth.

Orqa H7 QuadCore (6+ usable UARTs)

USART1 → USB VCP
USART2 → Available
USART3 → RC (GHST/IRONghost @ 420000)
UART4  → Available
USART6 → MAVLink telemetry (ATAK/TAK @ 115200)
UART7  → GPS (UBX @ 115200)
UART8  → ESC telemetry

Three free UARTs (2, 4, plus potential soft serial). The H7's extra UARTs are why it supports more complex integrations than F4.

PX4 on Pixhawk 6X

TELEM1 → MAVLink GCS (115200 or 57600)
TELEM2 → MAVLink companion computer (921600)
GPS 1  → GPS (auto-detect)
GPS 2  → Second GPS or compass
RC IN  → RC receiver (SBUS/CRSF)
DEBUG  → Console / NSH shell

PX4 labels its ports by function rather than UART number. The mapping to hardware UARTs is in the board configuration.

Common Mistakes

1. Wrong baud rate. CRSF is 420000. Many people set 115200 because that's the "default" they're used to. The receiver will not connect. Always check the protocol's required baud rate.

2. TX/RX swap. FC TX connects to device RX, and vice versa. This is wrong more often than any other wiring mistake. If a serial device doesn't respond, swap TX and RX as the first diagnostic step.

3. Voltage mismatch. Most FCs output 3.3V serial. Most peripherals accept 3.3V. But some older devices are 5V serial and can damage 3.3V inputs. Check before connecting.

4. Two devices on one UART. You can't connect a GPS and a telemetry radio to the same UART and expect both to work. Serial is point-to-point. Use a companion computer or multiplexer if you need to share.

5. Forgetting the configurator UART. If you reassign the USB/VCP UART to a peripheral, you may lose the ability to connect Betaflight Configurator. Always keep at least one path to the configurator available (USB or MSP-over-other-UART).

Next

• Chapter 6: MSP Protocol — the protocol that rides on these UARTs when talking to Betaflight and iNav.
• Chapter 13: Adding a Companion Computer — the architecture that solves the "not enough UARTs" problem.

Plan your UARTs before you solder. Desoldering a GPS module because you need that UART for a companion computer is not how you want to spend a Saturday.

Chapter 9: Pre-Flight Checklist That Actually Works

The manufacturer's checklist is marketing. This one catches the problems that actually ground you.

The 60-Second Field Check

This is the minimum check before every flight. Takes 60 seconds once you've done it a few times. Skipping it takes longer when you have to walk 500 meters to recover a crashed drone.

Visual (15 seconds)

1. Props: All four present, correct rotation, no nicks, nuts tight. Spin each by hand — should rotate freely with no catch.

2. Frame: No cracks on arms. No loose standoffs. Antenna mounts intact. Nothing rattling when you shake it.

3. Battery: Strapped tight. Will not shift under acceleration. Balance lead tucked, not dangling near props.

4. Antenna position: RC antenna elements deployed (not folded under the frame). VTX antenna pointed up/back, not blocked by battery. GPS antenna has clear sky view.

Power-On (30 seconds)

1. Voltage check: Battery voltage matches expected full charge. 4S = 16.4–16.8V. 6S = 24.6–25.2V. If significantly low, the battery wasn't fully charged or a cell is bad. Don't fly it.

2. Gyro cal: Wait for the FC to finish gyro calibration (usually 1-2 seconds after power on). Don't move the quad during this time. On Betaflight the OSD shows "CALIBRATING" then clears.

3. RC link: Confirm connected. Move sticks — verify response on OSD or in the video feed (stick position overlay if enabled). Check that arming switch is in disarmed position.

4. GPS (if equipped): Check satellite count. Wait for 3D fix. Most firmwares show sat count on OSD. Minimum 8 sats for any GPS-dependent mode. More is better. If you need GPS return-to-home, confirm the home point is set (some firmwares set home on arm, others on first GPS lock).

5. Video feed: Confirm you see a live image in your goggles or monitor. Correct channel. No interference patterns. If analog, check that nobody else is on your channel.

Arm Check (15 seconds)

1. Clear the area. Nobody within 3 meters of the drone. Nothing the drone could hit if it does something unexpected on arm.

2. Arm. Motors should spin at idle (or not, if "Motor Stop" is enabled). Listen for any unusual sounds — grinding, clicking, uneven RPM.

3. Control check (optional but recommended on new builds): With the drone on the ground, briefly blip throttle and check that it tries to lift evenly. Tilt the quad by hand — motors should speed up on the low side to self-level (in angle/level mode) or resist the tilt (in acro/rate mode).

Go fly.

The Deep Check (Pre-Session or New Build)

Do this once per session (before the first flight of the day) or after any change to the build (new props, firmware update, parameter change, crash repair).

Electrical

• [ ] Battery internal resistance: check with charger. Per-cell IR above 15 mΩ on LiPo or above 30 mΩ on Li-Ion means the pack is aging. Above 25 mΩ (LiPo) or 50 mΩ (Li-Ion), retire it.
• [ ] Cell balance: all cells within 0.02V of each other at full charge. Imbalance > 0.05V = failing cell. Don't fly it.
• [ ] ESC temperature after a flight: warm is normal. Hot to touch = something is wrong (motor issue, prop drag, ESC undersized).
• [ ] Motor temperature: same. Warm = normal. Hot = mechanical issue, PID/filter problem, or motor failing.
• [ ] Wiring: no frayed wires, no exposed copper, solder joints intact. Pay special attention to battery pigtail and motor phase wires.

Mechanical

• [ ] Prop adapters / prop nuts: torqued properly. A prop coming off in flight is not recoverable.
• [ ] Motor bell screws: C-clip or set screws tight. Bell should not wobble on the shaft.
• [ ] Camera mount: secure. Camera angle correct. Tilt hasn't shifted.
• [ ] FC mounting: soft mount grommets intact, FC not contacting frame.
• [ ] Antenna connectors: U.FL/IPEX connectors seated. SMA connectors finger-tight (do not overtorque SMA — you'll break the connector on the board).

Software

• [ ] Firmware version: matches what you expect. Verify in configurator before flying after any work session where USB was connected. Accidental firmware flash happens.
• [ ] Modes: verify arm switch, flight mode switches, and any other switches are assigned correctly. A mode switch that accidentally triggers GPS rescue at 2 meters altitude is a bad day.
• [ ] Failsafe: configured and tested. The only way to know failsafe works is to test it. Turn off the transmitter with the drone armed on the ground and verify the FC does what you expect (motors stop, or enters land mode, or whatever you configured).
• [ ] Blackbox: enabled, flash has space. If you want logs from this session, verify logging is on and the flash isn't full.
• [ ] OSD: shows what you need. Minimum: battery voltage, flight time, RSSI (or LQ for ELRS). Recommended: sat count, altitude, warnings.

Post-Flight Check

After each flight, before the next:

1. Battery voltage: Check remaining voltage. If below 3.5V/cell under resting conditions, you pushed too hard. Adjust your timer.

2. Temperature sweep: Touch each motor, each ESC, the FC, the VTX. Anything unusually hot compared to normal? Investigate before flying again.

3. Visual scan: Any new damage? Props nicked? Antenna bent? Camera mount shifted?

4. Log pull (if analyzing this session): Pull blackbox now. Flash will be overwritten by the next flight.

Post-Session

After the last flight of the day:

1. Storage charge batteries. LiPo storage voltage is 3.8V/cell (22.8V for 6S). Do not leave batteries at full charge or fully depleted. Storage charge the same day.

2. Clean the quad. Grass, dirt, and moisture accelerate corrosion on exposed electronics. Compressed air for motor bells.

3. Note anything that needs attention. A prop you noticed was slightly nicked. A motor that felt warm. A GPS that took too long to lock. Write it down or you'll forget by next session.

The Checks That Catch Real Problems

In order of how often they prevent incidents:

1. Props — wrong rotation, damaged, or loose. The most common cause of unexpected behavior on arm or immediately after takeoff.

2. Battery strap — a battery that shifts forward on a punch-out changes the CG and the drone flips. Cinch it tight.

3. RC link — flying on a dead receiver because you forgot to check the link. Especially after changing receiver firmware or binding phrase.

4. Failsafe — having the wrong failsafe behavior configured. "Drop" is almost never what you want. Test it before you need it.

5. GPS home point — flying 2 km out, triggering RTH, and having the drone return to a GPS position from three flights ago because you didn't wait for a fresh fix.

6. Antenna — a U.FL connector that popped off a receiver during a battery change. Video or RC works at 5 meters, fails at 50.

The One Check Nobody Does (But Should)

Turn off your transmitter with the drone armed on the ground.

This tests your failsafe. Every time you change firmware, change receivers, or change failsafe settings, do this test. It takes 10 seconds and it's the only way to know what will actually happen when you lose signal in the air.

If the motors keep spinning at the last throttle position: your failsafe is misconfigured and your drone will fly away on signal loss. Fix it before flying.

Next

• Chapter 12: When Things Go Wrong — when something slips past the checklist.
• Chapter 10: Blackbox Logs — analyzing what happened after the flight.

The checklist is boring. Walking half a kilometer to pick up a crashed drone because you didn't check the prop nuts is also boring, and takes longer.

Chapter 10: Blackbox Logs — What They Tell You

The blackbox doesn't lie. Your memory does. Pull the log.

What Gets Logged

A blackbox log records everything the flight controller knows at high sample rate (typically 1–4 kHz on Betaflight, 100–400 Hz on ArduPilot/PX4). This includes:

How to Pull Logs

Betaflight (Flash-Based)

Betaflight stores blackbox data on the FC's on-board flash chip (typically 2–16 MB) or an SD card.

Via Configurator: 1. Connect USB 2. Blackbox tab → Download Flash → Save .bbl file

Via MSP (what Wingman does): 1. MSP_DATAFLASH_SUMMARY → get used bytes 2. MSP_DATAFLASH_READ in 4 KB chunks → stream raw data 3. Save as .bbl file

Important: Flash fills up. If it's full, new flights overwrite old ones. After a session where you need the data, pull logs before the next flight. Or switch to SD card logging if your FC supports it.

ArduPilot (SD Card)

ArduPilot writes .bin DataFlash logs to the SD card.

Via Mission Planner: DataFlash Logs → Download Via MAVLink: LOG_REQUEST_LIST → LOG_REQUEST_DATA → stream Via SD card: Pull the card, copy .bin files directly

PX4 (SD Card)

PX4 writes .ulg (ULog) files to the SD card.

Via QGroundControl: Analyze → Log Download Via SD card: Pull the card, copy .ulg files

Reading the Traces

The Gyro Trace Is Everything

The gyroscope trace is the single most important data in a blackbox log. It shows the actual angular rate of the drone on each axis, sampled at 1–4 kHz. Everything else is derived from or compared against the gyro.

A clean gyro trace looks like smooth curves that follow the stick inputs. When you push the stick right, the roll gyro shows a clean step to the commanded rate, holds, then returns to zero when you release.

A noisy gyro trace looks like the clean curve with fuzz, spikes, or oscillation layered on top. The noise is real — the drone is actually vibrating. The question is where the vibration comes from and whether it matters.

The Five Patterns That Indicate Real Problems

Pattern 1: High-frequency noise on all axes, increasing with throttle.

What it looks like: Fuzz on the gyro trace that gets worse as you increase throttle. Consistent across roll, pitch, and yaw.

What it means: Mechanical vibration from the motors/props is reaching the FC. The motors are the only thing on the drone whose vibration scales with throttle.

What to check: Prop balance, motor bearings, FC soft mount, frame arm tightness. If the noise is broadband (not at a specific frequency), it's probably multiple sources. Fix the biggest one first — usually props.

Pattern 2: Oscillation at a specific frequency, visible as regular waves.

What it looks like: A sine wave overlaid on the gyro trace. Consistent frequency regardless of stick input. May be present on one axis more than others.

What it means: Resonance. Something on the frame has a natural frequency that's being excited by the motors. The FC's filters are either not catching it or are making it worse.

What to check: Look at the frequency (use the Betaflight Blackbox Explorer's spectrum analyzer). Common resonances: - 80–150 Hz: Frame flex (arms, standoffs) - 150–300 Hz: Prop/motor mechanical resonance - 300–600 Hz: Gyro noise floor (filter issue, not mechanical)

If the dynamic notch filter is enabled, check if it's tracking this frequency. If not, adjust the notch range.

Pattern 3: D-term noise spikes, especially on yaw.

What it looks like: The D-term trace (visible in debug mode) is noisy or spiky, even when the gyro trace looks relatively clean. Yaw axis is typically worst.

What it means: The D-term is the derivative of gyro error. It amplifies high-frequency noise by design — that's how it reacts quickly to changes. If the gyro has even small amounts of high-frequency content, D amplifies it into large motor corrections.

What to check: Lower D-term gain (try -20%). If that helps significantly, the issue is D sensitivity to noise, not mechanical. Also check: D-term lowpass filter cutoff (lowering it reduces D noise at the cost of slower D response), dynamic notch filter (should be catching the frequencies that D is reacting to).

Pattern 4: Motor output asymmetry — one motor consistently higher.

What it looks like: In the motor output traces, one motor is always running at higher output than the others. The difference is consistent across throttle levels.

What it means: The FC is compensating for something that makes the drone want to rotate toward the weak motor's side. Possible causes: - Motor or ESC weaker on one side (dying motor, marginal ESC) - Center of gravity offset (battery mounted off-center) - Bent motor mount changing thrust angle - Damaged prop generating less thrust

What to check: Swap the suspect motor to a different arm. If the asymmetry follows the motor, it's the motor. If it stays on the same arm, it's the mount or frame. If it moves to the diagonal, it's CG.

Rule of thumb: Up to 5% asymmetry is normal. 5–10% is worth investigating. Above 10% is a problem that will get worse.

Pattern 5: Voltage sag correlating with performance loss.

What it looks like: Battery voltage drops sharply during aggressive maneuvers. At the same time, motor outputs hit 100% (full throttle commanded but can't produce it), and the gyro shows the drone not achieving the commanded rate.

What it means: The battery can't deliver enough current. The voltage sags, the ESCs can't spin the motors fast enough, and the drone loses authority. This is a power system problem, not a tuning problem.

What to check: Battery internal resistance (measure with a charger that shows IR per cell). IR above 15 mΩ/cell means the pack is aging. Voltage sag below 3.3V/cell under load is concerning. Below 3.0V/cell is damaging the battery.

Don't tune around bad batteries. If the battery is sagging, no amount of PID tuning will fix the performance loss. Replace the battery.

Blackbox Analysis Workflow

Step 1: Pull the log. Immediately after the flight you want to analyze. Don't fly again first.

Step 2: Open in the right tool. - Betaflight: Betaflight Blackbox Explorer - ArduPilot: Mission Planner → DataFlash Log tab, or UAV Log Viewer - PX4: Flight Review or PlotJuggler

Step 3: Look at the gyro first. Always. Before looking at PIDs, motor outputs, or anything else. The gyro tells you what actually happened. Everything else tells you what the FC tried to do about it.

Step 4: Compare setpoint to gyro. The setpoint is what the FC was trying to achieve. The gyro is what actually happened. The gap between them is the error. A well-tuned drone tracks setpoint closely. A poorly tuned one lags, overshoots, or oscillates around it.

Step 5: Check motor outputs. Are they even? Are any hitting 100%? Are there sudden spikes? Motor output tells you how hard the FC is working to maintain control.

Step 6: Check battery voltage. Does it hold steady or sag under load? Voltage sag during aggressive maneuvers is normal. Voltage sag during hover is a problem.

Step 7: If you found a problem, change ONE thing. Fly again. Pull another log. Compare. This is how tuning works — iterative, data-driven, one variable at a time.

What Logs Don't Tell You

• Why the pilot made a decision. Logs show what the drone did, not what the operator intended. If a flyaway log shows the drone going north, you don't know if the pilot pushed north or if the drone went north on its own without checking the stick inputs.

• External conditions. Wind, temperature, air density, obstacles — none of these are in the log. A drone that oscillates on a windy day and flies clean on a calm day isn't broken. It's dealing with turbulence. Logs won't show you the wind.

• What happened after the crash. If the drone hits something and the FC loses power, the log ends. The last few hundred milliseconds of data may be corrupt or missing. The moments before the crash are usually there.

Next

• Chapter 11: PID Tuning for People Who Fly — using blackbox data to improve your tune.
• Chapter 12: When Things Go Wrong — the diagnostic tree that starts with symptoms and uses logs to find causes.

The log is the flight's memory. It remembers what you don't. Pull it. Read it. Trust it over your recollection.

Chapter 11: PID Tuning for People Who Fly, Not Simulate

PID tuning is not magic. P reacts to error. I removes steady error. D resists change. That's it. The rest is learning what each one feels like through the sticks.

What P, I, and D Actually Do

P (Proportional) — The Reaction

P pushes back proportional to how far off the drone is from where it should be. Big error = big correction. Small error = small correction.

Too high: The drone overshoots its target and corrects back, creating fast oscillation. Feels like the quad is vibrating or buzzing, especially visible on a punch-out or sharp turn.

Too low: The drone feels mushy, soft, unresponsive. It drifts through commands instead of snapping to them. Slow to respond to stick input.

What to listen for: P oscillation is fast — 10-50 Hz range. It sounds like a buzz or rattle. If you hear a high-pitched buzzing that increases when you do aggressive maneuvers, P is too high.

I (Integral) — The Memory

I accumulates error over time. If the drone is consistently a little off in one direction (wind pushing it, CG offset, motor imbalance), I builds up a correction to counter it.

Too high: The drone feels "stuck" or slow to change direction. Overshoot on sustained moves. After a long turn, it keeps turning briefly after you release the stick. In extreme cases, I windup causes the drone to suddenly lurch as the accumulated correction releases.

Too low: The drone drifts. In a hover, it doesn't hold position well. In forward flight, wind pushes it off course and it doesn't correct. The quad won't hold a steady rate in a turn.

What to feel for: I issues are slow. If the drone seems to "remember" what it was doing and resists changing, I is too high. If it can't hold a line in wind, I is too low.

For most operators: Leave I at the default. It's the least sensitive of the three terms and the default is usually close enough. Only touch I if you have specific drift or windup problems.

D (Derivative) — The Brake

D resists change. It's proportional to how fast the error is changing, not how big it is. D slows down both the drone's response AND oscillation.

Too high: Motors run hot. D amplifies noise (see Chapter 10, Pattern 3). The drone feels "dampened" — controlled but lacking snap. In extreme cases, motors make a grinding sound from rapid micro-corrections driven by noise.

Too low: The drone overshoots on quick maneuvers. Feels bouncy at the end of rolls and flips. P oscillation becomes harder to control because D isn't there to brake it.

What to listen for: D noise is a constant, low-level motor buzz that's present even in smooth flight. It gets worse with throttle because motor vibration (which D amplifies) increases with RPM.

The D dilemma: You need enough D to control overshoot but not so much that it amplifies noise. This is the core tension in PID tuning and why filters exist — filters clean the gyro signal so D can do its job without reacting to noise.

The Field Tuning Workflow

This workflow assumes you're starting from a reasonable default (Betaflight defaults are a good starting point for most 5-inch builds). If you're building from scratch on unusual hardware, start with community presets for your motor/frame size.

Step 0: Mechanical First

Before touching PIDs, confirm: - Props are balanced and undamaged - Motors spin freely with no grit or catch - FC is soft-mounted properly - Frame has no loose screws or cracked arms - Battery is secured and not shifting in flight

If any of these are wrong, no amount of PID tuning will fix it. See Chapter 12 (Troubleshooting), Step 2.

Step 1: Fly the Default

Fly a representative flight — hover, forward flight, some rolls and flips, a punch-out, some turns. Pay attention to: - Does it feel mushy or sharp? (P) - Does it hold a line in wind? (I) - Does it bounce at the end of maneuvers? (D) - Is there any buzzing or vibration? (P too high or D noise)

Pull a blackbox log.

Step 2: Adjust P

P is where most of the feel comes from. Adjust P first.

• If mushy/soft: raise P by 10%. Fly. Repeat until it feels responsive but not buzzy.
• If buzzy/oscillating: lower P by 10%. Fly. Repeat until the buzz goes away but it still feels locked in.

Adjust roll and pitch P together unless you have a reason not to (asymmetric frame, different prop spacing). Yaw P is usually set independently and is less sensitive.

Step 3: Adjust D

Once P feels right, check D:

• If bouncy at the end of flips/rolls: raise D by 10%.
• If motors are hot or buzzing at idle: lower D by 10%.
• If blackbox shows D-term noise: lower D, then check filters.

D and P interact — raising P often requires raising D to maintain damping. If you raised P in Step 2, you may need more D.

Step 4: Leave I Alone (Usually)

I is rarely the problem for freestyle and racing. If the default works, keep it.

• If the quad drifts in hover or can't hold a turn rate in wind: raise I by 10-20%.
• If the quad feels sluggish to change direction or has overshoot on sustained turns: lower I.

Step 5: Check Filters

If you can't get P and D where you want them because noise starts before you reach the desired gain, the issue is filters, not PIDs.

• Enable dynamic notch filter if not already enabled.
• Check gyro lowpass filter cutoff. Betaflight default (250 Hz for gyro lowpass 1) is fine for clean builds. Noisy builds may need 150-200 Hz.
• Check D-term lowpass. This is the most impactful filter for D noise. Lowering it from 150 Hz to 100 Hz significantly reduces D noise but also slows D response.

The filter-PID relationship: Filters remove noise so PIDs can run higher without reacting to it. A well-filtered build can run higher P and D, which means sharper and more responsive flight. A poorly filtered build (or a build with mechanical vibration issues) must run lower PIDs to compensate.

Step 6: Fly, Log, Compare, Repeat

After each change: 1. Fly a representative flight (same maneuvers as before) 2. Pull blackbox 3. Compare gyro traces to the previous flight 4. Did it get better or worse? If better, keep the change. If worse, revert.

One change at a time. If you change P, D, and filters simultaneously, you won't know what helped and what hurt.

Rates vs. PIDs

Rates and PIDs are different things. People confuse them constantly.

Rates control how fast the drone rotates per degree of stick deflection. Higher rates = faster rotation at full stick. Rates affect how the drone FEELS to fly but they don't affect stability.

PIDs control how well the drone FOLLOWS the rate command. Higher P = more aggressively follows the command. Higher D = more damped following.

If the drone feels slow: it might be rates (increase max rate), not PIDs.

If the drone feels floaty: it might be PIDs (increase P), not rates.

If the drone rotates at the right speed but wobbles while doing it: that's PIDs.

Tuning for Different Flight Styles

Freestyle

• Higher P for crisp, snappy response
• Moderate D for controlled stops after flips
• Lower I is acceptable (you're not holding position)
• Slightly higher rates (800-1200 deg/s max)

Racing

• Moderate P — not as high as freestyle because you need predictability, not snap
• Higher D to damp oscillation in high-speed turns
• Higher I to hold lines through corners and in prop wash
• Lower rates than freestyle (600-900 deg/s) for precision

Cinematic / Smooth

• Lower P for gentle, smooth movements
• Lower D to avoid any micro-corrections visible in footage
• Standard I
• Low rates (400-600 deg/s) for butter-smooth pans

Long-Range / GPS Cruise

• Default PIDs are usually fine
• I matters more here (wind rejection, position hold)
• D can be lower (less aggressive flying = less noise)
• Rates are less important (you're not doing flips at 5 km)

When to Stop Tuning

The tune is "good enough" when: - No audible buzz or vibration in normal flight - The drone responds to stick inputs without delay or overshoot - Blackbox gyro traces are clean (no sustained oscillation) - Motors are warm after flight, not hot (hot = D noise or P oscillation making the ESCs work too hard) - You stop noticing the quad and start noticing the flying

Most pilots overtune. The difference between a "good" tune and a "perfect" tune is 2-3% performance improvement that you'll never notice in real flying. Get it to "no oscillation, responsive, motors not hot" and go fly.

Next

• Chapter 10: Blackbox Logs — reading the data that drives these tuning decisions.
• Chapter 12: When Things Go Wrong — when the problem isn't PIDs at all.

The best tune is the one that lets you forget about the quad and focus on the flying. If you're thinking about PIDs in the air, you're not done tuning. If you're not thinking about PIDs in the air, you probably are.

Chapter 12: When Things Go Wrong

This is the chapter you read at the field with a broken drone in your hands. Start with the symptom. Follow the tree.

How to Use This Chapter

Find your symptom in the list below. Follow the diagnostic steps in order. Each step either solves the problem or narrows it down. Don't skip steps — the obvious cause is often not the actual cause.

Symptom: Won't Arm

The FC refuses to arm. This is the most common field problem and the one with the most possible causes.

Step 1: Read the arming flags. - Betaflight: CLI → status → look for arming disable flags - iNav: CLI → status → same - ArduPilot: GCS → Messages tab → pre-arm check failures - PX4: QGC → Vehicle Setup → Summary → pre-arm checks

Step 2: Common arming flags and fixes.

Step 3: If no flags show but still won't arm. - Check switch assignment. Arm switch might be on a channel that isn't configured or is inverted. - Check throttle endpoints. Some FCs require throttle below 1050 µs. - Power cycle everything. Receiver, FC, ESCs. In that order.

Symptom: Oscillation / Vibration in Flight

The quad shakes, wobbles, or makes a buzzing sound in flight. Could be mechanical or electronic.

Step 1: Determine if it's always present or speed-dependent. - Always present (even at hover): likely filter or PID issue - Only at high throttle: likely mechanical — prop balance, motor bearing, loose standoff - Only after a crash: prop damage, bent motor shaft, cracked frame arm

Step 2: Check mechanical first. Always. Before touching PIDs. - Spin each motor by hand. Feel for grit, catch, or uneven resistance. One bad bearing can cause the whole quad to oscillate. - Check props for damage. Even a tiny nick changes balance. Replace suspect props — they're the cheapest component. - Check motor mounting screws. Loose motor = oscillation source. - Press on each arm. Flex = vibration transmission path. Carbon fiber arms don't flex. Cheap 3D-printed arms do. - Check FC mounting. Soft mount grommets should be intact and the FC should not contact the frame directly.

Step 3: Pull a blackbox log. If mechanical checks pass: - Look at gyro traces. Clean gyro = clean flight. Noisy gyro = something is shaking the FC. - Compare pre-filter and post-filter gyro. If pre-filter is noisy but post-filter is clean, your filters are working hard. Consider addressing the source instead of filtering harder. - Look for a specific frequency peak. A resonance at a consistent frequency often indicates a specific mechanical source: - Prop-speed frequency: prop balance issue - Frame resonance (usually 100-300 Hz): frame flex - Motor bearing: broadband noise that increases with throttle

Step 4: If it's a filter/PID issue: - Lower D-term first. D is the most noise-sensitive PID term. Drop D by 20% and fly again. - Check dynamic notch filter. If not enabled, enable it. If enabled, check that it's tracking the right frequency range. - Lower gyro lowpass filter cutoff. Default is usually fine, but noisy builds may need 150 Hz instead of 200 Hz. - As a last resort, lower P-term. But if you need to drop P significantly to stop oscillation, the problem is mechanical, not tuning.

Symptom: Flyaway / Unexpected Movement

The drone moves in a direction the pilot didn't command.

Step 1: Did it respond to stick input during the event? - Yes, but drifted: likely sensor issue (compass interference, GPS glitch, accelerometer drift) - No response to sticks at all: likely failsafe triggered, mode switch, or loss of RC link

Step 2: Check flight mode. Did the mode change unexpectedly? - A mode switch bumped during handling can change from acro to angle to GPS hold, causing unexpected behavior. - ArduPilot/PX4: check mode channel (usually CH5) assignment and thresholds. - Betaflight: check mode tab for overlapping ranges on the aux channels.

Step 3: Check compass and GPS. For GPS-assist modes: - Compass interference from power wires is the #1 cause of GPS-mode flyaways. The compass reads the magnetic field from the battery leads as a heading change and "corrects" by turning. - Fix: move the compass (external GPS/compass module) as far from power wires as possible. Use a GPS mast. - Check for GPS glitch in the log. A sudden position jump causes the FC to "correct" toward the wrong position.

Step 4: After landing, pull logs immediately. Don't fly again until you understand what happened. Logs will show stick inputs, actual motor outputs, sensor readings, and mode changes. The cause is almost always visible in the data.

Symptom: Video Loss / Breakup

FPV video feed drops, goes to static, shows artifacts, or freezes.

Step 1: Analog or digital?

Analog 5.8 GHz: - Gradual static/snow = range limit or obstruction. Normal degradation. - Sudden black screen = VTX failure, antenna disconnect, or power loss to VTX. - Rolling lines or interference pattern = self-interference from another transmitter on the same airframe (RC, mesh radio). - Check antenna connector. IPEX/U.FL connectors are fragile. A crash can unseat them without visible damage. Reseat and check. - Check VTX power. Is it set to the right level? Too low = no range. Too high = overheating (some VTXs thermal throttle or shut down).

Digital (DJI, HDZero, Walksnail): - Frozen frame = link degradation. Digital doesn't gracefully degrade like analog — it works perfectly until it doesn't, then freezes. - Gray screen / "No Signal" = complete link loss. - Latency spike = the link is fighting to maintain connection. Reduce range or increase power. - Check firmware versions. DJI goggles and air unit firmware must match. Mismatched firmware can cause connection failures.

Step 2: Is it consistent or intermittent? - Consistent at a specific distance/direction = range or obstruction. Normal. Adjust flight pattern or antenna. - Intermittent at close range = self-interference, loose antenna, or power supply issue. Check that VTX is getting clean power (no voltage sag from motor current). - Only happens at high throttle = voltage sag pulling VTX supply below minimum. Add a capacitor on the VTX power input or use a dedicated BEC.

Symptom: Motor Desync / Stuttering

One or more motors stutters, stops momentarily, or makes grinding sounds.

Step 1: Is it one motor or all? - One motor: likely ESC or motor issue (bearing, winding, timing) - All motors: likely FC signal issue (DShot errors, wiring)

Step 2: Swap the suspect ESC and motor. If the problem follows: - The motor: bad bearing or winding - The ESC: bad ESC - Neither (stays on the same arm): wiring issue on that arm

Step 3: Check motor timing. In BLHeli_S/BLHeli_32/AM32: - Stock timing is usually fine. If someone has adjusted it, try resetting to default. - High timing + high KV + low battery voltage = desync recipe.

Step 4: Check DShot settings. - Bidirectional DShot (for RPM filter) can cause desyncs on some ESC/motor combinations. Try disabling it to test. - DShot300 is more reliable than DShot600 on longer signal wires. If wires from FC to ESC are >10 cm, try DShot300.

Symptom: Failsafe Triggered in Flight

The drone enters failsafe (lands, returns home, or drops) unexpectedly.

Step 1: Determine which failsafe. - RC failsafe (lost RC link): check RC RSSI in the log. Was signal actually lost or did the FC misinterpret a signal issue? - Battery failsafe: check voltage in the log. Did voltage sag below threshold under load? - GPS failsafe (geofence, GPS loss): check GPS data in log. - GCS failsafe (ArduPilot/PX4): lost MAVLink heartbeat from GCS.

Step 2: RC failsafe diagnosis. - Check RSSI history in the log. A gradual decline to zero = range. A sudden drop = obstruction, interference, or antenna issue. - Check failsafe settings. Betaflight: failsafe_procedure. ArduPilot: FS_THR_ENABLE + FS_THR_VALUE. PX4: COM_RC_LOSS_T. - Is failsafe set to the right response? "Drop" is rarely what you want. "Land" or "RTH" are usually better. But RTH requires GPS — if GPS isn't locked, RTH failsafe may not work. - Check RC receiver failsafe behavior. Some receivers output "no pulses" on signal loss (correct). Others output last-known values (dangerous — FC doesn't know signal is lost). Others output a pre-set failsafe position. Verify your receiver's behavior.

Step 3: Battery failsafe diagnosis. - Voltage sag under load can briefly dip below the failsafe threshold even when the battery has plenty of capacity. - Fix: lower the failsafe voltage threshold, or use mAh-consumed instead of voltage as the trigger (more reliable). - Check battery internal resistance. An aging battery sags more under load. If your pack used to fly 5 minutes and now triggers failsafe at 3 minutes, the battery is dying.

Symptom: GPS Glitch / Toilet Bowl / Position Drift

In GPS-assist modes, the drone circles, drifts, or jumps to a wrong position.

Step 1: Check satellite count. Below 8-10 satellites, GPS position accuracy degrades significantly. Don't use GPS modes with < 8 sats.

Step 2: Check HDOP. Horizontal Dilution of Precision. Below 1.5 is good. Above 2.5 is unreliable. Above 4.0, don't trust GPS position at all.

Step 3: Toilet bowl = compass problem. The classic circular drift pattern means the compass heading is wrong, so the FC "corrects" in the wrong direction, overshoots, corrects again, and orbits. - Calibrate compass away from metal, cars, buildings. - Move external compass away from power wires and motors. - Check compass orientation matches FC configuration. - If using internal compass on an FC near ESCs: disable it and use external compass only.

Step 4: Position jumps = multipath or interference. - Near buildings, GPS signals bounce off walls, creating phantom positions. This is normal in urban environments. No fix except dual-band GPS (L1+L5) which is more resistant to multipath. - Near military installations or during exercises, GPS can be jammed or spoofed. If GPS suddenly shows you 50 km away, that's not a hardware problem.

The Universal Diagnostic Rule

When something breaks:

1. Don't change multiple things at once. Change one thing, test, observe. If you change PID, filter, and rates all at once, you won't know what fixed (or broke) it.

2. Pull logs before flying again. The data is in there. Every time you fly without understanding why it broke, you're gambling.

3. Trust the instruments, not your memory. "I think it was oscillating on roll" is less useful than "gyro roll axis shows 200 Hz peak at 40% throttle." Log it. Read it. Then fix it.

4. The simplest explanation is usually right. Loose prop nut causes more crashes than firmware bugs. Check the physical hardware first.

Next

• Chapter 10: Blackbox Logs — What They Tell You — how to read the data that diagnoses everything in this chapter.
• Chapter 11: PID Tuning for People Who Fly — the tuning workflow that addresses oscillation and performance issues.

Something broke. That's normal. The question is whether you understand why, or whether you're about to break it again.

Chapter 13: Adding a Companion Computer

A flight controller flies the drone. A companion computer thinks about why it's flying. They're different jobs on different hardware connected by a serial cable.

When You Need One

You don't need a companion computer to fly a drone. You need one when:

• Autonomous missions beyond waypoints — obstacle avoidance, dynamic replanning, following a target, search patterns
• Computer vision — object detection, tracking, landing on a target, visual navigation without GPS
• Sensor fusion — combining LiDAR, depth cameras, and IMU data for environment mapping
• High-bandwidth data processing — real-time video analytics, SIGINT, spectrum analysis
• Network hub — bridging the FC to mesh radios, cellular modems, and other IP-based devices
• AI/ML inference — running neural networks for real-time decisions

If all you need is fly-to-waypoint with GPS, the FC handles that natively on ArduPilot and PX4. Don't add complexity you don't need.

The Hardware Options

What Matters Most

Weight: On a 5-inch quad, every gram counts. A Pi 5 at 50g (plus carrier board, cables, heatsink) adds 80-100g total. That's a significant percentage of all-up weight. A Pi Zero 2W at 10g is much more practical for small platforms.

Power: A companion drawing 10W from a 1300 mAh 6S battery is consuming roughly 30% of your total energy budget. Flight time drops proportionally. Budget the power before choosing the hardware.

I/O: The companion needs to connect to the FC (UART or USB), to the network (WiFi, Ethernet for mesh radio, USB for cellular), and to sensors (USB cameras, CSI cameras, SPI/I2C sensors). Count your I/O requirements before selecting hardware.

Connecting to the Flight Controller

The Physical Connection

The companion talks to the FC over serial (UART) or USB. Serial is preferred for reliability — USB adds a hub, OTG logic, and enumeration that can fail.

Companion TX  →  FC UART RX
Companion RX  →  FC UART TX
Companion GND →  FC GND

Baud rate: 921600 for high-bandwidth MAVLink. 115200 for MSP. Match both ends.

Level shifting: Pi GPIO is 3.3V. Most FCs are 3.3V. Compatible without level shifting. If your FC has 5V serial outputs (rare), use a level shifter or resistor divider.

The Protocol

ArduPilot / PX4: MAVLink v2. The companion runs mavproxy, MAVSDK, DroneKit, or a custom MAVLink parser. The FC streams telemetry to the companion and accepts commands from it.

# ArduPilot: connect via MAVSDK (Python)
from mavsdk import System
drone = System()
await drone.connect(system_address="serial:///dev/ttyAMA0:921600")

# PX4: connect via MAVSDK (same API, different autopilot behavior)
drone = System()
await drone.connect(system_address="serial:///dev/ttyAMA0:921600")

Betaflight / iNav: MSP over serial. The companion sends MSP requests and receives MSP responses. No streaming — poll-based.

# MSP: manual serial (simplified)
import serial
ser = serial.Serial('/dev/ttyAMA0', 115200)
# Send MSP_IDENT request
ser.write(bytes([0x24, 0x4D, 0x3C, 0x00, 0x64, 0x64]))
response = ser.read(32)

PX4 Dual-Channel

PX4 supports two simultaneous communication channels:

1. MAVLink (UART) — commands, parameters, mission, C2
2. uXRCE-DDS (UART or UDP) — high-bandwidth sensor telemetry, ROS2 topics

The dual-channel architecture lets you separate control traffic (low bandwidth, high priority) from data traffic (high bandwidth, lower priority). The companion runs a Micro-XRCE-DDS agent that bridges PX4's internal uORB topics to ROS2 topics on the companion.

This replaces the older microRTPS bridge. If you see references to microRTPS in older documentation, use uXRCE-DDS instead.

Software Stack

MAVProxy (Simplest)

MAVProxy is a command-line MAVLink proxy. It connects to the FC, parses MAVLink, and forwards it to multiple destinations (GCS, scripts, log files).

# Basic: FC on serial, forward to GCS on mesh radio
mavproxy.py \
  --master=/dev/ttyAMA0,921600 \
  --out=udp:10.0.0.255:14550

MAVProxy can run scripts (modules) that react to MAVLink messages. It's the fastest path from "I have a companion computer" to "I have telemetry flowing to a mesh radio."

MAVSDK (Programmatic Control)

MAVSDK is a library (Python, C++, Swift, Rust) for programmatic drone control over MAVLink. It abstracts MAVLink messages into clean API calls.

# Take off, fly to a point, land
await drone.action.arm()
await drone.action.takeoff()
await drone.action.goto_location(lat, lon, alt, yaw)
await drone.action.land()

MAVSDK is the recommended path for PX4. For ArduPilot, both MAVSDK and DroneKit work (DroneKit is older, more ArduPilot-specific).

ROS2 (Full Robotics Stack)

ROS2 (Robot Operating System 2) is the standard middleware for robotics. It provides publish/subscribe messaging, service calls, parameter management, and a massive ecosystem of packages for navigation, perception, planning, and control.

PX4 integrates with ROS2 via uXRCE-DDS. ArduPilot has a ROS2 interface via mavros2.

When to use ROS2: When you need sensor fusion (multiple cameras, LiDAR, IMU), SLAM (Simultaneous Localization and Mapping), path planning with obstacle avoidance, or integration with existing robotics software. ROS2 is heavyweight — it's the right choice for research and complex autonomy, overkill for "relay telemetry to a mesh radio."

Power and Cooling

Power Distribution

The companion needs clean, stable power. Noise from ESCs and motors on the main power bus will crash a Pi faster than any software bug.

Recommended: Dedicated BEC (Battery Eliminator Circuit) from the main battery to the companion. 5V, rated for the companion's peak current draw (2A minimum for Pi 5, 500mA for Pi Zero 2W).

Do not: - Power the companion from the FC's 5V rail (not enough current for most companions, and FC brownout risk) - Share a BEC with servos or LEDs (current spikes from servos cause voltage drops that crash the companion) - Use a USB cable to power the companion from the FC (USB host mode, OTG, and power delivery vary wildly between platforms)

Cooling

Most companions need cooling at sustained load. A Pi 5 at full CPU load will thermal throttle within minutes without airflow.

On a drone, the props create significant airflow. Mount the companion where prop wash hits the heatsink. In a sealed enclosure, this doesn't help — add a small thermal pad to conduct heat to the frame (carbon fiber is a reasonable heat spreader).

The VOXL 2 is designed for drones and handles thermal management internally. The Jetson Orin modules require active cooling (fan) for sustained ML inference.

The UART Budget Impact

Adding a companion computer consumes at least one FC UART. If you're using the companion-as-hub architecture (see Chapter 8), it may be the only non-RC UART you need — GPS, mesh radio, and telemetry radio connect to the companion instead of the FC.

Before (consuming 4 FC UARTs):
  FC ← RC receiver (UART1)
  FC ← GPS (UART2)
  FC ← Telemetry radio (UART3)
  FC ← Mesh radio (UART4)

After (consuming 2 FC UARTs):
  FC ← RC receiver (UART1)
  FC ← Companion MAVLink (UART2)
  Companion ← GPS (USB)
  Companion ← Telemetry radio (Ethernet)
  Companion ← Mesh radio (Ethernet)
  Companion ← Camera (USB/CSI)

This is one of the strongest practical reasons to add a companion even if you don't need AI or computer vision: it solves the UART shortage on F4-class FCs.

What to Start With

If you've never used a companion computer on a drone:

1. Start with a Pi Zero 2W ($15, 10g, 2W). Wire it to the FC UART, install MAVProxy, forward telemetry to your laptop over WiFi. This proves the concept without the weight or power penalty.

2. Graduate to a Pi 5 when you need more compute — running CV models, processing sensor data, or hosting a Wingman agent.

3. Move to Jetson or VOXL 2 when you need real-time ML inference with multiple camera streams. This is where object detection, visual SLAM, and neural network planning live.

The hardware changes. The MAVLink connection pattern stays the same. Learn it once on a Pi Zero and it works the same on a Jetson.

Next

• Chapter 8: UART Layout — how the companion fits into the FC's limited serial ports.
• Chapter 14: Mesh Radios — the network hardware that the companion bridges to the FC.

The flight controller flies. The companion thinks. Don't make the flight controller think. Don't make the companion fly.

Chapter 14: Mesh Radios for Multi-Vehicle Operations

The expensive tactical mesh radio in your kit bag is running the same open-source software as a $15 router. Knowing this changes how you think about mesh networking.

What Mesh Radios Actually Are

A mesh radio is a WiFi radio in a ruggedized enclosure with custom firmware that routes traffic between nodes without infrastructure. No access point, no router, no internet connection. Nodes find each other, establish links, and route packets through intermediate nodes to reach destinations.

That's it. Everything else is implementation detail.

The Software Stack (What They Won't Tell You in the Datasheet)

Doodle Labs is the most transparent about this — their radios run OpenWRT, and if you SSH into one (which you can), you'll see batman-adv kernel modules, standard Linux networking, and iptables rules. The "mesh intelligence" that costs $3,000 per radio is largely batman-adv with custom antenna design and RF front-end optimization.

This isn't a criticism. Antenna design, RF front-end engineering, thermal management, and ruggedization are real engineering. The software is well-integrated and tuned. But understanding that the foundation is open-source Linux networking demystifies mesh radios and helps you troubleshoot them.

The Major Players

Doodle Labs

What they sell: Compact mesh radios from 200 MHz to 6 GHz. The Mini series (Mini900, Mini2400, etc.) are small enough to mount on a drone. The MR series are larger with better RF performance. The Helix series covers L/S/C bands for defense.

What's good: - Open platform (OpenWRT) — you can SSH in and configure anything - Small form factor (Mini series fits on a 5-inch quad) - Wide frequency range across the product line - batman-adv mesh is well-understood and debuggable - Active development, responsive technical support

What's not: - batman-adv mesh has convergence delays when topology changes (a drone moving fast can outrun the routing table) - Power consumption is significant (2-5W depending on model) - At the low end (Mini series), RF performance is limited by the tiny antenna and low TX power

Typical use: Commercial drone fleets, tactical ISR, research platforms, any application where you want mesh but also want to understand and customize the network.

Silvus Technologies

What they sell: StreamCaster mesh radios. Higher-end than Doodle Labs, with custom MIMO radio hardware and their own MAC-layer protocol. The SC4200/4400 series are the workhorses.

What's good: - Custom MIMO gives better spectral efficiency than commodity WiFi - TDMA-based MAC layer provides deterministic latency - High throughput (up to 100 Mbps per radio) - Strong defense/government customer base - Good video streaming support (multicast-aware mesh)

What's not: - Closed platform — you can't SSH in and debug the way you can with Doodle Labs - Expensive ($5,000-15,000 per node) - Configuration is through their web GUI, which is functional but not scriptable - Larger and heavier than Doodle Labs Mini series

Typical use: Defense ISR, government operations, commercial applications where budget supports the higher cost.

Persistent Systems

What they sell: MPU5 (manpack), Wave Relay ecosystem. The most mature tactical mesh network product. Used extensively by US SOF and allied forces.

What's good: - Wave Relay protocol is the most resilient mesh available — handles high mobility, rapid topology changes, and contested spectrum better than batman-adv - Proven in combat - Ecosystem includes vehicle mounts, body-worn units, drone-specific form factors - Integrated MANET management tools

What's not: - Most expensive option ($10,000-50,000 per node) - Heaviest option (MPU5 is not going on a 5-inch quad) - Closed ecosystem — Wave Relay doesn't interoperate with batman-adv or other mesh protocols - Long procurement cycles for military variants

Typical use: Military operations, high-end defense ISR, applications where proven combat performance justifies the cost.

Rajant

What they sell: BreadCrumb mesh radios. Dual-radio architecture (each node has two radios on different bands for simultaneous transmit and receive on different frequencies).

What's good: - Dual-radio avoids the half-duplex penalty of single-radio mesh - InstaMesh protocol handles mobility well - Good industrial track record (mining, oil & gas)

What's not: - Larger form factor than Doodle Labs - Less drone-specific than Silvus or Persistent

Typical use: Industrial applications, infrastructure monitoring, some defense applications.

Mesh Networking Fundamentals

How batman-adv Works (And Why It Matters)

batman-adv (Better Approach To Mobile Ad-hoc Networking - advanced) is a Linux kernel module that implements layer-2 mesh routing. It's what Doodle Labs and many other mesh products use underneath.

Key concepts: - Each node broadcasts OGMs (Originator Messages) periodically. These propagate through the mesh, allowing every node to learn the best path to every other node. - OGM interval (default 1 second) controls how fast the mesh adapts to topology changes. Lower = faster adaptation but more overhead. - TQ (Transmit Quality) is batman-adv's link quality metric. It's calculated from OGM reception rates. Higher = better link. - Routing is hop-by-hop. Each node only needs to know the next hop toward the destination, not the full path.

Why this matters for drones: Drones move fast. A mesh network optimized for static nodes (cell towers, sensor posts) may not adapt fast enough for a drone moving at 20+ m/s. If the OGM interval is 1 second and the drone has moved 20 meters since the last OGM, the routing table may be stale. Solutions: - Lower OGM interval (250-500 ms for fast-moving nodes) - Accept that mesh routing will lag position by 0.5-1 second - Use direct unicast for time-critical messages when nodes are within direct radio range (bypass mesh routing)

Throughput vs. Hops

Every hop in a mesh network costs throughput. A single-hop link at 50 Mbps becomes roughly: - 2 hops: ~25 Mbps - 3 hops: ~17 Mbps - 4 hops: ~12 Mbps

This is because traditional mesh radios are half-duplex — they can't transmit and receive at the same time on the same channel. Each hop requires the intermediate node to receive, then retransmit. Rajant's dual-radio approach mitigates this by receiving on one radio while transmitting on the other.

For drone operations: Keep the mesh shallow. 2-3 hops maximum for real-time data (telemetry, commands). Store-and-forward is acceptable for non-real-time data (sensor logs, blackbox files).

Channel Planning

Mesh radios on the same channel form a shared collision domain. More nodes = more contention = less per-node throughput.

Rules of thumb: - Up to 5 nodes on one channel works well - 5-15 nodes: consider splitting into two channels with a gateway node bridging them - 15+ nodes: you need a proper network plan with multiple channels and deliberate topology

For drone swarms, the practical limit is usually 8-12 platforms on a single mesh channel before throughput degrades noticeably. This aligns with typical tactical swarm sizes.

Practical Setup: Doodle Labs on a Drone

This section covers the most common drone mesh setup — a Doodle Labs Mini radio on a multi-rotor.

Physical Installation

• Mount with the antenna(s) pointing down or outward, not blocked by carbon fiber. CF is a moderate RF attenuator.
• Keep the radio away from the ESCs and battery leads. Conducted EMI from motor current can desense the radio's receiver.
• Power from a dedicated BEC, not the FC's 5V rail. Mesh radios draw 500-2000 mA and the FC's regulator may not handle it.
• Secure the Ethernet or USB cable. A disconnect in flight kills your mesh link and possibly your telemetry.

Network Configuration

• Assign static IP addresses. DHCP works but adds boot time and can fail in contested RF environments.
• Use a consistent addressing scheme: 10.0.0.{MAVLink_system_ID} — GCS is 10.0.0.255, drone 1 is 10.0.0.1, drone 2 is 10.0.0.2, etc.
• Set the mesh SSID and encryption key to match across all nodes. PSK (pre-shared key) with AES-256 is standard.
• Set the OGM interval based on platform speed:
• Static ground nodes: 1000 ms (default)
• Slow-moving drones (<10 m/s): 500 ms
• Fast-moving drones (>10 m/s): 250 ms

MAVLink Over Mesh

The companion computer (or FC with Ethernet) sends MAVLink over UDP to the mesh radio. The mesh radio delivers it to the GCS.

FC (UART) → Companion (mavproxy) → UDP → Mesh Radio → [mesh] → GCS

MAVProxy configuration on the companion:

mavproxy.py --master=/dev/ttyS1,921600 --out=udp:10.0.0.255:14550

On the GCS, QGroundControl or Mission Planner listens on UDP 14550 for incoming MAVLink from any mesh node.

Critical: Set the MAVLink system ID on each drone to a unique value. If two drones both use system ID 1, the GCS can't distinguish them. PX4: MAV_SYS_ID parameter. ArduPilot: SYSID_THISMAV parameter.

When Mesh Isn't The Answer

Mesh networking adds weight, power consumption, complexity, and a new failure mode to every platform. Before adding a mesh radio, ask:

• Do I need real-time data between platforms? If each drone operates independently and you analyze data after landing, you don't need mesh. You need SD cards and patience.

• Can I solve it with sequential operations? If you can brief platforms one at a time via direct link (Tooth, phone, laptop), you don't need mesh. Mesh is for simultaneous coordination.

• Is my mesh just carrying telemetry to a GCS? If you only need one drone's telemetry at a time, a point-to-point telemetry radio (RFD900x) is simpler, cheaper, lighter, and more reliable than mesh.

• Is my operation within visual line of sight? If all platforms are within 500m of the operator, ESP-NOW (free, built into ESP32, no additional hardware) may be sufficient for coordination.

Mesh is the right answer when you need multiple platforms sharing data simultaneously, beyond point-to-point range, with dynamic topology. For everything else, simpler is better.

Next

• Chapter 13: Adding a Companion Computer — the compute platform that bridges the FC and the mesh radio.
• Chapter 15: TAK Integration — getting drone data onto the tactical common operating picture.

A $5,000 mesh radio is a $15 router with a great antenna and a ruggedized case. Respect the engineering. But don't be intimidated by it.

Chapter 15: TAK Integration

TAK is where your drone shows up on the map next to everyone else's position. Getting there doesn't require a defense contractor. It requires one UDP packet.

What TAK Is

TAK (Team Awareness Kit) is a situational awareness platform used by the US military, law enforcement, fire services, and increasingly by civilian teams. It shows positions, tracks, sensor data, and messages on a shared map.

The ecosystem: - ATAK — Android TAK (phone/tablet) - WinTAK — Windows version (laptop) - iTAK — iOS version - TAK Server — centralized server for team data sharing - WebTAK — browser-based viewer

TAK speaks one protocol: Cursor-on-Target (CoT). Everything that appears on the map is a CoT event — an XML message with a type, position, and metadata. If your drone can send a CoT event, it appears on TAK.

Cursor-on-Target (CoT) Basics

A CoT event is an XML message. Here's the minimum viable drone position report:

<?xml version="1.0" encoding="UTF-8"?>
<event version="2.0"
       uid="drone-01"
       type="a-f-A-M-H-Q"
       how="m-g"
       time="2026-03-16T18:30:00Z"
       start="2026-03-16T18:30:00Z"
       stale="2026-03-16T18:30:30Z">
  <point lat="44.9778" lon="-93.2650" hae="300"
         ce="10" le="15"/>
</event>

That's it. Send this over UDP to port 4242 on a TAK Server or directly to ATAK devices on the local network, and your drone appears on the map.

The Fields That Matter

uid: Unique identifier for your drone. Once set, every update with the same uid moves the same icon on the map. Use something stable — wingman-{tooth-id} or drone-{serial}.

type: The CoT type code determines the icon and classification. It follows the 2525C symbology standard:

The first character after a- is the affiliation: f = friendly, n = neutral, h = hostile, u = unknown.

how: How the position was determined. m-g = machine GPS, h-e = human entry, h-g-i-g-o = GPS from another source.

time/start/stale: When the event was generated, when it starts being valid, and when it becomes stale (should be removed from the map if not refreshed). Set stale to 30-60 seconds for a moving drone so the icon disappears if the drone stops reporting.

point: Latitude, longitude, height above ellipsoid (meters), circular error (meters), linear error (meters).

Adding Detail

Telemetry in CoT

CoT supports a <detail> element for additional data. TAK clients display this in the info popup when you tap the icon:

<event ...>
  <point lat="44.9778" lon="-93.2650" hae="300" ce="10" le="15"/>
  <detail>
    <remarks>Battery: 14.8V (76%) | Alt: 300m AGL | Speed: 12 m/s</remarks>
    <track course="045" speed="12"/>
    <contact callsign="WINGMAN-01"/>
    <__group name="Blue" role="Team Member"/>
  </detail>
</event>

track: Course (degrees true) and speed (m/s). Allows TAK to show heading arrows and predict future position.

contact: The callsign displayed on the map next to the icon.

__group: Team assignment and role. Determines icon color in some TAK configurations.

remarks: Free-text field. Put your telemetry summary here. ATAK shows it in the detail popup.

Sensor Point of Interest

When your drone detects something (RF emission, visual target, anomaly), send a separate CoT event for the detection:

<event uid="detect-001"
       type="a-h-G-E-V-A"
       how="m-g" ...>
  <point lat="44.9790" lon="-93.2640" hae="0" ce="50" le="50"/>
  <detail>
    <remarks>RF Detection: DoodleLabs MR900 | RSSI: -72 dBm | Bearing: 045</remarks>
    <contact callsign="RF-DETECT-001"/>
  </detail>
</event>

This places a hostile marker on the map at the estimated position of the detection. The NeedleNThread tactical RF detector uses exactly this pattern to push detections to TAK.

Transport: Getting CoT to TAK

Direct UDP (Simplest)

Send CoT XML as a UDP packet to ATAK devices on the local network. Default port: 4242.

import socket

cot_xml = '''<?xml version="1.0" encoding="UTF-8"?>
<event version="2.0" uid="drone-01" type="a-f-A-M-H-Q"
       how="m-g" time="{time}" start="{time}" stale="{stale}">
  <point lat="{lat}" lon="{lon}" hae="{alt}" ce="10" le="15"/>
  <detail>
    <contact callsign="WINGMAN-01"/>
    <track course="{heading}" speed="{speed}"/>
  </detail>
</event>'''

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.sendto(cot_xml.encode(), ('239.2.3.1', 6969))  # multicast
# or
sock.sendto(cot_xml.encode(), ('192.168.1.100', 4242))  # unicast to ATAK device

Multicast (239.2.3.1:6969) reaches all ATAK devices on the local network without knowing their IPs. Requires a network that supports multicast (WiFi works, some mesh radios don't forward multicast by default).

Unicast to a specific IP is more reliable but requires knowing the ATAK device's address.

Via TAK Server

A TAK Server centralizes all CoT traffic. Devices connect to the server (TCP, TLS, or WebSocket) and the server distributes events to all connected clients.

The drone (or its companion computer) connects to the TAK Server and sends CoT events. All ATAK/WinTAK clients connected to the same server see the drone.

FreeTAKServer is an open-source TAK Server that runs on a Pi, laptop, or cloud VM. It handles basic CoT routing without the complexity of the official TAK Server.

pip install FreeTAKServer
python -m FreeTAKServer.controllers.services.FTS

Via Mesh Radio

If the drone has a mesh radio (Chapter 14), CoT can travel over the mesh. The companion computer sends CoT to the mesh radio's IP, and the mesh radio delivers it to the GCS or TAK Server on the other end.

Drone: FC → Companion → CoT UDP → Mesh Radio → [mesh] → GCS/TAK Server

This is the standard architecture for tactical drone operations. The mesh radio carries both MAVLink (for flight control) and CoT (for situational awareness) on the same link, typically on different UDP ports.

Integration Points

From the Flight Controller

The FC has the position, altitude, heading, speed, and battery data. This needs to get from the FC to the TAK sender:

ArduPilot/PX4: MAVLink messages on the companion → parse GLOBAL_POSITION_INT, VFR_HUD, BATTERY_STATUS → format as CoT → send.

Betaflight/iNav: MSP on the companion → parse MSP_RAW_GPS, MSP_ATTITUDE, MSP_ANALOG → format as CoT → send. Or use the ELRS/CRSF telemetry downlink on the transmitter side → forward to ATAK on the GCS phone.

From Sensors

Payload sensors (cameras, RF detectors, environmental) generate their own CoT events through the companion computer. Each detection gets its own uid and type code.

From the Wingman Ecosystem

The Wingman architecture naturally generates TAK-compatible data: - Tooth mesh: Fleet position sharing maps directly to CoT events - Seed detections: Acoustic, RF, and PIR detections become CoT hostile/unknown markers - Wingman Command: The Command layer IS the TAK integration point for the full ecosystem — it translates Wingman mesh data into the CoT format that existing TAK infrastructure consumes

Practical Tips

1. Keep CoT events small. TAK clients handle thousands of events. Your drone doesn't need to send a novel — position, callsign, basic telemetry in remarks. The detail popup in ATAK has limited space.

2. Update rate: 1 Hz is enough. TAK is situational awareness, not flight control. Sending position once per second is plenty. Faster than that wastes bandwidth and doesn't improve the map display.

3. Use meaningful callsigns. "WINGMAN-01" is useful on a shared map. "drone-abc123def" is not. Callsigns should be short, unique, and recognizable.

4. Set stale time appropriately. 30 seconds for a moving drone. If the drone stops sending CoT (crash, link loss, battery dead), the icon disappears from the map after the stale time. This is correct behavior — a stale position is worse than no position.

5. Test with ATAK first. Install ATAK on an Android phone, connect to the same network as your CoT sender, and verify the icon appears. Don't integrate with a TAK Server until direct UDP works.

6. CoT type codes matter. Using the wrong type code means your drone shows up as a ground vehicle, or a hostile, or a waypoint. Get the type code right for your affiliation and platform type.

Next

• Chapter 14: Mesh Radios — the transport that carries CoT from the drone to the TAK ecosystem.
• Chapter 13: Adding a Companion Computer — the platform that generates CoT from flight controller data.

TAK is a shared map. Your drone belongs on it. One UDP packet puts it there. Everything else is refinement.

Unsolved Problems — What's Left to Build

The Unhandled Exceptions in Mesh Networking & Drone Swarm Operations

Version 1.0 — March 2026

This handbook covers what works today — the RF fundamentals, the firmware, the field procedures, the integration patterns, the components. But a handbook is only useful if it's honest about where the knowledge stops.

This chapter is the other side of the ledger. Every problem listed here is something the handbook can't solve for you yet because nobody has solved it. Some are active research. Some have partial answers that fall apart in the real world. Some have no credible path forward with current technology.

The point isn't to discourage. The point is to focus. If you're building something new, start here — because every unsolved problem on this list is an invitation. Solve one and the next edition of this handbook gets a new chapter.

Drone shows are not swarms. They are pre-choreographed screensavers playing back trajectory files in controlled airspace with RTK GPS and zero autonomy. If your "swarm" can't handle a 15 mph crosswind, a lost radio link, or a drone it's never met before, it's not a swarm.

This document exists because every unchecked box is an invitation. Solve one of these and you've moved the entire industry forward.

Buddy up.

The Drone Show Illusion

People watch 5,000 drones paint a dragon in the night sky and walk away thinking swarm technology is solved. It is not. Those shows are remarkable engineering achievements, but they are the opposite of what the word "swarm" means in any operational context. Here is what a drone show actually is:

• Pre-choreographed: Every trajectory is computed offline, often hours or days before the show. No drone makes a single decision during flight.
• Central server playback: A ground computer sends every position waypoint to every drone. Remove the server and nothing flies.
• RTK GPS: Sub-centimeter positioning from fixed base stations set up at the venue. Not field-deployable, not available indoors, not available in contested environments.
• Controlled airspace: The show area is a restricted zone with no other air traffic, no RF interference, no obstacles, no unknowns.
• Identical hardware: Every drone is the same model with the same firmware. Zero heterogeneity.
• No wind tolerance: Shows are cancelled in winds above 10–15 mph. Real operations happen in whatever weather the mission requires.
• No autonomy: If a drone loses comms, it lands. If the server fails, everything lands. There is no independent decision-making.
• No sensing: The drones don't see anything. They don't detect anything. They don't react to anything. They play back a file.

Now consider what a real operational swarm would need to do:

• Fly heterogeneous platforms (different sizes, different sensors, different endurance) in uncontrolled airspace.
• Coordinate in real time with sub-second latency over unreliable mesh radio links.
• Make autonomous decisions when communication is lost, degraded, or jammed.
• Share sensor data (video, detections, position) across the mesh without saturating bandwidth.
• Handle wind, weather, obstacles, and other aircraft that weren't in the plan.
• Operate with or without GPS.
• Add and remove drones mid-mission without stopping the operation.
• Keep flying safely when individual drones fail.

The gap between these two lists is the subject of this document. Every item below is a specific, defined problem that stands between the drone show illusion and real swarm capability. Some are being actively worked on. Some have partial solutions. Some have no credible path to solution with current technology.

If someone tells you their drone swarm "just works," ask them: how many drones, at what range, sharing what bandwidth, at what latency, in what weather, for how long, with how many operators, and what happens when you jam the radio? The answers will be disappointing. That's not a criticism. That's where the work is.

How to Read This Document

This is a checklist, not a textbook. Each problem is stated as concisely as possible with three columns:

• The Problem: What doesn't work and why it matters.
• The Reality: What actually happens today, with real numbers where available.
• What Would Solve It: What a solution would look like. This is the invitation.

Status key:

• ☒ UNSOLVED — No production-ready solution exists. Active research problem. Pick this one if you want to change the industry.
• ▣ PARTIAL — Works in controlled conditions, degrades or fails in the real world. Improvement is valuable but the core problem is understood.
• ☑ SOLVED — Production solutions exist and are deployed. Included for context — these were once unsolved too.

The goal is to turn red boxes amber, and amber boxes green. Every color change is a real contribution.

RF & Communications

Radio is the nervous system of a swarm. Everything else — coordination, navigation, sensing — depends on drones being able to talk to each other. And radio physics does not care about your product roadmap.

Swarm Coordination & Decision-Making

Coordination is where the swarm either becomes more than the sum of its parts, or collapses into an expensive traffic jam. Almost every coordination algorithm that works in simulation has never been tested with real radios, real wind, and real failure modes.

Navigation & Positioning

GPS made drone navigation feel solved. It is not. Take away GPS and most drones become expensive lawn darts. Even with GPS, the accuracy and update rate are insufficient for tight swarm coordination.

Power, Weight & Endurance

Every capability we add to a drone — compute, radios, sensors, cameras — draws power from the same battery that keeps it in the air. Physics does not offer free compute cycles.

Software, Standards & Regulation

Even if we solved every physics problem above, the software and regulatory infrastructure to deploy real swarms does not exist.

The Scoreboard

As of March 2026:

17 unsolved. 10 partial. 0 solved.

Zero boxes in the green column. That is the honest state of swarm technology in 2026. This is not a condemnation — it is the most exciting engineering frontier in robotics. Every one of these 27 problems is a PhD thesis, a startup, a contract, or a contribution to an open-source project that the entire industry would benefit from.

What AI Wingman Does About It

We don't pretend these problems are solved. We design around them:

• The Wingman Grid works without GPS. It doesn't fix GNSS-denied absolute positioning — it sidesteps it by making GPS optional, not required.
• The Assumptions List acknowledges that communication will fail. Instead of pretending the mesh is reliable, we pre-agree on what each drone does when the mesh is gone.
• Edge processing reduces the bandwidth problem. The APB's NPU processes video onboard and sends detections, not streams. This turns a 5 Mbps problem into a 50 Kbps problem.
• The autonomy slider explicitly communicates how much the system can do alone. L0 is honest: the drone flies, the human decides. L4 is aspirational: the drone operates independently per the Assumptions List. We don't claim L4 is production-ready.
• Product separation (Wingman advises, Forge recommends hardware, Command integrates C2) means each product can be honest about its own limitations without pretending the whole system is more capable than it is.
• Open documentation (including this document) invites the community to help solve these problems rather than pretending we already have.

We put "safety" in quotes because it reduces danger without eliminating it. We should put "swarm" in quotes too. The honest version: a group of drones that try to coordinate, sometimes succeed, and have a plan for when they can't.

The Invitation

This document is intended for inclusion in The Drone Integration Handbook — the free, open industry reference. It is not proprietary. It is not competitive intelligence. It is a shared accounting of what is hard, written by people who have tried to make this stuff work and know where it breaks.

If you solve one of these problems — even partially — tell someone. Publish it. Open-source it. Present it at a conference. File a patent if you need to, but make sure the knowledge reaches the people building drones in garages and labs and forward operating bases. The industry moves forward when hard problems get easier, and they get easier when people share what they've learned.

Every red box that turns amber is progress. Every amber box that turns green is a breakthrough. The scoreboard will be updated as the state of the art advances.

The drone show is beautiful. The unsolved problems list is useful. We'd rather be useful.

AI Wingman — Unsolved Problems in Mesh & Swarm v1.0 17 unsolved. 10 partial. 0 solved. Let's get to work.

Buddy up.

Part 5 — Platform References

Full integration profiles — RF links, firmware, payloads, SDKs, and gotchas. Vetted parts only.

Autel Robotics EVO MAX 4T V2

Category: Commercial Off-the-Shelf (COTS) NDAA Status: XE variant is NDAA compliant; standard V2 has mixed sourcing Manufacturer: Autel Robotics (Bothell, WA / Shenzhen assembly)

Overview

Autel's flagship enterprise drone and the most direct competitor to the DJI M30T. Quad-sensor gimbal (wide, zoom, thermal, laser rangefinder), GPS-denied flight via SLAM, A-Mesh drone-to-drone networking, and no geofencing. Positioned as the go-to DJI alternative for public safety and inspection operators.

Specs

Sensors

RF Links

SkyLink 3.0

• Antennas: 6 (4 tx, 6 rx)
• Frequency Bands: 900 MHz, 2.4 GHz, 5.2 GHz, 5.8 GHz — adaptive frequency hopping
• Range: 20 km (12.4 mi) — FCC
• Video Quality: 1080p/60fps, <150ms latency
• Encryption: AES-256 full-link
• Cellular: Optional 4G dongle
• A-Mesh 1.0: Drone-to-drone autonomous communication — drones relay comms and extend network coverage without ground infrastructure

Frequency Restrictions

• 5.2 GHz only available in FCC, CE, UKCA regions
• 900 MHz only available in FCC regions

Firmware & Software

• GCS: Autel Enterprise App (Android, on Smart Controller V3)
• Firmware: Proprietary, OTA updates
• SDK: UX SDK (iOS/Android), Payload SDK for third-party mounts
• No MAVLink, no QGroundControl
• Data stays local — no mandatory cloud connection, no cloud upload unless operator enables it

Autonomy & GPS-Denied Flight

• Autel Autonomy Engine: Real-time 3D scene reconstruction and autonomous path planning
• GNSS-Denied Navigation: SLAM-based visual navigation for indoors, underground, urban canyons
• AI Target Detection: Auto-identify and lock onto heat sources, people, vehicles
• Mission Reproduction: Fly once manually, the drone replays the exact mission autonomously
• Triple Anti-Jamming: RFI, EMI, and GPS spoofing countermeasures

Payload Integration

• Integrated quad-sensor gimbal — not swappable
• Payload SDK interface for accessories (loudspeaker, spotlight, RTK module)
• RTK module available for cm-level positioning
• Compatible with EVO Nest for automated remote operations

Gotchas

1. No geofencing — good for operators who need flexibility, but means no built-in airspace safety net. Know your airspace.

2. NDAA compliance depends on variant. The XE model is purpose-built for compliance. The standard V2 may contain restricted components. Ask your dealer specifically about the XE if compliance matters.

3. A-Mesh requires multiple Autel aircraft. No cross-manufacturer mesh networking.

4. Smart Controller V3 is proprietary — no third-party controller support.

5. Integrated gimbal means no payload swap. If you need LiDAR, this is the wrong platform.

6. 900 MHz band only in FCC regions. International operators lose a frequency band.

When to Use This Platform

The MAX 4T V2 is the strongest DJI M30T competitor for public safety and inspection. The quad-sensor gimbal, GPS-denied flight, and A-Mesh networking give it capabilities DJI doesn't offer. No geofencing is a feature, not a bug, for operators who know what they're doing. The XE variant solves the NDAA question for agencies that need it.

Last updated: March 2026

Autel EVO II Enterprise V3 (Dual 640T)

Category: Commercial Off-the-Shelf (COTS) NDAA Status: Non-NDAA standard; check with Autel for compliant builds Manufacturer: Autel Robotics (Bothell, WA / Shenzhen assembly)

Overview

Autel's workhorse dual-sensor enterprise platform. 8K RGB + 640×512 thermal in a foldable, portable form factor. Less autonomy than the MAX series but more affordable and widely deployed for fire, law enforcement, and utility inspection.

Specs

Integration Notes

• Solid mid-tier enterprise platform
• No GPS-denied flight or mmWave radar like the MAX
• Good thermal resolution for the price (640×512 @ 30fps)
• Supports Remote ID
• Same Autel Enterprise App ecosystem
• No payload swap — integrated dual sensor only
• No MAVLink

When to Use This Platform

Budget-conscious agencies that need thermal + RGB in a portable package. If you don't need the MAX's GPS-denied flight or A-Mesh networking, this saves money without sacrificing core sensor capability.

Last updated: March 2026

DJI Agras T50

Category: Commercial / Industrial — Agriculture NDAA Status: NOT compliant Manufacturer: DJI (Shenzhen, China)

Overview

DJI's flagship agricultural spraying/spreading drone. Coaxial twin-rotor design carrying 40 kg spraying or 50 kg spreading payloads. Dual atomizing spraying system, front/rear phased array radars, binocular vision. The dominant platform in commercial ag spraying worldwide. Covers ~52 acres/hour at 2 GPA.

Specs

RF Links

• Control: DJI O3 transmission, 2.4/5.8 GHz, up to 7 km (FCC)
• Controller: RM700B high-brightness 7" touchscreen
• RTK: D-RTK 2 Mobile Station for cm-level positioning
• Relay Module: Available for signal extension in hilly/canopy terrain

Software & Autonomy

• App: DJI Agras App / DJI SmartFarm
• Mapping: DJI Terra for local map generation, boundary/obstacle detection
• Variable Rate: Pairs with Mavic 3 Multispectral for NDVI-based prescription maps
• Mission Types: Farmland survey, spray, spread — auto route generation from boundary points
• KML Import: Supports third-party GIS file import

Gotchas

1. NOT NDAA compliant. Federal ag funding that requires compliant equipment cannot be used for this platform.
2. Requires Part 137 exemption for commercial agricultural application in the US.
3. 88 lb empty weight — not remotely portable. Requires truck/trailer setup.
4. DJI FlyCart 100 and T60 exist in China but are NOT FAA approved in the US. The T50 is currently the largest DJI ag drone available in the US market.
5. Battery logistics are critical. 9-min fast charge with DJI C10000 charger + generator is the only way to maintain production rates.
6. Nozzle clogging with powder-base products was an issue on earlier models — dual atomizing centrifugal nozzles on T50 address this.

Last updated: March 2026

DJI FlyCart 30

Category: Commercial / Industrial — Heavy-Lift Delivery NDAA Status: NOT compliant Manufacturer: DJI (Shenzhen, China)

Overview

DJI's heavy-lift delivery drone. 4-axis, 8-propeller configuration. 30 kg payload (dual battery) / 40 kg (single battery). Cargo mode and winch mode (30 m retractable cable). FAA-approved with Remote ID in the US. Built for logistics, agriculture supply, emergency response, and industrial material transport.

Specs

RF Links

• Control/Video: DJI O3, 2.4/5.8 GHz, 20 km range
• 4G Enhancement: For obstructed terrain
• Dual Operator Mode: Supported
• Controller: RC Plus, 7" high-brightness display

Gotchas

1. NOT NDAA compliant.
2. Winch kit sold separately — base price does not include it.
3. Battery and charger sold separately.
4. Requires careful weight/CG management — drone auto-detects payload weight and center of gravity.
5. FlyCart 100 (80 kg payload) exists but is China-only as of 2026.

Last updated: March 2026

DJI Matrice 30T

Category: Commercial Off-the-Shelf (COTS) NDAA Status: NOT compliant Manufacturer: DJI (Shenzhen, China)

Overview

DJI's mid-tier enterprise drone — smaller and more portable than the M350 but still a serious inspection and public safety platform. Integrated dual-camera + thermal + laser rangefinder payload. Weather-sealed and designed for rapid deployment.

Specs

RF Links

Same DJI O3 Enterprise video system as M350. Supports DJI RC Plus controller. Dual-operator mode. 4G dongle compatible. No MAVLink.

Firmware & Software

Proprietary DJI firmware. DJI Pilot 2 on RC Plus. MSDK and Cloud API for third-party app development. DJI Dock compatible for fully autonomous remote operations (automated takeoff, landing, charging, mission execution).

Gotchas

1. Not NDAA compliant.
2. No payload flexibility — the integrated sensor package is the only option. No LiDAR, no custom payloads.
3. DJI Dock integration is powerful but locks you into DJI's cloud ecosystem.
4. If you need LiDAR or custom sensors, use the M350 RTK instead.

Last updated: March 2026

DJI Matrice 350 RTK

Category: Commercial Off-the-Shelf (COTS) NDAA Status: NOT compliant — banned from U.S. federal procurement as of Dec 2025 (American Security Drone Act) Manufacturer: DJI (Shenzhen, China)

Overview

The DJI M350 RTK is DJI's flagship enterprise platform and the successor to the M300 RTK. It is the most widely deployed commercial drone for inspection, mapping, and public safety worldwide. Closed ecosystem, but deep third-party payload support via E-Port and Payload SDK.

Specs

RF Links

Link 1 — Control & Video (Combined)

• System: DJI O3 Enterprise transmission
• Frequencies: 2.4 GHz / 5.8 GHz (auto-switching)
• Max Range: 20 km (FCC) / 8 km (CE)
• Video Downlink: 1080p/30fps to DJI RC Plus controller
• Dual Operator: Supported — pilot + payload operator on separate controllers
• Cellular Backup: Optional 4G dongle for cellular C2

Link 2 — Telemetry

• Protocol: Proprietary DJI protocol — no native MAVLink
• Access: Telemetry data available via DJI MSDK / Cloud API for third-party GCS integration
• Fleet Management: DJI FlightHub 2

Firmware & Software

• Firmware: Proprietary DJI firmware
• Updates: DJI Pilot 2 app (OTA or offline SD card), or DJI Assistant 2 (Enterprise Series) via USB
• GCS: DJI Pilot 2 (Android, on RC Plus)
• Third-Party GCS: DroneSense, Pix4Dcapture, DJI FlightHub 2 — all via Mobile SDK
• No QGroundControl or Mission Planner support

Payload Integration

• Gimbal Mounts: 3 — single upward + dual downward
• Native Payloads: Zenmuse H30/H30T, H20/H20T/H20N, L2, L1, P1, S1, V1
• Third-Party Payloads: Skyport V2 adapter or E-Port
• E-Port: UART, USB, SDK API, 24V power — replaces the old Onboard SDK port
• DJI X-Port: For lightweight third-party gimbals
• Payload SDK: Custom camera control, data streaming, widget display on Pilot 2

Companion Computer / SDK

• E-Port: USB device connection for companion computers (Jetson, RPi, etc.)
• CRITICAL: Companion computer must operate as USB device (not host) — opposite of the old OSDK port
• SDKs: Payload SDK (PSDK), Mobile SDK (MSDK), Cloud API
• No open MAVLink access

Gotchas

1. NOT NDAA compliant. Banned from U.S. federal procurement as of December 2025 under the American Security Drone Act. If your funding source is federal, you cannot buy this.

2. E-Port USB role is reversed from OSDK. If you're migrating from M300 with an existing companion computer setup, the USB host/device relationship is flipped. You need to rewire or re-architect.

3. M300 Skyport V1 payloads need V2 adapter. Not all V1 payloads have V2 updates available from their manufacturers.

4. DJI firmware updates can break third-party integrations without warning. Pin your firmware version and test updates before deploying to your fleet.

5. Geofencing is aggressive. GEO 2.0 system can prevent flight in restricted areas without unlock authorization. This is a problem for emergency responders who need to fly NOW.

6. Data stays local unless operator enables FlightHub. No mandatory cloud connection — but also no easy way to share fleet data without buying into DJI's ecosystem.

When to Use This Platform

Despite the NDAA issues, the M350 RTK remains the most capable enterprise drone on the market in terms of raw performance, payload flexibility, and ecosystem maturity. If your use case is commercial (not federally funded), and you need a workhorse that Just Works, this is still the benchmark.

If you need NDAA compliance, look at Freefly Astro, Inspired Flight IF1200A, or Skydio X10D.

Last updated: March 2026

DJI Matrice 4 Series

Category: Commercial Off-the-Shelf (COTS) NDAA Status: NOT compliant Manufacturer: DJI (Shenzhen, China)

Overview

DJI's newest enterprise platform family, announced 2025. Successor positioning alongside the M350 RTK. Details emerging as the platform reaches market. Expected to feature updated DJI O4 transmission, improved obstacle sensing, and next-generation gimbal/payload system.

Notes

Platform is still reaching full market availability. Check DJI Enterprise for latest specs and availability. Community contributions with early field experience welcome.

Last updated: March 2026

DJI Mavic 3 Enterprise (Thermal / Multispectral)

Category: Commercial Off-the-Shelf (COTS) NDAA Status: NOT compliant Manufacturer: DJI (Shenzhen, China)

Overview

DJI's compact enterprise platform. Available in Thermal (Mavic 3T) and Multispectral (Mavic 3M) variants. The go-to portable enterprise drone for inspection, search & rescue, and precision agriculture. Lightweight, foldable, excellent camera. The platform most fire departments and small agencies buy first.

Specs

Integration Notes

• DJI Pilot 2 for flight control
• MSDK for third-party app development
• DJI FlightHub 2 for fleet management
• Pairs with Agras T50 for variable-rate prescription spraying (3M variant)
• RTMP/RTSP live streaming capable
• No MAVLink

Gotchas

1. NOT NDAA compliant.
2. No payload swap — fixed sensor package per variant.
3. Not as robust as M30T or M350 — smaller platform, less wind resistance.
4. Widely deployed — good parts availability and support network.

Last updated: March 2026

DJI Mavic 4 Pro

Category: Commercial Off-the-Shelf (COTS) — Prosumer/Light Commercial NDAA Status: NOT compliant Manufacturer: DJI (Shenzhen, China)

Overview

DJI's latest prosumer platform. Hasselblad camera, omnidirectional sensing, DJI O4 transmission. Not an enterprise platform — no thermal, no payload swap — but widely used for real estate, light mapping, and cinematography.

Specs

RF Links

DJI O4 transmission — 1080p/60fps at up to 20 km. Consumer-grade link. No SDK access for autonomous operations. No MAVLink. No third-party payload mount.

Gotchas

1. Not NDAA compliant.
2. Did not officially launch in the U.S. market — availability is complicated.
3. No SDK for autonomous operations in the consumer product line.
4. This is an imaging/video platform, not an integration platform. If you need to plug things into it, look elsewhere.

Last updated: March 2026

Flyability Elios 3

Category: Commercial / Industrial — Confined Space Inspection NDAA Status: Not listed (Swiss manufacturer) Manufacturer: Flyability (Lausanne, Switzerland)

Overview

The only collision-tolerant inspection drone in mass production. Designed for confined spaces — tanks, boilers, pressure vessels, tunnels, mines, ore passes. Protective carbon cage allows contact with walls and structures without crashing. LiDAR SLAM for GPS-denied navigation and 3D mapping. Unique reversing motors recover from upside-down flips.

Specs

Autonomy

• FlyAware™: Real-time 3D map building, trajectory tracking, coverage assessment
• Smart Return-to-Home: Retraces path autonomously
• Return-to-Signal: Auto-returns on signal loss
• Collision tolerance: Recovers from impacts and flips — no other drone does this

Software

• Cockpit App: Real-time 3D view, trajectory, coverage assessment
• Inspector 4.0: Data processing, reporting on 3D model
• Compatible: Recap, CloudCompare, industrial 3D software
• Training: One-day onboarding program

Gotchas

1. 12-minute flight time is limiting for large assets. High-capacity battery helps (17 min). Tether power unit eliminates limit entirely.
2. Not for outdoor use — the cage creates drag, no GPS, limited speed (7 m/s max).
3. Not NDAA listed — may be an issue for US federal confined-space inspection contracts.
4. Environments must be cleaned and inerted before flying in explosive atmospheres — drone is NOT ATEX certified.
5. $50K+ system cost — justified by the 90% cost reduction vs scaffolding/rope access, but significant upfront investment.

When to Use This Platform

If you need to inspect inside a boiler, tank, pressure vessel, mine shaft, or any confined space where sending a person is dangerous, expensive, or impossible. Nothing else does what the Elios 3 does. It replaced months of scaffolding work with 10-minute flights at LKAB's Kiruna mine.

Last updated: March 2026

Hylio AG-272

Category: Commercial / Industrial — Agriculture NDAA Status: NDAA compliant (designed and manufactured in USA) Manufacturer: Hylio, Inc. (Houston, TX) — Made in USA

Overview

American-made agricultural spray drone. 18-gallon capacity, 8-rotor configuration, up to 50 acres/hour at 2 GPA. NDAA-compliant GroundLink Controller. The largest and most capable US-made ag spray drone currently available. Designed for producers and applicators who need NDAA compliance or want to avoid Chinese supply chain dependencies.

Specs

Also in the Hylio Family

Gotchas

1. Requires Part 137 exemption — Hylio assists with onboarding (complimentary).
2. RTK base station sold separately. Budget for it.
3. 30-minute battery charge time is slower than DJI's 9-minute fast charge — need more battery sets for production rates.
4. US-made means higher price point than Chinese alternatives (DJI, XAG).
5. AgroSol software is functional but not as polished as DJI Agras app.

When to Use This Platform

When you need an American-made, NDAA-compliant ag spray drone. Only real option in the US market for federally-funded ag programs that require NDAA compliance. The AG-272 at 18 gal capacity competes with the DJI Agras T50 on throughput.

Last updated: March 2026

Quantum Systems Trinity Pro

Category: Commercial / Industrial — Fixed-Wing VTOL NDAA Status: NDAA compliant (German manufacturer, NATO-allied) Manufacturer: Quantum Systems (Munich, Germany)

Overview

Long-endurance fixed-wing VTOL drone built for large-scale mapping and ISR missions. Highly modular design with AI-ready onboard computing. Supports wide range of sensors and mission profiles. Used by military and commercial operators across NATO countries.

Specs

Notes

Strong NATO/defense pedigree. Used in Ukraine conflict for ISR. Modular sensor bay allows mission-specific configuration. AI onboard processing enables real-time intelligence rather than post-flight analysis.

Last updated: March 2026

senseFly eBee X (AgEagle)

Category: Commercial / Industrial — Fixed-Wing Mapping NDAA Status: NDAA compliant (Swiss/US — AgEagle Aerial Systems) Manufacturer: senseFly (now part of AgEagle, Wichita, KS)

Overview

Professional fixed-wing mapping drone for survey, agriculture, and mining. Hand-launched, no runway needed. Up to 90-minute flight time. Swappable camera payloads (RGB, multispectral, thermal). eMotion flight planning software. Widely used in surveying, mining volumetrics, and precision agriculture.

Specs

Gotchas

1. Fixed-wing = no hover. Cannot stop and inspect a structure.
2. Hand launch requires technique — not ideal for inexperienced operators.
3. Belly landing means wear on the fuselage over time.
4. AgEagle has had corporate instability — verify current support and parts availability.
5. Competes with WingtraOne (VTOL, no hand launch) and DJI Matrice + L2 (multirotor with LiDAR).

Last updated: March 2026

XAG P100 Pro / P150

Category: Commercial / Industrial — Agriculture NDAA Status: NOT compliant (Chinese manufacturer) Manufacturer: XAG Co. (Guangzhou, China)

Overview

XAG's flagship agricultural drone family. The P100 Pro carries 50 kg payload with 60L spray tank, covering 70 acres/hour. The P150 steps up to 70L tank and 80 kg max payload (P150 Max). Modular hot-swap payload system: spraying, spreading, mapping, and cargo transport. Fully autonomous via XAG One App with RTK cm-level positioning. Biggest direct competitor to DJI Agras T50.

Specs — P100 Pro

Specs — P150 / P150 Max

Software & Autonomy

• XAG One App: Fully autonomous flight planning, one-tap operation
• XAG SuperX 4 Pro: Intelligent flight control with AI algorithms
• RTK Network: Centimeter-level positioning, supports multiple simultaneous drones
• Multi-drone: Single operator can command multiple aircraft
• Mapping: 12MP camera with mechanical shutter for field survey/boundary detection

Gotchas

1. NOT NDAA compliant. Chinese manufacturer — same procurement restrictions as DJI.
2. Massive platform — requires truck/trailer infrastructure, generator for fast charging.
3. Part 137 exemption required for commercial ag application in the US.
4. XAG ecosystem is less mature in North America than DJI Agras — fewer dealers, less local support.
5. Competes directly with DJI Agras T50 — DJI has better software integration, XAG has larger payload options.

Last updated: March 2026

Ascent Aerosystems (Coaxial Platforms)

Category: NDAA-Compliant / Blue UAS NDAA Status: NDAA compliant Manufacturer: Ascent Aerosystems (USA)

Overview

Unique coaxial drone design — two counter-rotating rotors on a single axis. Compact, robust, and high-performance. Designed for industrial, defense, and public safety markets. The coaxial design provides exceptional stability and efficiency in a smaller form factor than equivalent multirotor platforms.

Key Features

• Coaxial rotor design: Smaller footprint than traditional multirotors for equivalent lift
• Rugged construction: Built for demanding industrial and defense environments
• Modular payloads: Configurable for ISR, inspection, mapping
• NDAA compliant
• Compact deployment

Notes

Niche platform worth tracking for operators who need compact form factor with heavy-lift capability. Less mainstream than Skydio/Freefly/Inspired Flight but carving out a space in defense and industrial inspection.

Last updated: March 2026

Freefly Astro (Astro Max)

Category: NDAA-Compliant / Blue UAS NDAA Status: Blue UAS certified (NDAA-compliant build available) Manufacturer: Freefly Systems (Woodinville, WA) — Made in USA

Overview

American-made, open-architecture mapping and inspection drone built on PX4. Running Auterion Enterprise PX4 on a Skynode flight controller with triple-redundant IMUs. Blue UAS certified. Swappable payload via Smart Dovetail system. The Astro Max variant carries the 61MP Sony LR1 full-frame sensor. Over 100,000 commercial flights logged.

This is the open-source success story. PX4-based, MAVLink-native, with a real payload ecosystem and federal compliance.

Specs

RF Links

Primary C2/Video

• Radio: Doodle Labs (NDAA compliant)
• Protocol: MAVLink v2 native
• Encryption: AES

Backhaul

• LTE: Via Auterion Skynode — cloud connectivity, OTA updates, fleet management
• Telemetry: SiK-compatible for development environments

Firmware & Software

• Firmware: Auterion Enterprise PX4 (open-source based, commercially supported)
• GCS: Auterion Mission Control (pre-installed)
• Compatible GCS: QGroundControl, UgCS, Esri SiteScan (validated)
• Other PX4 GCS: Works but not officially tested
• Fleet Management: AuterionOS provides predictive maintenance, geotagging, OTA updates
• Auterion SDK: For enterprise developers

This is a real PX4 platform. You get MAVLink. You get open parameters. You get QGC compatibility. But you also get commercial support, LTE connectivity, and fleet management that you won't get from a DIY Pixhawk build.

Payload Integration

Smart Dovetail System

Tool-less payload swap — slide on, lock, fly. Proprietary mechanical interface but open electrical/data bus.

Native Payloads

• Sony LR1: 61MP full-frame — the Astro Max flagship sensor
• Sony A7R IV: 60MP (previous gen)
• Various mapping payloads: Third-party sensors via Smart Dovetail adapter
• Thermal, LiDAR: Via adapter — check Freefly for current payload catalog

Gotchas

1. 25-minute flight time is shorter than competitors. DJI M350 does 55 min. Inspired Flight IF1200A does 43 min. If endurance is critical, factor this in.

2. Smart Dovetail is proprietary. Third-party payloads need an adapter. Freefly's payload ecosystem is good but not as deep as DJI's gimbal lineup.

3. NDAA/Blue build ships with GPS logging disabled by default. You must enable it in settings before your first mapping mission or you'll get untagged imagery.

4. Freefly keeps some PX4 code closed — motor drives, autonomy, avoidance. The core flight stack is open, but not everything.

5. Dual SL8-Air batteries are proprietary. Guaranteed 500+ cycles, but no third-party alternatives exist.

6. Network RTK requires Auterion licence (~$1,200) for NTRIP caster access. Base-station RTK works with any multi-band GNSS base.

When to Use This Platform

The Freefly Astro is the right choice when you need: Blue UAS compliance + open MAVLink + real payload flexibility + commercial support. It's the platform that proves you don't have to choose between open-source and enterprise readiness.

Best for: precision mapping, photogrammetry, inspection, agriculture. Not ideal for: long-endurance surveillance (25 min limit), heavy-lift (2 lb max), or thermal-primary missions (need to add thermal as a payload).

Last updated: March 2026

Inspired Flight IF1200A

Category: NDAA-Compliant / Blue UAS NDAA Status: Blue UAS certified, NDAA compliant, Green UAS certified Manufacturer: Inspired Flight Technologies (San Luis Obispo, CA) — Made in USA

Overview

Heavy-lift hexacopter developed to U.S. Air Force standards. The workhorse of the NDAA-compliant drone world. Carries large payloads (LiDAR, EO/IR, Phase One cameras) with 43-minute endurance. Open payload interface. ArduPilot-based. SAFE motor-out redundancy keeps flying if a motor fails.

Specs

RF Links

• C2/Video: Doodle Labs or similar NDAA-compliant radio
• GCS: GS-ONE ground control station (integrated controller + display)
• Protocol: MAVLink v2
• Telemetry: Standard MAVLink telemetry stream

Firmware & Software

• Firmware: ArduPilot-based
• GCS: Mission Planner, QGroundControl
• Flight Modes: Position Hold, Loiter, Auto, Return-to-Launch
• Open system architecture — configurable for specific missions

Payload Integration

Universal payload interface supports:

• EO/IR: FLIR, L3Harris
• LiDAR: Yellowscan, RIEGL, Velodyne
• Optical Imaging: Phase One, Sony
• Multispectral: Sentera 6X series
• Payload adapter guides available from Inspired Flight

Gotchas

1. Heavy platform — not backpackable. This is a truck drone, not a backpack drone.
2. Folding arms can be stiff after flight — thrust loads the locking mechanism. Support the arm bottom with upward force while sliding the lock.
3. Requires Part 107 waiver if total weight (aircraft + payload) exceeds 55 lb.
4. Batteries are proprietary.
5. No integrated camera — payload must be purchased separately. Budget accordingly.
6. SAFE motor-out capability is a lifesaver for expensive payloads but requires pilot awareness — land promptly when alerted.

When to Use This Platform

The IF1200A is the platform when you need to carry heavy sensors (LiDAR, Phase One, EO/IR) with NDAA/Blue UAS compliance. Nothing else in the Blue UAS ecosystem comes close on payload capacity. ArduPilot firmware means full MAVLink access and Mission Planner compatibility.

Last updated: March 2026

Parrot ANAFI USA

Category: NDAA-Compliant / Blue UAS NDAA Status: Blue UAS listed Manufacturer: Parrot (Paris, France) — NDAA Compliant

Overview

One of the lightest enterprise drones on the market at 500g. French-designed. Triple-sensor payload (32x zoom, wide, FLIR thermal). GOV and MIL variants. The MIL version adds a Microhard radio for extended comms. ISO9001 certified manufacturing.

Specs

RF Links

• GOV version: Wi-Fi based control/video via Skycontroller
• MIL version: Adds Microhard radio for longer range and better RF penetration
• Video sharing: RTSP stream via Ethernet (RJ45) to VLC-equipped PC, or via FFmpeg
• Fly-by-coordinates: GPS coordinate display and sharing for any visible POI

Firmware & Software

• App: FreeFlight 6 Enterprise
• SDK: Open Flight SDK for developer integration
• No MAVLink

Gotchas

1. Wi-Fi link on GOV version is range-limited and susceptible to interference in dense RF environments.
2. Small thermal sensor — FLIR Boson 320 vs competitors at 640×512. Adequate for detection, not ideal for detailed thermal analysis.
3. No payload swap. The integrated sensor package is all you get.
4. Lightweight is a double-edged sword — extremely portable, but poor wind resistance.
5. Parrot's enterprise support has historically been inconsistent compared to DJI/Autel/Skydio.

When to Use This Platform

Ultra-portable Blue UAS recon. When you need the smallest possible compliant drone with thermal capability. The MIL variant with Microhard is the more serious option for government work. Not a primary inspection or mapping platform.

Last updated: March 2026

Skydio X10 / X10D

Category: NDAA-Compliant / Blue UAS NDAA Status: X10 is NDAA compliant; X10D is Blue UAS listed Manufacturer: Skydio (San Mateo, CA) — Made in USA

Overview

Skydio's flagship AI-autonomous drone. The X10 is the commercial/public safety variant; the X10D is the defense variant with hardened comms, MAVLink support, and RAS-A compliance. Both feature six navigation cameras, NVIDIA Jetson Orin GPU, and the industry's most capable obstacle avoidance. Best-in-class autonomy. Built in the USA.

Specs

Sensor Packages (choose at purchase)

RF Links

X10 (Commercial)

• WiFi-based control/video link
• 5G/LTE unlimited range via Connect Fusion (optional)
• AES-256 encrypted

X10D (Defense)

• Dedicated defense comms (Doodle Labs Mesh Rider radio options)
• RAS-A v1.2 compliant
• Open MAVLink protocol for third-party GCS
• Multi-band operation

Both variants support Remote Ops for browser-based remote piloting from any location, and DFR Command for drone-as-first-responder workflows.

Firmware & Software

• Firmware: Proprietary Skydio Autonomy software
• X10 Controller: Skydio Flight Deck ONLY — no third-party controller support
• X10D: MAVLink support, QGroundControl compatible, third-party GCS
• SDKs:
• Cloud API — mission planning, fleet management, media sync
• Extend API — workflow integration (evidence management, inspection platforms)
• Mobile SDK — Android apps on controller
• Attachment ICD — custom payload mechanical/electrical specs

Autonomy

This is where Skydio leads the industry:

• GPS-denied navigation via visual-inertial odometry — flies in parking garages, under bridges, inside structures
• NightSense: Zero-light autonomous flight using visible or IR illumination (X10D)
• Subject Tracking (Shadow): Maintains lock on people/vehicles even through brief occlusions
• Scout: Autonomous overwatch mode
• Map Capture: 2D orthomosaic generation
• Onboard 3D Modeling: Low-res 3D preview on-device for field decisions
• Anchor Points: GPS-denied return-to-home via visual reference placement
• Crosshair Coordinates: Identify POI coordinates from air

Attachments

• Parachute — safety fallback for operations over people
• NightSense Visible/IR Light — zero-light autonomous flight
• Spotlight — nighttime visibility
• Speaker — communicate in high-risk situations
• RTK/PPK — precision mapping
• Dropper (planned) — payload release
• Connect Fusion+ (coming) — second cellular connection

Gotchas

1. X10 (commercial) is locked to Skydio software. No MAVLink, no QGC, no Mission Planner. If you need open protocol access, you need the X10D — which costs more and requires government/defense procurement.

2. Attachment bays limited to 340g total. No heavy payloads. This is not a mapping drone with a LiDAR rig.

3. No swappable primary sensor. You pick VT300-L, VT300-Z, or V100-L at purchase. Want a different sensor package? Buy another drone.

4. LTE connectivity requires active cellular plan. Remote Ops is browser-based but needs internet on both ends.

5. Thermal on VT300-L/Z is FLIR Boson+ 640×512 — excellent sensitivity (<30mK) but verify radiometric measurement support on your firmware version.

6. 10x more computing power than previous gen means higher power draw — the 40-minute flight time reflects this.

When to Use This Platform

Best autonomous flight in the industry, period. If your mission requires flying in GPS-denied environments, around obstacles, at night, or with minimal pilot training, Skydio X10 is the answer. The X10D is the only Blue UAS platform with this level of autonomy.

Not the right platform for heavy-lift mapping, LiDAR, or custom payload integration. For that, look at Freefly Astro or Inspired Flight IF1200A.

Last updated: March 2026

Teal 2

Category: NDAA-Compliant / Blue UAS NDAA Status: Blue UAS certified (added June 2023) Manufacturer: Teal Drones / Red Cat Holdings (Salt Lake City, UT) — Made in USA

Overview

Compact, rucksack-portable ISR drone optimized for night operations. "Dominate the Night." FLIR Hadron 640R EO/IR payload delivers exceptional thermal imaging in a Group 1 package. Used by DoD, law enforcement, and public safety.

Specs

Sensors

RF Links

• Standard: 2.4 GHz ISM band, AES-256 encrypted, ~5 km range
• Controller: TAC (Teal Air Controller) — ruggedized GCS with built-in display
• Multiband variant available
• Black Widow (SRR Tranche 2): Doodle Labs Helix Mesh Rider Radio with Sense Technology for anti-jamming and low probability of intercept

Gotchas

1. Small payload capacity — this is an ISR scout, not a mapping or inspection platform.
2. No swappable primary sensor beyond the Hadron EO/IR.
3. Near-silent propulsion is a tactical advantage but limits max speed and wind resistance.
4. Multi-vehicle command supported from single TAC.

When to Use This Platform

Night ISR, close-range reconnaissance, public safety overwatch. The Hadron 640R thermal is excellent for its size class. If you need a Blue UAS drone that fits in a rucksack and dominates in low-light conditions, this is the one.

Last updated: March 2026

WingtraOne GEN II / WingtraRAY

Category: NDAA-Compliant / Blue UAS — Fixed-Wing VTOL Mapping NDAA Status: Blue UAS listed, Green UAS certified Manufacturer: Wingtra (Zurich, Switzerland)

Overview

Professional fixed-wing VTOL mapping drone. Vertical takeoff, fixed-wing cruise at 16 m/s for up to 59 minutes. PPK GNSS for cm-level accuracy without ground control points. Swappable sensors (61MP RGB, 42MP full-frame, multispectral, LiDAR). Over 100,000 flights worldwide. The WingtraRAY (2025) successor covers up to 1,300 acres in one hour-long flight.

Specs — WingtraOne GEN II

Specs — WingtraRAY (2025+)

Integration Notes

• Processing: Compatible with Pix4D, Metashape, Propeller, DroneDeploy, WingtraCLOUD
• Exports: Civil 3D, TBC, ArcGIS
• No MAVLink — proprietary autopilot
• Airline carry-on compliant batteries (~525 g each vs ~4.7 kg for DJI M400 batteries)

Gotchas

1. Fixed-wing means no hover capability during mission. Can't stop and inspect a point.
2. Requires open launch/landing area — tail-sitter VTOL needs clear space.
3. Not for inspection or close-proximity work — this is a mapping/survey platform only.
4. Proprietary autopilot — no MAVLink, no QGC, no Mission Planner.
5. Wind limits on ground (8 m/s for launch/land) are lower than in-flight limits.

Last updated: March 2026

Custom ArduPilot / PX4 Builds — General Integration Reference

Category: Open-Source / Custom Build Firmware: ArduPilot or PX4 (open source) Protocol: MAVLink v2

Overview

Any drone built on ArduPilot or PX4 firmware running Pixhawk-compatible hardware. This covers hundreds of commercial products (Freefly Astro, Inspired Flight IF1200, Watts Innovations Prism, Harris Aerial H6, CubePilot-based builds) and thousands of custom builds. The open-source ecosystem is the backbone of non-DJI drone integration.

Common Flight Controllers

Key Integration Points

All ArduPilot/PX4 platforms share:

• MAVLink v2 as the telemetry protocol
• UART-based peripheral connections (GPS, telemetry, RC, rangefinder)
• PWM/DShot motor outputs
• I2C/SPI sensor buses
• USB for configuration and companion computer
• SD card for logging and parameter storage

The handbook's chapters on UART layout (Ch 8), MAVLink (Ch 7), MSP (Ch 6), and companion computers (Ch 13) are written specifically for this ecosystem.

Telemetry Radio Options

Ground Control Stations

Common Commercial Platforms Using ArduPilot/PX4

• Freefly Astro: PX4 (Auterion), Blue UAS, mapping/inspection
• Inspired Flight IF1200/IF800: ArduPilot, Blue UAS, heavy-lift
• Watts Innovations Prism: Multi-payload, industrial
• Harris Aerial H6: Heavy-lift surveying/mapping
• Aurelia Drones: Industrial-grade, high payload
• CubePilot-based custom builds: Anything you can imagine

The ArduPilot vs PX4 Decision

Both speak MAVLink. Both run on Pixhawk. Both work. Pick based on your ecosystem and support needs.

Integration Tips for Custom Builds

1. Map your UARTs before you build. See Chapter 8. You will run out.
2. Separate RC and video bands. 2.4 GHz RC + 5.8 GHz video, or 900 MHz RC + 5.8 GHz video. Never both on 2.4 GHz.
3. CRSF protocol at 420000 baud for ELRS/Crossfire RC links. Not 115200.
4. MAVLink stream rates matter. Too high floods the telemetry link. Start with SR0_POSITION=2, SR0_EXTRA1=4.
5. Test failsafe before you need it. Every firmware handles it differently. Know yours.
6. Blackbox logging is your post-flight truth. See Chapter 10.
7. PID tune in the field, not in simulation. See Chapter 11.

Last updated: March 2026

Holybro X500 V2 + Pixhawk 6X (PX4 Dev Kit)

Category: Open-Source / Custom Build NDAA Status: NOT compliant (Chinese-sourced components) Manufacturer: Holybro (Shenzhen, China)

Overview

The reference development platform for PX4 and ArduPilot. Carbon fiber frame with no-solder assembly. Ships with Pixhawk 6X (or 6C), M10 GPS, and SiK telemetry radio. Mounts for Raspberry Pi, Jetson Nano, and Intel RealSense depth cameras.

If you want to understand every layer of the drone integration stack, this is where you start. Every UART is documented. Every protocol is open. Every parameter is tunable. The handbook's chapters on UART layout, MAVLink, PID tuning, and companion computers were written with platforms like this in mind.

Specs

RF Links

Link 1 — RC Control

Add your own. Any standard RC receiver via UART: - ELRS 2.4 GHz or 900 MHz (CRSF protocol, UART, 420000 baud) - TBS Crossfire (CRSF) - FrSky (SBUS) - FlySky (IBUS)

Link 2 — Telemetry

• SiK radio: 915 MHz (Americas) or 433 MHz (EU/Asia), MAVLink, ~64 kbps, point-to-point
• Connects to Mission Planner or QGroundControl on ground station

Link 3 — Video

Add your own: - Analog 5.8 GHz VTX - DJI O3 Air Unit / HDZero (for FPV) - IP camera via companion computer (RPi + camera module) - No integrated video link — build-your-own

Firmware & Software

• PX4 or ArduPilot — both fully open source
• GCS: QGroundControl (PX4 default) or Mission Planner (ArduPilot default)
• Protocol: MAVLink v2 — full parameter access, mission upload, telemetry streaming
• Simulation: PX4 SITL for testing before flight
• Pixhawk 6X Ethernet interface for high-speed companion computer integration

Pixhawk 6X Flight Controller Details

Companion Computer Integration

The X500 V2 has mounting holes and platform board space for:

• Raspberry Pi 4: Standard mount, USB connection to Pixhawk
• NVIDIA Jetson Nano: Direct mount on platform board
• Intel RealSense: Depth camera mount on rail system (D435, T265)
• Pixhawk 6X Ethernet: High-speed connection for data-intensive applications

Communication: MAVLink via serial UART or USB. MAVSDK / DroneKit for programmatic control.

Gotchas

1. 18-minute flight time is short. Bigger batteries help but add weight. Budget for multiple batteries.
2. No obstacle avoidance out of the box. Add Intel RealSense + PX4 avoidance module if needed.
3. No weatherproofing. This is a fair-weather development platform.
4. SiK radios are low-bandwidth (~64 kbps). Fine for MAVLink telemetry, not for video.
5. Pixhawk 6X PM02D-HV power module requires firmware setting (SENS_EN_INA228) and ArduPilot 4.4+.
6. M10 GPS needs PX4 1.14+ or ArduPilot 4.3+. Older firmware won't see it.
7. Chinese-sourced components — not NDAA compliant. For federal work, look at ARK Electronics FC + U.S.-sourced components.

Why This Platform Matters

This is the teaching platform. Every concept in the handbook — the five link types, UART allocation, MAVLink telemetry, PID tuning, companion computers, mesh radios — can be implemented, tested, and understood on an X500. It's not the best at anything, but it teaches you everything.

Last updated: March 2026

Anduril Ghost X

Category: Tactical / Defense NDAA Status: Blue UAS listed Manufacturer: Anduril Industries (Costa Mesa, CA) — Made in USA Availability: Military/government procurement only

Overview

Anduril's medium-range reconnaissance drone designed for company-level military operations. Helicopter-type design (main + tail rotor) for superior endurance and payload compared to typical quadcopters. Controlled through Anduril's Lattice AI software. Combat-proven in Ukraine. Deployed at JPMRC Hawaii, Combined Resolve Germany, and Balikatan Philippines.

Specs

Payload Options

Modular mission kits: - EO/IR sensors (day/night imagery) - Laser designators - Communications relay modules - Other mission-specific payloads

Software — Lattice

Lattice automates mission planning, airspace deconfliction, and flight profiles. Integrates with broader C2 ecosystem for sensor-to-shooter workflows (e.g., HIMARS cueing). Reduces operator workload and training time.

Gotchas

1. Military/government procurement only — not available for commercial purchase.
2. Lattice is proprietary — no MAVLink, no open protocol access.
3. Helicopter design provides endurance but is mechanically more complex than multirotor.
4. Requires Anduril training and support pipeline.
5. Combat-deployed in Ukraine since 2022 — real-world validation, but also means adversaries have had time to study it.

Last updated: March 2026

Hoverfly LiveSky / Spectre

Category: Tactical / Industrial — Tethered UAS NDAA Status: Blue UAS listed (Spectre), Green UAS listed Manufacturer: Hoverfly Technologies (Orlando, FL) — Made in USA

Overview

Tethered drone systems for persistent surveillance, communications relay, and overwatch. Powered via tether cable — unlimited flight time as long as ground power is available. No battery constraints. Blue UAS and Green UAS certified. Used by military, law enforcement, and critical infrastructure protection.

Key Features

• Unlimited flight time (tethered power)
• Persistent ISR: EO/IR payload for continuous overwatch
• Communications relay: Extend comms range by elevating radio/antenna
• Blue UAS (Spectre): ATO from 2025 Blue UAS Challenge
• Weather resistant
• Rapid deployment

Gotchas

1. Tethered = limited mobility. Drone stays within cable radius of ground station.
2. Ground station required — not as portable as free-flying drones.
3. Cable management is a real operational concern in field conditions.
4. Best for persistent overwatch, events security, and fixed-site protection — not for search/recon over large areas.

Last updated: March 2026

ModalAI Seeker / Stinger

Category: Tactical / Defense — Autonomous FPV NDAA Status: Blue UAS Framework (16 components listed — most of any manufacturer) Manufacturer: ModalAI (San Diego, CA, USA — spun out of Qualcomm 2018)

Overview

ModalAI produces the most Blue UAS Framework components of any single manufacturer (16 listings). Their VOXL 2 compute platform is the reference companion computer for PX4-based autonomous drones. The Seeker and Stinger are ModalAI's own FPV/autonomous drone platforms built on this ecosystem.

ModalAI placed in the top 5 of DDG Phase I (~77–80 points).

Platforms

Seeker — Vision-Guided FPV

• GPS-denied capable via VOXL 2 visual-inertial odometry
• Onboard AI for target detection and tracking
• Autonomous terminal guidance option

Stinger — Strike FPV

• Strike-optimized variant
• Low-cost, expendable architecture
• Designed for contested RF environments

VOXL 2 Compute Platform

VOXL 2 runs PX4 natively, making it the most direct integration target for any PX4-based AI Wingman deployment.

Notes

ModalAI is the most interesting integration partner for the AI Wingman PX4 architecture. They run PX4 natively on VOXL 2, which maps directly to the existing PX4 Integration Architecture doc. Their visual-inertial odometry stack is production-ready for GPS-denied operations.

Last updated: March 2026

Neros Archer

Category: Tactical / Defense — FPV NDAA Status: Blue UAS listed (ATO from 2025 Blue UAS Challenge) Manufacturer: Neros Technologies (Los Angeles, CA) — Made in USA

Overview

High-performance, American-made FPV drone. Blue UAS certified. Designed for long-range missions, battlefield-proven, cost-effective for large-scale deployment. Optimized to resist electronic warfare. One of the first FPV platforms to receive Blue UAS listing.

Specs

Notes

The Blue UAS listing for FPV platforms was a first in the 2025 challenge cycle. The Neros Archer represents the DoD's recognition that FPV capabilities are critical for modern warfare (lessons from Ukraine). Detailed integration specs are restricted.

Last updated: March 2026

Orqa MRM1-5

Category: Tactical / 5-Inch Multi-Role Trainer NDAA Status: NDAA §848 + §889 + Berry Act compliant Manufacturer: Orqa d.o.o. — Osijek, Croatia (EU) Availability: Commercial / defense procurement — orqafpv.com

Overview

The MRM1-5 is Orqa's 5-inch multi-role platform — the training workhorse of the MRM fleet and the cost-effective entry point to the full Orqa tactical ecosystem. Airframe is reinforced with four carbon fiber braces for crash survivability during intensive training cycles.

Available in two radio variants: ISM (Ghost 2.4 GHz) for standard operations, and a licensed-band variant (IRONghost) for more demanding RF environments.

Operators who train on the MRM1-5 with Tac.Ctrl build direct muscle memory that transfers to the MRM2-10 — same controller, same GCS, same MAVLink/ATAK workflow. This cross-platform proficiency is intentional: the MRM1-5 is designed to feed the larger MRM2-10 pipeline, not replace it.

Specs

Ground System

Roles

ISM vs Licensed Variant Selection

Choose ISM when: - Training in standard environments - Budget is a constraint - Operating with mixed RC/FPV infrastructure

Choose licensed-band variant when: - Tac.Ctrl + GCS-1 workflow proficiency is the training objective - RF environment requires licensed-band operation

Gotchas

1. Licensed variant requires Tac.Ctrl — the standard FPV.Ctrl does not drive IRONghost. Factor controller cost into per-seat training budget.
2. ISM variant uses Ghost 2.4 GHz — GHST protocol (ImmersionRC/Orqa), not ELRS. Confirm receiver compatibility if integrating into non-Orqa ground equipment.
3. 4S battery, not 6S — unlike the MRM2-10. Separate battery logistics if running mixed MRM fleet.
4. Not Blue UAS listed — NDAA compliant but not on the DoD approved list.
5. High attrition expected in training — reinforced carbon braces help but budget for airframe replacement at scale.

Last updated: March 2026 | Source: orqafpv.com, Helicomicro, Flying Eye

Orqa MRM2-10

Category: Tactical / Multi-Role FPV NDAA Status: NDAA §848 + §889 + Berry Act compliant Manufacturer: Orqa d.o.o. — Osijek, Croatia (EU) Availability: Commercial / defense procurement — orqafpv.com

Overview

Orqa's flagship 10-inch tactical FPV platform and their most widely fielded system globally. Often referred to simply as "MRM" or "MRM10" by operators. Built around full vertical integration — every component from the flight controller to the motors to the radio is Orqa-designed and EU-manufactured, with no Chinese parts in the BOM.

Orqa acquired ImmersionRC in 2023, consolidating the Ghost radio ecosystem in-house. The MRM2-10 is the centerpiece of the resulting vertically integrated ecosystem: Orqa frame, Orqa FC, Orqa ESC, Orqa motors, IRONghost radio (Orqa), Justice camera (Orqa), Tac.Ctrl ground controller (Orqa), GCS-1 ground station (Orqa).

Specs

Ground System

Supply Chain & Compliance

Orqa manufactures all core components in-house at their Osijek, Croatia facility: flight controllers, ESCs, motors, PCBs, cameras, and radios. Zero Chinese-sourced parts. Full vertical integration provides supply chain security and eliminates third-party dependency risks.

Note (2025): A DoD procurement halt was reported after a radio module subcomponent was found to be Chinese-sourced. Orqa CEO confirmed manufacturing of that module was moved in-house. NDAA compliance status should be independently verified for current contracts.

Production & Scale

Funding & Industry

Gotchas

1. IRONghost requires licensed spectrum — not ISM. Coordinate with your RF authority before deployment.
2. Tac.Ctrl is required for IRONghost — the standard FPV.Ctrl does not drive IRONghost.
3. DoD NDAA cloud (2025) — a subcomponent issue caused a procurement pause. Verify current compliance status with Orqa before contracting.
4. No DJI ecosystem — fully closed Orqa stack. Ghost/IRONghost receiver protocol (GHST) only.
5. Proprietary GCS — Orqa GCS-1 is MAVLink-compatible but the physical ground station hardware is Orqa-only.
6. MRM2-10F (foldable) also available — if rapid deployment / backpack carriage matters, evaluate the -F variant.

Last updated: March 2026 | Source: orqafpv.com, WNK Store, Tectonic Defense

Orqa MRM2-10F

Category: Tactical / Multi-Role FPV (Foldable) NDAA Status: NDAA §848 + §889 + Berry Act compliant Manufacturer: Orqa d.o.o. — Osijek, Croatia (EU) Availability: Commercial / defense procurement — orqafpv.com

Overview

The MRM2-10F is the rapid-deployment foldable variant of the MRM2-10. Click-lock folding arms collapse the airframe to backpack size, then snap back to flight-ready in under 10 seconds — no tools, no adjustments. Same IRONghost C2 link, same 2.5 kg payload capacity, same 20 km range as the fixed-frame MRM2-10. The two share the same ground system (Tac.Ctrl + IRONghost QS + GCS-1).

Best suited to dismounted teams where platform carriage, concealment, or rapid redeployment between positions is a requirement.

Specs

Full avionics stack identical to MRM2-10 (H7 QuadCore FC, 70A ESC, Justice camera, IRONghost radio).

Ground System

MRM2-10 vs MRM2-10F

Gotchas

1. Fold joint longevity — click-lock hinges accumulate wear with high training cycles. Inspect and replace per Orqa maintenance schedule.
2. Same ground system as MRM2-10 — Tac.Ctrl and GCS-1 hardware is interchangeable between variants.
3. IRONghost requires licensed spectrum — same coordination requirement as MRM2-10.
4. Not Blue UAS listed — EU-manufactured NDAA-compliant platform. Not on the DoD Blue UAS approved list.

Last updated: March 2026 | Source: orqafpv.com, WNK Store

Red Cat FANG F7

Category: Tactical / Defense — FPV NDAA Status: NDAA compliant Manufacturer: Red Cat Holdings / Teal Drones (Salt Lake City, UT, USA)

Overview

The FANG (Fierce, Agile, Nimble, Guerrilla) F7 is Red Cat's entry into the tactical FPV strike market. Built with NDAA-compliant components including UMAC (Unusual Machines) American-made motors. Red Cat is also the manufacturer of the Teal 2 (ISR) and Teal Black Widow (Army SRR Program of Record).

Specs

Red Cat Portfolio

Notes

Red Cat/Teal did not place in the top 11 of DDG Phase I despite holding the Army SRR Program of Record. The FANG F7 represents their pivot toward the strike/FPV market. UMAC's American-made motor facility (50,000+ motors/month capacity in Orlando, FL) is a key Blue UAS Framework component.

Last updated: March 2026

Shield AI Nova 2

Category: Tactical / Defense — Autonomous Indoor ISR NDAA Status: NDAA compliant Manufacturer: Shield AI (San Diego, CA) — Made in USA Availability: Military / government procurement

Overview

Autonomous indoor ISR drone that flies and maps buildings without GPS, without a pilot, and without comms. Uses Shield AI's Hivemind autonomy software for fully autonomous room-by-room clearing and mapping. Designed for military MOUT (Military Operations in Urban Terrain) and law enforcement tactical entry support. The drone enters a structure autonomously and returns with a 3D map and video.

Key Features

• Fully autonomous indoor flight — no GPS, no pilot, no comms required
• Hivemind AI: Autonomous navigation, mapping, and obstacle avoidance
• Room-by-room clearing: Enters unknown structures and maps them
• 3D mapping output
• Quiet operation
• NDAA compliant, Made in USA

Gotchas

1. Military/government procurement only.
2. Hivemind is proprietary — no MAVLink, no open protocols.
3. Indoor-only use case — not an outdoor platform.
4. Limited flight time due to small form factor.
5. Shield AI is also developing the V-BAT (fixed-wing VTOL) for outdoor missions — separate platform.

Last updated: March 2026

SiFly Q12

Category: Tactical / Commercial NDAA Status: NDAA compliant Manufacturer: SiFly (USA)

Overview

SiFly entered the market in 2025 with the Q12, a platform that prioritizes endurance and range above everything else. American-made, NDAA-compliant. Positioned for long-duration inspection and surveillance missions where flight time is the primary constraint.

Notes

Relatively new to market — detailed integration specs are still emerging. Worth tracking for operators who need maximum endurance from an NDAA-compliant platform. Community contributions with field data welcome.

Last updated: March 2026

Skycutter Shrike 10 Fiber

Category: Tactical / Defense — FPV Strike NDAA Status: NDAA compliant (via Skycutter UK partnership) Manufacturer: Skycutter (UK) / SkyFall (Ukraine) DDG Phase I: 1st place (99.3 points — highest score in competition)

Overview

The Shrike 10 Fiber won the Drone Dominance Gauntlet Phase I with 99.3 points — the highest score of all 26 competitors. It is a fiber-optic FPV strike drone, meaning the video and control signals travel through a thin fiber-optic cable rather than RF, making it completely immune to electronic warfare jamming.

The platform is a partnership between Skycutter (UK) and SkyFall (Ukraine), combining Ukrainian combat-proven design with a NDAA-compliant Western manufacturing pathway.

Key Features

• Fiber-optic control: Zero RF emissions — immune to jamming, undetectable by RF sensors
• DDG Phase I winner: 99.3/100 — dominated the competition
• Combat-proven lineage: SkyFall's designs are battle-tested in Ukraine
• NDAA compliant (via Skycutter UK manufacturing)
• Low-cost, expendable

SkyFall (Ukraine)

SkyFall also produces the Vampire, a larger FPV platform capable of carrying 15 kg payloads. SkyFall is one of the most experienced combat FPV manufacturers in the world, with designs refined through continuous battlefield feedback.

DDG Phase II Implications

The fiber-optic approach has a fundamental advantage: it cannot be jammed. DDG Phase II introduces full EW opposition, GPS denial, and communications jamming — environments where RF-linked FPV drones degrade significantly. Fiber-optic platforms bypass the entire EW problem at the cost of limited range (determined by spool length) and the requirement to physically trail a fiber behind the drone.

Notes

The Shrike's DDG dominance signals that fiber-optic FPV may define the next generation of tactical strike drones. Kela Technologies (Israel, In-Q-Tel backed) is the key fiber-optic technology provider — they also partner with Neros for the Archer Fiber variant.

Last updated: March 2026

Skyfish Osprey

Category: Tactical / Commercial NDAA Status: NDAA compliant Manufacturer: Skyfish (Missoula, MT) — Made in USA

Overview

American-made drone built for precision mapping, inspections, and ISR missions. Designed around accuracy, repeatability, and secure operations rather than consumer features. Government-focused.

Specs

Notes

Emphasizes stable flight, precise positioning, and professional sensor support. Data quality and compliance prioritized over convenience. Worth profiling in more depth as field experience accumulates.

Last updated: March 2026

Teal Black Widow (SRR Tranche 2)

Category: Tactical / Defense NDAA Status: Blue UAS certified, NDAA compliant Manufacturer: Teal Drones / Red Cat Holdings (Salt Lake City, UT) — Made in USA Availability: Military procurement (U.S. Army SRR program)

Overview

The Black Widow won the U.S. Army's Short Range Reconnaissance (SRR) Tranche 2 contract — beating the Skydio X2D. Thousands of units will be fielded across Brigade Combat Teams over the next five years. Purpose-built for GPS-denied, EW-contested environments. Doodle Labs Helix Mesh Rider Radio with Sense Technology provides the communications backbone.

Key Details

• SRR Tranche 2 winner over Skydio X2D
• Comms: Doodle Labs Helix Mesh Rider Radio
• Anti-jamming via proprietary Sense Technology
• Dual-band operation
• Adaptive modulation
• Low-latency HD video and telemetry BVLOS
• Low probability of intercept/detect
• NDAA compliant, Blue UAS approved
• Validated in EW-contested environments including Ukraine
• Modular architecture for future capability upgrades

Gotchas

1. Military procurement pipeline only. Not available for commercial purchase.
2. Doodle Labs integration is specific to the SRR variant — not the same radio as the commercial Teal 2.
3. Detailed technical specs are largely restricted/FOUO.

Last updated: March 2026

UAS Nexus Platform One

Category: Tactical / MOSA FPV Ecosystem Platform NDAA Status: NDAA §848 compliant — NOT Blue UAS listed (uses Blue UAS-listed components) Manufacturer: UAS Nexus (United States) Availability: Syndicate membership required — syndicate.uasnexus.com

Overview

Platform One is less a fixed product and more an ecosystem — a MOSA-first (Modular Open Systems Architecture) airframe designed to accept whatever Western avionics stack the mission requires. Inspired by Ukraine's decentralized FPV production model: no single golden BOM, no single firmware, no vendor lock-in. The frame is the common denominator; everything else is operator-configured.

Supports 7-inch and 10-inch prop configurations on the same airframe. Solder-free build option available for trainer/non-technical user configuration. Decentralized manufacturing model targets 10,000+ aircraft/month capacity. Full NDAA §848 compliance. The platform is not itself Blue UAS listed, but is designed to accept Blue UAS Framework-listed components (ARK FPV, ModalAI VOXL 2, Auterion Skynode-S, Doodle Labs, etc.).

Access is gated behind UAS Nexus Syndicate membership, which requires request-based approval.

Specs

Supported Avionics

Flight Controllers

Autopilot / Compute

C2 / Radio Links

Autopilot Software

• Betaflight, INAV, PX4, ArduPilot

Configurations

FPV Trainer / EW

Learn to fly or defeat jammers. Featured: IRONghost or TBS/ELRS radio, TBS Lucid H7 or Orqa F405, NDAA camera, 3–5 kg payload capacity, solder-free option.

Mesh Node

Comms relay for GPS-denied environments. Featured: VOXL 2 Mini, Doodle Labs / BlueSDR / L3Harris / Silvus radio, low-light EO camera.

Autonomy Testing

Perception and navigation research with modular sensors. Featured: VOXL 2 / VOXL 2 Mini, Doodle Nano, low-light EO + perception cameras, downward LiDAR, autonomy software.

Sensors & Cameras

• NDAA-compliant EO camera
• Low-light EO camera
• Perception / stereo camera
• Downward LiDAR

Gotchas

1. Syndicate access is gated — membership requires approval. Factor lead time into procurement planning.
2. No fixed BOM — Platform One is an ecosystem, not a single SKU. Component selection varies by configuration and availability. You assemble your own stack.
3. Decentralized manufacturing — high-volume capacity but supply chain coordination is on the operator/integrator.
4. Multi-firmware support — no single "golden path." Operator must select and configure the autopilot stack. VOXL 2 / PX4, ArduPilot, Betaflight, and iNav all have different integration complexities.
5. Deeper product catalog behind the membership wall — publicly available specs are limited. Full component catalog accessible only post-approval.
6. NOT Blue UAS listed — the platform itself is not on the DoD approved list. It is NDAA §848 compliant and designed to accept Blue UAS Framework-listed components, but those are different designations. Do not represent it as Blue UAS listed in procurement documents.

Last updated: March 2026 | Source: syndicate.uasnexus.com, UAS Nexus Syndicate catalog

Vantage Robotics Vesper / Trace

Category: Tactical / Defense — ISR NDAA Status: NDAA compliant / Blue UAS Manufacturer: Vantage Robotics (USA)

Overview

Vantage Robotics builds compact ISR platforms for defense and public safety. The Vesper and Trace are small, portable reconnaissance drones designed for squad-level deployment with encrypted communications and secure data handling.

Vantage also manufactures the Vision2 ground control station — a 2500-nit display with 15 TOPS AI processing and AES-256 encryption, which is one of a handful of NDAA-compliant GCS options on the market.

Platforms

Vesper

• Small tactical ISR drone
• Blue UAS listed
• Encrypted data link
• Day/night sensor options

Trace

• Ultra-compact reconnaissance platform
• Designed for rapid deployment and covert operations
• Minimal visual and acoustic signature

Vision2 GCS

Notes

Vantage occupies the small ISR space alongside Teal 2 and Parrot ANAFI USA. Their Vision2 GCS is notable as one of the few NDAA-compliant ground control options with integrated AI processing.

Last updated: March 2026

Part 6 — Component References

Deep dives on flight controllers, ESCs, motors, batteries, companion computers, radios, sensors, and complete ecosystems. Specs that matter, gotchas that don't show up in datasheets.

Batteries & Power Systems — The Weight You Carry

Part 6 — Components Batteries define flight time, payload capacity, and increasingly, procurement eligibility. The NDAA battery ban is coming.

The Approaching Deadline

NDAA FY2026 prohibits DoD purchase of batteries for weapons and support systems from foreign entities of concern (China, Russia) effective January 1, 2028. This creates an 18-month window where the entire defense UAS industry must reshore its battery supply chain.

Most drone batteries today use Chinese cells — even packs assembled in the US typically contain CATL, EVE, or other Chinese cells. The 2028 deadline will force a transition to allied-nation cell manufacturers. Understanding who makes cells vs. who assembles packs is critical.

Cell Manufacturers vs. Pack Assemblers

A "drone battery" is a pack of individual cells wired together with a balance connector and protection circuit. The cells inside determine energy density, discharge rate, and cycle life. The pack integrator adds the BMS, connector, and housing.

Most operators buy packs (Tattu, CNHL, GNB). But the NDAA question is about the cells inside, not the label on the shrink wrap.

Cell Manufacturers — The Supply Chain Layer

Amprius Technologies — The NDAA Battery Leader

Amprius has near-monopoly positioning on NDAA-compliant high- performance UAS cells through 2028. Their silicon anode technology delivers 2× the energy density of conventional lithium-ion — same flight time at half the battery weight, or double the flight time at the same weight. The Nanotech Energy partnership (Feb 2026) establishes the first US-based production of Amprius cells, critical for NDAA compliance ahead of the Jan 2028 deadline.

American Lithium Energy (ALE) — SafeCore Safety Pioneer

ALE's key differentiator is safety. SafeCore+ is a patented internal safety layer that self-decomposes under abuse conditions to interrupt current flow — preventing thermal runaway at the electrode level, not just with external protection circuits. This reduces packaging weight (no bulky fireproofing needed) and passes nail penetration and overcharge abuse tests. ZeroVolt technology allows cells to be safely shipped and stored fully discharged — a significant logistics advantage for military supply chains.

At 400 Wh/kg shipping at scale, ALE bridges the gap between conventional Li-ion (~260 Wh/kg) and Amprius SiMaxx (520 Wh/kg), with a stronger safety story than either.

Wake Energy — US Pack Assembly at Scale

Wake Energy fills a critical gap: US-based pack assembly using non-Chinese cells (Molicel/Taiwan) at production scale. They don't make cells — they engineer and assemble packs with quality processes (CNC welding, pull-tested coupons, individual electrode QA) that hobby-grade pack assemblers don't match. The THOR 6030 is a ready-to-buy 6S pack for tactical FPV and UAS applications.

For operators who need NDAA-compliant battery packs without designing custom solutions, Wake Energy is the most accessible option — production-ready, tested to military standards, and shipping now.

Molicel (Taiwan)

Molicel P42A and P50B are the reference 21700 cells for high- performance drone applications. Taiwanese manufacturing makes them the most accessible non-Chinese high-discharge cells.

Samsung SDI (South Korea)

LG Energy Solution (South Korea)

Chinese Cell Manufacturers (Context — NOT NDAA)

• CATL — World's largest battery manufacturer. NOT NDAA.
• EVE Energy — Major Li-ion cell OEM. NOT NDAA.
• Most hobby LiPo packs (Tattu, CNHL, GNB) use Chinese cells.

Battery System Integrators

KULR Technology

KULR is the bridge between cell manufacturers and drone OEMs. They handle thermal management, BMS design, and pack engineering so that drone companies don't have to become battery companies.

Tattu / Gens Ace (Context — NOT NDAA)

In the parts-db for some products. Dominant hobby LiPo brand. Chinese-manufactured. NOT NDAA compliant. Needs compliance flags added to all existing entries.

LiPo vs. Li-Ion for Drones

The industry is moving from LiPo to 21700 Li-Ion for everything except extreme-discharge FPV applications. 21700 packs offer better energy density, longer cycle life, and a path to NDAA compliance through Molicel/Samsung/LG cells.

The Price Reality

The 2028 NDAA battery deadline will create a 3-5× cost increase for defense UAS battery systems unless allied-nation (Korea, Taiwan) cell production scales to meet demand.

Choosing Batteries

1. Match voltage to your ESCs and motors. 4S (14.8V nominal) is standard for 5" FPV. 6S (22.2V) is standard for larger builds. 8S and above for heavy-lift.

2. Capacity determines flight time. More mAh = more flight time but more weight. There's a sweet spot for every airframe.

3. Discharge rate determines power. "C rating" = max safe current draw as a multiple of capacity. A 1500mAh 100C pack can deliver 150A. LiPo C ratings are often inflated by manufacturers.

4. Storage charge matters. LiPo storage voltage is 3.8V/cell. Never store LiPo at full charge or fully depleted. Storage charge the same day you fly.

5. For NDAA builds: Molicel P42A/P50B 21700 packs are the pragmatic choice today. Amprius SiCore is the premium path with 2× energy density. KULR K1A provides engineered pack solutions.

Last updated: March 2026

Battery Deep Dive

The propulsion system matching guide covers battery selection for a given build. This guide goes deeper: what actually happens inside a LiPo as it ages, how to read internal resistance and what it tells you, why the C rating on the label is mostly marketing, and how to make rational decisions about parallel packs and storage.

Chemistry Comparison

LiPo (Lithium Polymer)

The standard for performance UAS. High discharge rate, low weight, available in every cell count and capacity imaginable. The cathode material is typically NMC (Nickel-Manganese-Cobalt) or NCA (Nickel-Cobalt-Aluminum).

• Nominal voltage: 3.7V/cell
• Full charge: 4.20V/cell (standard), 4.35V/cell (LiHV)
• Discharge cutoff: 3.5V/cell (conservative), 3.3V/cell (aggressive)
• Storage voltage: 3.80–3.85V/cell
• Energy density: 150–200 Wh/kg
• Cycle life: 150–400 cycles to 80% capacity
• Peak discharge: 25–150C rated (see C rating section)

Li-Ion (Lithium Ion)

Cylindrical cells (18650, 21700) with higher energy density but lower peak discharge. The right choice for long-endurance platforms that don't need burst power.

• Nominal voltage: 3.6V/cell
• Full charge: 4.20V/cell
• Discharge cutoff: 2.5–3.0V/cell
• Storage voltage: 3.6–3.7V/cell
• Energy density: 200–265 Wh/kg (35–60% more than LiPo)
• Cycle life: 500–1000 cycles
• Peak discharge: 2–10C typical (high-drain cells: 20–30C)

Where Li-Ion wins: Long-range fixed-wing, mapping platforms, delivery drones, anything where flight time matters more than max power. A 21700 Samsung 40T cell pack at 4,000mAh provides ~35% more flight time per gram than a same-weight LiPo — but if you need punch-out power for a 6S freestyle quad, Li-Ion won't keep up with the current demand.

LiHV (High Voltage LiPo)

Same physical construction as LiPo, charged to 4.35V instead of 4.20V. About 5–8% more energy per cell. Requires an LiHV-capable charger and an LiHV-rated ESC/FC (most modern ESCs handle 4.35V fine).

The tradeoff: the cells spend more time at high voltage, which accelerates degradation. Expect 20–30% shorter cycle life compared to the same cell charged to 4.20V. Worth it if you fly frequently and replace batteries regularly; not worth it if batteries sit between sessions.

LiFePO4 (Lithium Iron Phosphate)

Extremely safe, long cycle life, thermally stable. The chemistry of choice for ground vehicles, industrial systems, and high-cycle applications. Not competitive for UAS due to low energy density (90–120 Wh/kg) and low cell voltage (3.2V nominal).

The C Rating: What It Actually Means

The C rating on a LiPo label is a multiplier applied to the capacity:

Max discharge current (A) = C_rating × capacity_Ah

A 4S 1500mAh 100C pack has a rated max discharge of 150A.

The problem: C ratings are self-reported by manufacturers with no standard test methodology. A pack labeled 100C from a budget brand may actually provide 40–60A before voltage sag degrades significantly. A quality pack labeled 45C may outperform a cheap 100C pack at identical current.

What actually matters is internal resistance, not the C rating. Internal resistance is the real physical limit on discharge capability and it's measurable with a charger that has an IR measurement function.

Internal Resistance: The Real Health Metric

Internal resistance (IR) is the resistance inside the battery cell and wiring. When current flows, some voltage is lost across this resistance (V = IR), reducing the voltage available to your motors.

What IR tells you: - Fresh LiPo (good quality): 2–6mΩ per cell - Aged LiPo (80% capacity): 8–15mΩ per cell - Damaged/puffed cell: 20–50mΩ+

How voltage sag works: At 50A draw through a pack with 5mΩ IR per cell (4S = 20mΩ total):

Voltage sag = Current × IR = 50A × 0.020Ω = 1.0V

A 4S pack that reads 15.0V at rest shows 14.0V under 50A load. As the pack ages and IR increases to 40mΩ, sag at 50A becomes 2.0V — now your "15V" pack shows 13V under load, and your ESCs may hit their undervoltage cutoff.

Measuring IR: Use a charger with built-in IR measurement (iCharger, ISDT, Junsi series). Measure at rest, at consistent temperature (IR varies with temperature — cold cells have higher IR). Log IR on each charge cycle; rising IR is an early indicator of aging.

When to retire a pack: IR more than 3× the initial value, or capacity below 80% of rated, or any cell with a cell delta >0.1V after a full charge.

Voltage Sag Under Load

Voltage sag is not a flaw — it's physics. But excessive sag causes real problems:

• FC brownout: If the voltage at the FC input drops below minimum, the FC resets mid-flight.
• ESC undervoltage cutoff: ESCs have minimum operating voltages; crossing them causes motor shutdown.
• Reduced thrust: At lower voltage, motor RPM drops, reducing thrust.
• Inaccurate voltage monitoring: If you rely on resting voltage to estimate state-of-charge, the loaded voltage gives you a pessimistic picture — the battery recovers voltage when current demand drops.

Practical mitigation: - Set BATT_ARM_VOLT based on loaded voltage, not resting voltage. Test your platform's hover voltage under load and use that as the floor. - Add a 1000µF capacitor close to the ESC power input. This doesn't fix sag — it filters the fast transients. - Don't push packs to their rated maximum discharge for sustained periods. Flying at 70% of rated max discharge leaves margin for peaks.

Capacity Fade: How Batteries Age

LiPo capacity degrades with each charge-discharge cycle due to: 1. SEI (Solid Electrolyte Interphase) layer growth: Forms on the anode during charging; irreversible; increases IR over time 2. Lithium plating: At high charge rates or low temperatures, lithium metal deposits on the anode instead of intercalating; causes capacity loss and internal shorts 3. Cathode degradation: Physical and chemical changes at the cathode reduce active material

Accelerating factors: - High charge rate (>1C is fine; >3C degrades faster) - High storage voltage (storing at 4.2V vs 3.85V doubles degradation rate) - High operating temperature (>40°C significantly accelerates aging) - Deep discharge (below 3.3V/cell) - Physical damage (swelling, impact, moisture)

Slowing degradation: - Store at 3.80–3.85V/cell (most chargers have a "storage charge" function) - Charge at 1C or lower when not in a hurry - Avoid flying in temperatures below 5°C without pre-warming - Don't discharge below 3.5V/cell per battery monitor during flight (3.3V absolute minimum) - Don't charge immediately after a hot flight — let cells cool to under 40°C first

Storage Voltage: The Most Important Practice

Flying at full charge is fine. Storing at full charge is not. A LiPo stored at 4.2V/cell for a week loses measurable capacity; stored for a month, it may puff.

The sweet spot is 3.80–3.85V/cell — enough charge to prevent deep-discharge cell damage during storage, low enough to minimize electrolyte oxidation.

Practical workflow: 1. After flying: if you won't fly again within 48 hours, discharge or storage-charge to 3.85V/cell 2. Before flying: charge to 4.2V within 24 hours of use 3. Long-term storage (>1 month): store at 3.7–3.8V/cell, in a fireproof bag, in a cool location

Most quality chargers (iCharger, ISDT Q8, ToolkitRC M8) have a one-button storage charge function.

Parallel Packs

Running two or more batteries in parallel doubles capacity (and weight) without changing voltage.

What goes right: More capacity, lower effective C-rate for the same load, longer flights.

What can go wrong:

Connecting packs at different states of charge: When you connect a full pack (4.2V/cell) to a depleted pack (3.5V/cell), a large current flows between the packs as they equalize. This instantaneous equalization current can trip your ESCs, damage cell chemistry, or in extreme cases cause fires.

Rule: Never parallel-connect packs that differ by more than 0.1V per cell. Use a parallel charging board that lets you charge multiple packs simultaneously to the same voltage, then connect them in parallel.

Cell mismatches between packs: Even two nominally identical packs from the same manufacturer will have slightly different internal resistances. When paralleled, the lower-IR pack will supply more current under load. Over time this can cause one pack to age faster than the other.

Practical parallel approach for BVLOS endurance: 1. Buy a matched pair from the same batch (same production lot, same measured IR) 2. Cycle both packs together from new — don't alternate which pack you use 3. Retire both when either shows signs of aging

BMS for Larger Systems

For Group 2+ platforms and multi-cell configurations above 6S, a dedicated Battery Management System (BMS) is advisable.

A BMS provides: - Cell-level voltage monitoring (catch a single bad cell before it causes a runaway) - Overcurrent protection (hardware cutoff if current exceeds a threshold) - Temperature monitoring (thermistor per cell group) - State-of-charge estimation (Coulomb counting + voltage model) - Cell balancing (active or passive)

For ArduPilot integration, the BMS typically reports via I2C or UART. ArduPilot's BATT_MONITOR supports multiple BMS protocols:

BATT_MONITOR = 16  # SMBus-Maxim (common for 18650 packs)
BATT_MONITOR = 17  # ESCON
BATT_MONITOR = 18  # Bebop 2
BATT_MONITOR = 20  # Maxell (for industrial packs)

For custom or industrial LiPo packs with an integrated BMS UART output, use the BATT_MONITOR = 4 (UART protocol) or write a custom driver.

Fire Safety

LiPo thermal runaway is fast, hot (>800°C), and produces toxic gases. The standard precautions:

• Charge and store in a LiPo-safe bag — ceramic or reinforced bags rated for LiPo fires
• Never leave charging unattended
• Don't charge below 0°C — lithium plating risk
• Don't charge above 45°C ambient
• Inspect every pack before and after flight — any swelling, impact damage, or unusual warmth: ground it
• Discharge a damaged or retired pack completely (to 0V per cell, using a LiPo discharger or a resistive load) before disposal or recycling. A fully discharged LiPo is safe to dispose of in most municipal waste streams; a charged LiPo is not.

If a pack catches fire: Don't use water (water reacts with lithium). Move it outdoors if safe to do so; allow it to burn out. A metal bucket with sand is the standard field containment method.

BVLOS Pathways

Beyond Visual Line of Sight operations entered a new phase in August 2025 when the FAA published its long-awaited Part 108 Notice of Proposed Rulemaking. For the first time, there's a clear statutory framework for routine BVLOS operations — not just individual waivers. This guide covers the current compliance paths and what's changing.

Note: Part 108 is still proposed rulemaking as of early 2026. The FAA is reviewing public comments. What exists today are the Part 107 waiver and COA pathways. Part 108 is described here as the expected near-term framework.

What BVLOS Means and Why It's Hard

Under standard Part 107, you must maintain visual line of sight with your drone at all times — roughly 1,500 feet in optimal conditions. BVLOS operations remove this constraint, enabling long-range missions: infrastructure corridor inspection, precision agriculture at scale, last-mile delivery, and persistent ISR.

The regulatory difficulty is that VLOS is also the primary safety mechanism. Without it, the burden shifts to technology: detect-and-avoid systems that tell the drone (and operator) whether other aircraft are nearby, reliable command-and-control links that can't be severed beyond radio range, and airspace deconfliction systems that prevent two drones from being in the same place at once.

Current Paths (Pre-Part 108)

Path 1: Part 107 BVLOS Waiver

The existing mechanism. You apply to the FAA for a waiver to § 107.31 (visual line of sight requirement), demonstrating that your specific operation can be conducted safely without VLOS.

Reality check: BVLOS waivers increased from ~1,200 in 2020 to ~27,000 by 2023, but the vast majority of approved operations still use visual observers. Of 44,000+ BVLOS flights logged under the FAA's BEYOND program through 2025, fewer than 800 (~2%) were flown without a visual observer. The safety case for VO-less operations remains the hardest part of any waiver application.

What the application requires: - Detailed operational description (location, altitude, corridor, timing) - Aircraft technical description (remote ID compliance, C2 link architecture, DAA capability) - Emergency procedures (lost link, pilot incapacitation, aircraft malfunction) - Risk mitigation narrative addressing ground risk and air risk - Proof of operational safety (flight test data, simulation, comparable operations)

Timeline: 90 days minimum. In practice 6–18 months. Applies only to the specific described operation — a new location or aircraft requires a new application.

Path 2: Certificate of Authorization (COA)

COAs are issued to public agencies (law enforcement, fire, government entities) under 14 CFR § 91.203. They allow more flexible operations than Part 107, including BVLOS, at the cost of ongoing reporting and oversight requirements.

Public safety agencies often find COA amendments faster to process than commercial waivers because there's an established relationship with the FAA and a clear public benefit case.

Path 3: Part 135 Air Carrier Certificate

Amazon Prime Air, UPS Flight Forward, and Wing operate under Part 135 certificates. This gives them authority for routine BVLOS operations at scale but requires FAA oversight comparable to a small airline: operations specifications, airworthiness data, crew training programs.

Not a realistic path for most operators — it's the endpoint for mature commercial delivery networks, not a starting point for an inspection company.

Part 108: The Proposed BVLOS Framework (August 2025 NPRM)

Part 108 proposes to replace the waiver-by-waiver approach with a risk-tiered authorization framework. The core structure:

Two Authorization Types

Permit (lower-risk): - Faster issuance (targeted at days, not months) - Restricted to specific operation types: corridor surveys, infrastructure inspection, precision agriculture - Operations over sparse population in uncontrolled airspace - Remote ID required - DAA via ADS-B In required or equivalent - Flight below 400ft AGL in shielded areas

Certificate (higher-risk): - Full operations specification review — comparable to Part 135 light - Allows operations over people, in controlled airspace, and at higher operational complexity - Requires a designated Operations Supervisor and Flight Coordinator - Safety Management System (SMS) required - The path for package delivery, urban ISR, and complex corridor operations

Airworthiness

Under Part 108, aircraft up to 1,320 lbs including payload do not need traditional FAA type certification. Instead, manufacturers self-certify compliance with consensus standards (ASTM F3003, F2909, etc.) — the same approach used for Light Sport Aircraft. This is a significant reduction in friction for UAS manufacturers.

Detect-and-Avoid Requirements

Part 108 requires UAS to detect and yield right-of-way to any aircraft broadcasting ADS-B Out or other electronic conspicuity technology. The practical implication:

• Your aircraft needs ADS-B In (receiver) to detect manned traffic
• You need a DAA algorithm that can command avoidance maneuvers or alert the operator
• ADS-B Out is not required for UAS under 1,320 lbs but is strongly encouraged (and may be required in controlled airspace)

For DIY BVLOS platforms: uAvionix Ping (ADS-B transceiver, ~$800), Sagetech MXS, and mRo ACSP7 are the common hardware options. ArduPilot 4.4+ has native ADS-B In support with avoidance action.

UTM and ADSP Integration

For Permit-level operations, Part 108 requires coordination with an FAA-approved Automated Data Service Provider (ADSP) for airspace deconfliction. ADSPs are the commercial entities (currently in development / early certification) that will handle:

• Pre-flight airspace reservation
• Real-time conflict detection with other BVLOS operators
• ATC integration in controlled airspace

In practice, this means most BVLOS Permit operators will need to subscribe to a UTM service. ANRA Technologies, Airbus UTM, and Wing are among the early ADSP candidates. Pricing and availability are not yet established.

Practical BVLOS Stack for a Custom Platform

Assuming a DIY ArduPilot fixed-wing or VTOL targeting Part 108 Permit operations:

Command & Control Link

The C2 link must be reliable beyond visual range. Options ranked by practicality:

The most practical setup for low-cost BVLOS: primary C2 via LTE (DroneEngage), backup telemetry via LoRa mesh (Meshtastic), with a 900MHz or 1.4GHz direct link for short-range departure and approach phases.

ADS-B In

Required under Part 108. ArduPilot configuration:

ADSB_ENABLE = 1
ADSB_TYPE = 1 (MAVLink) or 2 (uAvionix Ping)
AVD_ENABLE = 1  (Airborne Vehicle Detection — ArduPilot avoidance)
AVD_F_ACTION = 2 (Climb on threat detection)

Remote ID

Required at all times. See the Remote ID for Custom Builds guide for wiring and configuration details.

GCS Software

QGroundControl and Mission Planner both support BVLOS workflows: corridor planning, altitude limits, geofence setup, and multi-link C2. Mission Planner has better ArduPilot integration; QGC has better cross-platform support and MAVLink 2 telemetry handling.

For cellular BVLOS via DroneEngage: the DroneEngage companion computer (Raspberry Pi) connects to your FC via USB serial and handles MAVLink forwarding over the cellular link transparently. You fly with QGC or Mission Planner on any internet-connected device.

Operational Requirements Under Part 108 Permit

The operational requirements for a Permit are manageable for a serious operator:

1. Pre-flight NOTAM: File a UAS-specific NOTAM via DroneZone for the planned operating area. Required before each BVLOS operation.
2. Remote ID active: Broadcast module powered and transmitting from the moment of departure.
3. ADSP coordination: File flight intent with an approved ADSP (once the infrastructure is in place; currently in development).
4. C2 link monitoring: Maintain and log C2 link quality throughout the flight. Lost link action (defined in operations manual) must execute automatically.
5. ADS-B monitoring: Active ADS-B In monitoring with DAA capability operative.
6. Post-flight reporting: Log flight data including any conflicts detected, C2 link outages, or operational deviations.

The reporting and logging requirements directly motivate Tooth's audit trail design — a complete Tooth record satisfies most of the Part 108 recordkeeping burden automatically.

What Changes Everything: Detect-and-Avoid

The fundamental barrier to scalable BVLOS has always been that operators can't visually scan for conflicting traffic. The regulatory structure compensates for this with technology requirements, but those requirements add cost, weight, and complexity.

The realistic near-term DAA stack for a Group 1 UAS (under 25kg):

• ADS-B In (~50–200g, ~$300–800): detects all manned aircraft broadcasting ADS-B Out. Covers most commercial and general aviation traffic.
• Traffic Advisory System integration: ArduPilot's native avoidance will command a climb maneuver when an ADS-B target approaches within a configurable range.
• Gap: Low-altitude, non-ADS-B aircraft (gliders, ultralights, non-equipped helicopters, other drones). No affordable solution yet. The FAA acknowledges this gap and Part 108 does not require detection of non-equipped aircraft — the risk mitigation is procedural (fly at appropriate times and locations).

This gap is the core reason VO-less BVLOS at scale remains difficult. The ADS-B → avoidance system handles the manned aviation threat; the unequipped aircraft threat is still mostly managed by procedural deconfliction (fly at night, fly in low-activity airspace, coordinate with ATC).

EW-Resilient Communications — Keeping the Link Alive

Part 6 — Components The radio link between operator and drone is the single point of failure that electronic warfare exploits. This chapter covers who builds the links that survive jamming.

The EW Reality

GPS-denied, spectrum-contested environments are the new baseline. Ukraine proved this at scale — Russian EW systems routinely jam GPS, spoof navigation, and disrupt C2 links. The average lifespan of a commercial drone on the Ukrainian front is days, not months, largely because consumer-grade links fail under EW pressure.

Any drone system intended for contested environments needs communications that degrade gracefully rather than failing catastrophically. This means frequency hopping, spread spectrum, mesh networking, and ultimately — for complete EW immunity — fiber-optic links.

The Handbook's RF Fundamentals (Part 1) covers the physics. This chapter covers the products and manufacturers.

Sine Engineering — Combat-Proven from Day One

The most important communications company most people have never heard of. Founded in Lviv, Ukraine in 2022 as a counter-UAS team. After realizing that resilient connectivity is both the most critical enabler and the most vulnerable aspect of UAS operations, they pivoted to building their own solutions.

Pasika Platform

Pasika ("Apiary") is Sine Engineering's integrated platform for multi-drone operations in contested environments. Four core pillars:

1. Resilient C2 Datalinks — Secure command and control with Smart FHSS (frequency hopping spread spectrum), jamming detect and avoid. Hardware-agnostic.
2. Digital Video Datalinks — HD video transmission optimized for EW-contested environments.
3. GPS-Independent Navigation — Satellite-free positioning using time-of-flight signals from nearby Sine.Links (inspired by legacy aviation navigation). Not centimeter-accurate, but maintains operational continuity when GPS is denied.
4. Swarm Capability — One operator controls multiple drones via single interface. Assign mission zones, launch sequentially, switch between drone feeds, deconflict paths automatically.

Combat record: Missions exceeding 200+ km in active EW conditions. Deployed across multiple Ukrainian drone types including strike FPVs, fiber-optic drones, and interceptors (Wild Hornets' Sting).

Why Sine Engineering Matters

Pasika allows $300–500 FPV drones to complete missions that would typically require more expensive platforms — because they maintain comms longer, avoid jamming more often, and deliver telemetry for continuous improvement. The system evolves weekly from direct battlefield feedback. As Sine puts it: "We don't bet on stability. We design for instability."

Their approach — "operator-scaled deployment" that extends human capability rather than replacing it — maps directly to the AI Wingman "Jarvis not Ultron" philosophy.

FPGA-based modules are in development for next-generation hardware. European branch opening for NATO-aligned manufacturing partnerships, including targeting US defense manufacturers supplying the Pentagon.

Western Mesh Radio Manufacturers

Doodle Labs

Doodle Labs Mesh Rider radios are the most commonly integrated mesh networking solution in commercial and defense small UAS. Under the hood, they run OpenWRT Linux with batman-adv mesh protocol — which means they're configurable Linux devices, not black boxes. This is both a strength (flexible, hackable) and a vulnerability (software complexity increases attack surface).

See the Handbook's mesh radios chapter (Chapter 14) for configuration details and real-world range expectations.

Silvus Technologies

Silvus provides the highest-throughput mesh radios in the market. Their MN-MIMO technology uses multiple-input multiple-output antenna configurations with mesh networking for combined throughput and resilience. Premium pricing — positioned for high-value platforms where bandwidth justifies the SWaP cost.

Persistent Systems

Persistent Systems MPU5 is unique in running Android OS natively on the radio, enabling onboard application hosting. Wave Relay MANET protocol. Used extensively by US SOF and DoD.

TrellisWare Technologies

Product Line:

TrellisWare's Barrage Relay technology eliminates traditional routing — all nodes collaboratively relay all traffic using cooperative combining. This means the network self-heals instantly when nodes join, leave, or are destroyed. Tested with 800+ nodes. Network formation in under 5 seconds.

Anti-jam C2 for UAS (2025): New waveform specifically for drone command and control with anti-jam uplink alongside high- throughput video/sensor downlink. Lowest latency in the industry. This directly addresses the DDG Phase II EW requirement.

Mobilicom

Turkish Manufacturers

Aselsan

Turkey's largest defense electronics company. Produces military- grade communications, EW systems, and radar. Supplies datalinks for Baykar TB2/TB3 and TAI ANKA platforms. Export-controlled.

TUALCOM

Stackable data acquisition and telemetry suites for UAS. Integrated with Turkish military platforms.

Meteksan

AKSON C-Band datalink (announced Nov 2025). Turkish defense communications.

Fiber-Optic — The EW-Immune Option

Fiber-optic FPV eliminates RF entirely. Video and control signals travel through a thin optical fiber trailed behind the drone. Zero RF emissions means zero detectability and complete immunity to electronic warfare jamming.

Key players: - Kela Technologies (Israel, In-Q-Tel backed) — fiber-optic technology partner for Neros Archer Fiber. World's first NDAA-compliant fiber-optic FPV. - SkyFall (Ukraine) — Fiber-optic FPV drones. Partnered with Skycutter for DDG Phase I (Shrike 10 Fiber won with 99.3 points). - 3DTech (Ukraine) — 3D-prints their own fiber spool casings. - Hasta (Ukraine) — Optically-guided FPV, 20–50 km range.

Tradeoff: Range is limited by spool length (physical fiber must trail behind the drone). The fiber can snag on obstacles. But for missions where EW immunity is paramount and range is known, fiber-optic is unbeatable.

DDG Phase I validated this: the fiber-optic Shrike dominated the competition. DDG Phase II's full EW environment will likely further advantage fiber-optic platforms.

NDAA RC & C2 Links

Most consumer RC links (ELRS, CRSF, FrSky) are Chinese-manufactured. For NDAA-compliant builds, the options narrow significantly.

Orqa Ghost — 2.4 GHz RC Link

EU-manufactured, NDAA-compliant 2.4 GHz RC link using LoRa-based chirp spread spectrum with adaptive FHSS. One of very few non-Chinese RC link options with both race and long-range performance.

Works with PX4 (RC_INPUT = GHST), QGroundControl, Betaflight 4.3+, iNav, and ArduPilot. OpenTX 2.3.13+ recommended.

Orqa IRONghost — Licensed-Band C2

Defense-grade C2 link operating on licensed bands. Dual-radio architecture. Manufactured in EU, NDAA compliant.

Paired with Orqa Tac.Ctrl (MAVLink, ATAK-compatible) and GCS-1 ground station for extended range and NLOS operations via aerial repeater. Requires licensed spectrum — coordinate with your RF authority before deployment.

Critical: Never power on without all antennas attached — 3W reflected back into amplifiers causes permanent damage.

Choosing Communications

1. Consumer FPV links (ELRS, CRSF, DJI) are NOT EW-resilient. They work in benign environments. They fail under deliberate jamming. Don't pretend otherwise.

2. Mesh radios add resilience but add SWaP. A Doodle Labs or Silvus radio is 100–300g and 5–15W. That's your biggest payload hit after the camera. Budget it.

3. Frequency diversity matters. A single-band radio can be jammed with a single jammer. Multi-band radios (TrellisWare UHF+L+S in one device) are harder to deny.

4. Non-routing mesh > traditional routing. TrellisWare's Barrage Relay and batman-adv (Doodle Labs) both eliminate single-point-of-failure routing tables. The network heals when nodes die.

5. For DDG Phase II / contested environments: TrellisWare anti-jam C2 or Sine Engineering Pasika are the purpose-built solutions. Fiber-optic for maximum EW immunity at the cost of range flexibility.

6. Combat-proven > spec sheet. Sine Engineering's Pasika has been tested against Russian EW daily for years. That validation data doesn't appear on any data sheet.

Meshtastic — LoRa Mesh as a Telemetry Backbone

Meshtastic is an open-source project that turns cheap LoRa radios (typically ESP32-based, sub-$30) into a self-healing encrypted mesh network. It was designed for off-grid human communication, but the architecture maps directly onto drone telemetry requirements for GPS-denied or RF-contested operations.

Why It Matters for Drones

Commercial drone links (GHST, ELRS, Crossfire) are point-to-point. When the GCS moves out of line-of-sight or the primary link is jammed, you lose everything. Meshtastic offers a different failure mode: packets route through whatever mesh nodes are still alive. A swarm of drones, each carrying a Meshtastic node, effectively forms its own relay network — each aircraft extending range for every other aircraft and the GCS.

Bandwidth is the constraint. Meshtastic at LoRa long-range settings moves roughly 1–5 kbps. That's enough for MAVLink heartbeat, GPS position, battery voltage, and flight mode — the minimum viable telemetry set — but not enough for video, high-rate sensor data, or fast command loops. Think of it as the backup nervous system, not the primary one.

AkitaEngineering Pattern (DroneBridge32 + Meshtastic)

The AkitaEngineering Meshtastic-Integration-for-DroneBridge32-Swarm project (GitHub, GPL-3.0) demonstrates the integration architecture: Arduino C++ on DroneBridge32 parses MAVLink from the FC, encrypts the telemetry payload with AES, and transmits over Meshtastic. Python ground station plugins receive, decrypt, display, and send control commands back. The project also implements geofencing at the mesh layer (drone enforces a fence independent of FC), dynamic channel switching based on link quality, and emergency landing commands that propagate through the mesh even under degraded conditions.

The code is a reference implementation, not production firmware — no versioned releases, minimal testing. But the architectural patterns are sound and directly applicable:

• MAVLink-over-Meshtastic bridge: parse MAVLink on the embedded side, serialize the essential fields, transmit over LoRa, reassemble on the GCS side and re-inject into Mission Planner or QGroundControl via UDP.
• Mesh-layer geofencing: the drone enforces its fence using its own GPS + the received boundary definition, independent of FC-level fence. This survives link degradation.
• Swarm broadcast commands: Meshtastic's broadcast addressing lets a single GCS message reach all nodes in the mesh simultaneously — useful for emergency stop, RTL, or mode change across a swarm.
• Dynamic channel switching: if interference is detected on the primary channel, both sides coordinate a channel hop through a pre-agreed fallback sequence.

Hardware

Any Meshtastic-compatible LoRa hardware works. The most drone-relevant options:

All run at 915 MHz (US) or 868 MHz (EU). LoRa is ISM band — no license required, but power limits apply. At maximum legal EIRP, reliable range in open terrain is 5–15 km depending on antenna and terrain.

Integration Pattern for Wingman/Command

For a Wingman swarm deployment, the recommended architecture is a dual-link stack: GHST (or ELRS) as the primary high-bandwidth link for normal operations, Meshtastic as the secondary low-bandwidth link for telemetry heartbeat and emergency commands. The Meshtastic node on each drone runs independently of the primary link — it has its own power rail, its own CPU, and its own antenna. A primary link failure leaves the mesh intact.

The MAVLink-over-Meshtastic bridge runs as a process on the companion computer (APB or VOXL 2), feeding MAVLink telemetry from the FC to the Meshtastic serial interface, and forwarding received commands from the mesh back to the FC.

DroneEngage — Cellular Telemetry at Scale

DroneEngage is the ArduPilot project's cloud companion software, running on Raspberry Pi and providing unlimited-range telemetry, video streaming, and fleet management over 4G/LTE/5G. It is the Linux successor to Andruav (the Android companion app) and is actively developed under the ArduPilot umbrella.

What It Does

A Raspberry Pi connected to an ArduPilot or PX4 flight controller via UART/USB becomes a DroneEngage unit. The Pi connects to the internet via a USB LTE modem or HAT, and from that point the drone is reachable from anywhere with a browser. The web client provides a full ground control station: MAVLink telemetry, gamepad control, video streaming, geofencing, and swarm management.

Key capabilities:

• Unlimited telemetry range — the link goes through the internet, so range is only limited by cellular coverage. Relevant for BVLOS operations.
• MAVLink forwarding — DroneEngage forwards MAVLink transparently to Mission Planner, QGroundControl, or any UDP endpoint. No change to existing GCS workflows.
• Video streaming — supports Raspberry Pi cameras and USB cameras. Stream from one or multiple cameras simultaneously.
• Swarm operations — control multiple drones from a single interface with synchronized missions and hierarchical formation management.
• RC Blocking / TX Freeze — a local field pilot can override remote control; TX Freeze holds throttle position for safe long-range cruise without active stick input.
• Independent geofencing — enforced at the companion computer level, independent of the FC's fence logic. Survives FC configuration changes.
• Air-gap server — self-hostable backend for operations where cloud dependency is unacceptable (contested environments, classified sites, comms-restricted areas).

Hardware

DroneEngage runs on Raspberry Pi Zero W, Zero 2 W, Pi 3, 4, or 5. Weight matters:

The 42g complete-system figure for the Zero W is notable — it's competitive with dedicated telemetry radios when you factor in that you're also getting cloud connectivity, geofencing, and swarm management in the same package.

Andruav (Legacy Android Path)

Andruav is the predecessor: an Android phone running as a companion computer, connected to the FC over USB serial. The phone provides GPS, camera (FPV), cellular telemetry, and SMS-based control as a fallback. It's simpler to deploy for rapid prototyping — tape a phone to the airframe, connect USB, install the app — but less capable than DroneEngage for serious operations. Active development has shifted to DroneEngage; Andruav is maintained for existing deployments.

Air-Gap Deployment

For operations where cloud routing is off the table, DroneEngage supports a self-hosted server that can run on a Raspberry Pi 4 at the GCS site. All drone-to-GCS traffic routes through this local server rather than ArduPilot's cloud infrastructure. The protocol and security model are identical — the only change is the server endpoint. This makes DroneEngage viable for classified programs, contested environments, and locations with unreliable internet.

Integration with Command

DroneEngage's swarm logic and its air-gap server are directly relevant to Command's architecture. The hierarchical swarm formation model (lead drone + subordinates, commands propagate through the tree) maps to CBBA task allocation with a broadcast command layer on top. The air-gap server pattern is exactly what Command needs for field-deployable C&C without cloud dependency. The DroneEngage communication protocol is documented (see ArduPilot cloud docs) and could serve as a reference or direct integration point for Command's GCS-to-swarm link.

Last updated: March 2026

OpenHD — Open-Source Digital Video Link

OpenHD is the open-source answer to DJI O3, Walksnail Avatar, and HDZero. Instead of proprietary hardware running a proprietary protocol, it puts commodity RTL8812AU WiFi adapters into a one-way broadcast mode (wifibroadcast) that behaves like an analog video transmitter — no association handshake, no ACK, just raw packets into the air. The result is a long-range digital HD video link built from hardware you can source on AliExpress for under $50 total.

The suite transmits HD video, two-way UAV telemetry, two-way OpenHD telemetry (settings, range adjustments, channel changes, wifi modulation), and RC control signals — all multiplexed over a single RF channel, using MAVLink for the telemetry layer. The world record stands at 55km on a fixed-wing platform.

Why It Matters

Commercial HD video links (DJI O3, HDZero, Walksnail) cost $150–400 for the air unit alone, lock you into specific cameras, and ship from China. OpenHD costs $15–30 for the air unit, works with any CSI camera your SBC supports, and is open source down to the driver level. For teams that need HD video over ranges where commercial links won't reach, or who can't use Chinese-manufactured hardware, OpenHD is the practical path.

It's also the only digital FPV link where you can inspect and modify every layer of the stack — from the WiFi driver to the video codec to the OSD renderer.

How Wifibroadcast Works

Standard WiFi requires both ends to associate before exchanging data. That association process adds latency and creates a hard cliff at range — when signal degrades below the association threshold, the link drops entirely. Wifibroadcast bypasses association entirely. The air unit injects raw 802.11 frames directly into the driver; the ground unit captures all frames promiscuously regardless of source. This is the same transmission model as analog video: signal degrades gracefully with distance rather than falling off a cliff. FEC (forward error correction) across multiple packets replaces the ACK mechanism, so isolated packet loss doesn't corrupt the stream.

Hardware Stack

Air unit (minimum): Raspberry Pi Zero 2 (not the original Zero 1 — not supported), a dedicated BEC for the WiFi adapter, and a supported camera with the 22-pin type B CSI cable. The WiFi adapter must be soldered to the SBC's USB pads — vibration will disconnect any plug-in connection.

Air unit (better): Raspberry Pi CM4 with Ochin CM4 carrier board, plus a supported WiFi card. The CM4 enables dual camera, better thermal performance, and lower latency.

Ground station: A laptop with SecureBoot disabled, plus a supported WiFi adapter. X86 performance matters — faster hardware means lower decode latency. For lowest latency ground decode, a Radxa Rock 5 is the current recommendation — it hardware-encodes H.265 in real time.

WiFi adapters:

Supported chipsets: RTL8812AU, RTL8814AU, RTL8811AU, RTL8812BU, RTL8812EU. Top picks: ALFA AWUS036ACH (500mW, 8812AU, 2× RP-SMA), ASUS USB-AC56 (500mW, 8812AU, widely available), "Taobao card" (generic 8812AU, 500mW, 2× u.fl). Most users prefer 5.8GHz — cleaner spectrum than 2.4GHz and no interference with 2.4GHz RC transmitters. 5.8GHz does not offer better penetration but has cleaner channels in most operating environments.

The BLM8812EU is the newest and most capable chipset — higher sensitivity and better power output — but has no FCC/CE certification so import and use are at the operator's discretion.

Latency

Lowest latency requires OpenHD custom hardware (purpose-built SBC + camera combination), which can cut latency roughly in half compared to standard configurations. Second-lowest is achievable with the Radxa Rock5 on both air and ground. RPi Zero 2 builds have higher latency — usable for FPV but not competitive with commercial HD systems on this metric.

Practical glass-to-glass latency numbers for RPi-based builds: 100–150ms depending on resolution, codec, and SBC (OpenHD states "100ms glass-to-glass, most setups in the 125ms range"). Custom hardware targets sub-40ms. Rock5 sits between the two — hardware H.265 encode gives meaningfully lower latency than RPi.

Security

OpenHD provides link encryption with verification, ensuring the link cannot be overtaken by external signals. This is configurable through QOpenHD settings.

Dual Camera + Picture-in-Picture

OpenHD supports two CSI cameras simultaneously — typically forward view + downward/thermal. The ground station displays both via an adjustable picture-in-picture overlay in QOpenHD. Supported camera types include libcamera, veye, raspivid, USB, thermal, and unmanaged cameras.

MAVLink Integration

OpenHD passes MAVLink telemetry transparently over the wifibroadcast link. The air unit connects to the FC via UART (same as any telemetry radio — standard MAVLink port configuration). On the ground, QOpenHD receives and displays the telemetry, and also forwards the MAVLink stream over UDP so Mission Planner or QGroundControl can connect simultaneously. This makes OpenHD a functional telemetry radio replacement, not just a video link.

Integration with Wingman / Buddy

QOpenHD's Android app receives the ground station video and telemetry stream over WiFi or USB. For Wingman deployments, this means:

• Buddy can consume the MAVLink UDP stream from the OpenHD ground station without any modification to the existing telemetry pipeline — it connects as a second MAVLink client on the same forwarded stream.
• The video stream can be pulled via RTSP or UDP from the ground station and displayed in Buddy's live view alongside the GCS data.
• OpenHD's RC passthrough can operate alongside dedicated GHST/ELRS links — video and telemetry over OpenHD, high-rate control commands over the primary link.

Range Realities

55km is the record under ideal conditions — fixed-wing platform, high-gain directional antennas with tracker, line of sight, quiet spectrum.

Stock antennas (dipoles that come with the adapter): 1–3km. This is what OpenHD's own FAQ states. Do not expect more without upgrading antennas.

With upgraded ground antenna (14dBi panel + tracker): 8–15km. OpenHD's Friis calculation: 14dBi panel / 5dBi omni at 5.2GHz 200mW = 8.2km theoretical.

With high-gain ground antenna (17–23dBi + tracker): 15–20km+. Their calculation: 17dBi planar / 5dBi omni at 5.8GHz 500mW = 16.4km theoretical.

The range comes from the antenna, not the radio. See the Antennas chapter (Ch. 3) for the full breakdown of what antennas the OpenHD community uses and how antenna trackers work.

WiFi Adapter Diversity

OpenHD supports RX diversity — two WiFi adapters on the ground, one omni + one directional, with per-packet best-signal selection. However, do not mix chipsets or vendors for diversity (e.g. don't combine RTL8812AU with RTL8812BU). Use the same chipset on both ground adapters. New users should start with a single adapter and add diversity later.

See also: OpenHD Implementation Guide — step-by-step from hardware to first flight

OpenIPC — IP Camera Firmware for FPV

OpenIPC is the other major open-source digital FPV system, taking a fundamentally different approach from OpenHD. Instead of using a Raspberry Pi as the air unit, OpenIPC reflashes cheap IP camera boards ($15–30) and turns them into FPV video transmitters directly. The IP camera's SoC has a dedicated hardware video encoder, so you get lower latency (80ms at 1080p60) and dramatically lower power consumption (1.7W vs RPi's 5–10W) without a separate encoding step.

How It Differs from OpenHD

Supported Hardware

The firmware runs on SoCs from HiSilicon, Goke (GK7205V200 — most common for FPV), SigmaStar (SSC338Q — recommended for new builds), Ingenic (T31), and several others. WiFi adapters: RTL8812AU and RTL8812EU (same as OpenHD). The community recommends buying adapters from the same batch in pairs.

For ground stations, OpenIPC supports SBC-based receivers (RunCam WiFiLink-RX, Emax Wyvern Link, Radxa Zero3) and PixelPilot — an Android app for Snapdragon devices that also works on Meta Quest VR headsets.

Key Software

• Majestic — the primary video streamer (replaces GStreamer on the IP camera SoC)
• WFB-NG — wifibroadcast next generation, the RF transport layer
• divinus — open-source multi-platform streamer alternative (MIT, 62★)
• smolrtsp — lightweight RTSP server library (MIT, 427★) — useful for any embedded video streaming
• ipctool — identifies unknown IP camera hardware (SoC, sensor, flash chip)

When to Choose OpenIPC over OpenHD

Choose OpenIPC when weight and power are critical (sub-250g builds, long-endurance fixed wings), when you want the lowest possible latency for FPV racing/freestyle, or when you need night vision on a budget (IMX307 sensor with F0.95 lens). Choose OpenHD when you want easier setup, broader ecosystem support, or need features like dual camera PiP and RC control over the same link.

Important: Military Use Prohibited

OpenIPC's license (MIT) includes an explicit restriction: "The use of the OpenIPC project and its components for military purposes is not permitted." This is not a standard MIT clause — it's a project-specific addition. If your use case involves military or defense applications, OpenHD (GPL-3.0, no military restriction) or a commercial solution is the appropriate path.

Repository: github.com/OpenIPC (1.9K★, 120 repos, MIT)

Companion Computers — When the FC Isn't Enough

Part 6 — Components When you need AI, computer vision, SLAM, or ROS on a drone, you add a companion computer. This is the compute layer between the flight controller and intelligence.

When You Need One

A flight controller runs the stabilization loop — PID control, motor mixing, sensor fusion for attitude. It doesn't run neural networks, process camera feeds, execute ROS nodes, or make autonomous decisions beyond basic waypoint navigation.

When your mission requires object detection, visual-inertial odometry, SLAM, AI-driven analysis, swarm coordination, or onboard data processing, you need a companion computer.

The companion computer talks to the FC over MAVLink (UART or Ethernet) and handles everything the FC can't.

ModalAI — The Blue UAS Standard

ModalAI holds 16 Blue UAS Framework listings — more than any other single manufacturer. Their VOXL 2 platform is the reference companion computer for PX4-based autonomous drones.

VOXL 2