Linux’lu robot kolumda tepkiler geç geliyor, PREEMPT_RT curunca gerçek zamanlı kontrol sağlayabilir mi?

[Ugur E.]

Arkadaşlar bir şey danışacağım. Bir süredir kendi kendime bir robot kolu projesi yürütüyorum, kontrol ünitesi olarak da sıradan bir Ubuntu kurulu x86 makine kullanıyorum. Kontrol döngüsünü 1 kHz civarında çalıştırmaya çalışıyorum ama maalesef servo sürücilere gönderdiğim komutlar bazen 10-20 ms geç geliyor, bazen de tam olarak aynı anda gitmiyor, yani belli bir jitter var. Özellikle diske yazma yapan bir loglama process’i arka planda açıkken durum daha da kötüleşiyor.

Önce görev önceliklerini ayarlamaya çalıştım, high priority verdim ama pek işe yaramadı. Sonra okudum ki sıradan Linux aslında gerçek zamanlı değil, best-effort bir sistem. Birkaç yerden PREEMPT_RT’ye bahsetildi, kernel’i yeniden derlemek ya da patchlemek gerekiyormuş. Peki gerçekten işimi görür bu konu?

Şimdi ikincisi de ş$: RTOS’a geçsem mi, yoksa PREEMPT_RT ile Linux üzerinde mi kalsam? VxWorks ya da FreeRTOS gibi şeyler düşünüyorum ama Linux’un sunduğu network, dosya sistemi, kütüphane desteği çok işime yarar. Tecrübesi olan var mı, nereden başlamalıyım, takılacağım yerler neler?

[Venom_35]

Reis bak olayın aslı tam olarak şu şekilde işliyor. Sıradan Linux çekirdeği aslında bir sunucu/iş istasyonu için optimize edilmiş, ortalamayı iyi tutmak ister ama tek bir işlemin ne kadar sürede tepki vereceğine garanti vermez. Sen 1 kHz’de ‘her seferinde tam zamanında ol’ dersen, doğal Linux sana bunu sunamaz. Çünkü iki şeyi yapamaz: kesmeleri çok kısa sürede bitiremez ve öncelik tersinmesini (priority inversion) giderebilir bir mekanizması uzun süre yoktu.

PREEMPT_RT aslında tam da bunları düzeltiyor. En büyük hamlelerden biri kesme işleyicilerini thread’e çevirmek, yani softirq’leri kullanıcı alanında çalıştırılabilir threadlere dönüştürmek. Böylece kesme sonrası yapılacak ağır işler başka bir görevin önüne giremiyor. İkincisi, öncelik tersinmesini önlemek için mutex’lere öncelik devretme (priority inheritance) eklemek. Basitçe ş$: düşük öncelikli bir görev bir kaynağı tutarken, yüksek öncelikli bir görev onun açısını bekliyorsa, düşük öncelikli görev geçici olarak o yüksek önceliği alıp kaynağı hızlıca geri verir. Eski Linux bunu yapamayıp senin döngünün beklemesine sebep oluyordu.

Pratikte dikkat etmen gerekenler şunlar: kernel’i PREEMPT_RT patch’li ile derlemen ya da hazır bir distro (Ubuntu Real Time paketi, ya da Yocto/Debian’ın linux-image-preempt_rt sürümü) kullanman lazım. Sonra power management’i kapat: C-state, turbo boost, frequency scaling gibi şeyler latency patlatır. İmplementasyon için isolcpus ve nohup/isolcpu ile bir CPU’yu döngü görevine ayır, scheduler’ı SCHED_FIFO’ye al. Test etmeden kesin production’a alma, latencyfs ya da cyclictest ile gerçek ölçüm yap, milisaniye değil mikrosaniye seviyesinde bak.

RTOS’a geçiş konusuna gelince: eğer ‘hard real-time’ diyorsen, yani bir seferlik bile miss deadline güvenlik/hasar riski taşıyorsa, VxWorks gibi sistemler o garantisi için orada duruyor. Ama robotik gibi soft-real-time dünyada, PREEMPT_RT ile Linux kullanıp 100-200 mikrosaniye seviyesinde deterministik sonuç alabiliyorsun ve network/fail sistemi/kütüphane lüksünden de vazgeçmiyorsun. Çoğu startup ve akademik projelik bende hep PREEMPT_RT + Linux ile gitmiş, sorun olmamıştır. Önce RT’ kerneli dene, ölç, sonra gerekirse karar ver. Kolay gelsin.

"Anakart: MSI MAG B650 Tomahawk"

"İşlemci: Ryzen 5 7600"

"RAM: 32GB DDR5 5600MHz"

[Yazar]

Yazılar