ROS 2 oor 'n VPN: Ontdekking is nie die datapad nie
Dat ontdekking eweknieë vind, bewys nie dat nutdata aankom nie. Kontroleer die RMW, die geadverteerde eindpunte en een werklading voordat jy DDS vervang of 'n roeteerder byvoeg.
Twee ROS 2-nodes aan weerskante van 'n VPN kan mekaar se onderwerpe lys en steeds nie 'n enkele boodskap aflewer nie. Ontdekking en gebruikerdata is afsonderlike uitruilings met afsonderlike paaie, en 'n ontdekkingsbediener stuur nie nutdata deur nie. Om een te kontroleer en die ander te aanvaar, is hoe spanne middleware vervang wanneer die tonnel bloot nooit die data gedra het nie. Die prosedure hieronder skei die twee resultate voordat enigiets vervang word.
Wat die ontdekkingsbediener werklik dra
In Fast DDS versprei 'n Discovery Server inligting oor eindpunte: wie publiseer, wie inteken en watter QoS elkeen verwag. Sodra eweknieë van mekaar weet, reis gebruikerdata direk tussen hulle eerder as deur daardie bediener. Om die bediener te bereik bewys dat die bekendsteller antwoord, niks meer nie. 'n Geroteerde VPN het steeds 'n werkende pad in beide rigtings tussen die adresse wat die eweknieë adverteer.
Daardie onderskeid verduidelik ook gedeeltelike mislukkings, waar bestaande eweknieë aanhou data uitruil terwyl nuwe ontdekking ophou werk. Hanteer dit as twee ondersoeke.
Lees die RMW wat die nodes werklik gebruik
ROS 2 kan verskillende middleware laai, en 'n veranderlike wat in jou skulp uitgevoer word, bereik nie prosesse wat elders begin is nie. Vra eerder die lopende stelsel as jou terminale geskiedenis.
printenv RMW_IMPLEMENTATION
ros2 doctor --report | head -n 20'n Ongestelde veranderlike beteken gewoonlik die geinstalleerde verstek, wat tussen masjiene in dieselfde eksperiment kan verskil. Die verslag noem ook die distribusie en die middleware in gebruik, so vergelyk dit aan beide kante van die tonnel voordat jy aanvaar dat hulle ooreenstem. Die ROS-opdragreel-daemon verberg toestand, so herbegin dit nadat jy die omgewing verander het eerder as om 'n verouderde daemon vir die ou konfigurasie te laat antwoord. Sit die distribusie en RMW van beide gashere in die toetsnotas terwyl die sessie oop is.
Toets ontdekking en data as twee resultate
Kies 'n onskadelike onderwerp en meet bekendstelling afsonderlik van aflewering. Die info-opdrag lys eindpunte en QoS, terwyl echo bewys of een boodskap werklik die skakel oorsteek.
ros2 topic info /chatter --verbose
ros2 topic echo /chatter --onceEindpunte wat in die info-uitset verskyn, is 'n ontdekkingsresultaat. 'n Boodskap wat by die intekenaar aankom, is 'n vervoerresultaat, en net die tweede een oefen die pad wat die toepassing nodig het. Wanneer ontdekking werk en echo tyd uit, ondersoek die geadverteerde adresse en die terugroete eerder as die ontdekkingsdiens. Voer beide opdragte van elke gasheer uit, want 'n asimmetriese VPN-roete openbaar hom dikwels net van een kant.
Verander een afhanklikheid op 'n slag
Wanneer die datapad misluk, vermy om middleware, ontdekkingsmodus en boodskapgrootte in dieselfde sessie te verander, want geen resultaat kan daarna toegeskryf word nie. Die Zenoh RMW is 'n geldige alternatief, maar sy roeteerder word nog 'n afhanklikheid wat deur die tonnel bereikbaar moet wees.
export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohdOnder daardie RMW dra die roeteerder ontdekking in die verstek Jazzy-reeling, en multicast-ontdekking is daar afgeskakel, so die afhanklikheid hoort in jou notas eerder as in 'n aanname wat by ander middleware geleen is. Hou die werklading vas terwyl jy een instelling verander, herhaal dan die echo-toets en teken rigting, boodskapstempo en skakeltoestande aan. Voer die vergelyking twee keer uit om 'n werklike verbetering van 'n gelukkige herverbinding te skei. As 'n verandering ontdekking verbeter terwyl aflewering dieselfde bly, het jy die bekendstellingsdiens verskuif, nie die datapad nie.