Yer Kontrol İstasyonu (GCS) Nedir? Mission Planner vs QGroundControl

Sahada ilk günümüzü hiç unutmuyoruz. Araç masada duruyor, pervaneler takılı değil, kumandadan arm komutu veriyoruz ve hiçbir şey olmuyor. Motorlar sessiz, LED turuncu yanıp sönüyor, kumandada bir geri bildirim yok. Elimizde tek bilgi: “çalışmıyor.”

Laptopu açıp telemetri telsizini USB’ye taktığımızda ekranın alt köşesinde tek satır belirdi: PreArm: Compass not calibrated. Beş saniyelik iş. Ama o beş saniyeyi bize kazandıran şey uçağın kendisi değil, yerdeki yazılımdı.

Yer Kontrol İstasyonu (Ground Control Station, GCS), aracı planlamak, izlemek ve ayarlamak için kullandığımız yer yazılımıdır. Uçuş kontrolcüsünün (Flight Controller, FC) beynine açılan pencere odur. Bu yazıda GCS’in ne işe yaradığını, Mission Planner ile QGroundControl arasındaki farkları, MAVLink’in bu ilişkideki rolünü ve log analizinin neden pazarlık konusu olmadığını anlatıyoruz.

GCS tam olarak ne yapar?

GCS’i “harita üzerinde waypoint koyma aracı” sanmak yaygın bir hata. Görev planlama sadece bir tanesi:

İşlev	Ne demek	Ne zaman kullanılır
Görev planlama	Waypoint, geofence, rally point tanımlama ve araca yükleme	Uçuş öncesi
Parametre ayarı	FC’deki yüzlerce parametreyi okuma/yazma	Kurulum, tuning
Kalibrasyon	Pusula, ivmeölçer, RC, ESC, batarya	İlk kurulum ve her yer değişiminde
Firmware yükleme	FC’ye ArduPilot/PX4 bootloader üzerinden yazma	Kart ilk açıldığında, sürüm yükseltmede
Telemetri izleme	HUD, konum, batarya, GPS, uyarı mesajları	Uçuş sırasında
Log indirme/analiz	Uçuş sonrası veriyi çekip grafiklemek	Her uçuştan sonra
SITL/HIL bağlantısı	Simülasyondaki araca gerçekmiş gibi bağlanmak	Geliştirme

ArduPilot dokümantasyonu Mission Planner’ın işlevlerini bu başlıklarla sayıyor: firmware yükleme, kurulum ve tuning, otonom görev planlama, log indirme/analiz ve PC uçuş simülatörüyle donanım-döngüde (HIL) simülasyon. QGroundControl da benzer beş alana bölünmüş: Plan, Setup, Fly, Analyze ve gelişmiş araçlar.

Bizim SUAS 2026 iş akışımızda GCS, simülasyonla saha arasındaki tek ortak arayüz. SITL + Gazebo kurulumumuzda simüle edilen araca bağlandığımız yazılım ile sahada gerçek Pixhawk’a bağlandığımız yazılım aynı. Bu, “simülasyonda çalıştı ama sahada çalışmadı” mesafesini ciddi biçimde kapatıyor.

MAVLink: GCS ile FC arasındaki ortak dil

GCS ile uçuş kontrolcüsü birbiriyle MAVLink (Micro Air Vehicle Link) protokolüyle konuşur. MAVLink, resmî tanımıyla dronelarla ve drone bileşenleri arasında haberleşmek için tasarlanmış “çok hafif” bir mesajlaşma protokolü. Dar bant ve gürültülü kanallar için optimize edilmiş.

Neden hafif olması önemli? Çünkü çerçeve yükü (overhead) doğrudan telemetri bütçenizi yer. Resmî dokümana göre MAVLink 1 paket başına 8 bayt, MAVLink 2 ise 12 bayt yük ekliyor (MAVLink 2 daha güvenli ve genişletilebilir olduğu için bu farka değer).

Telemetri linkinizin kaç mesaj taşıyabileceğini kabaca şöyle hesaplayabilirsiniz:

# 1) Seri porttan geçen etkin bayt hızı (8N1 çerçeveleme: bayt başına 10 bit)
bayt_hizi = baud / 10

# 2) Bir MAVLink 2 mesajının toplam boyutu
mesaj_boyutu = yuk_baytlari + 12

# 3) Teorik üst sınır
mesaj_hizi = bayt_hizi / mesaj_boyutu

Örnek: 57600 baud’luk klasik bir telemetri telsizi ve ATTITUDE mesajı (yükü 28 bayt) ile:

bayt_hizi    = 57600 / 10 = 5760 bayt/s
mesaj_boyutu = 28 + 12    = 40 bayt
mesaj_hizi   = 5760 / 40  = 144 mesaj/s   (teorik tavan)

Bu bir tavan, bir vaat değil. Gerçekte tek bir akış değil onlarca akış aynı anda gider (ATTITUDE, GLOBAL_POSITION_INT, SYS_STATUS, RC_CHANNELS…). Üstelik SiK sınıfı telsizlerde havadan veri hızı (air data rate) seri porttaki baud’dan bağımsız bir parametredir ve hata düzeltme ek yük getirir; gerçek verim için telsizinizin veri sayfasına bakın. Pratikte ArduPilot’ta SRn_* parametreleriyle her akışın Hz’ini kısarak bütçeyi elle yönetiyoruz.

Bağlantının kendisi de parametrelerle tanımlanır:

SERIALn_PROTOCOL = 1   # MAVLink1
SERIALn_PROTOCOL = 2   # MAVLink2 (tercih edin)
SERIALn_BAUD           # portun hızı; telemetri telsizlerinde tipik olarak 57600

Companion computer tarafında da aynı protokol geçerli — Jetson’dan FC’ye giden hat da MAVLink konuşur. Bunu ayrıntısıyla companion computer ve MAVLink rehberimizde yazdık.

Mission Planner vs QGroundControl

İkisi de açık kaynak (GPLv3) ve ikisi de ArduPilot ile çalışıyor. Fark, felsefede.

	Mission Planner	QGroundControl
Platform	Windows (ArduPilot GCS karşılaştırma sayfası macOS’ta Mono ile çalıştırılabildiğini not düşüyor)	Windows 10 (1809+)/11, macOS 13+, Ubuntu 22.04/24.04, Android 9+ (2026 itibarıyla)
Otopilot	ArduPilot odaklı	PX4 ve ArduPilot
Arayüz	Yoğun, sekmeli, her şey görünür	Sade, adım adım yönlendiren
Parametre erişimi	Full Parameter List / Tree ile ham erişim	Parametre arama ve düzenleme, daha filtrelenmiş sunum
Log analizi	Dataflash indirme + yerleşik grafik/analiz araçları	Analyze görünümü: Log Viewer (.bin ve .tlog), Download Logs, MAVLink Inspector
Tablet/saha	Zayıf	Android desteği var
Öğrenme eğrisi	Dik	Yumuşak

Ne zaman Mission Planner? ArduPilot kullanıyorsanız, derin parametre kurcalaması yapacaksanız, tuning döngüsündeyseniz ve masada Windows makineniz varsa. Biz SUAS 2026’da birincil istasyon olarak Mission Planner kullanıyoruz; sebebi ham parametre erişimi ve ArduPilot dokümanlarının büyük kısmının doğrudan Mission Planner ekranları üzerinden anlatılması.

Ne zaman QGroundControl? Ekipte macOS/Linux kullanan varsa, PX4 ile de çalışıyorsanız, sahada tablet üzerinden operasyon yapacaksanız veya ekibe yeni katılan birine ilk kurulumu yaptıracaksanız. Arayüzü daha az korkutucu.

İkisini birlikte kullanmak da mümkün — parametreler FC’de tutulur, GCS’te değil. Yani bir yazılımda yaptığınız ayar diğerinde de görünür.

Log analizi: tlog ve dataflash farkı

Bu, GCS’in en az kullanılan ama en değerli tarafı. İki farklı log türü var ve ikisi aynı şey değil:

	Telemetri log (.tlog)	Dataflash log (.bin)
Nerede oluşur	Yerde, GCS kaydeder	Havada, FC’nin SD kartında
İçerik	Linkten geçen MAVLink mesajları	FC’nin iç durumu, çok daha ayrıntılı
Hız	Telemetri bant genişliğiyle sınırlı	Aracın kendi döngü hızına yakın
Link koparsa	Kayıp	Etkilenmez
Ne için	“Operatör ne gördü, ne komut verdi”	“Araç gerçekte ne yaptı”

Kaza sonrası kök neden analizi neredeyse her zaman dataflash logunda çıkar. tlog ise operatör tarafını anlatır: hangi anda hangi komut gitti, link ne zaman koptu.

Loglamayı yöneten ArduPilot parametreleri:

LOG_BACKEND_TYPE   # 0=kapalı, 1=SD kart, 2=MAVLink akışı, 4=kart üzeri dataflash
LOG_BITMASK        # hangi kalemlerin loglanacağı
LOG_DISARMED       # arm beklemeden, güç verilir verilmez logla
LOG_FILE_DSRMROT   # disarm sonrası yeni log dosyası aç

LOG_DISARMED, arm olmayan bir aracı teşhis ederken hayat kurtarıyor — çünkü varsayılan davranışta log ilk arm ile başlar ve arm olmayan uçuşun kaydı hiç tutulmaz. Not: bu parametrenin 3 değeri, aracın arm durumuna geçmediği logları ayrıca siler; ne yaptığınızı bilerek kullanın.

Kuralımız basit: her uçuştan sonra, uçuş iyi geçse bile, dataflash logunu indir. SD kart doluyor, log numaraları çakışıyor ve iki hafta sonra “şu uçuşta bir tuhaflık vardı” dediğinizde veri artık yok.

Alternatifler

APM Planner 2.0 — Windows, macOS ve Linux’ta çalışan, GPLv3 lisanslı, daha hafif bir masaüstü seçeneği. Mission Planner kadar derin değil ama Linux’ta yerel çalışması avantaj.

MAVProxy — Komut satırı GCS’i. Linux üzerinde çalışır, Python ile genişletilebilir; ArduPilot dokümantasyonu doğrudan “kod geliştiricileri” için öneriyor. Asıl gücü MAVLink trafiğini çoğaltabilmesinde: tek bir seri porttan gelen akışı birden fazla istemciye dağıtır.

# FC'ye bağlan, konsol ve haritayı aç, akışı ayrıca UDP'ye yönlendir
mavproxy.py --master=/dev/ttyACM0,115200 \
            --out=udp:192.168.1.1:14550 \
            --console --map

Bu --out kalıbı bizim için kritik: aynı MAVLink akışını hem Mission Planner’a hem de kendi Python scriptimize aynı anda vermenin yolu bu. Jetson kurulum rehberimizde anlattığımız companion computer üzerinde de bu şekilde çalışıyoruz.

Sık düşülen tuzaklar

• Parametreleri yedeklemeden kurcalamak. Değişiklikten önce parametreleri dosyaya kaydedin. Tuning sırasında hangi değeri değiştirdiğinizi unutmak, sıfırdan başlamak demektir.
• Aynı seri porta iki şey bağlamak. Telemetri telsizi ve companion computer aynı SERIALn üzerinden geçemez. Ayrı port, ayrı SERIALn_PROTOCOL, ayrı baud.
• Baud uyuşmazlığını “bozuk kablo” sanmak. GCS bağlanmıyorsa önce baud’a bakın; telsiz çiftinin iki ucunun ayarı da eşleşmeli.
• Telemetri akış hızını sonuna kadar açmak. SRn_* değerlerini yükseltmek HUD’u akıcı gösterir ama linki doldurur; kritik anda komutunuz sıraya girer.
• Pusula kalibrasyonunu kapalı mekanda yapmak. Metal masa, güç kaynağı ve laptop manyetik alanı sonucu bozar. Açık alanda, aracı elde çevirerek yapın.
• Kalibrasyon ve motor testini pervaneler takılıyken yapmak. ESC kalibrasyonu ve GCS üzerinden motor testi motorları gerçekten döndürür. Pervaneleri sökün. Dönen bir pervane parmak keser; bu abartı değil, sahada olan bir şey. Aynı şekilde LiPo bağlıyken FC’nin USB’sine bağlanırken güç sıralamasına dikkat edin.
• Firmware’i sahada güncellemek. Yeni sürüm bazı parametreleri sıfırlayabilir veya yeniden adlandırabilir. Güncelleme masada yapılır, ardından tam bir yer testi gelir.

Pratik özet

1. Bir GCS seçin ve ekipçe ona hakim olun. ArduPilot ile çalışıyor ve derin parametre erişimi istiyorsanız Mission Planner; çapraz platform veya tablet gerekiyorsa QGroundControl.
2. SERIALn_PROTOCOL = 2 (MAVLink 2) kullanın, telemetri bütçenizi SRn_* akış hızlarıyla bilinçli yönetin.
3. Her uçuştan sonra dataflash logunu indirin — tlog operatörü, .bin aracı anlatır; kök neden neredeyse her zaman .bin’dedir.
4. Parametre yedeği alın, her ayar değişikliğini tarihiyle birlikte kaydedin.
5. Motor/ESC ile ilgili her testte pervaneleri sökün. GCS’ten verilen bir komut gerçek motoru döndürür.