ROS 1 թեմաները VPN-ով՝ հետևեք հայտարարված վերջնակետին

Ձեր աշխատանքային կայանը թունելով հասնում է ROS 1 master-ին և դեռ ցույց է տալիս դատարկ թեմաների ցանկ։ Այս օրինաչափությունը տարածված է, որովհետև master գրանցումը և թեմաների փոխանցումը երկու տարբեր զրույցներ են, և միայն առաջինն է անցնում master-ով։ Ստորև բերված ստուգաթերթը անցնում է երկրորդ զրույցով՝ վերջնակետը, որը հրատարակիչը հայտարարում է, հասցեն, որին բաժանորդը պետք է կարողանա հասնել, և թույլտվությունը, որը թույլ է տալիս զույգին խոսել։ Այստեղ ամեն ինչ վերաբերում է միայն հին ROS 1-ին, որի Noetic աջակցության պատուհանը ավարտվեց 2025 թվականի մայիսին։

Քայլ 1. ապացուցեք, որ master կապը թեմայի կապը չէ

Սկսեք առանձնացնելով այն, ինչ աշխատում է, այն ամենից, ինչ չի աշխատում։ Հաջող rostopic list-ը ապացուցում է, որ ձեր shell-ը հասնում է master-ի XMLRPC պորտին և որ master-ը գիտի թեմաների մասին, բայց ոչինչ չի ասում այն մասին, թե արդյոք բաժանորդը կարող է հասնել հրատարակչին։ Ստորև բերված երեք հրամանները տեսանելի են դարձնում այդ տարբերությունը, և բոլորը միայն կարդալու համար են։

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

rostopic info-ի ելքը նշում է հրատարակչի հանգույցի URI-ն, որը XMLRPC հասցե է հրատարակչի հոսթում։ Այդ հասցեն է, որ ձեր բաժանորդը կկանչի հաջորդիվ, ուստի այն պետք է հասանելի լինի այնտեղից, որտեղ էլ աշխատի բաժանորդը։ Եթե այն ցույց է տալիս ինտերֆեյսի, որը գոյություն ունի միայն ռոբոտի սեփական LAN-ում, ապա master-ի որոնումը հաջողվում է, և տվյալները երբեք չեն հասնում։

Քայլ 2. կարդացեք հայտարարված վերջնակետը հենց հանգույցից

ROS 1-ը ընտրում է իր հայտարարված հոսթի ինքնությունը ROS_IP-ից կամ ROS_HOSTNAME-ից, երբ դրանցից մեկը սահմանված է, հակառակ դեպքում վերադառնում է հոսթի սեփական անվան լուծմանը։ Քննեք այն գործընթացի միջավայրը, որն իրականում գործարկվել է, որովհետև systemd միավորը, կոնտեյները կամ երկրորդ տերմինալը կարող են կրել այլ արժեք, քան այն shell-ը, որտեղ ձեր փորձարկումն աշխատել է։

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

Հոսթանվան հայտարարումը աշխատում է միայն այն դեպքում, երբ յուրաքանչյուր գործընկեր այդ անունը լուծում է նախատեսված հասանելի հասցեի։ Եթե այդ անունը լուծվում է միայն ռոբոտի սեփական ցանցի ներսում, թունելի մյուս կողմի աշխատանքային կայանը ոչ մի կերպ չի կարող օգտագործել այն, և DNS վերջածանց չմղող VPN-ն ավելի է վատացնում անհամապատասխանությունը։ Երբ տոպոլոգիան երթուղված է, ROS_IP-ը թունելի հասցեին դնելը ավելի փոքր փոփոխություն է։ Ինչ էլ ընտրեք, գրանցեք այն երկու ծայրերի համար, որովհետև ինքնության շուրջ անհամաձայն հրատարակիչն ու բաժանորդը բանակցելու են, ապա չեն կարողանա միանալ։

Կանգ առեք այստեղ, եթե հայտարարված URI-ն օգտագործում է հասցե, որին ոչ մի գործընկեր չի կարող երթուղել։ Firewall-ի ոչ մի աշխատանք չի ուղղի անունը, որը լուծվում է սխալ ինտերֆեյսի։

Քայլ 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 հատվածը, ինչը սովորաբար հենց այն է, ինչ ուզում է հեռավոր օպերատորը։ Եթե ինչ-որ բան ստեկում փոխարենը կախված է broadcast-ից կամ multicast-ից, այդ պահանջը պետք է գնահատվի առանձին, իսկ թունելը TAP-ի վերածելը մեկ գործիք բավարարելու համար լայնացնում է ցանցը յուրաքանչյուր մասնակցի համար։

Կանգ առեք այստեղ, եթե երթուղին կամ վերադարձի ուղին բացակայում է։ Հրատարակիչը, որը պատասխանում է իր հոսթում, բայց հասանելի չէ աշխատանքային կայանից, ունի երթուղավորման խնդիր, ոչ թե ROS խնդիր։

Քայլ 4. թույլատրեք գործընկերների զրույցը և դիտեք մեկ թեմա

Բացեք միայն այն պորտերը, որոնք անհրաժեշտ են բանակցված զրույցին, և յուրաքանչյուր կանոն սահմանափակեք հայտարարված մասնակիցներով։ master-ի լսողը թեմաների բեռի ռելե չէ, ուստի միայն նրան թույլատրելը բաց է թողնում հրատարակչի վերջնակետը։ ROS լսողները պահեք մասնավոր VPN-ի սահմանին՝ փոխարենը չբացահայտելով դրանք հանրային ինտերնետին։

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

Դիտեք մեկ անվտանգ թեմա իրական հրատարակչից իրական բաժանորդ, և հաստատեք թե՛ հայտարարված վերջնակետը, թե՛ պատասխանի ուղին։ Մեկ հաղորդագրություն ապացուցում է, որ ուղին աշխատում է, իսկ կայուն հաճախականությունը՝ որ այն բաց է մնում։ Ակտուատորների կառավարումը և անվտանգության ստուգումները պահեք այս միայն ցանցային փորձարկումից դուրս, որովհետև աշխատող թեման չի վկայում աշխատող ռոբոտի մասին։ Գրանցեք ROS տարբերակը և դիտված վերջնակետերի զույգը, որպեսզի հաջորդ մարդը կարողանա տոպոլոգիայի փոփոխությունը տարբերել ռեգրեսիայից։

Ստուգաթերթն ավարտված է, երբ հայտարարված URI-ն հասանելի է բաժանորդից, բանակցված պորտը բաց է միայն այդ գործընկերոջ համար, մեկ հայտարարված թեմա հոսում է, և միջավայրի արժեքները գրված են երկու հոսթերի համար։ Հին ROS 1-ը այս ոլորտում ուղղումներ չի ստանա, ուստի գրառումը այն մասն է, որը շարունակում է աշխատել մարդկանց փոխվելուց հետո։