ROS 2 melalui VPN: penemuan bukan laluan data

Dua nod ROS 2 di hujung bertentangan VPN boleh menyenaraikan topik satu sama lain dan masih gagal menghantar satu mesej pun. Penemuan dan data pengguna ialah pertukaran berasingan dengan laluan berasingan, dan pelayan penemuan tidak menyampaikan muatan. Memeriksa satu dan menganggap yang lain ialah cara pasukan akhirnya menggantikan middleware apabila terowong itu memang tidak pernah membawa data. Prosedur di bawah memisahkan kedua-dua hasil sebelum apa-apa ditukar.

Apa yang sebenarnya dibawa pelayan penemuan

Dalam Fast DDS, Discovery Server mengedarkan maklumat tentang titik akhir: siapa menerbitkan, siapa melanggan dan QoS apa yang dijangkakan setiap satu. Setelah rakan saling mengenali, data pengguna bergerak terus antara mereka dan bukan melalui pelayan itu. Mencapai pelayan membuktikan bahawa perantara pengenalan menjawab, tidak lebih. VPN yang dihalakan masih memerlukan laluan yang berfungsi dalam kedua-dua arah antara alamat yang diiklankan oleh rakan.

Perbezaan itu juga menjelaskan kegagalan separa, apabila rakan sedia ada terus bertukar data manakala penemuan baharu berhenti berfungsi. Anggap kedua-duanya sebagai dua siasatan.

Baca RMW yang sebenarnya digunakan nod

ROS 2 boleh memuatkan middleware yang berbeza, dan pemboleh ubah yang dieksport dalam shell anda tidak sampai kepada proses yang dimulakan di tempat lain. Tanya sistem yang sedang berjalan dan bukan sejarah terminal anda.

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

Pemboleh ubah yang tidak ditetapkan biasanya bermaksud lalai yang dipasang, yang boleh berbeza antara mesin dalam eksperimen yang sama. Laporan itu juga menamakan pengedaran dan middleware yang digunakan, jadi bandingkan kedua-duanya di kedua-dua belah terowong sebelum menganggap ia sepadan. Daemon baris perintah ROS menyimpan keadaan dalam cache, jadi mulakannya semula selepas menukar persekitaran dan bukannya membiarkan daemon lapuk menjawab untuk konfigurasi lama. Catat pengedaran dan RMW kedua-dua hos dalam nota ujian semasa sesi dibuka.

Uji penemuan dan data sebagai dua hasil

Pilih topik yang tidak berbahaya dan ukur pengenalan secara berasingan daripada penghantaran. Perintah info menyenaraikan titik akhir dan QoS, manakala echo membuktikan sama ada satu mesej benar-benar melintasi pautan.

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

Kemunculan titik akhir dalam output info ialah hasil penemuan. Ketibaan mesej di pelanggan ialah hasil pengangkutan, dan hanya yang kedua menguji laluan yang diperlukan aplikasi. Apabila penemuan berfungsi dan echo tamat masa, periksa alamat yang diiklankan dan laluan balik dan bukannya perkhidmatan penemuan. Jalankan kedua-dua perintah dari setiap hos, kerana laluan VPN tidak simetri selalunya hanya mendedahkan dirinya dari satu pihak.

Tukar satu kebergantungan pada satu masa

Apabila laluan data gagal, elakkan menukar middleware, mod penemuan dan saiz mesej dalam sesi yang sama, kerana tiada hasil boleh dikaitkan selepas itu. RMW Zenoh ialah alternatif yang sah, tetapi penghalanya menjadi satu lagi kebergantungan yang mesti boleh dicapai melalui terowong.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

Di bawah RMW itu, penghala membawa penemuan dalam susunan lalai Jazzy, dan penemuan multicast dilumpuhkan di sana, jadi kebergantungan itu tergolong dalam nota anda dan bukan dalam andaian yang dipinjam daripada middleware lain. Kekalkan beban kerja tetap semasa anda menukar satu tetapan, kemudian ulangi ujian echo dan catat arah, kadar mesej dan keadaan pautan. Jalankan perbandingan dua kali untuk memisahkan penambahbaikan sebenar daripada penyambungan semula yang bertuah. Jika sesuatu perubahan meningkatkan penemuan tetapi penghantaran kekal sama, anda telah memindahkan perkhidmatan pengenalan, bukan laluan data.