ROS 1 konuları VPN üzerinden: duyurulan uç noktayı izleyin

İş istasyonunuz tünel üzerinden ROS 1 master'ına ulaşıyor ama konu listesi hâlâ boş görünüyor. Bu örüntü yaygın çünkü master kaydı ile konu taşıması iki farklı konuşmadır ve master üzerinden yalnızca birincisi geçer. Aşağıdaki kontrol listesi ikinci konuşmayı izler: bir yayıncının duyurduğu uç nokta, bir abonenin ulaşabilmesi gereken adres ve ikilinin konuşmasına izin veren yetki. Buradaki her şey yalnızca Noetic destek penceresi Mayıs 2025'te sona eren eski ROS 1 için geçerlidir.

Adım 1: master bağlantısının konu bağlantısı olmadığını kanıtlayın

Neyin çalıştığını neyin çalışmadığından ayırarak başlayın. Başarılı bir rostopic list, kabuğunuzun master'ın XMLRPC bağlantı noktasına ulaştığını ve master'ın konuları bildiğini kanıtlar; bir abonenin yayıncıya ulaşıp ulaşamayacağı hakkında hiçbir şey söylemez. Aşağıdaki üç komut bu farkı görünür kılar ve hepsi yalnızca okuma içindir.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

rostopic info çıktısı yayıncının düğüm URI'sini adlandırır; bu, yayıncının ana makinesindeki bir XMLRPC adresidir. Abonenizin bir sonraki çağıracağı adres budur, bu yüzden abonenin çalıştığı her yerden ulaşılabilir olmalıdır. Adres yalnızca robotun kendi LAN'ında bulunan bir arayüze işaret ediyorsa master araması başarılı olur ve veriler asla ulaşmaz.

Adım 2: duyurulan uç noktayı düğümün kendisinden okuyun

ROS 1, duyurduğu ana makine kimliğini ROS_IP veya ROS_HOSTNAME içinden seçer (biri ayarlıysa), aksi hâlde ana makinenin kendi ad çözümlemesine döner. Gerçekte başlatılan sürecin ortamını inceleyin, çünkü bir systemd birimi, kapsayıcı veya ikinci terminal testinizin çalıştığı kabuktan farklı bir değer taşıyabilir.

echo "$ROS_IP" "$ROS_HOSTNAME"
rosnode info /talker
getent hosts robot-host

Ana makine adı duyurusu yalnızca her eş bu adı amaçlanan ulaşılabilir adrese çözerse çalışır. Bu ad yalnızca robotun kendi ağı içinde çözülürse, tünelin diğer tarafındaki iş istasyonunun onu kullanma yolu yoktur ve DNS son eki göndermeyen bir VPN uyumsuzluğu daha da kötüleştirir. Topoloji yönlendirilmişse ROS_IP değerini tünel adresine ayarlamak daha küçük bir değişikliktir. Neyi seçerseniz seçin, her iki uç için de kaydedin, çünkü kimlik konusunda anlaşamayan bir yayıncı ve abone pazarlık eder ve sonra bağlanamaz.

Duyurulan URI hiçbir eşin yönlendiremeyeceği bir adres kullanıyorsa burada durun. Yanlış arayüze çözülen bir adı hiçbir güvenlik duvarı çalışması düzeltmez.

Adım 3: duyurulan adresi çözülebilir ve yönlendirilmiş yapın

URI elinizdeyken ulaşılabilirliği robottan değil abonenin ana makinesinden test edin. TCPROS bağlantı noktası pazarlık sırasında seçilir, bu yüzden yararlı erken test XMLRPC bağlantı noktasıdır ve yararlı geç test kurulmuş sokettir. Yalnızca tek yönde var olan bir rota, yönlendirilmiş VPN'lerde yaygın bir arızadır ve dönüş yolu gidiş yolu kadar önemlidir.

ip route get 10.70.0.2
nc -vz 10.70.0.2 33911
ss -tnp dst 10.70.0.2

Yönlendirilmiş TUN arayüzü bu IP konuşmalarını robotun Ethernet kesimini genişletmeden taşır; uzaktaki bir operatörün genellikle istediği budur. Yığındaki bir şey bunun yerine yayına veya multicast'a bağlıysa bu gereksinim ayrıca değerlendirilmelidir; tek bir aracı memnun etmek için tüneli TAP'a çevirmek ağı her katılımcı için genişletir.

Rota veya dönüş yolu eksikse burada durun. Kendi ana makinesinde yanıt veren ancak iş istasyonundan ulaşılamayan bir yayıncının yönlendirme sorunu vardır, ROS sorunu yoktur.

Adım 4: eşler arası konuşmaya izin verin ve tek bir konuyu izleyin

Yalnızca pazarlığı yapılan konuşmanın gerektirdiği bağlantı noktalarını açın ve her kuralı duyurulan katılımcılarla sınırlayın. Master'ın dinleyicisi konu yükü için bir aktarıcı değildir, bu yüzden yalnızca ona izin vermek yayıncının uç noktasını kapalı bırakır. ROS dinleyicilerini genel internete maruz bırakmak yerine özel VPN sınırında tutun.

rostopic hz /chatter
rostopic echo -n1 /chatter
rosnode ping /talker

Gerçek yayıncıdan gerçek aboneye zararsız bir konu izleyin ve hem duyurulan uç noktayı hem de yanıt yolunu doğrulayın. Tek bir ileti yolun çalıştığını kanıtlar; istikrarlı bir hız açık kaldığını kanıtlar. Eyleyici denetimini ve güvenlik kontrollerini yalnızca ağla ilgili olan bu testin dışında tutun, çünkü çalışan bir konu çalışan bir robotu belgelemez. Gözlemlediğiniz ROS sürümünü ve uç nokta çiftini kaydedin, böylece sonraki kişi topoloji değişikliğini bir gerilemeden ayırt edebilir.

Kontrol listesi, duyurulan URI aboneden ulaşılabilir olduğunda, pazarlığı yapılan bağlantı noktası yalnızca o eş için açık olduğunda, duyurulan tek bir konu aktığında ve ortam değerleri iki ana makine için kaydedildiğinde tamamlanır. Eski ROS 1 bu alanda düzeltme almayacak, bu yüzden kayıt insanlar değiştikten sonra da çalışmaya devam eden kısımdır.