लाइव प्रोसेसिंग या रिकॉर्ड किया गया डेटा: असल में किसे VPN चाहिए?
तय करें कि रोबोट का कौन-सा काम नेटवर्क पार करेगा: समय पर नतीजे, अवलोकन टेलीमेट्री या रिकॉर्ड किया गया डेटासेट। तीन शर्तें, फिर bag कमांड।
एक कमरे की दूरी पर बेकार होने वाले रोबोट को VPN की समस्या से बहुत पहले लिंक या काम के बोझ की समस्या होती है। एन्क्रिप्शन एक रास्ते की रक्षा करता है; वह रेडियो कवरेज नहीं बढ़ाता और दूर की गणना को जल्दी पूरा नहीं कराता। आपके सामने यह फैसला है कि कौन-सा काम सचमुच नेटवर्क पार करना चाहिए, और वह जवाब आम तौर पर लोगों की अपेक्षा से ज़्यादा ट्रैफ़िक हटा देता है। तीन शर्तें इसे तय करती हैं, और थ्रूपुट उनमें से एक नहीं है।
तीन व्यवस्थाएँ, निर्भरता का एक सवाल
तालिका व्यवस्थाओं को इस आधार पर अलग करती है कि क्या लिंक पर निर्भर है, इस आधार पर नहीं कि आरेख में कौन-सा सॉफ़्टवेयर दिखता है।
| Arrangement | What depends on the link | What stays onboard |
|---|---|---|
| Live remote processing | The exchange and any timely result the workstation returns | Only what the remote step does not block |
| Onboard processing, remote observation | The declared telemetry or display stream | The processing loop itself |
| Local recording, later analysis | Transfer of one selected dataset | The entire run, including raw sensors |
उस तालिका की कोई भी पंक्ति सुरक्षा का तर्क नहीं है। नियंत्रण और सुरक्षा कार्यों को देरी, पैकेट हानि और टूटे कनेक्शन के लिए अब भी योग्य जवाब चाहिए, और कोई टनल संकेतक वह नहीं देता। तालिका बताती है कि निर्भरता कहाँ रहती है, और यही वह हिस्सा है जिसे नेटवर्क डिज़ाइन सचमुच बदल सकता है।
शर्त एक: क्या जवाब समय पर होना चाहिए?
अगर दूर का नतीजा किसी नियंत्रक को खिलाता है, तो नेटवर्क नियंत्रण लूप के भीतर बैठता है, और उसकी देरी, जिटर और रुकावटें नियंत्रण के गुण बन जाती हैं। अगर वही नतीजा केवल डिस्प्ले, डैशबोर्ड या देखने वाले व्यक्ति को खिलाता है, तो वही देरी दिखावटी है।
बेतार लिंक पर क्लोज़्ड-लूप काम संभव है, और “VPN धीमा है” वाली ज़्यादातर रिपोर्टें यहीं से आती हैं, क्योंकि टनल दिखने वाला हिस्सा है जबकि रेडियो और राउटिंग कारण हैं। टनल के अपने ping के बजाय असली संदेश का आना-जाना मापें, फिर पूछें कि क्या संख्या लूप के बजट में फिट बैठती है। जब नहीं बैठती, तो कदम को ऑनबोर्ड ले जाएँ, ऐसे लिंक के लिए सख़्त सेवा स्तर पर मोल-भाव करने के बजाय जिसे कमरे में कोई नियंत्रित नहीं करता। मापी गई संख्या को उन स्थितियों के साथ लिखें जिनमें वह ली गई, क्योंकि अगली रिपोर्ट उनके बिना आएगी।
शर्त दो: कौन-सी दर, दिशा और रुकावट आप घोषित कर सकते हैं?
डेटा, दर, दिशा और वह सबसे लंबी रुकावट लिखें जो एप्लिकेशन सहता है। ऊपर जाने वाला कैमरा स्ट्रीम और नीचे जाने वाला कमांड चैनल अलग-अलग तरह से विफल होते हैं, और स्थिर निरीक्षण जो रुकावट सहता है वह चलते काम को ख़त्म कर देगी।
विकल्पों की तुलना करते समय भौतिक जुड़ाव और टनल को अलग रखें, क्योंकि ज़्यादा मज़बूत रेडियो और कम काम का बोझ अलग-अलग मरम्मतें हैं। बड़ा ट्रांसफ़र जो आख़िर में पूरा हो जाता है, समय-संवेदनशील नतीजे के लगातार आने के बारे में कुछ साबित नहीं करता, और स्वस्थ टनल अपने पीछे के रेडियो के बारे में कुछ साबित नहीं करता।
फिर मांग का बचाव करने के बजाय उसे घटाएँ। अवलोकन स्ट्रीम का सैंपलिंग घटाएँ, सारांश या डेल्टा भेजें, और कच्चा सेंसर डेटा ऑनबोर्ड रखें जहाँ भंडारण सस्ता है और प्रसारण नहीं। छोटा पेलोड तेज़ लिंक के पक्ष में तर्क को कमज़ोर करता है, और अक्सर उसकी ज़रूरत ही हटा देता है।
शर्त तीन: किसे यह देखना है, और क्या स्थानीय रहता है
अवलोकन आम तौर पर प्रोसेसिंग से कहीं छोटी आवश्यकता है। अगर किसी व्यक्ति को कैमरा देखना है और बाद में लॉग मौजूद होना चाहिए, तो यह टेलीमेट्री के साथ भंडारण है; अगर कोई मॉडल चलना चाहिए, तो पहले पूछें कि क्या वह ऑनबोर्ड चल सकता है और केवल उसका नतीजा आगे भेजा जाए। भारी कदम ऑनबोर्ड ले जाने से समकालिक निर्भरता हट जाती है और ऐसा ट्रांसफ़र बचता है जिसे दोहराया जा सकता है।
एक ही रोबोट पर दो 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 ऐसे आदान-प्रदान की रक्षा करता है जो होना ही है, ऑनबोर्ड प्रोसेसिंग ऐसे आदान-प्रदान को हटा देती है जिसे कभी समकालिक होने की ज़रूरत नहीं थी, और रिकॉर्ड किया गया डेटासेट जीवित उपभोक्ता को बाद वाले से बदल देता है। फिर किसी के डिज़ाइन को पूरा कहने से पहले, स्थानीय काम के चलते रहते हुए, डिस्कनेक्टेड स्थिति का जानबूझकर परीक्षण करें।