SUAS 2026 Yolculuğumuz: Görev Analizinden İlk Otonom Airdrop'a

Bir yarışmaya hazırlanmak, dışarıdan bakınca “drone yapmak” gibi görünüyor. İçeriden bakınca ise tamamen farklı bir şey: kural kitabını mühendislik gereksinimine çevirmek, sonra o gereksinimi tek tek doğrulamak. Bu yazıda SUAS 2026 hazırlık sürecimizi baştan sona anlatıyoruz — çalışan kısımları kadar tökezlediğimiz yerleri de.

Görev ne istiyor?

SUAS (Student Unmanned Aerial Systems), takımların otonom insansız hava aracı sistemleri geliştirdiği uluslararası bir yarışma. 2026 sezonunun ana görevi “Search, Detect, and Deliver”:

• Arama sınırları içinde bir manken ve bir pop-up çadır bulunuyor.
• Manken bulunduğunda su şişesi, çadır bulunduğunda strobe beacon bırakılıyor.
• Hedefler enkaz arasına saçılmış, kısmen örtülü olabiliyor.
• Bırakma en az 150 ft (yaklaşık 46 m) irtifadan yapılmak zorunda.

Buna ek olarak Risk Mapping görevi var: yaklaşık 10 acre’lık arama alanının birleştirilmiş görüntü haritası, görev süresi içinde teslim ediliyor.

İlk oturumumuzda yaptığımız en faydalı şey, bu maddeleri “yapılacaklar listesi” olarak değil, puan tablosu olarak okumak oldu. Hangi görev kaç puan, hangi ceza neyi götürüyor, hangi görev hangi görevle aynı uçuşta yapılabilir? Cevaplar tasarımı doğrudan şekillendirdi.

Tek uçuş, üç görev

En erken verdiğimiz stratejik karar buydu: haritalama için ayrı bir uçuş yapmamak.

Mission Planner ile planlanan waypoint turu sırasında uçak aynı anda iki iş yapıyor — haritalama görüntülerini topluyor ve üzerindeki tespit hattını çalıştırıp bulduğu hedeflerin konumunu kaydediyor. Son waypoint’te haritalama çekimi bitiyor. Ardından uçak kayıtlı konumlara gidip nesneyi ortalıyor ve yükünü bırakıyor.

Yani tek bir tarama geçişi hem waypoint puanını, hem haritalama puanını, hem de tespit aşamasını besliyor. Görev süresi 45 dakikayla sınırlı olduğu için bu, kağıt üzerinde bir “optimizasyon” değil, doğrudan puan demek.

Sistem mimarisi

Kabaca üç parça:

Katman	Ne var	Görevi
Uçuş	Pixhawk sınıfı uçuş kontrolcüsü + ArduPilot	Navigasyon, failsafe, AUTO mod
Algı	SIYI A8 mini gimbal kamera + Jetson Orin NX	Görüntü akışı, nesne tespiti, konum kaydı
Yer	Mission Planner + telemetri linki	Görev planlama, izleme, harita teslimi

Kamera görüntüsü Jetson’a RTSP akışı olarak geliyor; tespit tamamen uçak üstünde (onboard) çalışıyor. Bunu bilinçli seçtik: tespiti yer istasyonuna taşımak, video linkinin kalitesini görev-kritik hale getirir. Link koptuğunda uçak kör kalmasın istedik.

Nerede tökezledik

Süreci “her şey planlandığı gibi gitti” diye anlatmak kolay olurdu ama öğretici olan kısım tam tersi. İki büyük duvara çarptık:

1. Model uzağı göremiyordu. İlk eğittiğimiz model yakındaki hedefi yüksek güvenle buluyor, mesafe biraz açılınca hiç tespit üretmiyordu. Arada geçiş yoktu — ya tam görüyor ya hiç. Bunun kök nedenini bulmak, sandığımızdan çok daha öğretici bir kazı çalışması oldu (ayrı yazı: “Yakında Görüyor, Uzakta Kör”).

2. Doğru çözüm gerçek zamanda çalışmıyordu. Küçük nesne problemine bilinen çözüm olan “dilimli çıkarım” (tiling) tespit yeteneğini gerçekten kurtardı — ama Jetson üzerinde saniyede 1-3 kareye düştü. Kapalı döngü güdüm için bu çok yavaştı. Ölçüm bizi tasarımı değiştirmeye zorladı (ayrı yazı: “Tiling mi Hız mı?”).

Her iki durumda da bizi ilerleten şey tahmin değil, ölçüm oldu.

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

Sahaya çıkmadan önce Gazebo, ArduPilot SITL, ROS 2 ve pymavlink’i birleştiren bir simülasyon ortamı kurduk. Buradaki asıl numara şuydu: ortamı dağıtık kurduk. Uçuş dinamikleri simülasyonu, yer istasyonu ve gerçek Jetson ağ üzerinde ayrı düğümler olarak çalıştı; kamera görüntüsü Jetson’a yine RTSP ile gitti.

Sonuç olarak sahada kullanacağımız donanım ve ağ topolojisi, daha ilk uçuş yapılmadan birebir sınanmış oldu. GPS/EKF bozulması, bağlantı kaybı ve düşük pil gibi arıza senaryolarını da burada tetikleyip failsafe davranışlarını telemetri kayıtlarından doğruladık.

Simülasyonun asıl faydası şu cümlede özetlenebilir: saha uçuşları davranışı keşfetmek için değil, teyit etmek için yapılır.

İlk otonom airdrop

Kapsamlı ilk saha testimizde sistem şunları yaptı:

• Her iki hedefi de yaklaşık 20 m irtifadan tespit etti
• Tespit edilen konumları güdüme devretti
• Uçak bırakma noktalarına otonom gitti
• Beacon çadırın üzerine isabetle düştü
• Su şişesi mankenin yaklaşık 5 m yakınına düştü

Ayrıca ayrı bir testte, karanlıkta loş yapay ışık altında beton zemin üzerindeki insan vekillerini 20-25 m’den, 6 denemede yaklaşık 0.75 güven değeriyle tespit ettik. Bu bizim için önemliydi: yarışma ışığının eğitim verimize benzeyeceğinin garantisi yok.

Bunun tek bir test olduğunu da açıkça söyleyelim. Bir uçuş “sistem çalışıyor” demek için yeterli değil; “sistem çalışabiliyor” demek için yeterli. İstatistik için tekrar gerekiyor.

Sırada ne var

Dürüst olmak gerekirse en büyük açığımız belli: doğrulanmış tespit irtifamız ~20 m, oysa bırakma çiti ~46 m. Bu bandda tespit denemesi yapmadık. Yedek planımız hazır (dilimli mod + TensorRT’yi geri açmak) ama hazır plan, ölçülmüş sonuç değildir.

Kalan işler:

• 46 m bandında tespit denemesi
• Güven eşiği taraması (F1-optimal değeri bulmak)
• Bırakma isabetini tekrarlı ölçüp dağılıma çevirmek
• Kamera kalibrasyonu

Bu blog serisinde bu adımların her birini, sonucu ne olursa olsun paylaşacağız. Çalışan kısımları anlatmak kolay; asıl faydalı olan, çalışmayan kısmın nasıl teşhis edildiği.

---

Bu yazı bir seri: sonraki yazılarda tespit hatasının kök-neden analizini, veri seti birleştirme sürecini ve Jetson üzerindeki hız/doğruluk takasını ayrıntısıyla anlatıyoruz.