ROS 2 juu ya VPN: ugunduzi si njia ya data
Ugunduzi kupata wenzao hakuthibitishi kuwa mizigo inawasili. Kagua RMW, vituo vilivyotangazwa na mzigo mmoja wa kazi kabla ya kubadilisha DDS au kuongeza kipanga njia.
Nodi mbili za ROS 2 kwenye ncha tofauti za VPN zinaweza kuorodhesha mada za kila mmoja na bado zishindwe kuwasilisha ujumbe mmoja. Ugunduzi na data ya mtumiaji ni mabadilishano tofauti yenye njia tofauti, na seva ya ugunduzi haisambazi mizigo. Kukagua kimoja na kudhani kingine ndiyo njia ambayo timu huishia kubadilisha middleware wakati handaki halikuwahi kubeba data. Utaratibu hapa chini hutenganisha matokeo mawili kabla ya kitu chochote kubadilishwa.
Kile ambacho seva ya ugunduzi hubeba kwa kweli
Katika Fast DDS, Discovery Server husambaza taarifa kuhusu vituo: nani anachapisha, nani anajiandikisha na QoS gani kila mmoja anatarajia. Wenzao wanapojuana, data ya mtumiaji husafiri moja kwa moja kati yao badala ya kupitia seva hiyo. Kufikia seva huthibitisha kuwa mpatanishi wa utambulisho anajibu, na si zaidi. VPN iliyopangwa bado inahitaji njia inayofanya kazi katika pande zote mbili kati ya anwani ambazo wenzao hutangaza.
Tofauti hiyo pia inaeleza kushindwa kwa sehemu, ambapo wenzao waliopo wanaendelea kubadilishana data wakati ugunduzi mpya unaacha kufanya kazi. Wachukulie kama uchunguzi mbili.
Soma RMW ambayo nodi hutumia kwa kweli
ROS 2 inaweza kupakia middleware tofauti, na kigezo kilichosafirishwa kwenye shell yako hakifikii michakato iliyoanzishwa mahali pengine. Uliza mfumo unaoendesha badala ya historia ya terminal yako.
printenv RMW_IMPLEMENTATION
ros2 doctor --report | head -n 20Kigezo kisichowekwa kwa kawaida humaanisha chaguo-msingi kilichosakinishwa, ambacho kinaweza kutofautiana kati ya mashine katika jaribio moja. Ripoti pia hutaja usambazaji na middleware inayotumika, kwa hivyo vilinganishe pande zote mbili za handaki kabla ya kudhani vinalingana. Daemon ya mstari wa amri ya ROS huhifadhi hali kwenye akiba, kwa hivyo iianzishe upya baada ya kubadilisha mazingira badala ya kuacha daemon iliyopitwa na wakati ijibu kwa usanidi wa zamani. Andika usambazaji na RMW ya wenyeji wote wawili kwenye maelezo ya jaribio wakati kikao kiko wazi.
Jaribu ugunduzi na data kama matokeo mawili
Chagua mada isiyo na madhara na pima utambulisho kando na uwasilishaji. Amri ya info huorodhesha vituo na QoS, wakati echo huthibitisha kama ujumbe mmoja unavuka kiungo kweli.
ros2 topic info /chatter --verbose
ros2 topic echo /chatter --onceKuonekana kwa vituo kwenye matokeo ya info ni matokeo ya ugunduzi. Ujumbe kumfikia mteja ni matokeo ya usafirishaji, na ni wa pili pekee unaojaribu njia inayohitajika na programu. Ugunduzi unapofanya kazi na echo inapoisha muda, chunguza anwani zilizotangazwa na njia ya kurudi badala ya huduma ya ugunduzi. Endesha amri zote mbili kutoka kwa kila mwenyeji, kwa sababu njia ya VPN isiyo na ulinganifu mara nyingi hujidhihirisha kutoka upande mmoja pekee.
Badilisha utegemezi mmoja kwa wakati
Njia ya data inaposhindwa, epuka kubadilisha middleware, hali ya ugunduzi na ukubwa wa ujumbe katika kikao kimoja, kwa sababu hakuna matokeo yanayoweza kuhusishwa baadaye. Zenoh RMW ni mbadala halali, lakini kipanga njia chake kinakuwa utegemezi mwingine ambao lazima ufikike kupitia handaki.
export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohdChini ya RMW hiyo kipanga njia hubeba ugunduzi katika mpangilio chaguo-msingi wa Jazzy, na ugunduzi wa multicast umezimwa hapo, kwa hivyo utegemezi ni wa maelezo yako na si wa dhana iliyoazimwa kutoka middleware nyingine. Weka mzigo wa kazi ukiwa thabiti unapobadilisha mpangilio mmoja, kisha rudia jaribio la echo na urekodi mwelekeo, kasi ya ujumbe na hali za kiungo. Endesha ulinganisho mara mbili ili kutenganisha uboreshaji halisi na kuunganishwa tena kwa bahati. Ikiwa mabadiliko yanaboresha ugunduzi wakati uwasilishaji unabaki sawa, umehamisha huduma ya utambulisho, si njia ya data.