Mga paksa ng ROS 1 sa VPN: sundan ang inihayag na endpoint

Nararating ng iyong workstation ang master ng ROS 1 sa pamamagitan ng tunnel at nagpapakita pa rin ng walang laman na listahan ng paksa. Karaniwan ang pattern na ito dahil ang pagpaparehistro sa master at ang pagdadala ng paksa ay dalawang magkaibang usapan, at ang una lamang ang dumadaan sa master. Ang checklist sa ibaba ay dumadaan sa ikalawang usapan: ang endpoint na inihahayag ng publisher, ang address na dapat maabot ng subscriber, at ang pahintulot na nagpapahintulot sa pares na mag-usap. Ang lahat dito ay para lamang sa lumang ROS 1, na ang window ng suporta sa Noetic ay natapos noong Mayo 2025.

Hakbang 1: patunayan na ang koneksyon sa master ay hindi ang koneksyon sa paksa

Magsimula sa paghihiwalay ng gumagana sa hindi gumagana. Ang matagumpay na rostopic list ay nagpapatunay na naaabot ng iyong shell ang port ng XMLRPC ng master at alam ng master ang mga paksa; wala itong sinasabi tungkol sa kung naaabot ng subscriber ang publisher. Ang tatlong utos sa ibaba ay ginagawang nakikita ang pagkakaibang ito, at lahat ay basahin lamang.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

Ang output ng rostopic info ay nagpapangalan ng URI ng node ng publisher, na isang address ng XMLRPC sa host ng publisher. Iyon ang address na tatawagin ng iyong subscriber sa susunod, kaya dapat itong maabot mula saanman tumatakbo ang subscriber. Kung ito ay tumuturo sa isang interface na umiiral lamang sa LAN ng robot mismo, nagtatagumpay ang paghahanap sa master at hindi kailanman dumarating ang data.

Hakbang 2: basahin ang inihayag na endpoint mula sa node mismo

Pinipili ng ROS 1 ang inihayag na pagkakakilanlan ng host mula sa ROS_IP o ROS_HOSTNAME kapag isa sa kanila ay nakatakda, at kung hindi ay bumabalik sa sariling resolusyon ng pangalan ng host. Suriin ang kapaligiran ng prosesong aktwal na inilunsad, dahil ang unit ng systemd, container o ikalawang terminal ay maaaring magdala ng ibang halaga kaysa sa shell kung saan gumana ang iyong pagsubok.

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

Gumagana lamang ang anunsyo ng hostname kung bawat peer ay niresolba ang pangalang iyon sa inilaan na maaabot na address. Kung ang pangalang iyon ay niresolba lamang sa loob ng sariling network ng robot, walang paraan ang workstation sa kabilang panig ng tunnel na gamitin ito, at ang VPN na hindi nagtutulak ng anumang suffix ng DNS ay nagpapalala sa pagkakaiba. Kapag ang topolohiya ay naruruta, ang pagtatakda ng ROS_IP sa address ng tunnel ang mas maliit na pagbabago. Anuman ang piliin mo, itala ito para sa dalawang dulo, dahil ang publisher at subscriber na hindi nagkakasundo sa pagkakakilanlan ay mag-uusap at pagkatapos ay hindi makakakonekta.

Huminto dito kung ang inihayag na URI ay gumagamit ng address na hindi maruruta ng sinumang peer. Walang gawain sa firewall ang makakapaglinis ng pangalang niresolba sa maling interface.

Hakbang 3: gawing mareresolba at naruruta ang inihayag na address

Habang hawak ang URI, subukan ang maaabot mula sa host ng subscriber sa halip na mula sa robot. Ang port ng TCPROS ay pinipili sa panahon ng negosasyon, kaya ang kapaki-pakinabang na maagang pagsubok ay ang port ng XMLRPC at ang kapaki-pakinabang na huling pagsubok ay ang naitatag na socket. Ang rutang umiiral lamang sa isang direksyon ay karaniwang pagkabigo sa narurutang VPN, at ang daan pabalik ay kasinghalaga ng daan papunta.

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

Ang narurutang interface ng TUN ay nagdadala ng mga usapang IP na ito nang hindi pinalalawak ang segment ng Ethernet ng robot, na karaniwang gusto ng remote operator. Kung may bagay sa stack na umaasa sa broadcast o multicast sa halip, ang pangangailangang iyon ay dapat suriin nang hiwalay; ang pagpapalit ng tunnel sa TAP upang masiyahan ang isang tool ay nagpapalawak ng network para sa bawat kalahok.

Huminto dito kung nawawala ang ruta o ang daan pabalik. Ang publisher na sumasagot sa sariling host ngunit hindi maabot mula sa workstation ay may problema sa ruta, hindi problema sa ROS.

Hakbang 4: payagan ang usapan ng mga peer at obserbahan ang isang paksa

Buksan lamang ang mga port na kailangan ng napagkasunduang usapan, at limitahan ang bawat tuntunin sa mga inihayag na kalahok. Ang tagapakinig ng master ay hindi relay para sa payload ng paksa, kaya ang pagpayag lamang dito ay nag-iiwan ng saradong endpoint ng publisher. Panatilihin ang mga tagapakinig ng ROS sa hangganan ng pribadong VPN sa halip na ilantad sila sa pampublikong internet.

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

Obserbahan ang isang hindi mapaminsalang paksa mula sa tunay na publisher patungo sa tunay na subscriber at kumpirmahin ang inihayag na endpoint at ang daan ng tugon. Ang isang mensahe ay nagpapatunay na gumagana ang daan; ang matatag na rate ay nagpapatunay na nananatili itong bukas. Panatilihin ang kontrol ng actuator at mga pagsusuri sa kaligtasan sa labas ng pagsusuring ito na tungkol lamang sa network, dahil ang gumaganang paksa ay hindi nagpapatunay ng gumaganang robot. Itala ang bersyon ng ROS at ang pares ng endpoint na naobserbahan mo, upang ang susunod na tao ay makilala ang pagbabago ng topolohiya mula sa regression.

Tapos na ang checklist kapag ang inihayag na URI ay maaabot mula sa subscriber, ang napagkasunduang port ay bukas lamang para sa peer na iyon, ang isang inihayag na paksa ay dumadaloy, at ang mga halaga ng kapaligiran ay nakasulat para sa dalawang host. Ang lumang ROS 1 ay hindi makakatanggap ng mga pagwawasto sa larangang ito, kaya ang tala ang bahaging patuloy na gumagana pagkatapos magpalit ang mga tao.