TL;DR — Drones can't phone home to a cloud GPU mid-flight, so open-weight vision models running on tiny onboard computers like the Jetson Nano are doing the real work: spotting missing persons, cracks in bridges, and rows of crops. A recent study got a YOLOv5 variant to 0.802 mAP@50 on search-and-rescue imagery while holding 1-2 FPS on 4GB of Jetson memory — proof that open weights, not cloud APIs, are what actually flies.
A drone circling a flooded valley looking for a stranded hiker has maybe a few hundred milliseconds to decide whether that gray shape in the mud is a person or a rock. There's no cloud round-trip in that budget. Whatever intelligence the drone has, it has to carry with it — on a board the size of a deck of cards, running off a battery that's already busy keeping four motors spinning. This is where open-weight AI quietly does its most physically constrained work: not chatting, not writing code, just looking, fast, on hardware that fits in your palm.
The weight budget is literal
Every gram on a UAV competes with flight time, and every watt competes with motor draw. That's why the compute platform of choice for onboard drone AI keeps showing up as the same family of small boards. A 2025 study on UAV-based search and rescue ran its detection pipeline on an NVIDIA Jetson Nano with 4GB of RAM and a 128-core CUDA GPU, mounted on a Holybro X500 V2 quadrotor with a Pixhawk 6C flight controller — a build that's become almost a reference design in this space. The whole rig ran Ubuntu 18.04, JetPack 4.6, and CUDA 10.2, pulling video off a USB camera at 1080p/30fps through OpenCV. That's the actual weight class open models have to compete in: no data center, no burst GPU, just a small board sipping power from a dedicated 5V battery pack.
What the numbers actually say
The researchers took a YOLOv5s backbone and layered in architectural tweaks — enhanced feature fusion (FPN, BiFPN, PB-FPN), an extra detection head tuned for small objects, CBAM attention, and a lightweight deconvolution module — then trained it with a two-stage transfer strategy: general aerial detection on the VisDrone dataset, followed by fine-tuning on Heridal, a dataset built specifically for search-and-rescue imagery. The best configuration, YOLOv5s-PBfpn-Deconv, hit a mAP@50 of 0.802 on Heridal — a solid number for a task where the "object" is often a person-shaped smudge of ten pixels against forest canopy or floodwater. On the Jetson Nano itself, inference at 640×640 resolution averaged about 450ms per frame, roughly 2 frames per second including preprocessing and postprocessing. That sounds slow next to a data-center GPU chewing through hundreds of frames a second, but the authors' own benchmark for the mission was 1-2 FPS, because a search drone is usually hovering or scanning slowly, not racing. The model didn't need to be fast in absolute terms — it needed to be fast enough for how the aircraft actually flies.
Where this is actually flying
Strip away the demo footage and the deployments cluster around a few honest categories, each with its own constraint profile:
Search and rescue. Civil protection agencies need detection that survives cluttered backgrounds — wildfire smoke, flood debris, dense forest — and runs on hardware a volunteer team can actually afford and carry. The Heridal/YOLOv5 pipeline above was explicitly built for this: firefighters and civil protection operators get a ground-station GUI, not a Jupyter notebook, and the model has to work at altitude and in field conditions, not just on a clean validation set, per the MDPI study.
Infrastructure inspection. Bridges, transmission lines, pipelines, and solar farms get inspected by drones running defect-detection models onboard, catching cracks, corrosion, and thermal anomalies without sending a technician up a tower — a use case laid out in coverage of AI-powered autonomous drone inspection. The appeal here isn't raw accuracy so much as consistency: a model checks every meter of cable the same way, every time.
Obstacle avoidance and navigation. A broader vision-based learning survey for drones notes that image processing and flight control both run on the same onboard computer — commonly a Jetson, Intel NUC, or Raspberry Pi — while perception depends on whatever camera or sensor is bolted on. This is the layer that keeps a drone from flying into a wire, and it has to run continuously, not just when someone points a camera at something interesting.
Delivery and anomaly classification. Simpler commercial builds lean on established detectors like YOLO or SSD for object detection and classification tasks during delivery or inspection runs, as described in applied work on drone inspection and delivery systems — less exotic than SAR, but it's where a lot of the actual commercial deployment volume lives.
The honest pattern across all of these: open-weight YOLO variants, not massive multimodal models, are doing the flying today. The constraint isn't model quality, it's the power and memory budget of a board that also has to leave room for flight control, telemetry, and a camera driver.
The language layer is still on the runway
The more speculative frontier is giving drones a language interface — describing a mission in plain English and having the aircraft translate that into a flight plan. Coverage of this direction points to 2024 research exploring LLMs for interpreting high-level human instructions into UAV mission plans, but it's worth being precise about where this stands: that's mission planning and instruction parsing, largely happening before or alongside flight, not a language model doing real-time obstacle avoidance at 30fps on a Jetson Nano. The vision models are the ones actually airborne and load-bearing today; the language layer is the part still being prototyped on the ground.
What's genuinely missing
Nobody in this research pretends the problem is solved. The 450ms/frame result on Jetson Nano is explicitly flagged by its own authors as "not yet optimized for real-time operation" — a baseline, not a finish line. Multimodal sensor fusion (thermal, LIDAR, radar alongside RGB) and robustness across weather and lighting conditions are called out as open work in the same study. And older Jetson boards, running JetPack 4.6 and CUDA 10.2, are themselves a constraint — newer Jetson Orin-class hardware would change the math on frame rate, but that's a cost and weight trade-off every team has to make for itself, not a free upgrade.
Credits & sources
Detection accuracy figures, the Jetson Nano/Holybro X500 hardware setup, and inference timing come from the MDPI study on real-time search and rescue with drones. Background on onboard computers and vision pipelines draws from the arXiv survey on vision-based learning for drones. Infrastructure inspection use cases and the note on LLM-based mission planning research come from scientechworld.com's overview of AI-powered autonomous drones. Additional context on object detection in delivery and inspection systems is drawn from the IJCRT paper on drone inspection and delivery, with general AI-drone framing from Grepow's explainer on AI drones.
Tomorrow, the series follows open-weight AI off the planet entirely, into the very different weight and radiation budget of space.
Appendix — the field in one chart
Top comments (0)