आपका वर्कस्टेशन टनल से होकर 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 इस क्षेत्र में सुधार नहीं पाएगा, इसलिए रिकॉर्ड वह हिस्सा है जो लोगों के बदलने के बाद भी काम करता रहता है।

संबंधित लेख