एक कोठा टाढा उपयोगी नरहने रोबोटलाई VPN को समस्या आउनु धेरै अघि लिङ्कको वा कामको भारको समस्या हुन्छ। इन्क्रिप्सनले मार्ग सुरक्षित गर्छ, तर यसले रेडियोको पहुँच विस्तार गर्दैन र टाढाको गणना चाँडै सकिँदैन। तपाईंको अगाडिको निर्णय कुन कामले साँच्चै नेटवर्क पार गर्नुपर्छ भन्ने हो, र त्यो उत्तरले सामान्यतया मानिसहरूले अपेक्षा गरेभन्दा बढी ट्राफिक हटाउँछ। यसलाई तीन सर्तले निर्धारण गर्छ, र थ्रूपुट तीमध्ये एक होइन।

तीन व्यवस्था, एउटा निर्भरता प्रश्न

तालिकाले व्यवस्थाहरूलाई रेखाचित्रमा कुन सफ्टवेयर देखिन्छ भनेर होइन, लिङ्कमा के निर्भर छ भनेर छुट्याउँछ।

ArrangementWhat depends on the linkWhat stays onboard
Live remote processingThe exchange and any timely result the workstation returnsOnly what the remote step does not block
Onboard processing, remote observationThe declared telemetry or display streamThe processing loop itself
Local recording, later analysisTransfer of one selected datasetThe entire run, including raw sensors

त्यो तालिकाको कुनै पनि पङ्क्ति सुरक्षा तर्क होइन। नियन्त्रण र सुरक्षा कार्यहरूलाई ढिलाइ, प्याकेट हराउने र जडान टुट्ने विषयमा योग्य उत्तर अझै चाहिन्छ, र कुनै सुरुङ सूचकले त्यो दिँदैन। तालिकाले निर्भरता कहाँ छ भनेर बताउँछ, र नेटवर्क डिजाइनले साँच्चै बदल्न सक्ने भाग त्यही हो।

पहिलो सर्त: उत्तर समयमै हुनुपर्छ?

यदि टाढाको नतिजा नियन्त्रकमा जान्छ भने, नेटवर्क नियन्त्रण चक्रभित्र बस्छ, र यसको ढिलाइ, जिटर र अवरोध नियन्त्रणका गुण बन्छन्। यदि त्यही नतिजा केवल डिस्प्ले, ड्यासबोर्ड वा हेर्ने व्यक्तिमा जान्छ भने, त्यही ढिलाइ केवल देखावटी हो।

वायरलेस लिङ्कमा बन्द चक्रको काम सम्भव छ, र "VPN ढिलो छ" भन्ने धेरै रिपोर्ट यहीँबाट आउँछन्, किनकि सुरुङ देखिने घटक हो भने कारण रेडियो र मार्गनिर्देशन हो। सुरुङको आफ्नै पिङ होइन, वास्तविक सन्देशको आवतजावत समय नाप्नुहोस्, त्यसपछि त्यो सङ्ख्या चक्रको बजेटमा मिल्छ कि भनेर सोध्नुहोस्। नमिलेमा, कोठामा कसैले नियन्त्रण नगर्ने लिङ्कका लागि कडा सेवा स्तरमा वार्ता गर्नुको सट्टा चरणलाई अनबोर्डमा सार्नुहोस्। नापिएको सङ्ख्या कुन अवस्थामा लिइयो त्यससँगै लेख्नुहोस्, किनकि अर्को रिपोर्ट ती अवस्थाबिना आउनेछ।

दोस्रो सर्त: कुन दर, दिशा र अवरोध तपाईं घोषणा गर्न सक्नुहुन्छ?

डाटा, दर, दिशा र अनुप्रयोगले सहने सबैभन्दा लामो अवरोध लेख्नुहोस्। माथितिरको क्यामेरा प्रवाह र तलतिरको आदेश च्यानल फरक तरिकाले असफल हुन्छन्, र स्थिर निरीक्षणले सहने अवरोधले चलिरहेको काम अन्त्य गर्छ।

विकल्प तुलना गर्दा भौतिक जडान र सुरुङ अलग राख्नुहोस्, किनकि बलियो रेडियो र कम कामको भार फरक मर्मत हुन्। अन्ततः पूरा हुने ठूलो स्थानान्तरणले समय-संवेदनशील नतिजा निरन्तर आउँछ भन्ने प्रमाण दिँदैन, र स्वस्थ सुरुङले त्यसपछाडिको रेडियोको प्रमाण दिँदैन।

त्यसपछि मागको बचाउ गर्नुको सट्टा घटाउनुहोस्। अवलोकन प्रवाहको नमुना घटाउनुहोस्, सारांश वा डेल्टा पठाउनुहोस्, र कच्चा सेन्सर डाटा भण्डारण सस्तो र प्रसारण महँगो हुने ठाउँमा अनबोर्डै राख्नुहोस्। सानो पेलोडले छिटो लिङ्कको तर्क कमजोर बनाउँछ र प्रायः त्यसको आवश्यकता नै हटाउँछ।

तेस्रो सर्त: यो कसले देख्नुपर्छ, र के स्थानीय रहन्छ

अवलोकन सामान्यतया प्रशोधनभन्दा धेरै सानो आवश्यकता हो। यदि व्यक्तिले क्यामेरा हेर्नुपर्छ र पछि लग हुनुपर्छ भने त्यो टेलिमेट्री र भण्डारण हो; यदि मोडेल चल्नुपर्छ भने, यो अनबोर्डमै चल्न सक्छ र केवल नतिजा अगाडि पठाउन सकिन्छ भनेर पहिले सोध्नुहोस्। गह्रौँ चरण अनबोर्ड सार्दा सिंक्रोनस निर्भरता हट्छ र पुनः प्रयास गर्न सकिने स्थानान्तरण मात्र रहन्छ।

एउटै रोबोटमा दुई ROS सहभागी हुनुले आफैमा सुरुङको औचित्य पुष्टि गर्दैन। नोडको पहुँच, अनुप्रयोगको अधिकार र स्थानीय पुनःप्राप्ति योजना अलग समस्या हुन्, र VPN ले पहिलोलाई मात्र जवाफ दिन्छ, र त्यो पनि मार्गनिर्देशन गर्न भनिएको ट्राफिकका लागि मात्र।

डाटासेट रेकर्ड गर्नु आफ्नै आदेश भएको छुट्टै डिजाइन हो

संस्करणसँग जोडिएको उदाहरणका लागि, ROS 2 Jazzy रेकर्डिङ ट्युटोरियल ले चुनिएका विषयहरू रेकर्ड गर्ने, तयार भएको bag जाँच्ने र त्यसलाई पुनः बजाउने कुरा समेट्छ। स्वीकृत अवलोकन विषयहरू रेकर्ड गर्नुहोस्, दौडलाई नाम दिनुहोस्, र सन्देश परिभाषा तथा कन्फिगरेसन त्यसैको छेउमा राख्नुहोस्।

ros2 bag record -o run42 /scan /camera/image_raw
ros2 bag info run42
ros2 bag play run42

उपकरण सजिलो छ भनेर हरेक विषय रेकर्ड नगर्नुहोस्। भण्डारण भरिन्छ, क्यामेरा र स्थान डाटा संवेदनशील हुन्छ, र लेबल नभएका विषयको bag अर्को पटक खोल्नेका लागि विश्लेषणको समस्या बन्छ। तैनाथ गरिएको वितरणले आदेशहरू पनि निर्धारण गर्छ: ROS 1 bag का लागि लेखिएका उपकरण ROS 2 bag मा जाँदैनन्, त्यसैले कागजातलाई रोबोटमा स्थापित संस्करणसँग मिलाउनुहोस्।

अलग विश्लेषण वा सिमुलेसन वातावरणमा पुनः बजाउनुहोस्। रेकर्ड गरिएका आदेश विषयहरू चलिरहेको रोबोटका एक्चुएटरमा पुनः बजाउनु दुर्घटना हो, र रोकथाम भनेको छुट्टै ROS डोमेन वा चक्रमा कुनै हार्डवेयर नहुनु हो।

निर्भरता कहाँ पर्नुपर्छ भनेर निर्णय गरी लेख्नुहोस्: VPN ले हुनैपर्ने आदानप्रदान सुरक्षित गर्छ, अनबोर्ड प्रशोधनले सिंक्रोनस हुनु नपर्ने आदानप्रदान हटाउँछ, र रेकर्ड गरिएको डाटासेटले प्रत्यक्ष उपभोक्तालाई पछिको उपभोक्ताद्वारा प्रतिस्थापन गर्छ। त्यसपछि डिजाइन सकियो भनी कसैले भन्नु अघि स्थानीय काम अझै चलिरहेको अवस्थामा जडान काटिएको अवस्था जानाजान परीक्षण गर्नुहोस्।

सम्बन्धित लेखहरू