Çapraz aks mesafesi 35 cm olan bir multirotor, 800 metre mesafeden tipik bir EO sensörün karesinde çoğu lens/çözünürlük kombinasyonunda kenarı 15 pikseli geçmeyen bir leke olarak görünür. Aynı gökyüzünü martılar, bulut kenarları ve güneş parlamaları paylaşır; hedef saniyede 20 metre yol alıyor olabilir ve tespitten müdahale kararına kalan süre saniyelerle ölçülür. C-UAS (Counter-Unmanned Aircraft System) tespitinin özü budur: küçük hedef, büyük ve çoğunlukla boş bir arama alanı, dar bir zaman bütçesi. Sahadaki sensör düğümü buna bir kısıt katmanı daha ekler: SWaP-C (Size, Weight, Power, Cost). Bulut GPU'su yok, çoğu senaryoda veri bağlantısı bile yok. Bu yazıda, bu kısıtlar altında çalışan bir kenar çıkarım mimarisini parça parça ele alıyoruz. Referans platform Jetson Orin NX; tezgahta ölçtüğümüz sonuç, TensorRT FP16 hattıyla 31 fps'den 127 fps'ye çıkış ve kart üzerinde 8.4 W güç tüketimi.
Problem 1 — Küçük Piksel Alanı: Dedektörün Görmediği Hedef
COCO taksonomisi 32×32 pikselin altını "küçük nesne" sayar; C-UAS tespiti çoğunlukla bunun da altında, 5–15 piksel bandında çalışır. Bu bandın dedektör mimarisi için somut bir sonucu var: stride-8'lik P3 özellik haritasında 8×8 piksellik bir hedef tek bir hücreye düşer, stride-32'lik P5 katmanı hedefi hiç görmez. Modern tek aşamalı dedektörlerin varsayılan konfigürasyonları — YOLOv8 dahil — bu rejim için tasarlanmamıştır; COCO'da iyi çalışan bir model, gökyüzü videosunda sessizce kör kalabilir.
Üç standart müdahale var ve üçünün de bedeli ölçülebilir:
- Girdi çözünürlüğünü artırmak. Hesap yükü çözünürlükle karesel büyür; 640'tan 1280'e çıkmak kabaca 4× compute demektir. Aynı güç zarfında bu, kare hızından ödenir.
- P2 başlığı eklemek. Stride-4 özellik haritası küçük hedefi yakalar; karşılığında bellek bant genişliği tüketimi ve NMS yükü artar.
- Tiling (SAHI benzeri dilimleme). Kareyi dilimlere bölüp ayrı ayrı işlemek küçük hedef recall'unu belirgin iyileştirir; çıkarım süresi ise dilim sayısıyla çarpılır.
Hangisinin doğru olduğu senaryoya bağlıdır: menzil gereksinimi, sensör FOV'u ve güç bütçesi birlikte bir tasarım noktası tanımlar. Bizim yaklaşımımız bu üçlüyü bir kez "doğru" seçmek değil; her adayı aynı tezgahta fps / W / recall üçgeninde ölçüp yan yana koymaktır.
Problem 2 — Sınıf Dengesizliği: Çoğunlukla Boş Bir Gökyüzü
Gökyüzü videosunun ezici çoğunluğunda hedef yoktur. Eğitim tarafında bu, pozitif örneklerin binde birler mertebesinde kalması demektir; operasyon tarafında ise tek bir yüzde puanlık false positive oranının saatte yüzlerce yanlış alarma dönüşmesi. Bu yüzden mAP tek başına bir C-UAS metriği değildir: saatlik yanlış alarm oranı (FAR) ve tespit menzili aynı tabloda raporlanmadıkça model karşılaştırması anlam taşımaz.
Eğitim reçetesinde literatürde iyi belgelenmiş ve pratikte karşılığını gördüğümüz genel teknikler: focal loss ile kolay negatiflerin gradyan baskısını azaltmak, eğitim setine bilinçli olarak hedefsiz kareler (bulutlu gökyüzü, kuş sürüsü, parlama) eklemek ve copy-paste augmentation ile küçük hedefleri farklı arka planlara sentetik olarak yerleştirmek. Kritik nokta tekniklerin listesi değil, hangi kombinasyonun sizin sensörünüzde ve sizin sahanızda FAR'ı düşürdüğünü kontrollü biçimde ölçmektir.
Problem 3 — Kuş mu, Drone mu: Tek Kare Yetmez
12 piksellik bir lekede geometri, ayrım için yeterli bilgi taşımaz; o çözünürlükte kuş da drone da koyu bir blob'dur. Ayrımı taşıyan bilgi zamandadır:
- Kuşlarda kanat çırpma frekansı türe göre kabaca 3–10 Hz bandındadır ve görüntüde periyodik alan/parlaklık modülasyonu olarak izlenebilir.
- Multirotor rijit bir gövdedir ve sabit noktada asılı kalabilir. Hover, kuşta neredeyse hiç görülmeyen güçlü bir drone işaretidir.
- Yörünge karakteri ayrıştırır: sabit kanatlı İHA'lar düzgün, enerji-verimli yörüngeler çizer; kuşlar termallerde süzülür, ani yön değiştirir.
Bu niteliklerin tamamı kare-üstü (track-level) özelliklerdir; sınıflandırma kararının dedektörde değil izleyicide olgunlaşması gerekir. Çıkarım hızı burada doğrudan işlevsel bir avantaja dönüşür: 127 fps, 10 Hz'lik bir çırpma bileşenini periyot başına ~12 örnekle yakalar — Nyquist sınırının çok üzerinde. 10–15 fps'lik bir hat aynı imzayı aliasing'e kurban eder ve ayrım için elde yalnızca o yetersiz tek kare geometrisi kalır.
SWaP-C ve Hasım Ortam: Bulut Neden Masada Değil
C-UAS düğümünde bulut çıkarımını eleyen üç bağımsız neden var. Birincisi gecikme: tespit–karar–müdahale zinciri saniyeler içinde kapanmalı ve RF link üzerinden gidip gelen her kare bu bütçeden yer. İkincisi linkin kendisi: elektronik harp ortamında veri bağlantısı sistemin en kırılgan halkasıdır; jamming altında "bulut erişilemez" demek sistemin görevini bırakması anlamına gelir. Üçüncüsü güvenlik: birçok kritik tesiste görüntünün sahayı terk etmesi zaten yasaktır. Sonuç net: yakalama, çıkarım, izleme ve karar — tüm hat düğüm üzerinde, tipik olarak 10–25 W'lık bir güç zarfının içinde çalışmak zorundadır. SWaP-C'nin "C"si de gerçek bir kısıttır: çevre güvenliği tek sensörle değil düzinelerce düğümle sağlanır; birim maliyet, mimari kararı en az güç bütçesi kadar belirler.
Çıkarım Hattı: Jetson Orin NX + TensorRT FP16
Referans hattımız Jetson Orin NX üzerinde, JetPack 6 ile şu zinciri kurar: GStreamer yakalama (NVMM buffer, zero-copy) → VIC/GPU önişleme (letterbox + normalizasyon) → TensorRT FP16 engine → GPU'da decode + NMS → tracker. Optimizasyon kararları ve gerekçeleri:
| Karar | Uygulama | Gerekçe |
|---|---|---|
| FP16 kuantizasyon | TensorRT engine build, katman bazlı kernel seçimi | FP32'ye göre yaklaşık 2× throughput; küçük hedef doğruluğundaki etki doğrulanmalı, varsayılmamalı |
| Zero-copy yakalama | Kamera → NVMM → CUDA, CPU'ya kopya yok | memcpy ve format dönüşümünü hattan çıkarmak |
| Önişleme donanımda | Resize/letterbox VIC/GPU üzerinde | ARM çekirdeklerini izleyici ve füzyon koduna bırakmak |
| Batch=1, tek profil | Engine build'de düşük gecikme profili | Throughput değil worst-case gecikme optimize edilir |
| DLA offload | Backbone DLA'da, uyumsuz katmanlar GPU fallback | Watt başına iş; GPU'nun diğer yükler için boşaltılması |
Bu hattın tezgah ölçümü: PyTorch referans çalıştırmada 31 fps olan YOLOv8 çıkarımı, TensorRT FP16 motoru ve yukarıdaki hat düzenlemeleriyle 127 fps'ye çıktı; kart üzerinde ölçülen güç tüketimi 8.4 W. Ölçüm yöntemi ve adım adım kazanımlar Edge AI çıkarım optimizasyonu vaka analizinde belgelidir.
Engine üretimi tekrarlanabilir olmalıdır; build parametreleri model dosyasıyla birlikte versiyonlanır:
trtexec --onnx=yolov8s_cuas_1280.onnx \
--fp16 \
--useDLACore=0 --allowGPUFallback \
--memPoolSize=workspace:2048 \
--saveEngine=yolov8s_cuas_fp16_dla0.engine \
--useSpinWait --separateProfileRun \
--exportProfile=layer_profile.json
--exportProfile çıktısı katman bazında süreleri verir: hangi katmanların DLA'dan GPU'ya düştüğünü (fallback) ve araya giren reformat katmanlarının maliyetini burada görürsünüz. "Optimizasyon" dediğimiz işin büyük bölümü, bu profili okuyup darboğazı sayıyla göstermekten ibarettir.
DLA Offload: GPU'yu Asıl İşine Boşaltmak
Orin NX üzerindeki DLA (Deep Learning Accelerator) çekirdekleri, konvolüsyon ağırlıklı iş yüklerini GPU'dan bağımsız ve watt başına daha verimli çalıştırır. C-UAS bağlamında bunun stratejik anlamı şudur: dedektör backbone'unu DLA'ya taşıdığınızda GPU; izleyici, optik akış, koordinat dönüşümleri veya ikinci bir model (örneğin dar FOV'lu doğrulama kamerası üzerinde ayrı bir sınıflandırıcı) için boşalır. Sabit güç zarfında bu, aynı düğümden daha fazla işlev çıkarmanın en doğrudan yoludur.
Pratik uyarılar: DLA her katman türünü desteklemez; desteklenmeyenler allowGPUFallback ile GPU'ya düşer ve her DLA↔GPU geçişi bir reformat maliyeti getirir. Modeli DLA'ya "atmak" değil, DLA-uyumlu bir varyantını tasarlamak gerekir — aktivasyon fonksiyonları, katman türleri ve tensör boyutları baştan DLA kısıtlarına göre seçildiğinde fallback sayısı ve uçtan uca gecikme birlikte düşer. Kural değişmez: fallback sayısını ve gecikmeyi profil çıktısından oku, varsayma.
İzleme Entegrasyonu: Tespitten Hedef Sürekliliğine
Küçük hedef rejiminde dedektör güveni kareler arasında titrer: hedef bir karede 0.6, sonrakinde 0.2 güvenle gelir, ara sıra tamamen kaybolur. İzleyici bu titremeyi hedef sürekliliğine çevirir. Kullandığımız desen, literatürdeki ByteTrack ailesiyle aynı ilkeye dayanır: yüksek güvenli tespitlerle track başlat, düşük güvenli tespitleri mevcut track'lerle eşleştirerek geri kazan, eşleşme olmayan kareleri Kalman öngörüsüyle köprüle (coasting). Düşük güvenli tespitleri çöpe atmamak, tam da güvenin yapısal olarak düşük olduğu küçük hedeflerde en çok kazandıran karardır.
Yüksek kare hızı burada ikinci kez ödeme yapar: 127 fps'de hedefin kareler arası yer değiştirmesi küçüktür; bu, eşleştirme kapılarını (gating) daraltır, kimlik karışmalarını azaltır ve Kalman modelinin doğrusal öngörüsünü geçerli kılar. Kuş/drone sınıflandırması da bu katmanda olgunlaşır: çırpma imzası, hover tespiti ve yörünge istatistikleri track üzerinde birikir; karar tek kareye değil saniyelik bir gözlem penceresine dayanır.
Track çıktısı tek başına da yaşamaz. EO/IR track'lerinin RF yön bulma, radar cueing veya akustik sensörlerle birleştirilmesi gerektiğinde problem bir çoklu sensör füzyonu problemine dönüşür: ortak zaman tabanı, koordinat dönüşümleri ve sensörler arası gecikme telafisi, tespit hattının kendisi kadar mühendislik ister.
Air-Gapped Çalışma: Bağlantısız Yaşam Döngüsü
Düğümün ağa hiç çıkmaması, yalnızca çıkarımın değil tüm model yaşam döngüsünün sahada ve bağlantısız yönetilmesi demektir. Bunun mühendislik karşılıkları:
- İmzalı model paketleri. Engine + konfigürasyon + sürüm manifesti tek bir imzalı arşivde taşınır; düğüm, imza doğrulanmadan hiçbir paketi yüklemez.
- Deterministik sürümleme. Hangi düğümde hangi model/engine/JetPack kombinasyonunun koştuğu, sahada okunabilir bir manifestle kayıt altındadır; herhangi bir düğümün durumu tezgahta birebir yeniden üretilebilir.
- Yerinde kayıt. Yanlış alarmlar ve kaçırılan hedefler düğümde loglanır, periyodik fiziksel toplama ile eğitim setine geri beslenir. Telemetri yoktur; veri sahayı terk etmez.
Bu disiplin bulut kolaylıklarından vazgeçmek gibi görünür; pratikte sistemi daha test edilebilir yapar, çünkü davranışı ağdaki hiçbir dış duruma bağlı değildir.
Sonuç: Tasarım Noktanızı Ölçerek Seçin
Kenarda C-UAS tespiti tek bir "doğru mimariye" indirgenemez; menzil, FOV, güç zarfı ve birim maliyet hedefi her projede farklı bir tasarım noktası tanımlar. Değişmeyen şey yöntemdir: her adayı aynı tezgahta, aynı metriklerle — fps, W, FAR/saat, tespit menzili — ölçmek ve kararı sayıya bağlamak. Elinizde çalışan bir prototip varsa ve "Orin NX yeter mi, DLA'ya ne taşınmalı, FP16 mı INT8 mi" sorularını varsayımla değil ölçümle yanıtlamak istiyorsanız, mevcut hattınızı gömülü sistem mimari denetimi kapsamında birlikte profilleyebiliriz; platform ve güç zarfı seçiminde ilk elemeyi yapmak içinse sistem hesaplayıcı kaba ama dürüst bir başlangıç noktası sunar.