Arduino मैकेनिकल डिस्प्ले - बग फिक्स

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

कमजोरियों की पहचान की

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

पिछले चार हफ्तों में, डिज़ाइन को अंतिम रूप दिया गया है, और ऐसा ही हुआ है:

हैंडलिंग में त्रुटि

स्थिरता और आकार

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



अग्रभूमि में दो ऑप्टिकल जोड़े दिखाई देते हैं - अब आप वापसी स्ट्रोक की शुरुआत को पकड़ सकते हैं।

रंग

डिस्प्ले कलर बनाना एक आसान काम लगता है - बस सिंगल-कलर एलईडी को RGB से बदलें। जल्दी से नहीं कहा। उन्होंने डेटा बस में प्रतिरोधों को सीमित करने के माध्यम से आम एनोड को जोड़ा, और रंग में एक साथ कैथोड को मिलाया और रंग की पसंद के लिए जिम्मेदार अरुडिनो आउटपुट से जुड़ा। जब सभी आठ एल ई डी जलाए जाते हैं, प्रत्येक रंग चयन तार के माध्यम से 39 मिलीमीटर तक प्रवाह होता है, जबकि Arduino अधिकतम 40 हो सकता है। गारंटी के लिए, मैंने तीन IRF 540 MOSFET ट्रांजिस्टर जोड़े - प्रत्येक रंग के लिए एक। यह कुछ इस तरह से निकला (केवल तीन आरजीबी एलईडी दिखाए गए हैं):



स्विंग बार पतली तारों के साथ 8 + 3 नियंत्रक से जुड़ा हुआ है। बहुत सारे, लेकिन अगर उन्हें सावधानीपूर्वक रखा जाता है, तो वे आंदोलन में हस्तक्षेप नहीं करते हैं।

रेक नंबर एक

हम वांछित एनोड (D6-D13) को एक तार्किक इकाई खिलाते हैं, उसी इकाई के साथ हम ट्रांजिस्टर को रंग (D0-D2) और एलईडी लाइट्स के लिए जिम्मेदार खोलते हैं। यदि आप 001 को रंग नियंत्रण आउटपुट पर लागू करते हैं, तो लाल बत्ती ऊपर, 010 - हरा, 011 ... लाल फिर से, हालांकि पीले रंग की उम्मीद थी।

डेटाशीट को पढ़ने से पता चला कि लाल एलईडी रोशनी 2.0 वोल्ट के वोल्टेज पर, जबकि हरे और नीले रंग में 3.2 की जरूरत है। नतीजतन, लाल डायोड खोलने के बाद, वोल्टेज व्यावहारिक रूप से नहीं बढ़ता है, केवल वर्तमान बढ़ता है, और हरा और नीला नहीं खुलता है। मुझे एनोड सर्किट में वर्तमान-सीमित प्रतिरोधों के साथ दिए गए कनेक्शन आरेख का समाधान नहीं मिला। यदि आप प्रतिरोधों को कैथोड्स से जोड़ते हैं, तो प्रत्येक डायोड का अपना वोल्टेज होगा जिसे इसकी आवश्यकता है, लेकिन 24 टुकड़ों की आवश्यकता होगी, जो मेरी चल संरचना के लिए बहुत भारी है। Google को कई एलईडी मैट्रिक्स ड्राइवर चिप्स मिले, लेकिन मैंने उन्हें खेत पर नहीं किया। नतीजतन, उन्होंने समस्या को व्यावहारिक रूप से दरकिनार कर दिया, जल्दी से बदले में रंगों को प्रकाश में लाया। एक पिक्सेल के प्रदर्शन के दौरान प्रति रंग 50 माइक्रोसेकंड की देरी के साथ, प्राथमिक रंग कई बार बदलने और एक में विलय करने का प्रबंधन करते हैं।

रेक नंबर दो

एक स्थिर स्थिति में, डिवाइस अब अपेक्षित रंगों को दिखाता है, इसे गति में आज़माने का समय है। मैं इंजन शुरू करता हूं और निम्नलिखित समस्या खोजता हूं:



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

मैकेनिकल स्कैन

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



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

यहाँ क्या वोल्टेज फोटोरिसेस्टर पर दिखता है - यह स्पष्ट रूप से दिखाई देता है जब प्रकाश इसे मुखौटा में छेद के माध्यम से मारता है:



लेकिन इसकी महिमा में गैर-रैखिकता, यह अच्छा है कि मैंने इसे अनुकरण और गणना करने की कोशिश नहीं की:



एक्सेल पांचवें क्रम तक बहुपद के साथ मनमाने डेटा सेटों का अनुमान लगा सकता है, इसलिए कुछ मिनटों के बाद मेरे हाथ में क़ीमती सूत्र था जो आंदोलन का वर्णन करता है:



यहाँ y चक्र की शुरुआत से माइक्रोसेकंड में देरी है, x 1 से 20 तक भिन्न आभासी पिक्सेल की संख्या है (मैं अंशांकन मुखौटा में 20 छेद था)। एक्स भिन्नात्मक मान देकर, हम मनमाने संकल्प के लिए देरी की गणना कर सकते हैं। मैं 54 पिक्सल्स पर बस गया।

पिक्सल

सूत्र का परीक्षण करने के लिए, मैंने एक साधारण प्रोग्राम लिखा, जो एक चेकबोर्ड पैटर्न में पिक्सल को हाइलाइट करने के लिए वैकल्पिक रूप से 0x55 और 0xAA प्रदर्शित करता है।



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



नियंत्रण "बिसात" ने पुष्टि की कि यह वास्तव में बहुत बेहतर है:

प्रोग्रामिंग

सरल और जटिलताओं के एक एल्गोरिथ्म की उम्मीद नहीं की गई थी, हालांकि, कोड के लेखन में एक निश्चित बिंदु पर, कार्यक्रम अजीब, अप्रत्याशित परिणाम उत्पन्न करना शुरू कर दिया। यह पता चला कि रैम से बाहर चल रहा है, जो कि Arduino UNO में केवल दो किलोबाइट है। माइक्रोकंट्रोलर में एक ऑपरेटिंग सिस्टम नहीं होता है जो मेमोरी आवंटन की निगरानी करता है, इसलिए यह किसी भी त्रुटि को नोटिस नहीं करता है और एक अतिप्रवाह का संकेत नहीं देता है। मैंने मान लिया कि कॉन्स्टेबल के रूप में घोषित सरणियाँ फ्लैश मेमोरी में संग्रहीत हैं, लेकिन यह निकला कि ऐसा नहीं है। अधिक सटीक रूप से, वे पहले रीड-ओनली मेमोरी में वास्तव में झूठ बोलते हैं, लेकिन स्टार्टअप पर उन्हें रैम में कॉपी किया जाता है, हालांकि उन्हें बदला नहीं जा सकता। इससे बचने के लिए, PROGMEM के माध्यम से चरों को घोषित किया जाना चाहिए, एक लेख arduino वेबसाइट पर इसके बारे में पाया गया था । सामान्य तौर पर, "मन पढ़ें, वे शासन करते हैं।"

रूसीकरण

पत्र बिंदु को बिंदु से खींचना असुविधाजनक है, इसलिए मैंने चरित्र जनरेटर तालिका को उसी PROGMEM में रखा और पत्र प्रतिपादन समारोह लिखा। अंग्रेजी पात्रों के साथ कोई समस्या नहीं थी, लेकिन रूसी के बजाय, बकवास प्रदर्शित किया गया था। विकास के माहौल के रूप में, VisualStudio 2010 का उपयोग वीज़ा माइक्रो अरुडिनो प्लगइन के साथ किया गया था। इस तथ्य के बावजूद कि स्रोत फ़ाइलों को Win1251 एन्कोडिंग (प्रति वर्ण एक बाइट), प्रपत्र की एक पंक्ति में सहेजा गया था

char* text = "";

लंबाई में 27 + 1 बाइट्स की एक सरणी घोषित की गई, जिसमें प्रत्येक ट्रिपल में एक ही सामग्री थी, जिसका स्रोत पाठ के साथ कोई लेना-देना नहीं था। Arduino UNO पर्यावरण के तहत समान कोड रूसी चरित्र प्रति दो बाइट्स लिखता है, सबसे अधिक संभावना है UTF8 में। हम चरित्र द्वारा स्ट्रिंग चरित्र को एन्कोडिंग द्वारा समस्या को हल करने में कामयाब रहे:

char russianText[] = {'', '', '', '', '', '', '', '', '', '\0'};

अब, जैसा कि अपेक्षित था, हमें अंतिम शून्य पर पाठ के 9 बाइट्स मिलते हैं। हम कार्यक्रम शुरू करते हैं और देखते हैं ... पूरी तरह से अलग चरित्र। अध्ययन से पता चला है कि राजधानी रूसी पत्र "ए" कोड 144 में संकलित है, जो विन 1251 के लिए अपेक्षित 192 कोड के अनुरूप नहीं है।
मैंने इंटरनेट पर रूसी पत्रों के संभावित एन्कोडिंग के बारे में पढ़ा, जिसमें बहुत विदेशी भी शामिल हैं। उनमें से कोई भी ए में अनुवाद नहीं करता है। मन में आने वाली एकमात्र व्याख्या यूनिकोड में रूसी अक्षरों का प्रतिनिधित्व है, जिसके बाद कम बाइट को ए (यू + 0410) अक्षर से काट दिया जाता है, किसी कारण से 128 जोड़ा जाता है। यह स्पष्ट क्यों नहीं है। , लेकिन कोड के लिए आवश्यक निरंतर के अक्षरों को जोड़ने के बाद, वे जगह में गिर गए।

यहाँ परिणाम है:

वीडियो

लेकिन उसके बिना क्या?


170 मिलीसेकंड के चक्र समय के साथ, प्रति सेकंड लगभग छह फ्रेम प्राप्त होते हैं। कैमरे में प्रति सेकंड 30 फ्रेम होते हैं, और वीडियो में आवृत्ति की बहुलता के कारण, एक मजबूत झिलमिलाहट ध्यान देने योग्य है। यदि आप अपनी आँखों से देखते हैं, तो चित्र बहुत अधिक स्थिर दिखता है।

आगे क्या है?

रिवर्स स्वीप के दौरान इमेज आउटपुट को अभी तक प्रोग्राम नहीं किया गया है। यह फ्रेम दर को दोगुना कर देगा, लेकिन एनीमेशन और पाठ स्क्रॉलिंग की प्रोग्रामिंग को जटिल करेगा। केवल फॉरवर्ड स्ट्रोक के दौरान ड्राइंग करते समय, माइक्रोकंट्रोलर के पास अगले फ्रेम की धीरे-धीरे गणना करने के लिए 80 मिलीसेकंड जितना होता है।