VPN orqali ROS 1 mavzulari: e'lon qilingan oxirgi nuqtaga ergashing

ROS 1 master ro'yxatga olishi mavzu ma'lumotlarini olib o'tmaydi. E'lon qilingan tugun URI ni o'qing, bu manzilni marshrutlanadigan qiling, so'ngra nashr etuvchining portiga ruxsat bering.

Ish stansiyangiz tunnel orqali ROS 1 master ga yetib boradi, lekin mavzular ro'yxati baribir bo'sh ko'rinadi. Bu naqsh keng tarqalgan, chunki master ro'yxatga olish va mavzu tashish ikki xil suhbat, va master orqali faqat birinchisi o'tadi. Quyidagi tekshiruv ro'yxati ikkinchi suhbatni bosib o'tadi: nashr etuvchi e'lon qiladigan oxirgi nuqta, obunachi yetib borishi kerak bo'lgan manzil va ikkalasiga gaplashish imkonini beradigan ruxsat. Bu yerdagi hamma narsa faqat Noetic qo'llab-quvvatlash davri 2025 yil may oyida tugagan eski ROS 1 ga tegishli.

1-qadam: master ulanishi mavzu ulanishi emasligini isbotlang

Nima ishlayotganini nima ishlamayotganidan ajratishdan boshlang. Muvaffaqiyatli rostopic list shellingiz master ning XMLRPC portiga yetib borishini va master mavzularni bilishini isbotlaydi; obunachi nashr etuvchiga yetib bora oladimi-yo'qmi, bu haqda hech narsa demaydi. Quyidagi uchta buyruq bu farqni ko'rinadigan qiladi va ularning barchasi faqat o'qish uchun.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

rostopic info chiqishi nashr etuvchining tugun URI sini nomlaydi, bu nashr etuvchining xostidagi XMLRPC manzil. Obunachingiz keyingi gal shu manzilga murojaat qiladi, shuning uchun u obunachi ishlaydigan har qanday joydan yetib borish imkoniyatiga ega bo'lishi kerak. Agar u faqat robotning o'z LAN ida mavjud interfeysga ishora qilsa, master qidiruvi muvaffaqiyatli bo'ladi va ma'lumot hech qachon yetib kelmaydi.

2-qadam: e'lon qilingan oxirgi nuqtani tugunning o'zidan o'qing

ROS 1 o'zining e'lon qilingan xost identifikatorini ROS_IP yoki ROS_HOSTNAME dan tanlaydi, agar ulardan biri o'rnatilgan bo'lsa, aks holda xostning o'z nom yechimiga qaytadi. Haqiqatan ishga tushirilgan jarayon muhitini tekshiring, chunki systemd birligi, konteyner yoki ikkinchi terminal sizning testingiz ishlagan shell dan boshqa qiymat olib yurishi mumkin.

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

Xost nomi e'loni faqat har bir sherik bu nomni mo'ljallangan yetib borish mumkin manzilga yechganda ishlaydi. Agar bu nom faqat robotning o'z tarmog'i ichida yechilsa, tunnelning narigi tomonidagi ish stansiyasi undan foydalanishning hech qanday yo'liga ega emas, va hech qanday DNS qo'shimchasini itarib yubormaydigan VPN nomuvofiqlikni yanada yomonlashtiradi. Topologiya marshrutlangan bo'lsa, ROS_IP ni tunnel manziliga qo'yish kichikroq o'zgarish. Nimani tanlasangiz ham, uni ikkala uchun yozib qo'ying, chunki identifikatsiya bo'yicha kelishmaydigan nashr etuvchi va obunachi muzokara qiladi va keyin ulana olmaydi.

Agar e'lon qilingan URI hech bir sherik marshrutlay olmaydigan manzildan foydalansa, shu yerda to'xtang. Noto'g'ri interfeysga yechiladigan nomni hech qanday xavfsizlik devori ishi tuzatmaydi.

3-qadam: e'lon qilingan manzilni yechiladigan va marshrutlangan qiling

URI qo'lingizda bo'lganda, yetib borish imkoniyatini robotdan emas, obunachi xostidan sinab ko'ring. TCPROS porti muzokaralar davomida tanlanadi, shuning uchun foydali erta sinov XMLRPC porti, foydali kech sinov esa o'rnatilgan soket. Faqat bir yo'nalishda mavjud marshrut marshrutlangan VPN larda keng tarqalgan nosozlik, va qaytish yo'li borish yo'li kabi muhim.

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

Marshrutlangan TUN interfeysi bu IP suhbatlarini robotning Ethernet segmentini kengaytirmasdan tashiydi, bu odatda masofaviy operator xohlaydigan narsa. Agar stekdagi biror narsa buning o'rniga broadcast yoki multicast ga bog'liq bo'lsa, bu talabni alohida baholash kerak; bitta asbobni qondirish uchun tunnelni TAP ga aylantirish har bir ishtirokchi uchun tarmoqni kengaytiradi.

Marshrut yoki qaytish yo'li bo'lmasa, shu yerda to'xtang. O'z xostida javob beradigan, lekin ish stansiyasidan yetib bo'lmaydigan nashr etuvchining marshrutlash muammosi bor, ROS muammosi emas.

4-qadam: sheriklar suhbatiga ruxsat bering va bitta mavzuni kuzating

Faqat kelishilgan suhbatga kerak bo'lgan portlarni oching va har bir qoidani e'lon qilingan ishtirokchilar bilan cheklang. master ning tinglovchisi mavzu yuki uchun rele emas, shuning uchun faqat unga ruxsat berish nashr etuvchining oxirgi nuqtasini yopiq qoldiradi. ROS tinglovchilarini ommaviy internetga ochish o'rniga xususiy VPN chegarasida saqlang.

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

Haqiqiy nashr etuvchidan haqiqiy obunachiga bitta zararsiz mavzuni kuzatib, e'lon qilingan oxirgi nuqtani ham, javob yo'lini ham tasdiqlang. Bitta xabar yo'l ishlayotganini isbotlaydi; barqaror tezlik u ochiq qolayotganini isbotlaydi. Aktuatorlarni boshqarish va xavfsizlik tekshiruvlarini faqat tarmoqqa oid bu sinovdan tashqarida saqlang, chunki ishlayotgan mavzu ishlayotgan robotni tasdiqlamaydi. Kuzatgan ROS versiyangizni va oxirgi nuqtalar juftini yozib qo'ying, shunda keyingi odam topologiya o'zgarishini regressiyadan ajrata oladi.

Tekshiruv ro'yxati e'lon qilingan URI obunachidan yetib borish mumkin bo'lganda, kelishilgan port faqat shu sherik uchun ochiq bo'lganda, bitta e'lon qilingan mavzu oqayotganda va muhit qiymatlari ikkala xost uchun yozilganda tugaydi. Eski ROS 1 bu sohada tuzatishlar olmaydi, shuning uchun yozuv odamlar almashgandan keyin ham ishlashda davom etadigan qismdir.

O'xshash maqolalar