Uçuş Kontrol Yazılımını Sahada Değil, Simülasyonda Kırın: 6-DOF ve SITL

Bir insansız hava aracı programında en pahalı test, uçan testtir.

Maliyeti sadece paradan ibaret değil: uygun hava koşulu beklersiniz, saha izni alırsınız, ekibi toplarsınız, bataryaları hazırlarsınız ve bütün bunlardan sonra elinizde bir uçuşluk veri olur. Bir şey ters giderse hem veriyi hem hava aracını kaybedersiniz. Ve kaybettiğiniz hava aracı, bir sonraki testi haftalarca geciktirir.

Buna rağmen pek çok ekipte uçuş kontrol yazılımının ilk ciddi sınavı sahada verilir.

Oysa bu yazılımdaki hataların büyük kısmı, hiç havalanmadan yakalanabilir. Bu yazı, bunun nasıl yapıldığı hakkında.

Test piramidinin havacılık tarafındaki karşılığı

Yazılım dünyasının test piramidi tanıdıktır: çok sayıda hızlı birim testi altta, az sayıda yavaş uçtan uca test üstte. Uçuş kontrol yazılımında da aynı mantık geçerlidir, sadece katmanların adları farklıdır.

• Birim testi. Ne çalışır: Tek fonksiyon · Ne taklit edilir: Her şey · Hız: Milisaniye
• MIL (Model-in-the-Loop). Ne çalışır: Kontrol algoritmasının modeli · Ne taklit edilir: Araç dinamiği, sensör · Hız: Saniye
• SITL (Software-in-the-Loop). Ne çalışır: Gerçek uçuş yazılımı, PC üzerinde · Ne taklit edilir: Donanım, sensör, araç dinamiği · Hız: Saniye–dakika
• HIL (Hardware-in-the-Loop). Ne çalışır: Gerçek yazılım, gerçek uçuş kartı · Ne taklit edilir: Araç dinamiği, sensör · Hız: Gerçek zaman
• Yer testi. Ne çalışır: Her şey gerçek · Ne taklit edilir: Uçuş · Hız: Dakika
• Uçuş testi. Ne çalışır: Her şey gerçek · Ne taklit edilir: Hiçbir şey · Hız: Saat–gün

Her katman, bir üstündekinin yükünü hafifletmek için vardır. Piramidin alt katmanları zayıfsa, bütün doğrulama yükü en pahalı katmana yığılır ve o katman uçuş testidir.

MIL: algoritmayı denklemle sınamak

En alt seviyede kontrol algoritmasını, aracın matematiksel modeliyle birlikte çalıştırırsınız. MATLAB/Simulink bu iş için yaygın araçtır.

Burada henüz "yazılım" yoktur; kontrolcünün kendisi vardır. Kazanımı şudur: bir kontrolcü tasarımının kararlı olup olmadığını, adım cevabının nasıl göründüğünü, kazanç ve faz payının yeterli olup olmadığını saniyeler içinde görürsünüz. Yüzlerce katsayı kombinasyonunu tarayıp en iyisini seçmek bu katmanda mümkündür; hiçbir üst katmanda değildir.

MIL'in yakalamadığı şey: kodun kendisi. Simulink'te çalışan bir kontrolcü, C'ye çevrildiğinde sayısal hassasiyet, zamanlama veya tamsayı taşması yüzünden başka türlü davranabilir.

SITL: gerçek yazılımı, sahte bir dünyada uçurmak

SITL'in fikri basit ve güçlüdür: uçuş kartına yüklediğiniz yazılımın aynısını, bilgisayarda derleyip çalıştırırsınız. Yazılım, sensörlerden veri okuduğunu ve motorlara komut verdiğini sanır. Aslında okuduğu veri bir simülasyondan gelir, verdiği komut da o simülasyona gider.

Açık kaynak uçuş kontrol yazılımlarının çoğu bunu destekler. Betaflight'ın SITL hedefi, PX4 ve ArduPilot'ın SITL ortamları bunun yaygın örnekleridir. Fiziksel dünya tarafında ise bir 6-DOF (altı serbestlik dereceli) araç dinamiği modeli çalışır.

6-DOF ne demek? Bir katı cismin uzaydaki hareketi altı bağımsız serbestlik derecesiyle tanımlanır: üç eksende yer değiştirme (x, y, z) ve üç eksende dönme (yuvarlanma, yunuslama, sapma). 6-DOF simülasyon, bu altı denklemi kuvvet ve moment girdileriyle birlikte zaman adımlarında çözer. Bir quadrotor için girdi, dört motorun ürettiği itki ve momenttir; çıktı ise aracın konumu ve yönelimidir. Kontrolcü bu çıktıyı sensör okuması olarak alır ve döngü kapanır.

SITL'in yakaladığı hatalar, sahada en pahalıya patlayanlardır:

• Eksen işareti hataları: bir eksenin ters bağlanması, sahada anında düşüş demektir
• Birim hataları: derece/radyan, metre/santimetre karışıklıkları
• Mod geçişleri: kalkış, seyir, dönüş, arıza modu arasındaki geçişlerde takılma
• Doyum ve integral birikmesi (integral windup) davranışı
• Arıza senaryoları: sinyal kaybı, sensör bozulması, motor arızası. Bunları sahada test edemezsiniz; simülasyonda istediğiniz kadar test edebilirsiniz.

Son madde tek başına SITL'i haklı çıkarır. Uçan bir araçta "GPS'i kaybedersek ne olur"u denemenin güvenli tek yolu, GPS'in olmadığı bir dünyayı simüle etmektir.

SITL'in yakalamadıkları (dürüst olmak gerekirse)

Simülasyona güvenmenin de bir sınırı var ve bu sınırı bilmeyen ekip, simülasyonda mükemmel çalışan bir yazılımla sahada düşer.

• Gerçek zamanlama. SITL bilgisayarda çalışır; uçuş kartındaki gerçek zamanlı işletim kısıtları, kesme gecikmeleri, döngü süresi aşımları burada görünmez. Bunun için HIL gerekir.
• Sensör gürültüsünün gerçek karakteri. Modele gürültü eklersiniz ama gerçek bir IMU'nun titreşim altındaki davranışı, sıcaklık kayması, ivmeölçer-jiroskop hizalama hatası tam olarak modellenemez.
• Aerodinamik. 6-DOF modeliniz ne kadar iyi olursa olsun, pervane-gövde etkileşimi, yer etkisi, rüzgâr türbülansı yaklaşımdır. Model doğrulanmadıkça simülasyon sonucu bir hipotezdir.
• Mekanik ve elektriksel gerçekler. Titreşim, konektör gevşemesi, elektromanyetik girişim.

Bu yüzden simülasyon uçuş testinin yerine geçmez. Uçuş testinin verimini artırır. Fark önemli: amaç sahaya çıkmamak değil, sahaya çıktığınızda bilinen hataları değil, ancak sahada öğrenilebilecek şeyleri öğrenmektir.

Model doğrulama: en çok atlanan adım

Simülasyon altyapısı kuran ekiplerin çoğunun atladığı adım şudur: modeli gerçek uçuş verisiyle karşılaştırmak.

Yapılması gereken, birkaç kontrollü uçuşta telemetri kaydetmek, aynı komut dizisini simülatöre vermek ve iki çıktıyı üst üste bindirmektir. Aradaki fark, modelinizin ne kadar güvenilir olduğunu söyler. Bu yapılmadıkça simülasyon güzel görünen bir animasyondan ibarettir.

Bu doğrulama bir kere yapılıp bırakılmaz; araç her değiştiğinde tekrarlanır.

Program yönetimi açısından ne kazandırır?

Bu yazının teknik olmayan tarafı burası ve karar vericiyi ilgilendiren kısım da bu.

Kritik yolu kısaltır. Uçuş testi hava koşuluna, saha iznine ve ekip müsaitliğine bağlıdır; simülasyon hiçbirine bağlı değildir. Test kapasitesini takvimden kurtarmak, bir Ar-Ge programında elde edebileceğiniz en büyük hızlanmalardan biridir.

Regresyonu mümkün kılar. Bir hatayı düzelttiğinizde eskisinin geri gelmediğini kanıtlamak istersiniz. Sahada bunu her seferinde yapamazsınız. Simülasyonda bütün test senaryolarını her gece çalıştırabilirsiniz.

Riski öne çeker. TRL 4'ten 6'ya geçerken en çok korkulan şey, geç ortaya çıkan sistem seviyesinde bir davranış hatasıdır. Simülasyon o hatayı aylar önce, ucuzken bulur.

Kanıt üretir. Kalifikasyon ve müşteri kabulünde "şu senaryoları şu kadar kere çalıştırdık, sonuçlar bunlar" diyebilmek, "sahada denedik, çalıştı"dan çok daha güçlü bir argümandır.

Nereden başlanır?

Sıfırdan kurulacaksa şu sıra işe yarar:

1. Uçuş yazılımınızın SITL desteği var mı, kontrol edin. Açık kaynak bir tabana dayanıyorsanız büyük ihtimalle vardır ve iş bir günlük kurulumdur.
2. Basit bir 6-DOF model kurun. Mükemmel olması gerekmez; eksen işaretlerini ve mod geçişlerini yakalayacak kadar iyi olması yeter. İlk günün kazancı zaten oradadır.
3. Beş senaryo yazın: normal kalkış, agresif manevra, sinyal kaybı, düşük batarya, motor arızası. Bunları otomatik çalıştırın.
4. Sonuçları kaydedin ve her kod değişikliğinde tekrar çalıştırın. Otomatikleştirilmeyen test, ikinci haftadan sonra çalıştırılmaz.
5. Modeli gerçek uçuş verisiyle doğrulayın ve bu doğrulamayı düzenli tekrarlayın.

İlk üç adım genellikle birkaç haftalık iştir. Karşılığında kazandığınız şey, projenin geri kalanı boyunca her hafta işleyen bir sigortadır.

---

Bu yazıdaki görüşler şahsıma aittir, çalıştığım kurumları bağlamaz.