ROS 2 sa isang VPN: ang pagtuklas ay hindi ang landas ng datos

Dalawang node ng ROS 2 sa magkabilang dulo ng VPN ay maaaring ilista ang mga paksa ng isa't isa at gayon pa man ay hindi makapaghatid ng kahit isang mensahe. Ang pagtuklas at datos ng gumagamit ay magkahiwalay na palitan na may magkahiwalay na landas, at ang server ng pagtuklas ay hindi nagpapasa ng mga payload. Ang suriin ang isa at ipagpalagay ang isa pa ang dahilan kung bakit napapalitan ng mga koponan ang middleware kapag ang tunel ay talagang hindi kailanman nagdala ng datos. Ang pamamaraan sa ibaba ay naghihiwalay sa dalawang resulta bago palitan ang anuman.

Ano ang aktuwal na dinadala ng server ng pagtuklas

Sa Fast DDS, ang Discovery Server ay namamahagi ng impormasyon tungkol sa mga endpoint: sino ang naglalathala, sino ang nag-subscribe at anong QoS ang inaasahan ng bawat isa. Kapag magkakilala na ang mga kapares, ang datos ng gumagamit ay direktang naglalakbay sa pagitan nila sa halip na dumaan sa server na iyon. Ang maabot ang server ay nagpapatunay na sumasagot ang tagapamagitan ng mga pagpapakilala, at wala nang iba pa. Ang isang niruruta na VPN ay nangangailangan pa rin ng gumaganang landas sa dalawang direksyon sa pagitan ng mga address na inaanunsyo ng mga kapares.

Ipinapaliwanag din ng pagkakaibang iyon ang mga bahagyang pagkabigo, kung saan ang mga umiiral na kapares ay patuloy na nagpapalitan ng datos habang ang bagong pagtuklas ay tumitigil sa paggana. Ituring ang mga ito bilang dalawang hiwalay na imbestigasyon.

Basahin ang RMW na talagang ginagamit ng mga node

Maaaring mag-load ang ROS 2 ng iba't ibang middleware, at ang isang variable na na-export sa iyong shell ay hindi umaabot sa mga prosesong sinimulan sa ibang lugar. Tanungin ang tumatakbong sistema sa halip na ang kasaysayan ng iyong terminal.

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

Ang isang variable na hindi naitakda ay karaniwang nangangahulugan ng naka-install na default, na maaaring magkaiba sa pagitan ng mga makina sa parehong eksperimento. Binabanggit din ng ulat ang distribusyon at ang middleware na ginagamit, kaya ihambing ang mga ito sa magkabilang panig ng tunel bago ipagpalagay na magkatugma. Ang daemon ng command line ng ROS ay nag-cache ng estado, kaya i-restart ito pagkatapos baguhin ang kapaligiran sa halip na hayaang sumagot ang isang lumang daemon para sa dating configuration. Isulat ang distribusyon at RMW ng dalawang host sa mga tala ng pagsubok habang bukas ang session.

Subukan ang pagtuklas at datos bilang dalawang resulta

Pumili ng hindi mapanganib na paksa at sukatin ang pagpapakilala nang hiwalay sa paghahatid. Ang utos na info ay naglilista ng mga endpoint at QoS, habang ang echo ay nagpapatunay kung ang isang mensahe ay talagang tumatawid sa link.

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

Ang paglitaw ng mga endpoint sa output ng info ay isang resulta ng pagtuklas. Ang pagdating ng mensahe sa subscriber ay isang resulta ng transportasyon, at tanging ang pangalawa ang sumusubok sa landas na kailangan ng aplikasyon. Kapag gumagana ang pagtuklas at nag-time out ang echo, siyasatin ang mga inanunsyong address at ang pabalik na ruta sa halip na ang serbisyo ng pagtuklas. Patakbuhin ang parehong utos mula sa bawat host, dahil ang isang asymmetric na ruta ng VPN ay madalas na nagpapakita lamang mula sa isang panig.

Baguhin ang isang dependency sa isang pagkakataon

Kapag nabigo ang landas ng datos, iwasang baguhin ang middleware, mode ng pagtuklas at laki ng mensahe sa parehong session, dahil wala nang resulta ang maipapataw pagkatapos. Ang Zenoh RMW ay isang lehitimong alternatibo, ngunit ang router nito ay nagiging isa pang dependency na dapat maabot sa pamamagitan ng tunel.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

Sa ilalim ng RMW na iyon, ang router ay nagdadala ng pagtuklas sa default na kaayusan ng Jazzy, at ang multicast na pagtuklas ay hindi pinagana doon, kaya ang dependency ay kabilang sa iyong mga tala at hindi sa isang palagay na hiram mula sa ibang middleware. Panatilihing maayos ang workload habang binabago mo ang isang setting, pagkatapos ay ulitin ang pagsubok na echo at itala ang direksyon, rate ng mensahe at mga kondisyon ng link. Patakbuhin ang paghahambing nang dalawang beses upang ihiwalay ang tunay na pagpapabuti mula sa isang mapalad na muling pagkonekta. Kung ang isang pagbabago ay nagpapabuti sa pagtuklas habang ang paghahatid ay nananatiling pareho, inilipat mo ang serbisyo ng pagpapakilala, hindi ang landas ng datos.