Тэмы ROS 1 праз VPN: ідзіце за абвешчаным канцавым пунктам

Ваша працоўная станцыя дасягае master ROS 1 праз тунель і ўсё яшчэ паказвае пусты спіс тэм. Гэты паўтор сустракаецца часта, бо рэгістрацыя master і перадача тэм — гэта два розныя размовы, і толькі першая ідзе праз master. Кантрольны спіс ніжэй праходзіць другую размову: канцавы пункт, які абвяшчае публікатар, адрас, да якога павінен дабрацца падпісчык, і дазвол, які дазваляе пары размаўляць. Усё тут датычыцца толькі старога ROS 1, акно падтрымкі Noetic якога скончылася ў маі 2025 года.

Крок 1: дакажыце, што злучэнне з master — гэта не злучэнне з тэмай

Пачніце з таго, што аддзяляе працуючае ад няпрацуючага. Паспяховы rostopic list даказвае, што ваша абалонка дасягае порт XMLRPC master і што master ведае пра тэмы; ён нічога не кажа пра тое, ці можа падпісчык дабрацца да публікатара. Тры каманды ніжэй робяць гэтую розніцу бачнай, і ўсе яны толькі чытаюць.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

Вывад rostopic info называе URI вузла публікатара, які з'яўляецца адрасам XMLRPC на хаспе публікатара. Гэты адрас — той, да якога ваш падпісчык звернецца далей, таму ён павінен быць дасягальным адтуль, дзе б ні працаваў падпісчык. Калі ён паказвае на інтэрфейс, які існуе толькі ў LAN самога робата, пошук у master паспяховы, а даныя ніколі не прыходзяць.

Крок 2: прачытайце абвешчаны канцавы пункт з самога вузла

ROS 1 выбірае сваю абвешчаную ідэнтычнасць хаспа з ROS_IP або ROS_HOSTNAME, калі адзін з іх зададзены, а інакш вяртаецца да ўласнага развязання імёнаў хаспа. Агледзьце асяроддзе працэса, які быў фактычна запушчаны, бо модуль systemd, кантэйнер або другі тэрмінал могуць несці іншае значэнне, чым абалонка, дзе ваш тэст працаваў.

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

Абвяшчэнне імя хаспа працуе, толькі калі кожны партнёр развязвае гэтае імя ў патрэбны дасягальны адрас. Калі гэтае імя развязваецца толькі ўнутры ўласнай сеткі робата, працоўная станцыя на іншым баку тунеля ніяк не можа яго выкарыстаць, а VPN, які не прасоўвае ніякага DNS-суфікса, робіць неадпаведнасць яшчэ горшай. Усталяванне ROS_IP на адрас тунеля — меншае змяненне, калі тапалогія маршрутызаваная. Што б вы ні выбралі, запішыце гэта для абодвух бакоў, бо публікатар і падпісчык, якія разыходзяцца ў ідэнтычнасці, дамовяцца, а потым не змогуць злучыцца.

Спыніцеся тут, калі абвешчаны URI выкарыстоўвае адрас, да якога не можа пракласці маршрут ніводзін партнёр. Ніякая праца з брандмаўэрам не выправіць імя, якое развязваецца ў няправільны інтэрфейс.

Крок 3: зрабіце абвешчаны адрас развязальным і маршрутызаваным

Маючы URI, праверце дасягальнасць з хаспа падпісчыка, а не з робата. Порт TCPROS выбіраецца падчас дамоўленасці, таму карысны ранні тэст — гэта порт XMLRPC, а карысны позні тэст — усталяваны сокет. Маршрут, які існуе толькі ў адным кірунку, — частая праблема на маршрутызаваных VPN, і зваротны шлях важны не менш за прамы.

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

Маршрутызаваны інтэрфейс TUN пераносіць гэтыя IP-размовы, не пашыраючы Ethernet-сегмент робата, чаго звычайна і хоча аддалены аператар. Калі нешта ў стэку залежыць замест гэтага ад шырокавяшчальнасці або multicast, гэта патрабаванне трэба ацэньваць асобна; пераўтварэнне тунеля ў TAP, каб задаволіць адзін інструмент, пашырае сетку для ўсіх удзельнікаў.

Спыніцеся тут, калі маршрут або зваротны шлях адсутнічае. Публікатар, які адказвае на сваім хаспе, але да якога не дабрацца з працоўнай станцыі, мае праблему маршрутызацыі, а не праблему ROS.

Крок 4: дазвольце размову партнёраў і назірайце за адной тэмай

Адкрыйце толькі тыя порты, якія патрэбны дамоўленай размове, і абмяжуйце кожнае правіла абвешчанымі ўдзельнікамі. Слухач master не з'яўляецца рэтранслятарам для карыснай нагрузкі тэм, таму дазвол толькі яму пакідае канцавы пункт публікатара закрытым. Трымайце слухачоў ROS на мяжы прыватнай VPN, а не выстаўляйце іх у публічны інтэрнэт.

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

Назірайце за адной бяспечнай тэмай ад сапраўднага публікатара да сапраўднага падпісчыка і пацвердзіце як абвешчаны канцавы пункт, так і шлях адказу. Адно паведамленне даказвае, што шлях працуе; устойлівы тэмп даказвае, што ён застаецца адкрытым. Трымайце кіраванне прывадамі і праверкі бяспекі па-за гэтым тэстам, які тычыцца толькі сеткі, бо працуючая тэма не пацвярджае працуючага робата. Запішыце версію ROS і пару канцавых пунктаў, якую вы назіралі, каб наступны чалавек мог адрозніць змяненне тапалогіі ад рэгрэсу.

Кантрольны спіс завершаны, калі абвешчаны URI дасягальны з боку падпісчыка, дамоўлены порт адкрыты толькі для гэтага партнёра, адна абвешчаная тэма цячэ, а значэнні асяроддзя запісаны для абодвух хаспоў. Стары ROS 1 не атрымае выпраўленняў у гэтай галіне, таму запіс — гэта тая частка, якая працягвае працаваць пасля змены людзей.