Temat e ROS 1 përmes VPN: ndiqni pikën fundore të shpallur

Regjistrimi në master të ROS 1 nuk transporton të dhëna temash. Lexoni URI-n e nyjës të shpallur, bëjeni atë adresë të rrugëtueshme dhe më pas lejoni portën e botuesit.

Stacioni juaj i punës arrin master-in e ROS 1 përmes tunelit dhe prapë shfaq një listë të zbrazët temash. Ky model është i zakonshëm sepse regjistrimi në master dhe transporti i temave janë dy biseda të ndryshme, dhe vetëm e para kalon përmes master-it. Lista e kontrollit më poshtë kalon bisedën e dytë: pikën fundore që shpall një botues, adresën që një abonent duhet të arrijë dhe lejen që i lejon çiftit të flasë. Çdo gjë këtu vlen vetëm për ROS 1 e vjetër, dritarja e mbështetjes së të cilit për Noetic mbaroi në maj 2025.

Hapi 1: vërtetoni se lidhja me master nuk është lidhja me temën

Filloni duke ndarë atë që funksionon nga ajo që nuk funksionon. Një rostopic list i suksesshëm vërteton se shell-i juaj arrin portën XMLRPC të master-it dhe se master-i i njeh temat; nuk thotë asgjë për faktin nëse një abonent mund të arrijë botuesin. Tre komandat më poshtë e bëjnë të dukshme këtë dallim, dhe të gjitha janë vetëm për lexim.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

Rezultati i rostopic info emërton URI-n e nyjës së botuesit, e cila është një adresë XMLRPC në hostin e botuesit. Kjo është adresa që abonenti juaj do të thërrasë më pas, prandaj duhet të jetë e arritshme nga kudo që funksionon abonenti. Nëse ajo tregon një ndërfaqe që ekziston vetëm në LAN-in e vetë robotit, kërkimi në master ka sukses dhe të dhënat nuk arrijnë kurrë.

Hapi 2: lexoni pikën fundore të shpallur nga vetë nyja

ROS 1 zgjedh identitetin e hostit të shpallur nga ROS_IP ose ROS_HOSTNAME kur njëri prej tyre është vendosur, dhe përndryshe kthehet te zgjidhja e emrave të vetë hostit. Inspektoni mjedisin e procesit që u nis në të vërtetë, sepse një njësi systemd, një kontejner ose një terminal i dytë mund të mbajnë një vlerë të ndryshme nga shell-i ku funksionoi testi juaj.

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

Një shpallje emri hosti funksionon vetëm nëse çdo palë e zgjidh atë emër në adresën e synuar të arritshme. Nëse ai emër zgjidhet vetëm brenda rrjetit të vetë robotit, një stacion pune në anën tjetër të tunelit nuk ka asnjë mënyrë për ta përdorur, dhe një VPN që nuk shtyn asnjë prapashtesë DNS e përkeqëson mospërputhjen. Kur topologjia është e rrugëtueshme, vendosja e ROS_IP në adresën e tunelit është ndryshimi më i vogël. Çfarëdo që të zgjidhni, shënoni atë për të dy skajet, sepse një botues dhe një abonent që nuk bien dakord për identitetin do të negociojnë dhe më pas nuk do të mund të lidhen.

Ndaloni këtu nëse URI-ja e shpallur përdor një adresë ku asnjë palë nuk mund të rrugëtojë. Asnjë punë në firewall nuk rregullon një emër që zgjidhet në ndërfaqen e gabuar.

Hapi 3: bëjeni adresën e shpallur të zgjidhshme dhe të rrugëtueshme

Me URI-n në dorë, provoni arritshmërinë nga hosti i abonentit dhe jo nga roboti. Porta TCPROS zgjidhet gjatë negocimit, prandaj testi i hershëm i dobishëm është porta XMLRPC, dhe testi i vonshëm i dobishëm është socket-i i vendosur. Një rrugë që ekziston vetëm në një drejtim është një dështim i zakonshëm në VPN-të e rrugëtueshme, dhe rruga e kthimit vlen sa ajo e shkuarjes.

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

Një ndërfaqe TUN e rrugëtueshme i transporton këto biseda IP pa zgjeruar segmentin Ethernet të robotit, që zakonisht është ajo që do një operator në distancë. Nëse diçka në stek varet në vend të kësaj nga transmetimi ose multicast, ajo kërkesë duhet vlerësuar veçmas; kthimi i tunelit në TAP për të kënaqur një mjet të vetëm e zgjeron rrjetin për çdo pjesëmarrës.

Ndaloni këtu nëse mungon rruga ose rruga e kthimit. Një botues që përgjigjet në hostin e vet, por nuk arrihet nga stacioni i punës, ka një problem rrugëtimi, jo një problem ROS.

Hapi 4: lejoni bisedën mes palëve dhe vëzhgoni një temë

Hapni vetëm portat që i nevojiten bisedës së negocuar, dhe kufizoni çdo rregull te pjesëmarrësit e deklaruar. Dëgjuesi i master-it nuk është përcjellës për ngarkesën e temave, prandaj lejimi vetëm i tij e lë pikën fundore të botuesit të mbyllur. Mbani dëgjuesit e ROS në kufirin e VPN-së private në vend që t'i ekspozoni ndaj internetit publik.

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

Vëzhgoni një temë të padëmshme nga botuesi i vërtetë te abonenti i vërtetë dhe konfirmoni si pikën fundore të shpallur ashtu edhe rrugën e përgjigjes. Një mesazh i vetëm vërteton se rruga funksionon; një ritëm i qëndrueshëm vërteton se ajo mbetet e hapur. Mbani kontrollin e aktuatorëve dhe kontrollet e sigurisë jashtë këtij testi që ka të bëjë vetëm me rrjetin, sepse një temë që funksionon nuk certifikon një robot që funksionon. Shënoni versionin e ROS dhe çiftin e pikave fundore që vëzhguat, në mënyrë që personi tjetër të mund të dallojë një ndryshim topologjie nga një regresion.

Lista e kontrollit përfundon kur URI-ja e shpallur është e arritshme nga abonenti, porta e negocuar është e hapur vetëm për atë palë, një temë e deklaruar rrjedh dhe vlerat e mjedisit janë shënuar për të dy hostet. ROS 1 i vjetër nuk do të marrë rregullime në këtë fushë, prandaj shënimi është pjesa që vazhdon të funksionojë pasi njerëzit ndryshojnë.

Artikuj të ngjashëm