Nanodet Plus 1.5x Aerial 6cls

nanodet-plus-1.5x-aerial-6cls

17개 도시 × 두 가지 고도(10m/15m)의 한국 드론 항공 영상으로 전이학습된 NanoDet-Plus 모델. NanoDet-Plus fine-tuned on Korean aerial drone footage from 17 cities at 10m/15m altitudes.

Before vs After

코드·문서 전체 리포지토리: github.com/DeepMav/aerial-perception

---

버전 / Versions

버전	핵심 변경	청라10m	4-도메인 평균
v0.1	청라 10m 단일 (과적합)	30.1%	17.1% ⚠
v0.2	17 cities × 10m+15m	27.1%	28.9% (+69%)
v0.3 (Exp J)	4도메인 + hard-cap 샘플링	26.6%	28.5%
v0.4	고도층화 재샘플링	24.4%	29.2%
v0.5 (Exp B)	입력 416→640	29.3%	35.4%
v0.9 (Exp 960, current)	입력 640→960	34.1%	40.4% ✅

v0.9(입력 960)가 4개 도메인 전부에서 역대 최고입니다 (4-도메인 평균 v0.5 대비 +5.0pp, +14%). v0.5가 416→640으로 벽을 넘었던 것과 같은 방식으로, 640→960이 다시 한 번 네 도메인을 동시에 끌어올렸습니다. 게다가 이번에는 정확도와 오탐이 맞교환되지 않고 FPPI(이미지당 오탐 수)도 네 도메인 모두 감소했습니다.

✅ 현재 호스팅 가중치(.pth/.onnx)는 v0.9(입력 960) 기준입니다. 모든 수치는 동일 평가 파이프라인 측정값입니다. 같은 실행에서 v0.5를 재측정한 값이 기존 발표치(29.3 / 25.1 / 43.6 / 43.6)와 정확히 일치함을 확인했습니다.

i v0.6 (보류) — 타일 파인튜닝 + test-time SAHI, 음성 결과. 15m 고도 차량을 잡으려고 1024 타일로 v0.5를 파인튜닝한 뒤 SAHI 추론을 시도했습니다. vehicle recall은 회복됐으나 building 오탐이 폭증(FPPI ~24)해 종합 mAP가 v0.5 전체추론(0.417)을 넘지 못했습니다. px 게이팅은 vehicle과 structure 박스 크기 분포가 겹쳐 분리에 실패(오탐을 줄이면 차량도 동반 사망: vehicle recall 0.45→0.09). 결론: test-time SAHI 단독으론 부족 → 운용 가중치는 v0.5 유지. 진짜 이득은 train-time 타일링 + score 캘리브레이션이 필요(ROI 불확실).

i v0.7 (운용개선) — 나무 오탐 줄이기, 재학습 없음. 가중치는 v0.5 그대로이며 후처리만 개선했습니다. 나무 전용 NMS 중복제거(IoU 0.3) + 클래스별 score threshold로 4-도메인 전체 FPPI를 절반 이하로 감축(청라 8.4→3.7·택배 7.8→2.6·농약 5.0→2.2·용인하남 9.6→3.2), 나무 AP 변화 <1pp로 mAP 사실상 불변. 진단상 나무 FP는 위치오차/중복 + 그림자 환각 + 학습셋 라벨 희소(16.5%만 라벨)의 복합이라, negative-mining 파인튜닝은 보류하고 무료 레버로 운용점을 해결했습니다. 근본 해결(미라벨 나무 재라벨 후 재학습)은 향후 과제.

운용점 2종 (나무 threshold만 다름, 6/9 4-도메인 재측정). 같은 v0.5 가중치에 FP↔recall 트레이드오프를 골라 쓰는 후처리입니다 — F1레버(tree τ=0.325, 나무 recall 보존) vs 정밀레버(tree τ=0.40, FPPI 최저).

도메인	전체 FPPI (베이스→F1→정밀)	나무 FPPI	나무 recall
청라10m	8.43 → 3.65 → 2.21	4.41 → 2.14 → 0.69	18.0% → 13.5% → 5.6%
용인하남15m	9.55 → 3.19 → 3.19	0.01 → 0.00 → 0.00	(나무 GT 0)
택배15m	7.77 → 2.61 → 2.53	0.17 → 0.12 → 0.04	(나무 GT 0)
농약	5.00 → 2.20 → 1.87	0.93 → 0.55 → 0.23	46.7% → 39.7% → 27.3%

모델 [email protected](풀캐시, 레버 무관 불변): 청라 29.3 / 용인하남 25.1 / 택배 43.6 / 농약 43.6. ⚠️ 레버는 모든 클래스 τ를 0.3 위로 올리는 정밀도-우선 운용점이라 macro recall은 하락(청라 41.6→32~33%) — mAP는 불변이고 recall 하락은 더 높은 정밀도 점을 택한 대가입니다.

i v0.8 (실험) — 나무 라벨 완성 후 재학습, 근본 원인 공략. v0.7이 "향후 과제"로 남긴 학습셋 라벨 정화를 시도했습니다. 진단 심화: 나무 라벨은 고도별 이중모드 — 저고도(510m)는 촘촘(청라10m 27.8개/img)하나 15m↑는 사실상 0(00.2개/img). 같은 나무가 10m엔 라벨·15m엔 무라벨이라 모순 신호가 생기고, v0.5는 그 결과 15m 나무에 사실상 장님(고고도 0.0검출/img). 방법: open-vocab 검출기(OWLv2)로 15m 나무 후보를 만들고 v0.5의 안정적 건물·구조물 검출로 오탐을 veto해 라벨을 자동 완성(나무 라벨 77.5k→106k, +37%), exp_b warm-start 10ep 재학습(전체 33k). 결과(정직): 15m 나무 검출 recall 1.1%→14.3%(자동 생성 기준 라벨 대비, 13×), 라벨 도메인 나무 FP 감소(청라 tree FPPI 2.14→1.21·농촌 0.55→0.41), 4-도메인 헤드라인 mAP는 동률(≈26.6, 동일 운용점). ⚠️ 한계: 15m 향상은 자동 생성 기준 라벨(≈85% 정밀, 사람 GT 아님) 대비 측정이고, 평가셋 15m 나무 라벨도 희소해 헤드라인 mAP엔 반영되지 않습니다. 호스팅 가중치는 v0.5 유지(v0.8은 헤드라인 동률 + 자동라벨 기준 측정이라 본배포 보류). 결론: 메커니즘(15m 라벨 완성→검출 회복)은 입증, 사람 라벨로 검증이 다음 단계.

🔬 사람 GT 검증 결과 (6/9, 부분 표본 — 정직한 후속). 평가셋 15m 나무를 사람이 완전 교정해(현재 12장, 나무 483개) 재측정한 결과, 자동 라벨 기준 14.3%는 자기확증 착시로 확인됐습니다. 사람 GT 대비 15m 나무 recall은 운용점에서 0.4%, threshold를 0까지 풀어도 천장이 6.0%(이때 FPPI 8.3 — 사용 불가), 개별 나무를 군락 단위로 12배 뭉쳐 재채점해도 FP 통제점에서 최대 **7.3%**였습니다. 비교군 v0.5는 모든 조건에서 0.0%(12장 전체 나무 검출 1개 = 완전 장님)이므로, v0.8의 학습 메커니즘 자체는 작동(0%→검출)하지만, 14.3%는 OWLv2 자동 라벨(모델이 학습한 것과 동형)에 대고 측정한 값이라 부풀려졌고 배포 가능한 15m 나무 성능에는 크게 못 미칩니다. → 호스팅 가중치 v0.5 유지 확정. (n=12는 부분 표본이며 잔여 28장 교정 예정이나, 0%·6%·7% 세 측정이 일관됩니다.)

✅ v0.9 (배포) — 입력 640→960, 처음부터 재학습. v0.6v0.8이 후처리·라벨 쪽에서 벽을 넘지 못한 뒤, v0.5의 성공 공식(해상도 상향)을 한 번 더 적용했습니다. 데이터셋·증강·에폭은 v0.5(Exp B)와 동일하고 입력 크기와 그에 딸린 배치·학습률만 바꾼 통제 실험입니다(batch 10→4/GPU, lr 0.00113→0.000715). 결과: 4-도메인 평균 35.4% → 40.4% (+5.0pp, +14%), 네 도메인 전부 상승(청라 29.3→34.1 · 용인하남 25.1→29.5 · 택배 43.6→49.4 · 농약 43.6→48.4). 오탐도 동반 감소(FPPI 청라 8.43→5.90 · 용인하남 9.55→8.58 · 택배 7.77→7.51 · 농약 5.00→4.56)로, 정확도-오탐 맞교환이 없었습니다. 학습 검증셋 기준으로는 mAP 0.1619→0.1965(+21%)이며 여섯 클래스 전부 상승했습니다. 비용: 픽셀 수 2.25배지만 RTX 3070에서 forward 1216ms로 640(11ms) 대비 실시간성은 유지됩니다. ⚠️ 최고점은 30에폭 중 18에폭이었고 이후 12에폭은 과학습으로 하락만 했습니다(v0.5도 동일 패턴) — 재현 시 18에폭 근처에서 끊는 것을 권합니다.

🚨 정정 (2026-08-07) — "고고도 차량 미해결" 주장을 철회합니다. 이 카드의 이전 판은 "용인하남 도메인의 차량을 v0.9로도 못 잡는다(recall 1.7%→0.6%)"고 적었으나, 근거였던 평가셋의 vehicle GT가 개별 차량 라벨이 아니었습니다.

모델	용인하남 vehicle [email protected]
v0.5 (640)	1.7%
v0.9 (960)	0.6%
YOLOv8s-VisDrone (11M)	1.2%
YOLOv8x-VisDrone (68M)	1.0%

구조도 크기도 학습 데이터도 다른 네 모델이 전부 1% 내외로 실패해 GT를 직접 렌더링한 결과, 해당 셋의 vehicle GT 172개(전체 어노테이션 53,594개의 0.3%)는 1 주차장 한 열의 차량 수십 대를 박스 하나로 묶거나 2 공사 중장비와 주변 나무·비탈을 통째로 감싼 영역 라벨이었습니다(bbox 폭 중앙값 374px, 최대 2747px). YOLOv8x는 육안상 개별 차량을 정확히 검출하는데도 IoU가 맞지 않아 FP 74,766개로 집계됩니다. 또한 이 도메인을 "15m"로 불러왔으나 원본 파일명은 40M·50M 고도입니다(파일명 필드 오독).

따라서 이 도메인의 vehicle 지표는 모델 성능 지표로 쓸 수 없습니다. 고고도 차량 성능은 현재 판정 불가이며, 개별 차량 단위 재라벨 후에야 답할 수 있습니다. 4-도메인 평균은 building 어노테이션(44,654개)이 지배하므로 헤드라인 40.4%에는 영향이 거의 없습니다. 이 도메인의 상승은 structure(8.1→18.1)와 bridge(31.9→36.8)가 이끌었습니다.

⚙️ v0.9 운용점 — 오탐 줄이기 (2026-08-08 재측정). v0.7의 무료 레버(나무 NMS + 클래스별 threshold)를 v0.5가 아닌 v0.9 기준으로 다시 측정했습니다. 재학습 없이 후처리만 바꾸므로 이 저장소의 가중치는 그대로 씁니다.

운용점	청라10m	용인하남	택배15m	농약	검출 손실
기본 (τ=0.3)	5.90	8.58	7.51	4.56	—
A. 나무 NMS만	5.36	8.58	7.51	4.37	나무 recall -5%, 타 클래스 무손실
B. NMS + 클래스별 τ	3.84	3.96	3.53	3.16	클래스별 recall -9~23%

A는 사실상 공짜입니다 — 겹쳐 찍힌 중복 박스만 지우기 때문에 청라 기준 나무 오탐이 2,372→1,819개로 23% 줄고 나무 정밀도가 43.4%→48.7%로 오르는 동안, 놓치는 나무는 5%만 늘어납니다. 기본 적용을 권장합니다. B는 오탐을 31~54% 줄이지만 검출도 함께 잃으므로(청라 vehicle -9%·person -12%·building -23%) 오탐이 비싼 용도에서만 쓰십시오. B 권장 τ = tree 0.275 / structure 0.325 / building 0.375 / vehicle 0.35 / bridge 0.40 / person 0.35.

⚙️ v1.0 운용점 — 차량 recall 회복 (2026-08-11). 차량은 v0.9의 유일한 약점이었습니다(청라 vehicle AP 54.9 vs YOLOv8x 65.9). 진단 결과 원인은 크기·밝기·라벨이 아니라 확신 부족(학습셋 vehicle 4.5%로 클래스 불균형) — 모델이 차를 보고도 낮은 점수로 흘려보내는 문제였습니다. AI Hub #182 교차로 데이터 추가학습(고고도 40~100m)으로 이를 풀려 했으나, 저고도 평가셋(10~15m)과 도메인이 불일치해 비중 19%·5% 두 번 모두 v0.9 미달로 종결했습니다. 대신 재학습 없는 운용점 조정이 답이었습니다: vehicle 클래스만 τ를 0.3→0.2로 낮추면 청라 차량 recall 56.9%→67.6%(+10.7pp), 전체 FPPI +9%(5.90→~6.4, 허용선 +20% 이내), 타 클래스·mAP 불변. 차량 검출이 중요한 용도의 권장 운용점입니다(vehicle τ=0.2, 나머지 0.3). 오탐이 비싼 용도라면 위 B 레버와 병행하십시오.

⚠️ 레버 적용 후 mAP를 다시 재지 마십시오. 잘라낸 검출로 AP를 계산하면 5~8pp 낮게 나오지만 이는 측정 아티팩트입니다(AP는 PR 커브 전체를 쓰므로 낮은 점수를 자르면 recall 상한이 깎임). 모델 mAP는 레버와 무관하게 **4-도메인 40.4%**이고, 레버는 FPPI·precision·recall로만 평가해야 합니다.

---

모델 정보 / Model Info

항목	값
Base	nanodet-plus-m-1.5x (COCO 80 pretrained)
Backbone	ShuffleNetV2-1.5x
Neck	GhostPAN
Input	416 × 416 RGB (v0.2~v0.4) · 640 × 640 (v0.5) · 960 × 960 (v0.9)
Params	7.79M
Classes	6 (drone-specific)
Training	30 epoch, AdamW, cosine. v0.5: batch 10×5 (eff 50), lr 0.00113 · v0.9: batch 4×5 (eff 20, 960 메모리 제약), lr 0.000715
Dataset	AI Hub #183 — Urban surveillance + delivery + dusting, 다중 도메인
Best epoch	18 (v0.9) · 15 (v0.5) — 이후 에폭은 과학습으로 하락
License	CC BY-NC 4.0

클래스 / Classes

ID	Name	KR
0	tree	나무
1	structure	시설물 (가로등·송전탑 등)
2	building	건물
3	vehicle	차량
4	bridge	다리
5	person	사람

---

성능 / Performance

In-domain (Cheongna 10m val, 1,023 images — same as v0.1)

Class	v0.1 (Cheongna only)	v0.2 (multi-city)	Δ
tree	18.0%	11.8%	-6.2pp
structure	18.1%	12.8%	-5.3pp
building	27.1%	32.9%	+5.8pp
vehicle	61.0%	45.6%	-15.4pp
bridge	14.9%	21.3%	+6.4pp
person	41.4%	38.2%	-3.2pp
[email protected]	30.1%	27.1%	-3.0pp

v0.1은 청라 데이터에 과적합되어 더 높은 점수가 나왔습니다. v0.2는 일반화를 위해 다양성을 학습한 결과 일부 점수를 양보했습니다.

4-Domain Generalization (out-of-distribution 평가, τ=0.3, IoU≥0.5)

Val 도메인	v0.1	v0.2	v0.3	v0.4	v0.5	v0.9
청라10m (in-domain)	30.1	27.1	26.6	24.4	29.3	34.1
용인하남 15m (외삽-도시)	7.3	23.6	19.2	19.5	25.1	29.5
드론택배 15m (외삽-도시 시나리오)	10.7	43.6	33.5	36.5	43.6	49.4
농약살포 (외삽-농촌)	20.4	21.3	34.8	36.4	43.6	48.4 🔥
4-도메인 평균	17.1	28.9	28.5	29.2	35.4	40.4

오탐(FPPI, 이미지당 오탐 수) — 낮을수록 좋음, 같은 운용점 τ=0.3:

Val 도메인	v0.5	v0.9
청라10m	8.43	5.90
용인하남 15m	9.55	8.58
드론택배 15m	7.77	7.51
농약살포	5.00	4.56

핵심 인사이트:

• v0.9(입력 960)가 4개 도메인 전부 역대 최고 — 평균 40.4% (v0.5 대비 +5.0pp, +14%). 프로젝트 최초로 40% 돌파
• 정확도-오탐 맞교환 없음: 네 도메인 모두 mAP는 오르고 FPPI는 내려감. 해상도 상향이 "더 많이 찍어서" 얻은 점수가 아니라는 뜻
• 해상도가 두 번 연속 유일한 돌파구: v0.3·v0.4의 데이터 실험은 도메인 맞교환으로 평균이 정체했고, 돌파는 416→640(v0.5)과 640→960(v0.9) 두 번 모두 해상도에서 나옴
• 고고도 차량은 판정 불가: 근거로 삼던 용인하남 vehicle 지표가 평가셋 GT 결함으로 무효임이 확인돼(2026-08-07) 기존 "미해결" 주장을 철회했습니다. 해상도 가설을 기각할 반례는 현재 없습니다

---

파일 / Files

File	Size	Format	Note
nanodet_model_best.pth	31 MB	PyTorch	v0.9 학습 가중치 (입력 960) — 권장
drone_nanodet_960.onnx	11 MB	ONNX	v0.9 배포용 (모바일/엣지), 입력 960×960 — 권장
drone_nanodet_640.onnx	11 MB	ONNX	v0.5 구버전, 입력 640×640 (호환용으로 보존)
config.yaml	4 KB	NanoDet training config	v0.9: input 960, batch 4×5, lr 0.000715, 30 epoch
example.jpg	~700 KB	Sample inference	참고용

---

사용법 / Usage

PyTorch (NanoDet)

NanoDet 설치 필요 / Requires NanoDet installed from github.com/RangiLyu/nanodet:

from huggingface_hub import hf_hub_download
from nanodet.util import cfg, load_config, load_model_weight, Logger
from nanodet.model.arch import build_model
import torch

# Download weight
pth = hf_hub_download(
    repo_id="harveykim/nanodet-plus-1.5x-aerial-6cls",
    filename="nanodet_model_best.pth"
)
cfg_path = hf_hub_download(
    repo_id="harveykim/nanodet-plus-1.5x-aerial-6cls",
    filename="config.yaml"
)

load_config(cfg, cfg_path)
model = build_model(cfg.model)
ckpt = torch.load(pth, map_location="cpu")
load_model_weight(model, ckpt, Logger(-1,...