Giriş

"RTOS kullandın mı?" sorusu, gömülü yazılım mülakatlarının klasiği. Ama bu soruya gerçekten anlamlı bir cevap verebilmek için önce şunu anlamak gerekiyor: RTOS'u neden kullanıyorsunuz?

Drone otopilot yazılımı aynı anda onlarca farklı görevi yönetmek zorunda. IMU'dan saniyede 400 kez veri okumak, bu veriden anlık PID hesabı yapmak, ESC'lere motor komutları göndermek, GPS ve barometre verilerini EKF filtresinden geçirmek, DroneCAN üzerindeki sensörlerle konuşmak, yer istasyonuna MAVLink telemetri paketleri atmak... Ve tüm bunları deterministik, öngörülebilir zamanlama ile yapmak.

İşte bu noktada RTOS devreye girer: görevler arasındaki zamanlamayı ve önceliklendirmeyi çözer. Kritik döngüler her zaman önce koşar; düşük öncelikli işler ancak işlemci boşta kaldığında çalışır.

RTOS Olmadan Ne Olur? Süperloop Yaklaşımı

FPV racing sistemlerini düşünün. Betaflight, KISS — bunların neredeyse tamamı RTOS kullanmaz. Bunun yerine main loop içinde her şeyi sırayla çalıştıran bir süperloop mantığı var:

while (true) {
    scheduler();  // hangi task'ın sırası geldi?
}

Bu yaklaşım FPV için yeterli çünkü sistem tek bir şey yapıyor: mümkün olduğunca hızlı PID döngüsü koşturmak. 8 kHz döngü frekansı = 125 mikrosaniye — bütün döngü bu süreye sığmak zorunda.

Ama multirotor otopilotta bu yaklaşım çöküyor. Bir görevi bloklayan işlem (yavaş bir SD kart yazımı gibi), IMU okumasını geciktirebilir. Bu da tutarsız PID hesaplamasına, titreyen uçuşa ya da en kötü senaryoda kazaya yol açar.

Multirotor Otopilotta Görev Öncelik Haritası

Gerçek bir uçuş kontrol yazılımındaki görev hiyerarşisi aşağıdaki gibidir. Her görevin farklı bir frekansı ve önceliği var; RTOS bu önceliklere göre işlemci zamanını dağıtır:

Öncelik	Görev	Açıklama	Frekans
P1 — Kritik	IMU okuma	Ham ivme/gyro verisi	400 Hz
P2	PID / attitude ctrl	Roll, pitch, yaw döngüsü	400 Hz
P3	ESC / motor output	PWM / DSHOT komutları	400 Hz
P4	EKF / GPS füzyon	Konum tahmini, navigasyon	50 Hz
P5	DroneCAN polling	GPS, manyetometre, ESC	10–50 Hz
P6	MAVLink telemetri	GCS'e heartbeat, durum	10 Hz
P7 — Düşük	Logging / spray	Uçuş kaydı, ilaçlama	1–5 Hz

FreeRTOS

2003'ten bu yana gömülü yazılımın en yaygın RTOS'u. Amazon tarafından geliştirilen ve MIT lisansıyla dağıtılan FreeRTOS, minimalist tasarımıyla öne çıkıyor.

Güçlü yanları

• Kernel boyutu 6–12 KB; kaynak kısıtlı MCU'larda rahat çalışır
• STM32F1'den H7'ye kadar geniş platform desteği
• Task, queue, semaphore, mutex, event group — tüm temel primitifler mevcut
• SafeRTOS varyantı ile DO-178C sertifikasyonu mümkün

Zayıf yanları

• POSIX uyumu yok — Linux'ta geliştirdiğiniz kodu doğrudan port edemezsiniz
• Sürücü altyapısı yok; donanım sürücülerini kendiniz yazıyorsunuz

NuttX

PX4 Autopilot'un resmi çekirdeği. Apache 2.0 lisansıyla dağıtılan NuttX, gerçek bir POSIX-compliant RTOS olmasıyla diğerlerinden ayrılıyor.

Güçlü yanları

• Tam POSIX API — Linux'ta yazılan kod çok az değişiklikle Pixhawk'a taşınıyor
• VFS (Virtual File System) — sürücüler /dev/imu0, /dev/gps0 gibi dosya olarak görünüyor
• uORB mesajlaşma sistemi NuttX üzerine inşa edilmiş; PX4'ün pub-sub mimarisinin temeli

Neden PX4 NuttX seçti?

POSIX API sayesinde bir PX4 modülünü Linux üzerinde geliştirip test edebilir, ardından minimal değişiklikle Pixhawk'a taşıyabilirsiniz. Bu, özellikle büyük açık kaynak projelerinde contributor sayısını ciddi ölçüde artırıyor.

Zephyr

Linux Foundation çatısı altında geliştirilen Zephyr, 2016'dan bu yana hızla büyüyen modern bir RTOS. IoT ve gömülü dünyada "bir sonraki FreeRTOS" olma iddiasıyla ilerliyor.

Güçlü yanları

• Devicetree tabanlı konfigürasyon — donanım bağımsızlığı üst seviyede
• Modern toolchain: CMake, west build sistemi
• Nordic nRF serisi için birinci sınıf destek — ELRS receiver'larda fiilen kullanımda
• IEC 61508 sertifikasyon yolu açık

UAV ekosistemindeki durumu

• PX4 veya ArduPilot entegrasyonu henüz yok
• ELRS firmware'i üzerinden UAV donanımına girmiş durumda
• Gelecek 2–3 yılda ciddi bir yer edinmesi bekleniyor

FPV'lerde Gerçekten RTOS Yok mu?

Teknik olarak doğru — ama biraz nüanslı. Betaflight'ta bir scheduler var, ama bu bir RTOS scheduler'ı değil. Elle yazılmış, öncelik tabanlı bir görev sıralaması.

// Betaflight scheduler mantığı (sadeleştirilmiş)
while (true) {
    scheduler();  // hangi task'ın sırası geldi?
}

Asıl kritik nokta: IMU okuma ve PID hesabı scheduler'dan bile bağımsız. Bu iki görev doğrudan gyro interrupt handler (ISR) içinde koşuyor.

Neden RTOS almıyor?

• Tek kritik görev: gyro → PID → motor. Geri kalan her şey gecikebilir
• RTOS context switch overhead'i sub-millisecond döngülerde hissedilir. 8 kHz = 125 µs
• Flash/RAM kısıtlı: STM32F7 = 512 KB flash — kernel için yer yok

Karşılaştırma

Kriter	FreeRTOS	NuttX	Zephyr
Kernel boyutu	~6–12 KB	~50–200 KB	~8–512 KB
POSIX uyumu	Kısmi	Tam	Kısmi+
Öğrenme eğrisi	Düşük	Dik	Orta
RAM kullanımı	Çok az	Fazla	Orta
Uçuşta olgunluk	Yaygın	Standart	Büyüyor
UAV kullanımı	ArduPilot/ChibiOS	PX4 resmi	ELRS / araştırma

Sonuç

RTOS seçimi çoğu zaman teknik performanstan çok ekosistem uyumluluğu ve geliştirici deneyimi tarafından belirleniyor. PX4 ile çalışıyorsanız NuttX zaten sizi bekliyor. ArduPilot ile çalışıyorsanız ChibiOS/FreeRTOS paradigması. Yeni bir şey inşa ediyorsanız Zephyr ciddi bir alternatif.

Ama şunu unutmayın: hangi RTOS'u seçerseniz seçin, deterministik zamanlama ve görev önceliklendirmesi konusundaki temel anlayışı edinmeden sadece araç bilmek yeterli değil. RTOS'u anlamak, uçuş yazılımının nasıl nefes aldığını anlamak demek.