ROS2 DDS QoS Ayarları: Robotikte Deterministik Mesajlaşma

ROS2'nin altındaki DDS katmanı, doğru yapılandırıldığında endüstriyel sınıf bir yayın-abonelik altyapısıdır; yanlış yapılandırıldığında ise en sinsi hata sınıflarından birini üretir: sessizce eşleşmeyen publisher/subscriber çiftleri, yük altında birikip taşan kuyruklar ve açıklaması zor gecikme sıçramaları. Bu sorunların büyük bölümü QoS (Quality of Service) sözleşmesinin bilinçsizce kurulmasından kaynaklanır. Bu yazıda üretim robotiği bağlamında reliability, durability ve deadline politikalarını, DDS vendor'ları arasındaki pratik farkları ve executor tarafında determinizmi korumanın yollarını doğrudan uygulanabilir örneklerle ele alıyorum.

QoS Bir Sözleşmedir: RxO Kuralı

DDS'te QoS, publisher'ın sunduğu (offered) ile subscriber'ın talep ettiği (requested) profillerin karşılaştırılmasıyla çalışır; buna RxO (Requested vs Offered) kuralı denir. Publisher'ın sunduğu garanti, subscriber'ın talebi kadar veya ondan daha güçlü olmak zorundadır. BEST_EFFORT yayın yapan bir publisher'a RELIABLE bekleyen bir subscriber bağlanmaz — ve kritik nokta şu: bu durumda çalışma zamanında hata fırlatılmaz, iki endpoint sadece sessizce eşleşmez. Sahada “topic görünüyor ama veri gelmiyor” şikâyetlerinin klasik nedeni budur. İlk teşhis aracınız ros2 topic info /scan --verbose olmalı: komut, her endpoint'in QoS profilini ayrı ayrı gösterir. Uyumsuzlukları çalışma zamanında yakalamak içinse incompatible QoS event callback'lerini bağlayın.

Üç Kritik Politika

Reliability. RELIABLE modda DDS kaybolan örnekleri yeniden iletir; bunun bedeli bant genişliği ve tail latency'dir. BEST_EFFORT kaybolan örneği unutur. Yüksek frekanslı sensör verisinde neredeyse her zaman BEST_EFFORT + KEEP_LAST(1) doğru seçimdir: 100 ms önceki LiDAR taramasını yeniden iletmenin kimseye faydası yok, önemli olan en güncel örnektir. Komut, mod değişimi ve durum makinesi geçişleri gibi kaybı tolere edilemeyen mesajlarda ise RELIABLE kullanın.

Durability. VOLATILE, abonelikten önce yayınlanmış örnekleri yok sayar; TRANSIENT_LOCAL, publisher tarafında saklanan son örnekleri geç katılan (late-joining) subscriber'lara teslim eder. tf_static, harita ve robot_description gibi “bir kez yayınla, herkes alsın” verileri TRANSIENT_LOCAL ister. Yüksek frekanslı topic'lerde ise TRANSIENT_LOCAL, gereksiz bellek ve discovery yükü demektir.

Deadline. Deadline, periyodik veri için bir tazelik sözleşmesidir: publisher “en geç her X ms'de bir örnek” taahhüt eder, subscriber da bunu talep eder. Taahhüt kaçırıldığında iki tarafta da event callback tetiklenir — yani ekstra kod yazmadan middleware seviyesinde bir watchdog elde edersiniz. RxO burada da geçerlidir: publisher'ın sunduğu periyot, subscriber'ın talep ettiğinden büyük olamaz.

Politika	Değerler	Tipik kullanım	Dikkat
Reliability	RELIABLE / BEST_EFFORT	Komutlar / LiDAR, kamera, IMU	RELIABLE + yavaş subscriber = kuyruk birikmesi
Durability	VOLATILE / TRANSIENT_LOCAL	Akış verisi / tf_static, harita	TRANSIENT_LOCAL isteyen subscriber, VOLATILE publisher ile eşleşmez
Deadline	periyot (ms)	Kontrol döngüleri, füzyon girişleri	Offered periyot ≤ requested periyot olmalı
History	KEEP_LAST(n) / KEEP_ALL	Çoğu durumda KEEP_LAST(1–10)	KEEP_ALL + RELIABLE bellek kullanımını sınırsız büyütebilir

Örnek: Deadline'lı IMU Aboneliği

rclcpp'nin hazır SensorDataQoS() profili (BEST_EFFORT, VOLATILE, KEEP_LAST(5)) çoğu sensör için iyi bir başlangıçtır; aşağıdaki örnek buna deadline ve kaçırılma callback'i ekliyor:

auto qos = rclcpp::SensorDataQoS()
               .keep_last(1)
               .deadline(std::chrono::milliseconds(15));

rclcpp::SubscriptionOptions opts;
opts.event_callbacks.deadline_callback =
    [this](rclcpp::QOSDeadlineRequestedInfo & info) {
      RCLCPP_WARN(get_logger(),
                  "IMU deadline kaçtı (toplam: %d)", info.total_count);
      fusion_->mark_stale(SensorId::kImu);  // kanalı bayat işaretle
    };

imu_sub_ = create_subscription<sensor_msgs::msg::Imu>(
    "/imu/data", qos,
    std::bind(&FusionNode::on_imu, this, std::placeholders::_1),
    opts);

Publisher tarafında da aynı periyodu taahhüt etmeyi unutmayın; deadline yalnızca subscriber'da tanımlıysa eşleşme yine RxO kuralına takılır.

DDS Vendor Farkları

QoS semantiği OMG DDS standardında tanımlıdır ama discovery, transport ve threading davranışı implementasyona göre ciddi biçimde değişir:

Fast DDS (Humble ve sonrasında varsayılan RMW): FASTRTPS_DEFAULT_PROFILES_FILE ile gösterilen XML profilleriyle ince ayar yapılır. Data-sharing ve loaned message API'siyle büyük mesajlarda (PointCloud2, Image) zero-copy mümkündür; publish modunu SYNCHRONOUS'a çekmek düşük gecikme hedefleyen sistemlerde tail latency'yi belirgin azaltır.
Cyclone DDS (Galactic'te varsayılandı): CYCLONEDDS_URI ile tek XML dosyası üzerinden yapılandırılır; konfigürasyon yüzeyi küçük, varsayılanları öngörülebilirdir. iceoryx entegrasyonuyla shared memory transport sunar.
RTI Connext: Ticari lisanslıdır; tooling'i (Admin Console) ve güvenlik/sertifikasyon paketleri geniştir. Savunma ve havacılık projelerinde sık karşılaşırsınız.

RMW katmanını değiştirmek tek satırdır: export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp. Ancak bir vendor'da doğruladığınız gecikme profili diğerine otomatik taşınmaz; geçişten sonra ros2 topic hz, ros2 topic delay ve ros2_tracing (LTTng) ile ölçümü mutlaka tekrarlayın.

Executor ve İşletim Sistemi: Determinizmin Diğer Yarısı

QoS'u doğru kursanız bile mesaj, callback'iniz koşana kadar deterministik değildir. Pratikte dikkat edilecekler:

Varsayılan SingleThreadedExecutor her spin döngüsünde wait-set'i yeniden kurar ve heap allocation yapar; bu, yük altında jitter üretir. Yeni dağıtımlardaki EventsExecutor bu maliyeti büyük ölçüde ortadan kaldırır.
MultiThreadedExecutor kullanacaksanız callback group'ları bilinçli seçin: aynı mutually exclusive gruptaki callback'ler birbirini bekler; reentrant gruplarda paylaşılan durumu kendi kilidinizle korumanız gerekir.
Kontrol düğümünü SCHED_FIFO önceliğiyle koşturun, mlockall ile belleği kilitleyin, kritik çekirdekleri izole edin ve IRQ affinity ayarlayın. PREEMPT_RT yamalı bir çekirdek doğru yapılandırıldığında planlama gecikmesini tipik olarak onlarca mikrosaniye bandına çeker; bu katmanın ayrıntıları hard real-time Linux yapılandırması başlığı altında başlı başına bir konudur.
DDS'in kendi thread'lerinin önceliğini unutmayın: kullanıcı kodu RT önceliğinde koşarken middleware thread'leri varsayılan öncelikte kalırsa veri yolundaki en yavaş halka onlar olur.

Sensör Füzyonu Bağlamında QoS

Tipik bir füzyon hattında 400 Hz IMU, 10–20 Hz LiDAR ve 30 fps kamera aynı düğümde birleşir; üç akışın QoS ihtiyacı birbirinden farklıdır ve tek bir varsayılan profil üçünü birden karşılamaz. En tehlikeli senaryo, QoS uyumsuzluğunun sensörlerden birini sessizce düşürmesidir: message_filters'ın ApproximateTime senkronizatörü kalan girişlerle çalışmaya devam eder, füzyon dışarıdan “çalışıyor” görünür, ama durum kestiriminin kovaryansı sessizce bozulur. Pratik çözüm, her sensör girişine ayrı deadline tanımlayıp kaçırılma event'inde ilgili kanalı bayat (stale) işaretlemek ve filtreyi kontrollü biçimde degrade etmektir. Zaman damgalarının kaynak saatte üretildiğini, ağ genelinde PTP senkronu yoksa ApproximateTime'ın yanılabileceğini de hesaba katın. Bu desenlerin çok sensörlü mimarilere nasıl ölçeklendiği sensör füzyonu sayfasında ayrıntılı olarak ele alınıyor.

Elinizdeki ROS2 sisteminde QoS eşleşmelerini, executor yapılandırmasını ve uçtan uca gecikme bütçesini sistematik biçimde gözden geçirmek istiyorsanız, gerçek zamanlı sistemler için mimari denetim kapsamı tam olarak bu katmanları hedefliyor.