Can Real-Time Drone Detection Run on the Edge?

Unmanned aerial vehicles are one of the defining hardware stories of the last decade, and the interesting frontier now isn't the airframe, and it's the intelligence you can cram onto it. Once you start bolting computer vision onto a drone, you hit a wall almost immediately: the models that detect and track objects reliably are hungry, and the compute you can carry on a small aircraft is not. Everything downstream including, vision-driven swarming, collaborative sensor fusion, autonomous target following, that depends on solving that tension between what the model wants and what the battery and the board can give. That's exactly the tension this paper interrogates. Rather than proposing a new architecture, the authors run a comparative performance analysis of a representative real-time UAV image-processing pipeline across several edge devices. As someone who spends a lot of time on the deployment side of this problem, I find that framing more useful than yet another benchmark chasing a fraction of a mAP point. The full paper is worth reading in its own right: arXiv:2502.15737. A quick note on YOLO (and where it stands in 2026) YOLO, aka "You Only Look Once," is the object detector most people reach for first, and for good reason: it's a single-stage, real-time architecture that's become the default for visual detection work. When this study was run, YOLOv8 and YOLOv10 were the workhorses in the field, and that's what the authors used. Worth flagging for anyone reading this in 2026: the family has moved on fast. Ultralytics shipped YOLO11 in late 2024, YOLOv12 and YOLOv13 through 2025, and YOLO26 in January 2026, the last of which is specifically engineered for edge deployment, with native NMS-free end-to-end inference that removes a post-processing step known to bottleneck latency on constrained hardware. That's directly relevant here: a study that concludes YOLOv8 is viable on a Jetson Orin is, if anything, a conservative floor now. If you're standing up a pipeline like this today, the newer NMS-free models are the obvious starting point. You can pull any of them from the Ultralytics repo. Why edge devices are the hard part There's a body of prior work chasing the optimal hardware configuration that balances inference speed, energy consumption, and real-time processing, and a lot of it evaluated on individual boards like the Jetson Nano or AGX Xavier. What the authors point out, correctly, is that most of that work looks at devices in isolation, when the real deployment questions are architectural and comparative. It's one thing to know a board can run YOLO; it's another to know how three candidate boards trade off against each other under a workload that actually resembles flight. The methodology: three boards, one model The study picks three single-board computers deliberately spread across the price-performance curve: Raspberry Pi 5: the low-cost, CPU-bound baseline NVIDIA Jetson Orin Nano: entry-level GPU acceleration NVIDIA Jetson Orin NX: the higher-end edge option All three run YOLOv8. The spread is the point: you're not looking for a winner so much as a curve you can reason about when you're spec'ing your own payload. Building the dataset The first step was data. The team assembled 6,000 aerial images of targets at varying positions relative to the drone's field of view, flying the drones along both linear and diagonal paths to capture a range of viewing angles, then hand-annotating the set. That annotated dataset became the foundation for training and evaluating the detector inside the YOLO pipeline. The test setup This is the part I like most. The experiments run in an indoor room deliberately cluttered with furniture to introduce visual complexity. Inside it, a fleet of DJI Tello drones flies overhead while a fleet of TurtleBot ground robots plays the role of the targets to be detected from the air. The Tellos' onboard cameras feed the platform, and crucially, an OptiTrack motion-capture system provides high-accuracy, high-speed ground-truth positioning for everything in the room. That OptiTrack rig is what separates this from a casual benchmark. When you have millimeter-grade ground truth for both the drone and the target, you can actually quantify detection error instead of eyeballing it. Training configuration The team narrowed to the two lightest YOLOv8 variants including YOLOv8s (small) and YOLOv8n (nano), because latency is the whole game on the edge. YOLOv8n is the fastest in the family; the "s" model carries more convolutional layers and feature-extraction stages, which buys accuracy at the cost of speed. That trade is the central lever anyone deploying on a drone ends up pulling. Training details, for the reproducibility-minded: Optimizer: AdamW, chosen for decoupled weight decay Learning rate: 0.002: fast convergence without tipping into divergence Weight decay: 0.0005 on most weights, biases excluded: regularizes toward smaller weights (more robust to noise) without penalizing parameters critical to feature representation The evaluation strategy The evaluation is staged, and the staging is the real contribution. Stage one runs in the controlled, isolated environment and measures the things you can only cleanly measure on a bench: Inference-time measurement Continuous-inference evaluation, inferences per minute (IPM) Energy-consumption analysis Stage two moves to a real-world scenario and measures the metric that ultimately decides whether the system flies: Throughput and latency under actual operating conditions Progressing from isolated testing to live deployment is exactly how I'd want an edge-vision claim substantiated. The isolated stage tells you what the hardware is capable of; the real-world stage tells you what survives contact with reality. For the actual numbers, the throughput, energy, and latency results per board and read the paper; I'm not going to reproduce or invent figures I can't stand behind here. The steelman: and where I'd push back I want to give this study its due and then be honest about the limits, because that's the useful part. The case for it: the experimental design is genuinely strong. Ground-truth motion capture, a staged bench-to-field methodology, a deliberate spread of hardware, and a workload built around real (if small) aircraft. As a template for how to evaluate an edge-vision pipeline honestly, it's better than most. Where I'd push back: it's a lab in a room. A furniture-cluttered indoor space with OptiTrack coverage is a controlled proxy for the messy conditions real drones fly in such as variable outdoor lighting, motion blur at speed, wind-induced camera shake, backgrounds far busier than a test lab, and targets that don't cooperate. The DJI Tello is a lightweight indoor trainer, not a payload-carrying outdoor platform, so the flight dynamics and camera characteristics won't fully transfer either. Detecting a TurtleBot from a slow indoor hover is a meaningfully easier problem than detecting an object from a drone maneuvering outdoors, and the throughput/latency numbers that hold in the room may not hold in the field. The second caveat is temporal: benchmarking YOLOv8 is reasonable, but the edge-detection landscape has shifted under it. The NMS-free designs in YOLOv10 and now YOLO26 directly target the post-processing latency that bites hardest on constrained boards and so a fair 2026 read is that this study establishes a conservative baseline, and the practical ceiling is now higher than what YOLOv8 shows. None of that diminishes the work. It just means the honest headline is "here's a rigorous way to measure edge-vision viability, demonstrated indoors," not "edge YOLO is solved for real flight." Those are different claims, and the gap between them is where the actual engineering lives. Why this sits close to what I build This paper lands right in the middle of a problem I keep circling: getting real autonomy onto small, cheap, power-constrained aircraft. Onboard detection is one piece; knowing where you are without GPS is another, which is why I've spent time on visual SLAM for autonomous UAVs. And the "can commodity hardware actually do this" question is the same one I chased when I started reverse-engineering a cheap RC drone to make it autonomous. Studies like this one are the connective tissue: they tell you which of the ambitions you sketch on a whiteboard the battery and the board will actually let you fly. If you're working the same edge-autonomy problem, the paper is here. I'd love to compare notes.