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