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 परीक्षण दोहराएँ और दिशा, संदेश दर तथा लिंक स्थितियाँ दर्ज करें। वास्तविक सुधार को भाग्यशाली पुनःकनेक्शन से अलग करने के लिए तुलना दो बार चलाएँ। यदि कोई परिवर्तन डिस्कवरी सुधारता है जबकि डिलीवरी समान रहती है, तो आपने परिचय सेवा स्थानांतरित की है, डेटा पथ नहीं।