VPN üzerinden ROS 2: keşif, veri yolu değildir

VPN'in karşıt uçlarındaki iki ROS 2 düğümü birbirlerinin konularını listeleyebilir ve yine de tek bir ileti bile iletemeyebilir. Keşif ve kullanıcı verileri, ayrı yollara sahip ayrı alışverişlerdir ve bir keşif sunucusu yükleri aktarmaz. Birini kontrol edip diğerini varsaymak, tünel veriyi hiç taşımadığında ekiplerin ara katman yazılımını değiştirmesine yol açar. Aşağıdaki prosedür, herhangi bir şey değiştirilmeden önce iki sonucu ayırır.

Keşif sunucusunun gerçekte taşıdığı şey

Fast DDS'de bir Discovery Server uç noktalar hakkında bilgi dağıtır: kimin yayımladığı, kimin abone olduğu ve her birinin hangi QoS'yi beklediği. Eşler birbirini tanıdıktan sonra kullanıcı verileri o sunucudan değil, doğrudan aralarında hareket eder. Sunucuya ulaşmak, tanıştırmaların aracısının yanıt verdiğini kanıtlar, daha fazlasını değil. Yönlendirilmiş bir VPN hâlâ eşlerin duyurduğu adresler arasında her iki yönde çalışan bir yola ihtiyaç duyar.

Bu ayrım, mevcut eşler veri alışverişine devam ederken yeni keşfin çalışmayı bıraktığı kısmi arızaları da açıklar. Bunları iki ayrı soruşturma olarak ele alın.

Düğümlerin gerçekte kullandığı RMW'yi okuyun

ROS 2 farklı ara katman yazılımları yükleyebilir ve kabuğunuzda dışa aktarılan bir değişken başka bir yerde başlatılan süreçlere ulaşmaz. Terminal geçmişiniz yerine çalışan sisteme sorun.

printenv RMW_IMPLEMENTATION
ros2 doctor --report | head -n 20

Ayarlanmamış bir değişken genellikle kurulu varsayılan anlamına gelir ve bu, aynı deneydeki makineler arasında farklılık gösterebilir. Rapor ayrıca kullanılan dağıtımı ve ara katman yazılımını belirtir, bu yüzden eşleştiklerini varsaymadan önce tünelin iki tarafında bunları karşılaştırın. ROS komut satırı arka plan programı durumu önbelleğe alır, bu nedenle ortamı değiştirdikten sonra onu yeniden başlatın; eski yapılandırma için eski bir arka plan programının yanıt vermesine izin vermeyin. Oturum açıkken iki ana bilgisayarın dağıtımını ve RMW'sini test notlarına yazın.

Keşfi ve veriyi iki sonuç olarak test edin

Zararsız bir konu seçin ve tanıştırmayı teslimattan ayrı ölçün. info komutu uç noktaları ve QoS'yi listeler, echo ise bir iletinin bağlantıyı gerçekten geçip geçmediğini kanıtlar.

ros2 topic info /chatter --verbose
ros2 topic echo /chatter --once

info çıktısında uç noktaların görünmesi bir keşif sonucudur. İletinin aboneye ulaşması bir taşıma sonucudur ve yalnızca ikincisi uygulamanın ihtiyaç duyduğu yolu test eder. Keşif çalışıp echo zaman aşımına uğradığında, keşif hizmeti yerine duyurulan adresleri ve dönüş yolunu inceleyin. Her iki komutu da her ana bilgisayardan çalıştırın, çünkü asimetrik bir VPN yolu genellikle yalnızca bir taraftan ortaya çıkar.

Her seferinde bir bağımlılığı değiştirin

Veri yolu başarısız olduğunda, aynı oturumda ara katman yazılımını, keşif modunu ve ileti boyutunu değiştirmekten kaçının, çünkü sonrasında hiçbir sonuç ilişkilendirilemez. Zenoh RMW meşru bir alternatiftir, ancak yönlendiricisi tünelden erişilebilir olması gereken başka bir bağımlılık haline gelir.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

Bu RMW altında yönlendirici, keşfi Jazzy'nin varsayılan düzeninde taşır ve çoklu yayın keşfi orada devre dışıdır, bu nedenle bağımlılık başka bir ara katman yazılımından ödünç alınan bir varsayımda değil, notlarınızda yer alır. Bir ayarı değiştirirken iş yükünü sabit tutun, ardından echo testini yineleyin ve yönü, ileti hızını ve bağlantı koşullarını kaydedin. Gerçek bir iyileştirmeyi şanslı bir yeniden bağlantıdan ayırmak için karşılaştırmayı iki kez çalıştırın. Bir değişiklik keşfi iyileştirirken teslimat aynı kalırsa, tanıştırma hizmetini taşımışsınız, veri yolunu değil.