Dışarıdan bakınca bir yarışmaya hazırlanmak "drone yapmak" gibi görünür. İçeriden bakınca ise tamamen başka bir şeydir: şartnameyi mühendislik gereksinimlerine çevirmek, sonra da bu gereksinimleri tek tek doğrulamak. Bu yazıda SUAS 2026 hazırlığımızı baştan sona anlatıyoruz: işe yarayan kısımları ve en az onlar kadar, tökezlediğimiz yerleri.

Görev bizden ne istiyor?

SUAS (Student Unmanned Aerial Systems), takımların otonom insansız hava sistemleri geliştirdiği uluslararası bir yarışma. 2026 sezonunun ana görevi "Search, Detect, and Deliver" — yani ara, tespit et, teslim et:

• Arama sınırının içinde bir manken ve bir katlanır çadır bulunuyor.

• Mankeni bulursanız bir su şişesi, çadırı bulursanız bir flaşörlü işaret cihazı (strobe beacon) bırakıyorsunuz.

• Hedefler enkaz ve moloz arasına dağıtılmış durumda; kısmen örtülü olabiliyorlar.

• Bırakma, en az 150 ft (yaklaşık 46 m) irtifadan yapılmak zorunda.

Bunların üstüne bir de Risk Mapping (risk haritalama) görevi var: yaklaşık 10 akrelik arama alanının birleştirilmiş görüntü haritası, görev penceresi içinde teslim ediliyor.

İlk çalışma toplantımızda yaptığımız en faydalı şey, bu maddeleri bir yapılacaklar listesi olarak değil, bir puan cetveli olarak okumak oldu. Hangi görev kaç puan ediyor, her ceza bize neye mal oluyor, hangi görevler tek bir uçuşu paylaşabilir? Cevaplar tasarımı doğrudan şekillendirdi.

Tek uçuş, üç görev

En erken stratejik kararımız buydu: ayrı bir haritalama uçuşu yok.

Mission Planner'da planlanan waypoint turu sırasında hava aracı iki işi aynı anda yapıyor: haritalama görüntülerini topluyor ve kart üstündeki tespit hattını çalıştırıp bulduğu her hedefin konumunu kaydediyor. Görüntü alımı son waypoint'te bitiyor. Ardından hava aracı kaydedilen konumlara uçuyor, nesnenin üzerinde kendini ortalıyor ve yükünü bırakıyor.

Yani tek bir arama turu; waypoint puanını, haritalama puanını ve tespit aşamasını aynı anda besliyor. Görev penceresinin 45 dakikayla sınırlı olduğu bir yarışmada bu, kâğıt üstünde bir "optimizasyon" değil; doğrudan puan demek.

Sistem mimarisi

Kabaca üç parça:

Kamera görüntüsü Jetson'a RTSP akışı olarak geliyor ve tespit tamamen hava aracının üzerinde çalışıyor. Bu bilinçli bir tercihti: tespiti yer istasyonuna taşımak, video linki kalitesini görev-kritik hâle getirirdi. Link koptuğu anda hava aracının körleşmesini istemedik.

Nerede tökezledik

Bu hikâyeyi "her şey planlandığı gibi gitti" diye anlatmak kolay olurdu; ama öğretici olan kısım tam tersi. İki büyük duvara tosladık:

1. Model uzağı göremiyordu. Eğittiğimiz ilk model yakındaki hedefleri yüksek güvenle buluyor, mesafe biraz açıldığında ise hiç tespit üretmiyordu. Arada bir düşüş eğrisi yoktu: ya hedefi net görüyor ya da hiçbir şey görmüyordu. Kök nedeni kazıp çıkarmak, beklediğimizden çok daha öğretici bir kazı çalışmasına dönüştü (ayrı yazı: "Yakında Görüyor, Uzakta Kör").

2. Doğru çözüm gerçek zamanlı çalışmıyordu. Küçük nesne probleminin bilinen cevabı olan dilimli çıkarım (tiling), tespit kabiliyetimizi gerçekten kurtardı; ama Jetson üzerinde bizi saniyede 1-3 kareye düşürdü. Kapalı çevrim güdüm için fazlasıyla yavaş. Ölçüm bizi tasarımı değiştirmeye zorladı (ayrı yazı: "Tiling mi, Hız mı?").

Her iki durumda da bizi ileri taşıyan şey ölçüm oldu, tahmin değil.

Uçmadan önce uçmak: simülasyon

Sahaya çıkmadan önce Gazebo, ArduPilot SITL, ROS 2 ve pymavlink'i birbirine bağlayan bir simülasyon ortamı kurduk. İşin asıl püf noktası şuydu: ortamı dağıtık kurduk. Uçuş dinamiği simülasyonu, yer istasyonu ve gerçek Jetson, ağ üzerinde ayrı düğümler olarak çalıştı; kamera görüntüsü yine RTSP üzerinden Jetson'a ulaştı.

Sonuç olarak sahada kullanacağımız donanım ve ağ topolojisi, daha ilk uçuş gerçekleşmeden birebir denenmiş oldu. Arıza senaryolarını da burada tetikledik (GPS/EKF bozulması, link kaybı, düşük batarya) ve failsafe davranışını telemetri loglarıyla karşılaştırarak doğruladık.

Simülasyonun asıl değeri tek cümleye sığıyor: saha uçuşları davranışı keşfetmek için değil, doğrulamak içindir.

İlk otonom airdrop

İlk kapsamlı saha testimizde sistem şunları yaptı:

• İki hedefi de yaklaşık 20 m irtifadan tespit etti

• Tespit edilen konumları güdüme aktardı

• Bırakma noktalarına otonom olarak uçtu

• İşaret cihazı tam çadırın üzerine düştü

• Su şişesi mankenin yaklaşık 5 m yakınına düştü

Ayrı bir testte, hava karardıktan sonra zayıf yapay ışık altında beton üzerindeki insan figüranlarını 20-25 m'den, 6 tekrarda, yaklaşık 0.75 güven değeriyle tespit ettik. Bu bizim için önemliydi: yarışma günü ışığın eğitim verimize benzeyeceğinin hiçbir garantisi yok.

Açık konuşalım, bu tek bir testti. Bir uçuş "sistem çalışıyor" demeye yetmez; ancak "sistem çalışabiliyor" demeye yeter. İstatistik tekrar ister.

Sırada ne var

Bu kayıt yazıldığında en büyük açığımız ortadaydı: doğrulanmış tespit irtifamız ~20 m, bırakma tabanı ise ~46 m ve o bantta henüz hiç denememiştik. O açık kapandı; kapatan şey de daha büyük bir ağ değil, optik oldu. Tespit artık 3x dijital zoom ile uçuluyor — 4K sensör okuması kırpılıyor, görüş alanı 31.8 dereceye daralıyor — böylece 50 m'de yer örnekleme mesafesi 44.5 yerine 14.8 mm/px oluyor ve 1.7 m boyundaki manken 640 px'lik çıkarım girdisinde yaklaşık 38 px yer kaplıyor. Bu, 20 m'de tekli zoomla elde ettiğimiz ~32 px'e yakın: zoom, irtifanın götürdüğünü geri getiriyor.

O günden bu yana ölçtüklerimiz: hava aracı 49 m AGL'de, kamera 3x zoomdayken insan maketi 0.60-0.80 güven aralığında tespit edildi; 0.25'lik işletim eşiğimizin rahatça üzerinde. Ardından zincirin tamamını 50 m görev irtifasında tekrarladık: benzer tespit güveni, alçak irtifadaki denemeyle aynı mertebede teslimat sapması ve her iki faydalı yük de 50 ft (15.2 m) puanlama yarıçapının içinde. Uçuş konfigürasyonu 0.25 eşiğiyle tam kare 640 px çıkarım — eşik bilinçli olarak düşük tutuluyor, çünkü bırakma kararı tek bir karenin güvenine değil sürekliliğe bakıyor: hedefin ardışık karelerde kare merkezinin 20 px içinde kalması gerekiyor. TensorRT ile hızlandırılmış dilimli çıkarım yedek olarak rafta duruyor; otonom güdümün gerektirdiği işlem hızını karşılamadığı için uçuş konfigürasyonu değil.

Geriye kalanlar:

• Uç güdüm döngüsünün canlı görüntü üzerinde kapalı döngü doğrulanması — sahadaki bırakmalar şimdiye kadar kayıtlı koordinattan komut edildi

• Bırakma isabetini tekrar tekrar ölçüp bir dağılıma dönüştürmek

• Kamera kalibrasyonu

Bu adımların her birini, sonucu ne olursa olsun bu blog serisinde paylaşacağız. İşleyen kısımları yazmak kolay; asıl faydalı olan, işlemeyen kısmın nasıl teşhis edildiği.

Bu yazı bir serinin parçası: sonraki yazılarda tespit hatasının kök neden analizini, veri setlerimizi nasıl birleştirdiğimizi ve Jetson üzerindeki hız/doğruluk ödünleşimini ayrıntılı olarak ele alıyoruz.