VPN orqali ROS 2: aniqlash ma'lumot yo'li emas

VPNning qarama-qarshi uchlaridagi ikkita ROS 2 tuguni bir-birining mavzularini ro'yxatlashi mumkin, lekin baribir bitta ham xabar yetkaza olmaydi. Aniqlash va foydalanuvchi ma'lumotlari alohida yo'llarga ega alohida almashinuvlardir, va aniqlash serveri yuklamalarni uzatmaydi. Birini tekshirib, ikkinchisini taxmin qilish tunnel ma'lumotni hech qachon olib o'tmagan bo'lsa ham jamoalar middlewareni almashtirishiga sabab bo'ladi. Quyidagi tartib biror narsa almashtirilishidan oldin ikkita natijani ajratadi.

Aniqlash serveri aslida nima olib yuradi

Fast DDSda Discovery Server so'nggi nuqtalar haqida ma'lumot tarqatadi: kim nashr etadi, kim obuna bo'ladi va har biri qanday QoS kutadi. Hamkorlar bir-birini bilgach, foydalanuvchi ma'lumotlari o'sha server orqali emas, to'g'ridan-to'g'ri ular orasida harakatlanadi. Serverga yetish tanishuv vositachisi javob berishini isbotlaydi, undan boshqa narsani emas. Marshrutlangan VPN hali ham hamkorlar e'lon qiladigan manzillar orasida ikki yo'nalishda ishlaydigan yo'lni talab qiladi.

Bu farq qisman nosozliklarni ham tushuntiradi: mavjud hamkorlar ma'lumot almashishda davom etadi, yangi aniqlash esa ishlashdan to'xtaydi. Ularni ikkita alohida tekshiruv sifatida ko'ring.

Tugunlar aslida ishlatadigan RMWni o'qing

ROS 2 turli middlewarelarni yuklashi mumkin va sizning qobig'ingizda eksport qilingan o'zgaruvchi boshqa joyda ishga tushirilgan jarayonlarga yetib bormaydi. Terminal tarixingizdan emas, ishlab turgan tizimdan so'rang.

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

O'rnatilmagan o'zgaruvchi odatda o'rnatilgan standart qiymatni bildiradi, u bir tajribadagi mashinalar orasida farq qilishi mumkin. Hisobot ishlatilayotgan distributiv va middleware nomini ham aytadi, shuning uchun ular mos keladi deb taxmin qilishdan oldin tunnelning ikki tomonida ularni solishtiring. ROS buyruq qatori demoni holatni keshda saqlaydi, shuning uchun muhitni o'zgartirgandan keyin uni qayta ishga tushiring, eski konfiguratsiya uchun eskirgan demon javob berishiga yo'l qo'ymang. Sessiya ochiq turganda ikkala hostning distributivi va RMWsini sinov eslatmalariga yozing.

Aniqlash va ma'lumotni ikkita natija sifatida sinang

Zararsiz mavzuni tanlang va tanishuvni yetkazib berishdan alohida o'lchang. info buyrug'i so'nggi nuqtalar va QoSni ro'yxatlaydi, echo esa bitta xabar haqiqatan ham havoladan o'tishini isbotlaydi.

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

info chiqishida so'nggi nuqtalarning ko'rinishi aniqlash natijasidir. Xabarning obunachiga yetishi transport natijasidir va faqat ikkinchisi ilova uchun zarur yo'lni sinovdan o'tkazadi. Aniqlash ishlab, echo vaqti tugaganda, aniqlash xizmati o'rniga e'lon qilingan manzillar va qaytish marshrutini tekshiring. Ikkala buyruqni har bir hostdan ishga tushiring, chunki assimetrik VPN marshruti ko'pincha faqat bir tomondan ko'rinadi.

Bir vaqtda bitta bog'liqlikni o'zgartiring

Ma'lumot yo'li ishlamasa, bitta sessiyada middleware, aniqlash rejimi va xabar hajmini o'zgartirishdan saqlaning, chunki keyin hech bir natijani unga bog'lab bo'lmaydi. Zenoh RMW qonuniy muqobil, lekin uning routeri tunnel orqali yetib borilishi kerak bo'lgan yana bir bog'liqlikka aylanadi.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

O'sha RMW ostida router aniqlashni Jazzy standart tartibida olib yuradi va u yerda multicast aniqlash o'chirilgan, shuning uchun bu bog'liqlik boshqa middlewaredan olingan taxminga emas, sizning eslatmalaringizga tegishli. Bitta sozlamani o'zgartirganda ish yuklamasini barqaror tuting, so'ngra echo sinovini takrorlang va yo'nalish, xabar tezligi va havola sharoitlarini yozib oling. Haqiqiy yaxshilanishni omadli qayta ulanishdan ajratish uchun taqqoslashni ikki marta o'tkazing. Agar o'zgarish aniqlashni yaxshilab, yetkazib berish o'zgarmasa, siz tanishuv xizmatini ko'chirdingiz, ma'lumot yo'lini emas.