The FCC public notice landed on December 22, 2025, and the OEM calls that followed taught me something I should have said more clearly from the start: clearing an airframe for procurement and clearing an autonomy stack for GPS-denied operations are different problems. The first has a list—the Blue UAS Cleared List, now more than 50 platforms managed by DCMA's US-X command after its December 2025 transfer from DIU. The second has twelve to twenty-four months of engineering in it, and no list is going to change that.
Why I Stopped Calling It a GPS Backup Problem
I used to describe GPS-denied navigation as a backup system question—what does the drone do when GPS degrades? The Ukrainian front-line data that IEEE Spectrum and other reporting documented through 2024 and 2025 forced me to retire that framing. Russian R-330Zh Zhitel jammers now extend GPS denial across 30-kilometer bubbles along the front line, and the operational response wasn't "activate the backup." It was "remove GPS from the architecture entirely." Front-line Ukrainian operators now ship FPV frames without GPS receivers because the satellite signal is no longer assumed to be present.
More than 50% of Ukrainian FPV drones are reported downed by electronic warfare, with some units reporting 31% sortie loss rates. That data isn't an argument for more GPS-resistant receivers. It's an argument for an autonomy stack that never assumed GPS in the first place.
GPS-denied navigation isn't a backup mode. For drone programs in contested environments—or underground, or beneath steel infrastructure—it's the baseline operating assumption the stack should be designed around from day one.
What that means technically is Visual Inertial Odometry (VIO) as the primary navigation source, not a fallback. VIO uses a calibrated stereo camera and inertial measurement unit to compute position without any external reference: no GPS, no radio, no landmark database. The physics that make GPS unreliable in jammed environments, mine shafts, or urban canyons don't touch VIO. The limitations of VIO—calibration, compute, library licensing—are engineering problems, which means they're solvable in a way that jamming countermeasures largely aren't.
The $1 billion per day that NIST and RTI International estimated as the US economic cost of a GPS service outage captures financial markets and logistics infrastructure. It undersells what a mining operator loses when a drone that can't navigate without GPS puts itself into a rib wall on its first underground flight.
The Procurement Question I Kept Getting Wrong
My first instinct after the FCC action was to map the cleared inventory and help OEM contacts understand what DA 25-1086 meant for their procurement pipeline. Every foreign-made UAS and UAS critical component in one sweeping action—not just DJI and Autel as the NDAA (National Defense Authorization Act) had specified, but every foreign manufacturer at once. The Army's $52 million award for 2,500 Skydio X10D drones—the largest single-vendor small UAS contract in Army history, closed bid-to-award in under 72 hours—made the scarcity of GPS-denied capable platforms legible in a way no report had.
The conversations that followed, though, weren't about finding the right cleared frame. They were about what autonomy payload would make the frame function in the environment the contract actually called for. Whether a Freefly Astro Blue, ModalAI Starling 2, or Anduril Ghost-X could navigate GPS-denied underground mine shafts or hold station in a GPS shadow under a steel bridge depended entirely on what was wired onto them—and whether it had been calibrated for those specific conditions. The cleared-inventory question and the autonomy-stack question kept getting conflated in those early calls, and the conflation was costing programs time.
The conversations that became productive were the ones where I stopped leading with airframes and started leading with the operational environment: "Where does your drone need to fly when GPS isn't available?" is a different scoping question than "which cleared platform fits your procurement?"
What a Drone Crash Taught Me About Calibration
The first GPS-denied integration we shipped had a timestamp synchronization gap between the IMU and the stereo camera that was too small to surface in bench testing. It surfaced on an early operational flight in conditions confined enough to accumulate position error fast—the IMU noise double-integrated to meter-level drift within thirty seconds. The airframe didn't reach its waypoint.
I had not thought of calibration as a deliverable before that engagement. I had thought of it as a setup step. The operator's view afterward was direct: the calibration scope had been ours, so the calibration failure was ours. Which was correct, and which changed how we structure every integration that followed.
The correction was hardware-synchronized timestamp verification across the specific sensor mount on the specific airframe, against datasets drawn from the actual deployment environment—not bench synthetic data. That's now the first milestone on any engagement. Not the SLAM library selection, not the compute sizing, not the autopilot integration. Calibration first, because loop closure quality, position accuracy, and semantic object avoidance all depend on it.
The timestamp gap between IMU and stereo camera doesn't surface on a bench. It surfaces in the operational environment, on the flight that matters.
TensorRT INT8 quantization came out of the same engagement. Getting SuperPoint feature extraction from 7 frames per second—baseline PyTorch on the Jetson Orin NX at 100 TOPS—to the 28-plus FPS that stable position hold requires meant INT8 quantization, which meant a calibration dataset for the quantization pass itself. The dataset we'd built from KITTI road sequences performed well in testing. Underground, it didn't. We rebuilt the calibration dataset from mine shaft imagery and the model worked. The lesson: the deployment environment, not the benchmark dataset, is what the quantization calibration dataset needs to reflect.
The License Nobody Checks Until Week Eleven
I was partway through a SBIR (Small Business Innovation Research) Phase II final deliverable review when the program officer's counsel asked whether the SLAM library was GPLv3-compatible with our closed-source deliverable. I looked across the table at the team and none of us had a prepared answer. We had built the architecture on ORB-SLAM3—strong benchmarks, well-documented, the most widely cited visual SLAM library in the autonomy literature. Also GPLv3, which is incompatible with commercial closed-source products that ship it as a linked library.
Most defense OEM teams I've spoken with since have discovered the same thing in roughly the same week of a delivery cycle—late, when switching SLAM libraries is an architectural change rather than a swap. The alternatives aren't worse; they just require earlier decisions. NVIDIA Isaac ROS cuVSLAM is free, GPU-accelerated, Jetson-optimized, and carries no commercial license constraints. VINS-Fusion ships under Apache 2.0. A SuperPoint front-end under a permissive license—where the recent arXiv work (SuperPoint-SLAM3) shows translational error dropping from 4.15% to 0.34% on KITTI, a 12x improvement over ORB-SLAM3—requires the TensorRT optimization work but delivers meaningfully better feature matching in low-texture environments.
This isn't the integration layer that Shield AI's Hivemind autonomy infrastructure addresses—that's a full-stack program at a different scale, and Auterion's PX4-based platform (which supplied 33,000 Skynode AI strike kits to Ukraine under a $50 million Pentagon contract) occupies a different position entirely. What I'm describing is the sub-prime integration work for OEMs and defense primes who have the frame and the contract but not the autonomy team. We built Veriprajna's GPS-denied drone autonomy stack to start with a license-and-compute audit before any SLAM library selection, specifically because the week-eleven discovery pattern is predictable enough to be preventable.
The Math That Closes When You Talk to Operators
When I need to make the commercial case without a defense procurement context, I reach for two numbers. LKAB's Kiruna iron ore operation went from eight-hour manual stope inspections to 20-minute Flyability Elios 3 flights. A manual survey crew costs thousands per day; the drone covers the same volume in 30 minutes to two hours. The constraint on that ratio is whether the drone can hold station in GPS-denied airspace—and a drone that crashes on its first underground flight because VIO wasn't calibrated for dark, low-texture conditions costs $10,000 to $50,000 in hardware replacement before you account for the program delay. For operators who can't justify a full Emesent Hovermap ST-X deployment, a calibrated autonomy retrofit on existing frames is the calculation that closes.
The other number: a single oil and gas pipeline failure runs $8.5 million in cleanup, regulatory penalties, and remediation, against $75,000 for a routine drone inspection. That ROI only exists if the drone can hold station in a GPS shadow beneath a steel bridge. A non-autonomous drone in GPS denial doesn't complete that inspection.
The operators who came to us earliest had already crashed something expensive. I find the conversation after a total-loss first flight is simpler than the one before: calibration, licensing, compute—these stop being abstract once they've been associated with a specific loss event.
If you're navigating a Blue UAS autonomy payload selection, a SBIR scope where GPS-denied nav is a key performance parameter, or an inspection retrofit that stalled at a drone loss—Veriprajna's GPS-denied drone autonomy work covers what we've built across those environments. The question worth asking before committing to a SLAM library, though, is which calibration dataset your deployment environment actually requires. That answer is specific enough to be worth a scoping conversation before the architecture is locked.