VPN પર ROS 1 વિષયો: જાહેર કરેલા અંતિમ બિંદુને અનુસરો
ROS 1 master નોંધણી વિષય ડેટા વહન કરતી નથી. જાહેર કરેલ નોડ URI વાંચો, તે સરનામું રૂટ કરી શકાય તેવું બનાવો, પછી પ્રકાશકનો પોર્ટ મંજૂર કરો.
તમારું વર્કસ્ટેશન ટનલ દ્વારા ROS 1 master સુધી પહોંચે છે અને તો પણ વિષયોની યાદી ખાલી દેખાય છે. આ પેટર્ન સામાન્ય છે કારણ કે master નોંધણી અને વિષય પરિવહન બે અલગ વાતચીતો છે, અને ફક્ત પ્રથમ એક જ master દ્વારા જાય છે. નીચેની ચેકલિસ્ટ બીજી વાતચીત ચાલે છે: પ્રકાશક જે અંતિમ બિંદુ જાહેર કરે છે, ગ્રાહક જે સરનામે પહોંચી શકવો જોઈએ અને જે પરવાનગી બંનેને વાત કરવા દે છે. અહીં બધું ફક્ત જૂના ROS 1 પૂરતું છે, જેની Noetic સપોર્ટ વિન્ડો મે 2025 માં પૂરી થઈ.
પગલું 1: સાબિત કરો કે master જોડાણ વિષય જોડાણ નથી
શું કામ કરે છે અને શું નથી કરતું તે અલગ કરીને શરૂ કરો. સફળ rostopic list સાબિત કરે છે કે તમારો શેલ master ના XMLRPC પોર્ટ સુધી પહોંચી શકે છે અને master ને વિષયોની જાણ છે; ગ્રાહક પ્રકાશક સુધી પહોંચી શકે છે કે નહીં તે વિશે તે કંઈ કહેતું નથી. નીચેની ત્રણ આદેશો આ ભેદ દૃશ્યમાન કરે છે, અને તે બધા ફક્ત વાંચવા માટેના છે.
echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter
rostopic info નું આઉટપુટ પ્રકાશકના નોડ URI નું નામ આપે છે, જે પ્રકાશકના હોસ્ટ પરનું XMLRPC સરનામું છે. તે સરનામું જ તમારો ગ્રાહક આગળ કૉલ કરશે, તેથી ગ્રાહક જ્યાં પણ ચાલે ત્યાંથી તે પહોંચી શકાય તેવું હોવું જોઈએ. જો તે એવા ઇન્ટરફેસ તરફ ઇશારો કરે જે ફક્ત રોબોટના પોતાના LAN પર જ છે, તો master શોધ સફળ થાય છે અને ડેટા ક્યારેય પહોંચતો નથી.
પગલું 2: જાહેર કરેલ અંતિમ બિંદુ નોડમાંથી જ વાંચો
ROS 1 તેની જાહેર કરેલ હોસ્ટ ઓળખ ROS_IP અથવા ROS_HOSTNAME માંથી પસંદ કરે છે જ્યારે તેમાંથી એક સેટ હોય, અને અન્યથા હોસ્ટના પોતાના નામ-ઉકેલ પર પાછું જાય છે. ખરેખર શરૂ થયેલી પ્રક્રિયાનું વાતાવરણ તપાસો, કારણ કે systemd એકમ, કન્ટેનર અથવા બીજું ટર્મિનલ તમારી કસોટી જ્યાં ચાલી હતી તે શેલ કરતાં અલગ મૂલ્ય ધરાવી શકે છે.
echo "$ROS_IP" "$ROS_HOSTNAME"
rosnode info /talker
getent hosts robot-host
હોસ્ટનામ જાહેરાત ફક્ત ત્યારે જ કામ કરે છે જ્યારે દરેક પીઅર તે નામને ઇચ્છિત પહોંચી શકાય તેવા સરનામે ઉકેલે. જો તે નામ ફક્ત રોબોટના પોતાના નેટવર્કની અંદર ઉકેલાય, તો ટનલની બીજી બાજુનું વર્કસ્ટેશન તેનો ઉપયોગ કરવાનો કોઈ રસ્તો ધરાવતું નથી, અને કોઈ DNS પ્રત્યય ધકેલે નહીં તેવું VPN અસંગતિને વધુ ખરાબ કરે છે. ટોપોલોજી રૂટ કરેલી હોય ત્યારે ROS_IP ને ટનલ સરનામે સેટ કરવું નાનો ફેરફાર છે. તમે જે પણ પસંદ કરો, તેને બંને છેડા માટે નોંધો, કારણ કે ઓળખ વિશે અસહમત પ્રકાશક અને ગ્રાહક વાટાઘાટ કરશે અને પછી જોડાઈ શકશે નહીં.
જો જાહેર કરેલ URI એવા સરનામાનો ઉપયોગ કરે જ્યાં કોઈ પીઅર રૂટ કરી શકતું ન હોય, તો અહીં થોભો. ખોટા ઇન્ટરફેસ પર ઉકેલાતા નામને કોઈ ફાયરવોલ કાર્ય સુધારશે નહીં.
પગલું 3: જાહેર કરેલ સરનામું ઉકેલી શકાય તેવું અને રૂટ કરેલું બનાવો
URI હાથમાં લઈને, રોબોટ પરથી નહીં પણ ગ્રાહકના હોસ્ટ પરથી પહોંચતા શક્યતા ચકાસો. TCPROS પોર્ટ વાટાઘાટ દરમિયાન પસંદ થાય છે, તેથી ઉપયોગી પ્રારંભિક કસોટી XMLRPC પોર્ટ છે અને ઉપયોગી પછીની કસોટી સ્થપાયેલ સોકેટ છે. ફક્ત એક દિશામાં રહેલો માર્ગ રૂટ કરેલા VPN પર સામાન્ય નિષ્ફળતા છે, અને પાછળનો રસ્તો આગળના રસ્તા જેટલો જ મહત્વપૂર્ણ છે.
ip route get 10.70.0.2
nc -vz 10.70.0.2 33911
ss -tnp dst 10.70.0.2
રૂટ કરેલું TUN ઇન્ટરફેસ રોબોટનું Ethernet સેગમેન્ટ વિસ્તાર્યા વિના આ IP વાતચીતો વહન કરે છે, જે સામાન્ય રીતે દૂરસ્થ ઓપરેટર ઈચ્છે છે. જો સ્ટેકમાં કંઈક તેના બદલે બ્રોડકાસ્ટ કે multicast પર આધાર રાખે, તો તે જરૂરિયાત અલગથી મૂલ્યાંકન કરવી પડશે; એક સાધનને સંતોષવા ટનલને TAP માં ફેરવવાથી દરેક સહભાગી માટે નેટવર્ક પહોળું થાય છે.
જો માર્ગ કે પાછળનો રસ્તો ખૂટે તો અહીં થોભો. પોતાના હોસ્ટ પર જવાબ આપતું પણ વર્કસ્ટેશનથી પહોંચી ન શકાય તેવું પ્રકાશક રૂટિંગ સમસ્યા ધરાવે છે, ROS સમસ્યા નહીં.
પગલું 4: પીઅર વાતચીત મંજૂર કરો અને એક વિષય જુઓ
ફક્ત તે પોર્ટ ખોલો જે વાટાઘાટ કરેલ વાતચીતને જોઈએ છે, અને દરેક નિયમને જાહેર કરેલ સહભાગીઓ સુધી મર્યાદિત કરો. master નો શ્રોતા વિષય પેલોડ માટે રિલે નથી, તેથી ફક્ત તેને મંજૂર કરવાથી પ્રકાશકનું અંતિમ બિંદુ બંધ રહે છે. ROS શ્રોતાઓને જાહેર ઇન્ટરનેટ સામે ખુલ્લા મૂકવાને બદલે ખાનગી VPN સીમા પર રાખો.
rostopic hz /chatter
rostopic echo -n1 /chatter
rosnode ping /talker
ખરા પ્રકાશકથી ખરા ગ્રાહક સુધી એક નિરુપદ્રવી વિષય જુઓ અને જાહેર કરેલ અંતિમ બિંદુ તથા જવાબનો રસ્તો બંનેની પુષ્ટિ કરો. એક સંદેશ સાબિત કરે છે કે રસ્તો કામ કરે છે; સ્થિર દર સાબિત કરે છે કે તે ખુલ્લો રહે છે. એક્ચ્યુએટર નિયંત્રણ અને સલામતી તપાસને આ ફક્ત-નેટવર્ક કસોટીની બહાર રાખો, કારણ કે કામ કરતો વિષય કામ કરતા રોબોટનું પ્રમાણપત્ર નથી. તમે જોયેલ ROS આવૃત્તિ અને અંતિમ બિંદુની જોડી નોંધો, જેથી આગલી વ્યક્તિ ટોપોલોજી ફેરફારને રિગ્રેશનથી અલગ કરી શકે.
ચેકલિસ્ટ ત્યારે પૂરી થાય છે જ્યારે જાહેર કરેલ URI ગ્રાહકથી પહોંચી શકાય તેવું હોય, વાટાઘાટ કરેલ પોર્ટ ફક્ત તે પીઅર માટે ખુલ્લો હોય, એક જાહેર કરેલ વિષય વહેતો હોય, અને વાતાવરણના મૂલ્યો બંને હોસ્ટ માટે લખાયેલા હોય. જૂનું ROS 1 આ ક્ષેત્રમાં સુધારા મેળવશે નહીં, તેથી રેકોર્ડ એ ભાગ છે જે લોકો બદલાયા પછી પણ કામ કરતો રહે છે.