बहुत छोटा जवाब: २
सेंसर
सभी नोड्स में या अलग से सेंसर से पढ़ने के बारे में, आपको खुद से यह सवाल पूछना चाहिए:
क्या सेंसर दूसरे के बिना अर्थहीन हैं?
यह प्रश्न पूछता है कि सेंसर कसकर युग्मित हैं या नहीं। उदाहरण के लिए, मान लें कि आपके पास एक सेंसर है जो तापमान के प्रति संवेदनशील है (और आपको इसकी भरपाई करने की आवश्यकता है)। आप अन्य सेंसर के मूल्य को ठीक करने के लिए मुख्य रूप से एक तापमान संवेदक जोड़ते हैं। इस परिदृश्य में, यह एक ही समय में दोनों मानों को पढ़ने के लिए समझ में आता है, क्योंकि वे कसकर युग्मित हैं। वास्तव में, तापमान सेंसर से रीडिंग के बिना, मूल सेंसर से रीडिंग बेकार है।
दूसरी ओर, यदि सेंसर व्यक्तिगत रूप से उपयोगी हैं, तो हर तरह से उन्हें अलग-अलग नोड्स में रखें। इसके कई लाभ हैं:
- नोड्स को अलग-अलग प्रोसेसर पर चलाया जा सकता है
- भविष्य के रोबोट में नोड्स का पुन: उपयोग किया जा सकता है
- एक नोड के साथ संचार में विफलता पूरे सिस्टम को नीचे नहीं लाती है
- दोषपूर्ण सेंसर बोर्ड से अधिग्रहण को फिर से करना दूसरों से अलग किया जा सकता है
वास्तव में, यदि आपको उपरोक्त किसी भी लाभ की आवश्यकता है, तो आपको अलग-अलग नोड्स के साथ जाना होगा, भले ही सेंसर कसकर युग्मित हों, लेकिन आमतौर पर ऐसा नहीं होता है।
एक्चुएटर
यह अनुरूप है।
क्या एक्ट्यूटर्स दूसरे के बिना अर्थहीन हैं?
उदाहरण के लिए, यदि आप रोबोट टेंडन के साथ एक कलाई डिजाइन कर रहे हैं, जहां प्रत्येक कण्डरा के लिए (जो भी कारण हो) दो मोटर्स एक साथ एक या दूसरी दिशा में एक संयुक्त काम करने के लिए जिम्मेदार हैं, तो उन्हें एक ही नोड में सेवा करने से बहुत अधिक होता है अलग से समझ।
दूसरी ओर, जहां एक्ट्यूएटर स्वतंत्र (सामान्य मामला) हैं, यह प्रत्येक एक्ट्यूएटर के लिए एक नोड होने के लिए समझ में आता है। उस स्थिति में, प्रत्येक को एक अलग नोड में रखा जा सकता है। सेंसरों के समान सटीक लाभों के अलावा, यह अतिरिक्त लाभ है:
- यदि कोई एक्ट्यूएटर्स रुका हुआ है (जो भी कारण के लिए), तो अन्य एक्ट्यूएटर्स अभी भी कार्य करते हैं। यदि स्वतंत्रता की बेमानी डिग्री है, तो वे इसके लिए पूरी तरह से क्षतिपूर्ति भी कर सकते हैं।
इसका एक निहितार्थ है। यदि आपको एक्ट्यूएटर्स को सद्भाव में काम करने की आवश्यकता है, तो उन्हें उसी नोड में डालें। यह केवल संचार में विफलता के कारण नहीं है, बल्कि इसलिए कि विभिन्न नोड्स का मतलब अलग-अलग देरी है; एक वितरित प्रणाली पर प्रत्येक नोड नेटवर्क के एक अलग हिस्से पर है और इसलिए देरी में अंतर, एक केंद्रीकृत प्रणाली पर शेड्यूलिंग में प्रत्येक प्रक्रिया के भाग्य के कारण उच्च सीपीयू लोड पर विभिन्न देरी होती है ।
क्या एक हैंडलर होना चाहिए?
भले ही इसका जवाब "यह निर्भर करता है", कई फायदे के साथ एक सामान्य दृष्टिकोण है। आइए नाम बदलें और इसे "नियंत्रक" कहें। दृष्टिकोण "हाँ, एक नियंत्रक होना चाहिए"।
नियंत्रक होने के फायदे (कई के बीच):
- अस्वीकृत प्रक्रिया: प्रत्येक नोड एक चीज़ के लिए ज़िम्मेदार है जिसका अर्थ है:
- सरलता: जिसका अर्थ है
- आसान विकास
- आसान डिबगिंग
- कम त्रुटियाँ
- असफलता की संभावना कम
- पुन: प्रयोज्य: क्योंकि एक ही नियंत्रक का उपयोग विभिन्न सेंसर नोड्स के साथ किया जा सकता है यदि उनके पास समान कार्यक्षमता (यानी संदेश और सेवा प्रारूप) हो।
- अलग हार्डवेयर पर निष्पादन: प्रत्येक नोड को नेटवर्क में स्थानांतरित किया जा सकता है। उदाहरण के लिए, सेंसर और एक्चुएटर नोड को एक समर्पित माइक्रोकंट्रोलर ( उदाहरण के लिए Arduino) में ले जाया जा सकता है (ऐसा नहीं है कि मैं सलाह देता हूं) और एक पीसी पर नियंत्रक।
- अत्यधिक कुरूपता से बचें: यदि सेंसर सीधे एक्ट्यूएटर्स को प्रभावित करना चाहते थे, तो परिणाम केवल एक गड़बड़ है। कोई नियंत्रक नहीं मानते हुए, आइए प्रत्येक मामले को देखें:
- एक सेंसर नोड: मूल रूप से इसका मतलब सेंसर नोड और नियंत्रक को एक ही नोड में एक साथ रखा जाता है। बहुत बुरा नहीं है, लेकिन बहुत अनावश्यक है।
- कई सेंसर नोड्स: यह गड़बड़ है। इसका मतलब है कि नियंत्रक सेंसर नोड्स के बीच वितरित किया गया है। इसलिए सभी सेंसर नोड्स को एक-दूसरे के साथ बात करनी है ताकि यह पता चल सके कि इसके संबद्ध एक्ट्यूएटर को कैसे नियंत्रित किया जाए। संचार में विफलता या विभिन्न प्रकार की देरी की कल्पना करें और आप देखेंगे कि यह कितना मुश्किल हो जाता है। यह देखते हुए कि यह पूरी तरह से अनावश्यक है, इसे करने का कोई कारण नहीं है!
ये कहा, नुकसान भी हैं। अधिक नोड्स (किसी भी नोड्स, न केवल नियंत्रक) का अर्थ है:
- अधिक व्यर्थ संचार: डेटा को नेटवर्क या साझा मेमोरी के माध्यम से मानक स्वरूपों (ताकि क्रमबद्ध और deserialized) में घूमना पड़ता है, ROS Core को उन्हें देखना होता है और यह तय करना होता है कि उन्हें किसे पहुंचाना है, आदि संक्षेप में, कुछ सिस्टम संसाधन व्यर्थ हैं। संचार में। यदि सभी नोड्स जहां एक में हैं, तो वह लागत शून्य हो सकती है।
- विफलता का उच्च मौका: यदि किसी भी कारण से नेटवर्क लिंक डाउन हो जाता है, या नोड की मृत्यु हो जाती है, तो सिस्टम में विफलता होती है। यदि आप इसके लिए तैयार नहीं हैं, तो यह पूरी प्रणाली को नीचे ले जा सकता है। अब यह वास्तव में सामान्य रूप से सिस्टम का हिस्सा खोने में सक्षम होने के लिए एक अच्छी बात है , लेकिन यह ( शालीन गिरावट ) नहीं है, लेकिन ऐसे अनुप्रयोग भी मौजूद हैं जहां इसे जितना संभव हो उतना टाला जाना चाहिए। संचार को काटना और एक नोड में सभी कोड डालना वास्तव में सिस्टम स्थिरता के साथ मदद करता है। नीचे की ओर निश्चित रूप से है, सिस्टम या तो ठीक काम करता है या अचानक पूरी तरह से मर जाता है।
- अराजक समय: प्रत्येक नोड अपने आप चलता है। इसके संदेशों को दूसरों तक पहुंचने में लगने वाला समय गैर-नियतात्मक है और अलग-अलग चलता है। जब तक आपके नोड्स प्रत्येक संदेश (साइड नोट के रूप में) टाइमस्टैम्प न करें: आपको एक अच्छी डिग्री के लिए सिंक्रोनाइज़ की गई घड़ियों की आवश्यकता होती है, जो कि ROS नहीं करता है) और जब तक कि प्रत्येक प्राप्त नोड को ध्यान में नहीं रख सकते हैं और तदनुसार नियंत्रण कर सकते हैं (जो कि बहुत मुश्किल काम है अपने आप) तब कई नोड्स होने का मतलब है डेटा की उम्र के बारे में उच्च अनिश्चितता। यह वास्तव में एक कारण है (कई के बीच) कि अधिकांश रोबोट इतने धीमे चलते हैं; उनके नियंत्रण लूप को धीमा करना होगा ताकि यह सुनिश्चित हो सके कि सभी डेटा मौजूदा अवधि के अनुरूप हैं। विलंब बड़ा, नियंत्रण लूप धीमा।
उपरोक्त सभी नुकसानों में, समाधान नोड्स की संख्या को कम करना है, अधिमानतः एक नोड को। एक मिनट रुको, कि अब आरओएस का उपयोग नहीं कर रहा है! बिल्कुल सही।
संक्षेप में:
- गैर-रीयलटाइम सिस्टम के लिए आरओएस का उपयोग करें जहां देरी से छिटपुट रूप से उच्च प्राप्त हो सकता है। उस स्थिति में, अपनी इच्छानुसार कई ROS नोड्स के लिए स्वतंत्र महसूस करें। वास्तव में, यह बहुत अच्छा अभ्यास है कि प्रत्येक ROS नोड में एक और केवल एक ही चीज़ हो। इस तरह, वे बहुत सरल हो जाते हैं, और वे अत्यधिक पुन: प्रयोज्य हो जाते हैं।
- दूसरी ओर, रियलटाइम सिस्टम के लिए, हर तरह से आरओएस से बचें। उस के लिए वहाँ है orocos और प्रौद्योगिकियों की तरह EtherCAT और अधिक से अधिक बार, तदर्थ समाधान।
एक अंतिम शब्द के रूप में, ROS ठीक करता है। महान नहीं, लेकिन ठीक है। बहुत बार सिस्टम क्रिटिकल नहीं होता है और असफलता की संभावना इतनी कम होती है कि हर बार और फिर रिस्टार्ट होना कोई बड़ी बात नहीं है। यह शुतुरमुर्ग एल्गोरिथम है !
