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 चाचणी पुन्हा करा आणि दिशा, संदेश दर आणि लिंक परिस्थिती नोंदवा। खऱ्या सुधारणेला भाग्यवान पुनःकनेक्शनपासून वेगळे करण्यासाठी तुलना दोनदा चालवा। जर बदलामुळे शोध सुधारला पण डिलिव्हरी तशीच राहिली, तर तुम्ही ओळख सेवा हलवली आहे, डेटा मार्ग नाही।