Küçük nesne tespitinin bilinen bir çözümü var: dilimli çıkarım (tiling). Modele tüm kareyi vermek yerine kareyi birbiriyle örtüşen parçalara (tile) bölüp her parçayı ayrı ayrı işlersiniz. Böylece uzaktaki küçük bir hedef, parçanın içinde oransal olarak büyük görünür ve model onu yakalayabilir.

Bizde de tam olarak böyle oldu. Sonra Jetson'a taşıdık ve saniyede 1-3 kareye düştük.

Bu yazı, "çalışan bir çözüm" ile "sahada kullanabileceğiniz bir çözüm" arasındaki mesafenin hikâyesi.

Tiling gerçekten işe yaradı

Önce kanıt. Eski modelimizin üzerlerinde hiçbir tespit üretemediği iki gerçek havadan kareyi aldık; modelde, veride ya da eğitimde hiçbir değişiklik yapmadan bu karelerde yalnızca dilimli çıkarım koşturduk.

Bu sonuç bizim için bir dönüm noktasıydı, çünkü bize problemin nerede olmadığını gösterdi. Model bu nesneleri tanıyabiliyordu; onları yalnızca göremiyordu. Fark, nesnenin ağa kaç piksel olarak ulaştığıydı.

(Bir not: bu iki karede ground truth resmî olarak etiketlenmedi; bu yüzden bunu bir "recall ölçümü" değil, bir kurtarma sinyali olarak paylaşıyoruz. Bizim için önemli olan aradaki fark.)

Bu bulgu iki şeyi tetikledi: veri setinin ve ölçek politikasının sıfırdan yeniden kurulması (o yazı burada) ve dilimli çıkarımın uçuş yazılımına taşınması.

Jetson'a taşıma: 1-3 FPS

Dilimli hattı Jetson Orin NX üzerinde koşturduğumuzda ölçtüğümüz değer saniyede 1 ilâ 3 kare oldu.

İlk refleksimiz "GPU yetişemiyor" demek olurdu. Ama profil çıkardığımızda darboğazın GPU'da olmadığını gördük: zaman, her parça için yapılan CPU tarafındaki ön ve son işlemeye gidiyordu. Kareyi parçalara bölmek, her parçayı modelin istediği biçime sokmak (letterbox, normalizasyon), sonra her parçanın çıktısını global koordinatlara geri eşleyip birleştirmek (NMS): hepsi parça sayısıyla çarpılıyor.

Yani sorun "model ağır" değildi; sorun şuydu: "her kare için aynı işi N kez yapıyor olmamız".

Bu ayrım önemli: teşhisi "GPU yetersiz" diye koysaydık daha küçük bir model ya da daha güçlü donanım aramaya başlar, tamamen yanlış yöne sapardık.

Asıl soru: FPS bir gereksinim mi, tercih mi?

Tam burada durup sorduk: gerçekte kaç FPS'e ihtiyacımız var?

Atlanması çok kolay bir soru. "Gerçek zamanlı" ifadesi, sorgusuz sualsiz 30 FPS demekmiş gibi kullanılıyor. Oysa gereksinimi görev belirler:

• Bizim akışımızda hava aracı hedefi tespit ediyor, konumunu kaydediyor, sonra hedefe gidip üzerine merkezlenmiş hâlde yükü bırakıyor.

• Merkezleme aşaması kapalı çevrim kontroldür: hava aracı görüntüye bakarak kendi konumunu düzeltir.

Kapalı çevrim kontrolde düşük kare hızı doğrudan gecikmeye dönüşür. 2 FPS'te çalışan bir kontrol döngüsü, hava aracı hareket etmeye devam ederken 500 ms bayatlamış bilgiyle karar verir; sonuçta hedefin etrafında salınmaya başlar. Arama aşaması için 2 FPS yeterli olabilirdi; merkezleme aşaması için değildi.

Cevap şu: bizim senaryomuzda FPS gerçekten bir gereksinimdi.

Takas: hız satın almak için çözünürlük harcadık

Uçuş konfigürasyonunu değiştirdik:

Hızlanmayı neyin sağladığına dikkat edin: daha küçük bir model ya da daha agresif bir optimizasyon değildi. Tiling'in kendisini kaldırmaktı: parça başına düşen CPU işi ortadan kalkınca kare hızı doğrudan 15-20'ye fırladı.

Bu takasın geçerli olduğu bir bant var: doğruladığımız ~20 m çalışma irtifasında manken, küçültmeden sonra hâlâ kabaca 32 piksele denk geliyor. Yeniden eğittiğimiz modelin ölçek politikası bu boyutu kapsıyor.

Bu takas bize dürüstçe neye mal oldu

Böyle bir hikâyeyi anlatmanın kolay yolu, kazandığınızı yazıp bedeli geçiştirmektir. Bedel şu:

Tekli zoomda piksel bütçesi irtifayla birlikte gerçekten çöküyor: 46 metrede (yarışmanın airdrop tavanı) 640 piksellik girdide manken kabaca 14 piksele düşüyor ve bu ölçümü yaptığımız gün o bantta henüz bir tespit denemesi uçurmamıştık.

O günden bu yana bu boşluğu iki şey kapattı. Birincisi, yukarıdaki hesabın eksik olması. Tespit tekli zoomda uçulmuyor; 3x dijital zoomla uçuluyor. Bu, görüş alanını 31.8 dereceye daraltıyor ve 50 m'de yer örnekleme mesafesini 44.5 mm/px'ten 14.8 mm/px'e indiriyor. Bu konfigürasyonda manken 640 piksellik girdide kabaca 38 piksele geri çıkıyor; yani tekli zoomun 20 m'de verdiği 32 piksele yakın. Zoom, irtifanın aldığını geri ödüyor.

İkincisi, deneme artık uçuldu. 49 m AGL'de, kamera 3x zoomdayken insan maketi 0.60-0.80 güvenle tespit edildi; 0.25'lik işletim eşiğimizin rahat üzerinde. Ardından uçtan uca otonom zincir 50 m görev irtifasında tekrarlandı ve her iki faydalı yük de 50 ft (15.2 m) puanlama yarıçapının içine indi. Hâlâ açık olan tek başlık var ve burada yazdığımızdan daha dar: uç güdüm döngüsü canlı görüntü üzerinde kapalı çevrim olarak doğrulanmadı, çünkü sahadaki bırakmalar kayıtlı geolocation'dan komut edildi.

Yedek plan olduğu yerde duruyor: dilimli modu ve derlenmiş TensorRT FP16 engine'ini kod tabanında kapalı bir seçenek olarak tutuyoruz. Dilimli çıkarım, tam karenin kaçırdığı tespitleri gerçekten kurtarıyor; ama otonom güdümün gerektirdiği işlem hızını hiçbir zaman karşılamadı. Bu yüzden tek geçişte tam kare 640 px ve 0.25 eşiği, geçici bir çözüm değil uçuş konfigürasyonunun kendisi.

Ama "rafta duran bir plan", "ölçülmüş bir sonuç" değildir. Bunu tam olarak böyle kaydediyoruz.

Tek bir tasarım kararı, iki kez değişti

Geriye dönüp baktığımızda ilginç olan şu: aynı test tasarımı iki kez değiştirdi.

1. Dilimli çıkarım denemesi → kaçan tespitlerin sebebinin ölçek olduğunu gösterdi → veri seti ve eğitim politikası yeniden kuruldu.

2. Aynı hattın Jetson üzerinde profillenmesi → CPU darboğazını ortaya çıkardı → uçuş konfigürasyonu tam kare moduna geçti.

İyi bir test "geçti/kaldı" demez; bir sonraki kararı belirler. Bizim durumumuzda tiling, uçuşta kullanmıyor olsak bile projedeki en değerli deneylerden biri oldu; çünkü bize problemin nerede olduğunu ve nerede olmadığını gösterdi.

Çıkardığımız dersler

1. "Çalışıyor" ile "sahada çalışıyor" farklı iddialardır. Bir çözümü hedef donanımda ölçmeden mimarinize sabitlemeyin.

2. Optimize etmeden önce profil çıkarın. Darboğazımız GPU değil, CPU ön/son işlemesiydi; yanlış teşhis doğrudan yanlış çözüme götürürdü.

3. "Gerçek zamanlı" ifadesini sorgulayın. Kaç FPS'e ihtiyacınız olduğuna görev karar verir; bir arama geçişiyle kapalı çevrim bir kontrolcü aynı şeyi istemez.

4. Takasın size neye mal olduğunu yazın. Kazancınızı anlatıp kaybınızı gizlemek, kendi ekibinizi de yanıltır.

5. Reddettiğiniz çözümü silmeyin. Dilimli mod hâlâ kod tabanımızda kapalı bir seçenek olarak duruyor; koşullar değişirse hazır.