Hızlı CUDA Çekirdeği Yetmiyor: NVIDIA, ROS 2 Düğümünü AI Ajanla Sıfır Kopyaya Taşıdı

GPU hızlandırma robotikte tek başına yetmiyor. Hızlı bir CUDA çekirdeği yazdınız diyelim; mesaj düğümler arasında dolaşırken hâlâ CPU belleğinden serileştirilip kopyalanıyorsa, algı ve AI işini GPU'da tutmanın faydası eriyor. NVIDIA'nın 22 Eylül 2026 tarihli teknik blog yazısı tam bu noktaya parmak basıyor: sorun çekirdekte değil, ROS 2 grafiğinin taşıma katmanında . Şekil 1'de klasik yol — GPU çekirdeği biter, mesaj CPU'ya iner, serialize olur, tekrar kopyalanır — gösterilirken, Şekil 2'de yeni yolun nasıl düzleştiği anlatılıyor; üstelik bunu standart ROS mesajını bozmadan yapmanın yolu artık upstream'de var.

rosidl::Buffer nedir ve ROS 2 Lyrical'da ne değişti

ROS 2 Lyrical ile değişken uzunluklu primitive dizi alanları — örneğin `uint8[]` — artık üretilen C++ kodunda `rosidl::Buffer` olarak temsil ediliyor. Varsayılan CPU destekli `rosidl::Buffer`, mevcut kodun beklediği `std::vector` arayüzü gibi davranıyor; yani kaynak uyumluluğu korunuyor ve soyutlama takılabilir (pluggable) hale geliyor: platform sağlayıcıları ayrı mesaj tipi tanımlamadan alanın arkasındaki depolamayı harici yönetebiliyor. NVIDIA'nın katkısı olan CUDA buffer backend , aynı alanın arkasına CUDA Virtual Memory Management (VMM) ile GPU belleğini koyuyor; yayıncı ve abone aynı host, aynı CUDA cihazı, aynı Linux kullanıcısı ve destekli bir RMW (`rmw_fastrtps_cpp`, `rmw_zenoh_cpp`) koşullarını karşıladığında payload co-located düğümler arasında serileştirme veya host kopyası olmadan taşınabiliyor, aksi halde ROS 2 otomatik olarak CPU yoluna geri dönüyor.

Örnek düğüm: Depth Anything 3 neden biçilmiş kaftan

Eğitim örneği Depth Anything 3 (DA3) TensorRT ROS 2 düğümü ; ByteDance Seed'in modeli değişken sayıda görüntüden uzamsal olarak tutarlı geometri tahmin ediyor. Mevcut callback tanıdık: gelen ROS görüntüsünü OpenCV görünümüne çevir, NVIDIA TensorRT ile monoküler metrik derinlik çıkar, `cv::Mat`'i tekrar ROS görüntüsüne dönüştür ve 32FC1 float derinlik olarak yayınla (Video 1'de RGB→derinlik akışı gösteriliyor). Kod düz, ama kritik detay şu: algoritma zaten GPU-native iken onu çevreleyen ROS sınırı CPU-backed — CPU üretici/tüketici için doğru olan bu sınır, iki taraf da CUDA belleği üretip tüketebiliyorken gereksizleşip iki payload-büyüklüğünde host transferi + host tahsisi + serileştirme maliyetine dönüşüyor.

Amaç modeli yeniden tasarlamak veya mesajı değiştirmek değil; mevcut ROS sözleşmesini korurken çıktıdaki `Image.data` alanının uygun backend'den depolama taşımasına izin vermek. Yani aynı `sensor_msgs/msg/Image`, aynı topic, aynı API — sadece alanın arkası gerektiğinde CUDA destekli olabiliyor; edge'de her milisaniyenin sayıldığı Jetson AGX Thor gibi platformlarda algı boru hattını yeniden yazmadan hız kazanmanın pratik yolu bu.

AI ajanı devriye: migrate-node-to-rosidl-buffer becerisi

En zor işin sınırı doğru seçmek olduğunu söyleyen yazı, bu denetimi bir AI kodlama ajanına devrediyor. Amaç sihirli yeniden yazım değil; migrate-node-to-rosidl-buffer becerisi ajanı tekrarlanabilir iş akışına yönlendiriyor — şablonla düğümü değiştirmek yerine, ajan payload'u callback'ler ve yardımcı kütüphaneler boyunca izliyor, host-device sınırlarını buluyor, düğüm sözleşmesini koruyor ve kaynak, bağımlılık, launch ve test değişikliklerini koordine ediyor.

Beceri ajana sırayla şunları yaptırıyor: başlangıç revizyonunu ve ROS ortamını kaydet , üretilen mesaj alanı tipinin uyumunu doğrula ve CUDA buffer backend paketlerini bağımlılık olarak ekle , her mesaj alanını receipt'ten publication'a kadar izle (transitive CUDA çağrıları, stride, stream, opsiyonel çıktılar ve sahiplik dahil), salt-okunur copy-boundary audit 'ini çalıştır ve her sonucu bağlamında incele, kopyaları kaldıran / promotion veya materialization gerektiren alan bazlı migrasyon planı çıkar, en küçük arayüz koruyan yamayı uygula ve son olarak semantiği, backend pazarlığını, ayrı proses transportunu, buffer yaşam döngüsünü ve gerçek bellek kopyası davranışını bağımsız biçimde doğrula.

Refactor anatomisi: tek abonelik seçeneği, tek tahsis, iki handle

Becerinin ürettiği yama şaşırtıcı derecede küçük: çoğu değişiklik TensorRT sarmalayıcısını giriş/çıkış verisi için CUDA handle kabul edecek şekilde uyarlarken ROS taşıma değişikliği tek abonelik seçeneği, tek CUDA tahsisi, iki stream-aware handle çıkarımı ve tek publish ile sınırlı — özel mesaj, duplicate CUDA topic veya CPU/CUDA publisher dalı gerekmiyor . Mesaj tanımı `sensor_msgs/msg/Image` olarak kalıyor, pakete sadece `cuda_buffer` ve `cuda_buffer_backend` ekleniyor; abonelikte `rclcpp::SubscriptionOptions options; options.acceptable_buffer_backends = "cuda";` ile abone CUDA destekli buffer'ları kabul edecek şekilde güncelleniyor, CPU varsayılan fallback kaldığından ayrı CPU/CUDA callback'i gerekmiyor ve mevcut `image_transport` + `message_filters` topolojisi aynen korunuyor.

Çekirdek değişiklik callback içinde: çıktı mesajına `cuda_buffer_backend::allocate_buffer()` ile `Image.data` alanına CUDA destekli depolama veriliyor; `tensorrt_depth_anything_->getCudaStream()` üzerinden alınan stream ile ` from_input_buffer() ` gelen veriden okuma, ` from_output_buffer() ` ise giden veriye yazma için stream-güvenli CUDA handle'ları sağlıyor. TensorRT'nin CUDA post-process'i nihai 32FC1 sonucunu doğrudan bu handle üzerinden — device-to-host kopyası ve ara device-to-device ara çıktısı olmadan — giden mesaja yazıyor; iç kapsam yayın öncesi write handle'ı serbest bırakarak CUDA event'ini kaydedip CUDA operasyonlarının sırasını güvenceye alıyor, sonra `pub_depth_image_->publish(std::move(depth_msg))` her zamanki gibi aynı mesaj tipiyle çalışırken paylaşım middleware + backend tarafından otomatik yönetiliyor.

Beceri nokta bulutu oluşturma ve debug görselleştirme gibi yerel CPU tüketicilerini bilerek ayrı bırakıyor; etkinleştirildiklerinde hâlâ device-to-host kopyası ve senkronizasyon gerekebilir ama bu yollar depth topic'inde sunulan temsili belirlemediğinden migrasyon optimize yayın yolunu karmaşıklaştırmak yerine bu sınırları açık ve opsiyonel tutuyor — “her şeyi GPU'ya taşı” ezberini kıran pratik bir mimari kararı.

Derle, çalıştır ve Jetson Thor'a dağıt

Özellik ROS 2 Lyrical ile geldiğinden migrate edilmiş düğüm Lyrical ve üstünde destekli RMW'lerle (`rmw_fastrtps_cpp`, `rmw_zenoh_cpp`) çalışıyor; mesaj tipi ve çekirdek fonksiyonlar aynı kalırken pakete sadece `cuda_buffer` ve `cuda_buffer_backend` ekleniyor. Backend'i etkinleştirmek için `rosidl_buffer_backends` deposunu klonla (`git clone https://github.com/ros2/rosidl_buffer_backends.git`), `colcon build --symlink-install --packages-up-to cuda_buffer_backend`, `source install/setup.bash`, sonra `colcon build --symlink-install --packages-up-to depth_anything_v3` ve `export RMW_IMPLEMENTATION=rmw_fastrtps_cpp` ile aynı launch dosyasını koş — çekirdek `rosidl::Buffer` zaten Lyrical'da derli olduğundan core'u yeniden derlemeye gerek yok, backend bir plugin gibi davranıyor ve NVIDIA bunu Isaac ROS 5.0 yığını içinde Jetson AGX Thor hedefiyle sunuyor.

Doğrulama: Nsight'te host kopyası kayboldu mu?

Migrasyon TensorRT hesaplamasına dokunmuyor, etrafındaki taşımayı hedefliyor; doğrulama için NVIDIA Nsight Systems ile GPU aktivitesi inceleniyor — uygun CUDA yolunda ROS sınırında payload-büyüklüğünde host-to-device / device-to-host transferi görülmemeli ve karşılaştırılabilir latency önce/sonra kaydedilmeli (Şekil 3 migrate edilmiş DA3 düğümünün RGB→derinlik sonucunu korurken CUDA-backed depolama kullandığını gösteriyor). Backend pazarlığı için `msg->data.get_backend_type()` "cuda" döndürmeli; örnek abonede `acceptable_buffer_backends = "cuda"` ile loglayıp `cuda` değilse hata fırlatılan test, üretimde genellikle CPU fallback'i kabul et ve `from_input_buffer()`'ın otomatik promotion'ına bırak şeklinde kullanılıyor. Beceri ayrıca kaynak ve sink düğümleri üreterek iki ayrı boru hattı kurmayı sağlıyor: biri CPU veri yayınlayan kaynakla (gelen buffer CPU-backed, callback otomatik CPU→CUDA promotion yapıyor), diğeri CUDA veri yayınlayan kaynakla ( ek kopyasız CUDA handle) — aynı kod tek dal ile her iki kurulumda da doğru çalışarak migrasyonun gerçekten arayüz koruyan bir optimizasyon olduğunu kanıtlıyor.