Topik ROS 1 melalui VPN: ikuti titik akhir yang diumumkan

Stesen kerja anda mencapai master ROS 1 melalui terowong dan masih memaparkan senarai topik yang kosong. Corak itu biasa kerana pendaftaran master dan pengangkutan topik ialah dua perbualan berbeza, dan hanya yang pertama melalui master. Senarai semak di bawah menelusuri perbualan kedua: titik akhir yang diumumkan penerbit, alamat yang mesti dicapai pelanggan, dan kebenaran yang membolehkan pasangan itu bercakap. Semua di sini terhad kepada ROS 1 lama, yang tetingkap sokongan Noetic-nya berakhir pada Mei 2025.

Langkah 1: buktikan sambungan master bukan sambungan topik

Mulakan dengan memisahkan apa yang berfungsi daripada apa yang tidak. rostopic list yang berjaya membuktikan shell anda dapat mencapai port XMLRPC master dan master mengetahui topik; ia tidak menyatakan apa-apa tentang sama ada pelanggan dapat mencapai penerbit. Tiga arahan di bawah menjadikan perbezaan itu kelihatan, dan semuanya hanya baca.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

Output rostopic info menamakan URI nod penerbit, iaitu alamat XMLRPC pada hos penerbit. Alamat itulah yang akan dipanggil pelanggan anda seterusnya, jadi ia mesti boleh dicapai dari mana-mana pelanggan itu berjalan. Jika ia menunjuk ke antara muka yang hanya wujud pada LAN robot itu sendiri, carian master berjaya dan data tidak pernah tiba.

Langkah 2: baca titik akhir yang diumumkan dari nod itu sendiri

ROS 1 memilih identiti hos yang diumumkannya daripada ROS_IP atau ROS_HOSTNAME apabila salah satunya ditetapkan, dan jika tidak kembali kepada peleraian nama hos itu sendiri. Periksa persekitaran proses yang benar-benar dilancarkan, kerana unit systemd, kontena atau terminal kedua mungkin membawa nilai berbeza daripada shell tempat ujian anda berjaya.

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

Pengumuman nama hos hanya berfungsi jika setiap rakan menyelesaikan nama itu kepada alamat yang boleh dicapai yang dimaksudkan. Jika nama itu hanya diselesaikan dalam rangkaian robot itu sendiri, stesen kerja di seberang terowong tiada cara untuk menggunakannya, dan VPN yang tidak menolak sebarang akhiran DNS menjadikan ketidakpadanan lebih teruk. Menetapkan ROS_IP kepada alamat terowong ialah perubahan yang lebih kecil apabila topologinya dihalakan. Apa pun yang anda pilih, catatkannya untuk kedua-dua hujung, kerana penerbit dan pelanggan yang tidak bersetuju tentang identiti akan berunding dan kemudian gagal bersambung.

Berhenti di sini jika URI yang diumumkan menggunakan alamat yang tiada rakan boleh halakan. Tiada kerja tembok api akan membaiki nama yang diselesaikan kepada antara muka yang salah.

Langkah 3: jadikan alamat yang diumumkan boleh diselesaikan dan dihalakan

Dengan URI di tangan, uji kebolehcapaian dari hos pelanggan dan bukan dari robot. Port TCPROS dipilih semasa rundingan, jadi ujian awal yang berguna ialah port XMLRPC dan ujian lewat yang berguna ialah soket yang telah terbentuk. Laluan yang hanya wujud dalam satu arah ialah kegagalan biasa pada VPN yang dihalakan, dan laluan balik sama pentingnya dengan laluan hadapan.

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

Antara muka TUN yang dihalakan membawa perbualan IP ini tanpa meluaskan segmen Ethernet robot, yang biasanya dikehendaki oleh pengendali jauh. Jika sesuatu dalam tindanan bergantung pada siaran atau multicast, keperluan itu mesti dinilai secara berasingan; menukar terowong kepada TAP untuk memenuhi satu alat meluaskan rangkaian kepada setiap peserta.

Berhenti di sini jika laluan atau laluan balik tiada. Penerbit yang menjawab pada hosnya sendiri tetapi tidak boleh dicapai dari stesen kerja mempunyai masalah penghalakan, bukan masalah ROS.

Langkah 4: benarkan perbualan rakan dan perhatikan satu topik

Buka hanya port yang diperlukan oleh perbualan yang dirundingkan, dan hadkan setiap peraturan kepada peserta yang diisytiharkan. Pendengar master bukan penyampai untuk muatan topik, jadi membenarkannya sahaja membiarkan titik akhir penerbit tertutup. Kekalkan pendengar ROS di sempadan VPN peribadi dan bukan mendedahkannya kepada internet awam.

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

Perhatikan satu topik tidak berbahaya dari penerbit sebenar ke pelanggan sebenar dan sahkan kedua-dua titik akhir yang diumumkan dan laluan balasan. Satu mesej membuktikan laluan itu berfungsi; kadar yang stabil membuktikan ia kekal terbuka. Jauhkan kawalan penggerak dan pemeriksaan keselamatan daripada ujian rangkaian semata-mata ini, kerana topik yang berfungsi tidak memperakui robot yang berfungsi. Catat versi ROS dan pasangan titik akhir yang anda perhatikan, supaya orang seterusnya dapat membezakan perubahan topologi daripada regresi.

Senarai semak selesai apabila URI yang diumumkan boleh dicapai dari pelanggan, port yang dirundingkan terbuka hanya untuk rakan itu, satu topik yang diisytiharkan mengalir, dan nilai persekitaran dicatat untuk kedua-dua hos. ROS 1 lama tidak akan menerima pembaikan dalam bidang ini, jadi rekod ialah bahagian yang terus berfungsi selepas orang bertukar.