VPN પર ROS 2: ડિસ્કવરી એ ડેટા પાથ નથી

VPN ના વિરોધી છેડે રહેલા બે ROS 2 નોડ એકબીજાના વિષયોની સૂચિ બનાવી શકે છે અને તેમ છતાં એક પણ સંદેશ પહોંચાડી શકતા નથી. ડિસ્કવરી અને વપરાશકર્તા ડેટા અલગ માર્ગો સાથેના અલગ વિનિમયો છે, અને ડિસ્કવરી સર્વર પેલોડ રિલે કરતું નથી. એક તપાસીને બીજું માની લેવું એ જ રીતે ટીમો મિડલવેર બદલવા લાગે છે જ્યારે ટનલે ક્યારેય ડેટા વહન કર્યો જ ન હોય. નીચેની પ્રક્રિયા કંઈપણ બદલતા પહેલાં બે પરિણામોને અલગ કરે છે.

ડિસ્કવરી સર્વર ખરેખર શું વહન કરે છે

Fast DDS માં Discovery Server એન્ડપોઇન્ટ્સ વિશે માહિતી વિતરિત કરે છે: કોણ પ્રકાશિત કરે છે, કોણ સબ્સ્ક્રાઇબ કરે છે અને દરેક કઈ QoS ની અપેક્ષા રાખે છે. સાથીઓ એકબીજાને જાણ્યા પછી વપરાશકર્તા ડેટા તે સર્વર દ્વારા નહીં પણ સીધો તેમની વચ્ચે જાય છે. સર્વર સુધી પહોંચવું સાબિત કરે છે કે પરિચયનો બ્રોકર જવાબ આપે છે, વધુ નહીં. રાઉટેડ VPN ને હજી પણ સાથીઓ જાહેર કરેલા સરનામાંઓ વચ્ચે બંને દિશામાં કાર્યકારી માર્ગની જરૂર છે.

એ ભેદ આંશિક નિષ્ફળતાઓને પણ સમજાવે છે, જ્યાં હાલના સાથીઓ ડેટાનું વિનિમય ચાલુ રાખે છે જ્યારે નવી ડિસ્કવરી કામ કરવાનું બંધ કરે છે. તેમને બે અલગ તપાસ તરીકે ગણો.

નોડ ખરેખર જે RMW વાપરે છે તે વાંચો

ROS 2 વિવિધ મિડલવેર લોડ કરી શકે છે, અને તમારા શેલમાં એક્સપોર્ટ કરેલું ચલ બીજે શરૂ થયેલી પ્રક્રિયાઓ સુધી પહોંચતું નથી. તમારા ટર્મિનલ ઇતિહાસને બદલે ચાલતી સિસ્ટમને પૂછો.

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

સેટ ન કરેલું ચલ સામાન્ય રીતે ઇન્સ્ટોલ કરેલા ડિફોલ્ટનો અર્થ થાય છે, જે એક જ પ્રયોગમાં મશીનો વચ્ચે અલગ હોઈ શકે છે. રિપોર્ટ વપરાયેલી ડિસ્ટ્રિબ્યુશન અને મિડલવેરનું નામ પણ આપે છે, તેથી બંને મેળ ખાય છે એમ માની લેતા પહેલાં ટનલની બંને બાજુ તેમની તુલના કરો. ROS કમાન્ડ-લાઇન ડીમન સ્થિતિને કેશ કરે છે, તેથી પર્યાવરણ બદલ્યા પછી તેને ફરી શરૂ કરો, જૂની ગોઠવણી માટે જૂના ડીમનને જવાબ આપવા દેવાને બદલે. સેશન ખુલ્લું હોય ત્યારે બંને હોસ્ટની ડિસ્ટ્રિબ્યુશન અને RMW પરીક્ષણ નોંધમાં લખો.

ડિસ્કવરી અને ડેટાને બે પરિણામ તરીકે ચકાસો

એક નિરુપદ્રવી વિષય પસંદ કરો અને પરિચયને ડિલિવરીથી અલગ માપો. info આદેશ એન્ડપોઇન્ટ્સ અને QoSની સૂચિ આપે છે, જ્યારે echo સાબિત કરે છે કે એક સંદેશ ખરેખર લિંક પાર કરે છે કે નહીં.

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

info આઉટપુટમાં એન્ડપોઇન્ટ્સ દેખાવું એ ડિસ્કવરી પરિણામ છે. સંદેશ સબ્સ્ક્રાઇબર સુધી પહોંચવો એ ટ્રાન્સપોર્ટ પરિણામ છે, અને ફક્ત બીજું જ એપ્લિકેશનને જરૂરી માર્ગનું પરીક્ષણ કરે છે. જ્યારે ડિસ્કવરી કામ કરે અને echo સમય સમાપ્ત થાય, ત્યારે ડિસ્કવરી સેવાને બદલે જાહેર કરેલા સરનામાંઓ અને પરત માર્ગની તપાસ કરો. દરેક હોસ્ટથી બંને આદેશ ચલાવો, કારણ કે અસમપ્રમાણ VPN માર્ગ ઘણી વાર ફક્ત એક જ બાજુથી પોતાને પ્રગટ કરે છે.

એક સમયે એક અવલંબન બદલો

જ્યારે ડેટા માર્ગ નિષ્ફળ જાય, ત્યારે એક જ સેશનમાં મિડલવેર, ડિસ્કવરી મોડ અને સંદેશ કદ બદલવાનું ટાળો, કારણ કે પછી કોઈ પરિણામને આભારી શકાતું નથી. Zenoh RMW એ કાયદેસર વિકલ્પ છે, પરંતુ તેનું રાઉટર બીજું અવલંબન બની જાય છે જે ટનલ દ્વારા પહોંચી શકાય તેવું હોવું જોઈએ.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

તે RMW હેઠળ રાઉટર ડિફોલ્ટ Jazzy ગોઠવણીમાં ડિસ્કવરી વહન કરે છે, અને ત્યાં મલ્ટીકાસ્ટ ડિસ્કવરી નિષ્ક્રિય છે, તેથી અવલંબન બીજા મિડલવેરમાંથી ઉધાર લીધેલી ધારણામાં નહીં પરંતુ તમારી નોંધમાં હોવું જોઈએ. એક સેટિંગ બદલતી વખતે વર્કલોડ સ્થિર રાખો, પછી echo પરીક્ષણનું પુનરાવર્તન કરો અને દિશા, સંદેશ દર અને લિંકની સ્થિતિ નોંધો. સાચા સુધારાને નસીબદાર પુનઃકનેક્શનથી અલગ કરવા માટે સરખામણી બે વાર ચલાવો. જો કોઈ ફેરફાર ડિસ્કવરી સુધારે પણ ડિલિવરી સમાન રહે, તો તમે પરિચય સેવા ખસેડી છે, ડેટા માર્ગ નહીં.