MBZUAI · IoT Course Project · 2026

Design and Evaluation of a Low‑Latency Drone‑Based Vision System

Alyaa Alghfeli Buthaina Almulla Dilnaz Utemissova Jenna Khanfar Shamma Yaqoob

Mohamed bin Zayed University of Artificial Intelligence, Abu Dhabi, UAE

92.74%MobileFaceNet accuracy on DroneFace
16.7 msper-face latency at 400 MHz (59.7 FPS)
~39×faster than accuracy-best ArcFace-R50
7recognizers, 1.1 M → 65 M params

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.

Phase 1

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 →
Phase 2

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 →
Phase 3

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 →
Drone camera H.264 / RTP Frame queue depth 1, drop-old SIMULATED DRONE CPU · 400 MHz · 1 core · 128 MB UltraFace 320×240, NMS Recognizer swappable ×7 Gallery cosine, τ = 0.3 Action layer alert · snap · track 112×112 crop → L2-normalized embedding

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)

ModelParamsAcc. (%)Latency (ms)P95 (ms)FPSSize (MB)ΔRAM (MB)
ArcFace-R5043.6 M95.75659.2902.61.5166.314.2
ArcFace-R10065.0 M93.181152.51393.30.9248.612.5
MobileFaceNet1.2 M92.7416.729.759.713.00.2
ArcFace-R1812.4 M86.8055.281.918.191.89.2
FaceNet27.9 M78.37261.4336.23.8106.812.6
FaceNet-CASIA28.9 M74.85241.1328.04.1110.613.8
SFace1.1 M56.96109.1172.59.236.90.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.

DroneFace VGGFace2

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

Model250400650 MHz
ArcFace-R1001092.31152.51126.2
ArcFace-R50615.7659.2624.6
FaceNet298.9261.4221.3
FaceNet-CASIA282.8241.1223.2
SFace105.9109.1103.2
ArcFace-R1864.455.255.6
MobileFaceNet24.316.719.5

Phase 3: benchmark vs. live streaming

RecognizerPhase 2 acc.Live acc.Live acc. (face detected)Live latency (ms)Phase 2 FPSLive FPS
MobileFaceNet92.74%23.5%34.0%74.859.713.4
ArcFace-R50*95.75%28.4%39.4%307.31.53.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

Code

Phases 1 & 3

bubulean/drone_project

Live drone application: Hula stream handling, drone-side inference worker, pluggable detectors, alerts, tracking, edge-case clips, and live evaluation tools.

Phase 2

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}
}