ROS 2 melalui VPN: penemuan bukan jalur data

Dua node ROS 2 di ujung VPN yang berlawanan dapat mencantumkan topik satu sama lain dan tetap gagal mengirim satu pesan pun. Penemuan dan data pengguna adalah pertukaran terpisah dengan jalur terpisah, dan server penemuan tidak meneruskan payload. Memeriksa yang satu dan menganggap yang lain adalah cara tim akhirnya mengganti middleware padahal terowongan memang tidak pernah membawa data. Prosedur di bawah memisahkan kedua hasil sebelum apa pun diganti.

Apa yang sebenarnya dibawa server penemuan

Di Fast DDS, Discovery Server mendistribusikan informasi tentang endpoint: siapa yang memublikasikan, siapa yang berlangganan, dan QoS apa yang diharapkan masing-masing. Setelah peer saling mengenal, data pengguna berpindah langsung di antara mereka alih-alih melalui server itu. Mencapai server membuktikan bahwa perantara perkenalan menjawab, tidak lebih. VPN yang dirutekan tetap memerlukan jalur yang berfungsi di kedua arah antara alamat yang diiklankan peer.

Perbedaan itu juga menjelaskan kegagalan sebagian, ketika peer yang ada terus bertukar data sementara penemuan baru berhenti berfungsi. Perlakukan keduanya sebagai dua penyelidikan.

Baca RMW yang benar-benar dipakai node

ROS 2 dapat memuat middleware yang berbeda, dan variabel yang diekspor di shell Anda tidak menjangkau proses yang dimulai di tempat lain. Tanyakan sistem yang berjalan, bukan riwayat terminal.

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

Variabel yang tidak disetel biasanya berarti default terpasang, yang dapat berbeda antar mesin dalam eksperimen yang sama. Laporan juga menyebutkan distribusi dan middleware yang digunakan, jadi bandingkan keduanya di kedua sisi terowongan sebelum menganggapnya cocok. Daemon baris perintah ROS menyimpan status di cache, jadi mulai ulang setelah mengubah lingkungan alih-alih membiarkan daemon usang menjawab untuk konfigurasi lama. Catat distribusi dan RMW kedua host di catatan pengujian selama sesi terbuka.

Uji penemuan dan data sebagai dua hasil

Pilih topik yang tidak berbahaya dan ukur perkenalan secara terpisah dari pengiriman. Perintah info mencantumkan endpoint dan QoS, sedangkan echo membuktikan apakah satu pesan benar-benar melintasi tautan.

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

Munculnya endpoint di keluaran info adalah hasil penemuan. Tibanya pesan di pelanggan adalah hasil transportasi, dan hanya yang kedua melatih jalur yang dibutuhkan aplikasi. Saat penemuan berfungsi dan echo habis waktu, periksa alamat yang diiklankan dan rute kembali alih-alih layanan penemuan. Jalankan kedua perintah dari setiap host, karena rute VPN asimetris sering hanya terungkap dari satu sisi.

Ubah satu dependensi dalam satu waktu

Saat jalur data gagal, hindari mengubah middleware, mode penemuan, dan ukuran pesan dalam sesi yang sama, karena tidak ada hasil yang dapat dikaitkan setelahnya. RMW Zenoh adalah alternatif yang sah, tetapi routernya menjadi dependensi lain yang harus dapat dijangkau melalui terowongan.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

Di bawah RMW itu, router membawa penemuan dalam susunan Jazzy default, dan penemuan multicast dinonaktifkan di sana, jadi dependensi itu masuk ke catatan Anda, bukan ke asumsi yang dipinjam dari middleware lain. Pertahankan beban kerja tetap saat Anda mengubah satu pengaturan, lalu ulangi uji echo dan catat arah, laju pesan, dan kondisi tautan. Jalankan perbandingan dua kali untuk memisahkan perbaikan nyata dari penyambungan ulang yang beruntung. Jika suatu perubahan meningkatkan penemuan sementara pengiriman tetap sama, Anda telah memindahkan layanan perkenalan, bukan jalur data.