ROS 2-ը VPN-ով. հայտնաբերումը տվյալների ուղին չէ

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

Ինչ է իրականում կրում հայտնաբերման սերվերը

Fast DDS-ում Discovery Server-ը տարածում է տեղեկություն վերջնակետերի մասին՝ ով է հրապարակում, ով է բաժանորդագրվում և ինչ QoS է սպասում յուրաքանչյուրը։ Երբ գործընկերները տեղյակ են միմյանցից, օգտվողի տվյալները շարժվում են ուղղակիորեն նրանց միջև, այլ ոչ այդ սերվերի միջով։ Սերվերին հասնելը ապացուցում է, որ ծանոթությունների միջնորդը պատասխանում է, և ոչ ավելին։ Երթուղավորված VPN-ին դեռ անհրաժեշտ է աշխատող ուղի երկու ուղղություններով այն հասցեների միջև, որոնք հայտարարում են գործընկերները։

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

Կարդացեք RMW-ն, որն իրականում օգտագործում են հանգույցները

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

printenv RMW_IMPLEMENTATION
ros2 doctor --report | head -n 20

Չսահմանված փոփոխականը սովորաբար նշանակում է տեղադրված լռելյայնը, որը կարող է տարբեր լինել նույն փորձի մեքենաների միջև։ Զեկույցը նաև նշում է օգտագործվող դիստրիբուտիվը և միջնորդ ծրագրաշարը, ուստի համեմատեք դրանք թունելի երկու կողմերում նախքան ենթադրելը, որ դրանք համընկնում են։ ROS-ի հրամանի տողի դեմոնը պահում է վիճակը քեշում, ուստի միջավայրը փոխելուց հետո վերագործարկեք այն, փոխարենը թույլ չտալով հնացած դեմոնին պատասխանել հին կոնֆիգուրացիայի համար։ Գրանցեք երկու հոսթերի դիստրիբուտիվը և RMW-ն թեստի նշումներում, քանի դեռ նստաշրջանը բաց է։

Փորձարկեք հայտնաբերումը և տվյալները որպես երկու արդյունք

Ընտրեք անվտանգ թեմա և չափեք ծանոթությունը առանձին առաքումից։ info հրամանը թվարկում է վերջնակետերն ու QoS-ը, մինչդեռ echo-ն ապացուցում է՝ արդյոք մեկ հաղորդագրություն իրոք անցնում է կապով։

ros2 topic info /chatter --verbose
ros2 topic echo /chatter --once

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

Փոփոխեք մեկ կախվածություն միաժամանակ

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

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

Այդ RMW-ի ներքո երթուղիչը հայտնաբերումը կրում է Jazzy-ի լռելյայն դասավորությամբ, և այնտեղ multicast հայտնաբերումն անջատված է, ուստի կախվածությունը պատկանում է ձեր նշումներին, այլ ոչ թե այլ միջնորդ ծրագրաշարից փոխառված ենթադրությանը։ Աշխատանքային բեռը պահեք ֆիքսված, մինչ փոխում եք մեկ կարգավորում, ապա կրկնեք echo թեստը և գրանցեք ուղղությունը, հաղորդագրությունների հաճախականությունը և կապի պայմանները։ Կրկնեք համեմատությունը երկու անգամ՝ իրական բարելավումը հաջողակ վերամիացումից տարանջատելու համար։ Եթե փոփոխությունը բարելավում է հայտնաբերումը, մինչ առաքումը մնում է նույնը, դուք տեղափոխել եք ծանոթության ծառայությունը, ոչ թե տվյալների ուղին։