सर्वेक्षण ड्रोन के लिए ArduPilot और कॉन्फ़िगरेशन प्रबंधन

सॉफ़्टवेयर को हार्डवेयर से अलग करें

ArduPilot विभिन्न वाहनों का समर्थन करने वाले पारिस्थितिकी तंत्र के भीतर ऑटोपायलट सॉफ्टवेयर है। यह एक नियंत्रक मॉडल या एक विमान नहीं है। व्यवहार हार्डवेयर, फ़र्मवेयर, पैरामीटर, सेंसर और एकीकरण पर निर्भर करता है। यह कहना कि ड्रोन ArduPilot का उपयोग करता है, सभी स्वीकृत क्षमताओं की व्याख्या नहीं करता है। कॉन्फ़िगरेशन पहचान और साक्ष्य मांगें. सामान्य दस्तावेज़ीकरण में उपलब्ध फ़ंक्शन को सॉफ़्टवेयर का उपयोग करके प्रत्येक विमान पर स्वचालित रूप से परिचालन के रूप में प्रस्तुत नहीं किया जाना चाहिए। यह अंतर खरीदारों और ऑपरेटरों को वास्तव में क्या आपूर्ति और परीक्षण किया गया है, उसके बारे में उपयोगी प्रश्न पूछने की सुविधा देता है।

पैरामीटर को कॉन्फ़िगरेशन मानें

पैरामीटर सिस्टम के कार्यों को प्रभावित करते हैं और विमान को समझने वाले लोगों द्वारा मूल्यांकन की आवश्यकता होती है। सेंसर, ओरिएंटेशन, पावर और फर्मवेयर की जांच किए बिना समान एयरफ्रेम से सेटिंग्स कॉपी न करें। एक स्वीकृत आधार रेखा को परिभाषित करें और इसे संरक्षित करें। वह संदर्भ समस्या निवारण और प्रतिस्थापन का समर्थन करता है। क्रमबद्ध रिकॉर्ड एक उचित समायोजन को आकस्मिक परिवर्तन से अलग करते हैं। वे अगले ऑपरेटर को किसी सहकर्मी की याददाश्त पर भरोसा किए बिना इच्छित स्थिति की पुष्टि करने की अनुमति देते हैं कि विमान को पिछले प्रोजेक्ट के लिए कैसे कॉन्फ़िगर किया गया था।

संस्करण-उपयुक्त दस्तावेज़ का उपयोग करें

सॉफ़्टवेयर दस्तावेज़ीकरण समय के साथ बदलता रहता है। पुष्टि करें कि पैरामीटर और फ़ंक्शन जानकारी स्थापित फर्मवेयर से मेल खाती है। समान नाम समान व्यवहार सिद्ध नहीं करते। जब कोई अद्यतन प्रस्तावित हो तो संस्करण रिकॉर्ड करें और रिलीज़ जानकारी की समीक्षा करें। यह आलेख कोई ऑपरेटिंग पैरामीटर मान प्रदान नहीं करता है. सामान्य संदर्भ शब्दावली की व्याख्या करते हैं; विमान की नियमावली और अधिकृत तकनीकी व्यक्ति वास्तविक सेटअप तय करते हैं। उन भूमिकाओं को अलग रखने से इंटरनेट उदाहरण को कॉन्फ़िगरेशन-विशिष्ट स्वीकृति का विकल्प बनने से रोका जा सकता है। यह समर्थन चर्चाओं को और अधिक सटीक बनाता है क्योंकि दोनों पक्ष सही संशोधन पर परामर्श कर सकते हैं।

बदलाव करने से पहले वर्तमान स्थिति सुरक्षित रखें

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

प्रोजेक्ट प्लानिंग को बेसलाइन से अलग करें

नई सर्वेक्षण सीमा या क्षेत्र के विभाजन के लिए मूल पैरामीटर बदलना जरूरी नहीं है। ये विमान सेटअप के बजाय मिशन योजना से संबंधित हो सकते हैं। इसके विपरीत, बदले हुए पेलोड को व्यापक कॉन्फ़िगरेशन समीक्षा की आवश्यकता हो सकती है। दस्तावेज़ों को लिंक करें ताकि निर्णय संदर्भ में दिखाई देता रहे। जब एक परिवर्तन कई क्षेत्रों को प्रभावित करता है तो जिम्मेदारी सौंपें। यह वैध परियोजना अनुकूलन को रोके बिना निरंतरता बनाए रखता है। यह कर्मचारियों को यह समझने में मदद करता है कि क्या समायोजन केवल किसी विशेष मिशन पर लागू होता है या विमान की नई स्वीकृत स्थिति का प्रतिनिधित्व करता है।

वास्तव में आवश्यक कार्यों का परीक्षण करें

ArduPilot में व्यापक क्षमताएं हैं, लेकिन स्वीकृति को आपूर्ति की गई व्यवस्था और परियोजना के लिए आवश्यक कार्यों को संबोधित करना चाहिए। उद्देश्यों, स्वीकृत तरीकों, साक्ष्यों और मानदंडों को परिभाषित करें। किसी फ़ंक्शन को केवल इसलिए सक्षम न करें क्योंकि वह परिणामों की समीक्षा किए बिना मौजूद है। परीक्षण मिशन, सेंसर घटनाओं और वितरित फ़ाइलों को लिंक कर सकते हैं, उड़ान निष्पादन मैनुअल और ऑपरेटर के अधीन रहेगा। इकाई, संस्करण और स्थापित डिवाइस का नाम बताएं। एक सामान्य कथन कि परीक्षण सफल हुआ, उस स्पष्ट रिकॉर्ड से कमजोर है जो दर्शाता है कि कौन से कॉन्फ़िगर किए गए कार्यों का प्रदर्शन किया गया था और उनके परिणामों का मूल्यांकन कैसे किया गया था।

स्वीकृत परिवर्तनों का मूल्यांकन करने के लिए लॉग का उपयोग करें

परिवर्तन उद्देश्य से प्रारंभ करें और प्रासंगिक रिकॉर्ड चुनें। ऐसे ग्राफ़ की खोज न करें जो केवल बेहतर प्रतीत होता हो। तुलनीय परिस्थितियों और कॉन्फ़िगरेशन की स्थिति में अंतर की तुलना करें। सेंसर आउटपुट और ऑपरेटर नोट्स सर्वेक्षण के परिणामों को प्रकट कर सकते हैं। यदि परिणाम अस्पष्ट रहते हैं, तो शीर्ष पर अधिक परिवर्तन डालने से बचें। प्रेक्षणों और संभावित कारणों को अलग रखें और साक्ष्य और प्रक्रिया के माध्यम से अगली तकनीकी कार्रवाई तय करें। यह उत्पादन उपकरण को अप्रलेखित परीक्षण और त्रुटि के लिए एक मंच बनने से रोकता है जबकि वास्तविक मुद्दे की संरचित जांच की अनुमति देता है।

अप्रलेखित समायोजनों पर नियंत्रण रखें

कॉन्फ़िगरेशन जिम्मेदारियों, सेटिंग्स के वर्तमान स्रोत और परिवर्तन का अनुरोध करने के पथ को परिभाषित करें। इसके लिए धीमी गति से काम करने की आवश्यकता नहीं है: तैयार की गई जानकारी अक्सर मूल्यांकन को गति देती है। इकाई या संस्करण पहचान के बिना सामान्य फ़ाइल नामों से बचें। दूरस्थ समर्थन के लिए स्थानीय कार्य के समान ही रिकॉर्ड की आवश्यकता होती है। एक अस्थायी समायोजन एक अज्ञात स्थायी स्थिति नहीं बननी चाहिए। स्पष्ट संचार ऑपरेटर को यह जानने की अनुमति देता है कि कौन सा सेटअप स्वीकृत है, और तकनीकी टीम को यह देखने की अनुमति देता है कि बाद का व्यवहार किसी दस्तावेजी परिवर्तन या सिस्टम में किसी अन्य अंतर से संबंधित है या नहीं।

स्वीकृत मूल कॉन्फ़िगरेशन को अद्यतन रखें

स्वीकृत परिवर्तनों को स्वीकार किए जाने के बाद इतिहास को संरक्षित करते हुए बेसलाइन को अपडेट करें। संस्करणों को मिशन और डेटा से लिंक करें ताकि बार-बार किए गए सर्वेक्षण समझाने योग्य बने रहें। प्रशिक्षण को पुराने स्क्रीनशॉट के बजाय वास्तविक कॉन्फ़िगरेशन से मेल खाना चाहिए। ArduPilot दस्तावेज़ीकरण उपयोगी है, लेकिन परिचालन मूल्य विशिष्ट एकीकृत प्रणाली के प्रबंधन पर निर्भर करता है। एक जीवंत संदर्भ सॉफ्टवेयर, विमान, पेलोड और परियोजना उद्देश्यों को जोड़ता है। यह आवश्यक कार्यों और उनकी सीमाओं का समर्थन करता है, जांच में मदद करता है, और भविष्य के उपयोगकर्ताओं को एक विश्वसनीय शुरुआती बिंदु देता है, तब भी जब मूल एकीकरण कर्मी मौजूद नहीं होते हैं।

उदाहरणात्मक मामला: स्रोत अज्ञात पैरामीटर फ़ाइल को अस्वीकार करना

एक काल्पनिक समर्थन अनुरोध की कल्पना करें जिसमें एक विमान कॉन्फ़िगरेशन फ़ाइल को एक आश्वस्त नाम के साथ आपूर्ति की जाती है लेकिन कोई इकाई या फ़र्मवेयर पहचान नहीं होती है। कोई इसे लोड करने का सुझाव देता है क्योंकि एक समान विमान ने इसका सफलतापूर्वक उपयोग किया था। जिम्मेदार तकनीकी व्यक्ति पहले वर्तमान स्वीकृत स्थिति को संरक्षित करता है और पूछता है कि प्रस्तावित फ़ाइल में क्या बदलाव करने का इरादा है। तुलना वास्तविक हार्डवेयर, सेंसर ओरिएंटेशन, पेलोड एकीकरण और लागू सॉफ़्टवेयर दस्तावेज़ीकरण पर विचार करती है। जहां अंतर का कारण स्थापित नहीं किया जा सकता है, फ़ाइल को केवल उसके नाम से तैयार होने का संकेत मिलने पर स्वीकृत प्रतिस्थापन नहीं माना जाता। एक स्वीकृत परिवर्तन अनुरोध विशिष्ट उद्देश्य, जिम्मेदार समीक्षक, साक्ष्य और मूल्यांकन प्रक्रिया की पहचान करता है। मिशन-सीमा संपादन बेसलाइन सेटिंग्स से अलग रहते हैं इसलिए प्रोजेक्ट प्लानिंग एक अनियंत्रित कॉन्फ़िगरेशन परिवर्तन नहीं बन जाती है। किसी भी अधिकृत कार्य के बाद, परिणामी स्थिति और आवश्यक जांच वास्तविक इकाई के विरुद्ध दर्ज की जाती है। यह उदाहरणात्मक परिदृश्य कोई पैरामीटर मान या संचालन अनुक्रम प्रदान नहीं करता है। इसका मूल्य मूल स्थिति, उचित हस्तक्षेप और स्वीकृति साक्ष्य के बीच संरक्षित श्रृंखला है। अगला समर्थन व्यक्ति यह देख सकता है कि क्या बदला गया था और क्यों, बजाय स्पष्ट रूप से अंतिम फ़ाइलों के संग्रह को प्राप्त करने के, जिनके संबंधों का पुनर्निर्माण नहीं किया जा सकता है।

प्रस्तावित अंतर की जांच करते समय ज्ञात स्वीकृत आधार रेखा को बनाए रखना उचित हो सकता है। एक उचित अद्यतन तब भी आगे बढ़ सकता है जब उसका उद्देश्य और मूल्यांकन स्पष्ट हो जाए। किसी भी विकल्प के लिए अज्ञात फ़ाइल को आधिकारिक मानने की आवश्यकता नहीं है। हैंडऑफ़ अनुमोदित पहले और बाद की स्थितियों की तुलना करता है और प्रासंगिक साक्ष्य को विशिष्ट इकाई से जोड़ता है। किसी भी अस्थायी स्थिति की फ़ाइल नाम में गायब होने के बजाय एक स्पष्ट स्थिति होती है। एक भावी समीक्षक किसी परियोजना संपादन या एक अनसुलझे सुझाव से जानबूझकर स्वीकार किए गए परिवर्तन को अलग कर सकता है, जो तब आवश्यक होता है जब कई लोग समय के साथ तकनीकी सहायता प्रदान करते हैं।