Abstract
This paper presents a controlled empirical study of face recognition under realistic UAV deployment constraints. We combine a live UAV streaming pipeline with a benchmark framework that fixes the detector, preprocessing, gallery construction, and similarity metric while varying only the recognition model. Seven pretrained recognizers, ranging from a 1.1M-parameter SFace model to a 65M-parameter ArcFace-R100 model, are evaluated under a simulated 400 MHz single-core CPU and 128 MB inference-memory budget on the DroneFace dataset, with VGGFace2 used as a generalization probe. We also report per-altitude, per-distance, and per-gender breakdowns. Three findings emerge. First, MobileFaceNet achieves 92.74% accuracy at 16.7 ms latency (59.7 FPS), within approximately three percentage points of the accuracy-best ArcFace-R50 model while running about 39× faster. Second, training-distribution alignment can be as important as architectural capacity: FaceNet performs best on VGGFace2 but degrades substantially on DroneFace, while ArcFace-based models show stronger performance under aerial conditions. Third, CPU-frequency scaling is non-uniform, with mid-weight models benefiting more clearly than very light models dominated by runtime overhead or very heavy models dominated by compute saturation. These results identify MobileFaceNet as the most practical deployment choice under the simulated UAV constraint, and live re-validation on 17 edge-case streaming clips preserves the Phase 2 ranking while exposing a sharp drop in absolute accuracy attributable to threshold-gated matching and to specific lighting and geometry cases.
Demo
Live demo: the drone streams video to a laptop while a constrained “drone-side” worker runs UltraFace + MobileFaceNet, raising intruder alerts on recognized faces across altitudes, angles, and edge cases.
A three-phase study
Build a real live pipeline, rank recognizers fairly under a simulated drone budget, then plug the winners back in to see if the ranking survives the real stream.
Live deployment pipeline
Hula drone → RTP stream → laptop. Detection and recognition run in an isolated “drone-side” subprocess with a depth-1 drop-old frame queue, so inference always sees the newest frame. Alerts, snapshots, and optional tracking with per-identity cooldowns.
bubulean/drone_project →Controlled benchmark harness
UltraFace detector, preprocessing, gallery, and cosine metric fixed; only the recognizer changes. Single-core affinity, duty-cycle CPU throttling to 250/400/650 MHz, and a hard 128 MB RSS-delta kill switch.
jennakhanfar/IOT-DRONE-PROJECT →Live re-validation
The top two benchmark models (MobileFaceNet, ArcFace-R50) are replayed through the live pipeline on 17 edge-case clips: hijab, glasses, mask, steep overhead and side angles, near-dark, harsh sun.
edge-case clips →Key findings
MobileFaceNet is the practical winner
92.74% on DroneFace at 16.7 ms (59.7 FPS), within ~3 points of ArcFace-R50 (95.75%) while running ~39× faster, using under 3% of its parameters and ~0.2 MB of inference memory.
Training distribution matters as much as capacity
FaceNet wins on VGGFace2 (93.33%, its own training set) but drops to 78.37% on DroneFace; ArcFace variants show the opposite pattern. Evaluate on data from the deployment distribution.
CPU frequency is not a universal lever
Only mid-weight models (ArcFace-R18, FaceNet) speed up from 250→650 MHz. Tiny models are dominated by runtime overhead; heavy ones are compute-saturated. Architecture is the primary deployment decision.
Live streaming exposes a threshold problem
The benchmark ranking holds live, but absolute accuracy collapses (92.74% → 23.5% for MobileFaceNet). The dominant live failure is a similarity-below-τ “Unknown” miss, not identity confusion, so the threshold is the next knob to tune.
Results
Accuracy vs. latency on DroneFace
400 MHz single-core, 128 MB budget. Latency on a log scale; up and to the left is better.
Recognition performance on DroneFace (400 MHz / 128 MB)
| Model | Params | Acc. (%) | Latency (ms) | P95 (ms) | FPS | Size (MB) | ΔRAM (MB) |
|---|---|---|---|---|---|---|---|
| ArcFace-R50 | 43.6 M | 95.75 | 659.2 | 902.6 | 1.5 | 166.3 | 14.2 |
| ArcFace-R100 | 65.0 M | 93.18 | 1152.5 | 1393.3 | 0.9 | 248.6 | 12.5 |
| MobileFaceNet | 1.2 M | 92.74 | 16.7 | 29.7 | 59.7 | 13.0 | 0.2 |
| ArcFace-R18 | 12.4 M | 86.80 | 55.2 | 81.9 | 18.1 | 91.8 | 9.2 |
| FaceNet | 27.9 M | 78.37 | 261.4 | 336.2 | 3.8 | 106.8 | 12.6 |
| FaceNet-CASIA | 28.9 M | 74.85 | 241.1 | 328.0 | 4.1 | 110.6 | 13.8 |
| SFace | 1.1 M | 56.96 | 109.1 | 172.5 | 9.2 | 36.9 | 0.2 |
ΔRAM is the peak inference-time memory delta enforced against the 128 MB budget. ArcFace-R100’s 248 MB weights exceed the drone’s total RAM by construction.
Generalization: DroneFace vs. VGGFace2
Accuracy (%) at 400 MHz. The model that wins on generic faces is not the one that wins from the air.
Accuracy (%) by subject distance on DroneFace
MFN = MobileFaceNet. Darker cells are higher accuracy. FaceNet collapses beyond ~10 m; only the heavy ArcFace models hold up at 16 m.
Accuracy (%) by drone altitude
Latency (ms) vs. CPU target
| Model | 250 | 400 | 650 MHz |
|---|---|---|---|
| ArcFace-R100 | 1092.3 | 1152.5 | 1126.2 |
| ArcFace-R50 | 615.7 | 659.2 | 624.6 |
| FaceNet | 298.9 | 261.4 | 221.3 |
| FaceNet-CASIA | 282.8 | 241.1 | 223.2 |
| SFace | 105.9 | 109.1 | 103.2 |
| ArcFace-R18 | 64.4 | 55.2 | 55.6 |
| MobileFaceNet | 24.3 | 16.7 | 19.5 |
Phase 3: benchmark vs. live streaming
| Recognizer | Phase 2 acc. | Live acc. | Live acc. (face detected) | Live latency (ms) | Phase 2 FPS | Live FPS |
|---|---|---|---|---|---|---|
| MobileFaceNet | 92.74% | 23.5% | 34.0% | 74.8 | 59.7 | 13.4 |
| ArcFace-R50* | 95.75% | 28.4% | 39.4% | 307.3 | 1.5 | 3.3 |
*ArcFace-R50 needed the simulated RAM cap raised from 128 MB to 512 MB to load its 166 MB ONNX, so it is a memory-relaxed reference rather than a deployable candidate. Live matching is thresholded best-match with an explicit Unknown outcome, which is stricter than Phase 2’s closed-set nearest-centroid rule.
Limitations & future work
- The hardware budget is simulated with an x86 duty-cycle throttle, so latencies are good for ranking but not cycle-accurate for a real onboard processor. Next step: deploy MobileFaceNet on a physical ARM target.
- DroneFace has only 11 identities (7 male, 4 female), so per-gender gaps may reflect individual subjects rather than systematic bias, and it has no skin-tone, head-covering, or weather annotations.
- The live clip catalogue has no unknown-only clips, so false-alarm rate is not yet measured. A per-environment τ sweep is the natural next experiment.
Code
bubulean/drone_project
Live drone application: Hula stream handling, drone-side inference worker, pluggable detectors, alerts, tracking, edge-case clips, and live evaluation tools.
jennakhanfar/IOT-DRONE-PROJECT
Benchmark harness: drone-constraint context (CPU affinity, throttle, RSS kill), seven-model sweep orchestrator, result aggregation, and compression experiments.
Citation
@techreport{alghfeli2026dronevision,
title = {Design and Evaluation of a Low‑Latency Drone‑Based Vision System},
author = {Alghfeli, Alyaa and Almulla, Buthaina and Utemissova, Dilnaz
and Khanfar, Jenna and Yaqoob, Shamma},
institution = {Mohamed bin Zayed University of Artificial Intelligence},
address = {Abu Dhabi, United Arab Emirates},
year = {2026}
}