वालेस - DIY स्वायत्त रोबोट - भाग 5 - IMU जोड़ें: 9 चरण

2024 लेखक: John Day | [email protected]. अंतिम बार संशोधित: 2024-01-30 09:22

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

वैलेस घूम सकता है, वह आईआर दूरी सेंसर का उपयोग करके बाधाओं से बच सकता है (हाल ही में, किसी तरह उन्होंने तला हुआ (?) time, एक MCP23017 विस्तारक के साथ), और अंत में, मोटर-करंट में परिवर्तन का पता लगा सकता है यह जानने के लिए कि यह कब किसी चीज़ से टकराया है।

सेंसर के अलावा, वालेस 100 चालों को "याद" करता है, और आंदोलन के इतिहास का उपयोग करते हुए कुछ अल्पविकसित विश्लेषण करता है।

वैलेस के लिए अब तक का लक्ष्य केवल आगे बढ़ते रहने की कोशिश करना है, और यह जानना है कि यह कब कुछ दोहराए जाने वाले पैटर्न (जैसे कि एक कोने में) में फंस गया है और वास्तव में आगे नहीं बढ़ रहा है।

मैं आंदोलन और नेविगेशन के लिए कई पुनरावृत्तियों से गुजरा हूं, और लगातार सिरदर्द रोटेशन के दौरान रहा है।

चूंकि वालेस एक ट्रैक किया गया रोबोट है, और मैं सॉफ्टवेयर में चीजों को सरल रखना चाहता था (बाद के लिए), ताकि मैं उसे घुमाने के लिए बस उसे जगह पर घुमा सकूं। इस प्रकार, मोटर्स के लिए समान लेकिन विपरीत शक्ति / कर्तव्य चक्र लागू करें।

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

फर्श पर और सीधे जाने पर, यह कोई समस्या नहीं रही है। यह कारपेटिंग पर दिखाई देता है। मैंने वालेस को गलीचे से ढंकने से दूर रखने का फैसला किया, क्योंकि इसके ट्रैक खराब हो गए थे (वे बहुत आसानी से जमी हुई मैल उठाते हैं)।

असली समस्या फर्श पर पिवट करते समय होती है।

यदि मेरे पास सॉफ़्टवेयर उच्च स्तरीय कर्तव्य चक्र लागू करता है, तो यह कमोबेश लगातार बदल जाता है। हालांकि, कम कर्तव्य चक्र के दौरान, यह वास्तव में मुड़ सकता है या नहीं भी हो सकता है। या यह थोड़ा मुड़ सकता है और फिर धीमा हो सकता है। धुरी क्रिया सॉफ्टवेयर के माध्यम से बेकाबू लगती है, या सर्वोत्तम रूप से बहुत कठिन है।

समस्या नेविगेशन के दौरान और बाधाओं से इधर-उधर या दूर जाने के दौरान दिखाई देती है। यह या तो बेतहाशा दूर स्विंग कर सकता है, या यह वास्तव में बिना हिले-डुले बहुत मिनट की शिफ्ट करने के प्रयास में फंस सकता है।

और इसलिए उपरोक्त स्पष्टीकरण ने इस निर्देश को प्रेरित किया।

प्रारंभ में, मैं मोशन-सेंसिंग यूनिट (IMU) को शुरू करने में देरी करना चाहता था, या देरी करना चाहता था, क्योंकि वे A) जटिल हैं, B) शोर, C) त्रुटियां समय के साथ शुरू हो सकती हैं, और आदि, आदि। मेरा विचार था यह कि हम उड़ान के समय के IR लेजर सेंसर से आगे बढ़कर बहुत अच्छा कर सकते हैं। और हम कर सकते थे - लेजर का उपयोग करके हम यह जान सकते थे कि रोबोट घूमता है या नहीं, दूरी में परिवर्तन को ट्रैक करके।

वास्तव में, हम अब ध्वनिक सेंसर के साथ भी ऐसा कर सकते हैं।

हालांकि, यह सब एक सरल प्रश्न का उत्तर देने का एक बहुत ही अप्रत्यक्ष, जटिल तरीका है: "क्या हमने घुमाया है या नहीं?"

मुझे ऐसा लगा कि टीओएफ लेजर सेंसर का उपयोग करने के लिए कूदना मुझे सॉफ्टवेयर के अगले स्तर पर ले जाएगा; अर्थात्, SLAM (एक साथ स्थानीयकरण और मानचित्रण)। मैं अभी वहाँ जाने के लिए तैयार नहीं था।

परतों में रोबोट प्रोजेक्ट करना एक अच्छी बात है, पहली (निचली) परतें सरल होती हैं, और बाद वाली (ऊपरी) परतें अधिक सारगर्भित होती हैं और अधिक कठिन मुद्दों से निपटती हैं।

परतों के बारे में कुछ इस तरह सोचा जा सकता है:

1. रोबोट भौतिक फ्रेम / यांत्रिक संरचनात्मक आधार
2. अल्पविकसित ड्राइव सिस्टम (रास्पबेरी, रोबोक्ला, मोटर्स, केबलिंग, आदि, बुनियादी सॉफ्टवेयर, कीबोर्ड-चालित)
3. सेंसर का समर्थन करने के लिए आवश्यक सर्किटरी (द्वि-दिशात्मक वोल्टेज शिफ्टर, पोर्ट विस्तारक, ई-स्टॉप, बिजली वितरण, आदि)
4. बाधा से बचाव सेंसर (ध्वनिक, आईआर)
5. आवश्यक, बुनियादी स्थिति और गति - पता लगाना (एक्सेलेरोमीटर, जाइरो, मैग्नेटोमीटर, मोटर एनकोडर, व्हील एनकोडर)

आप अपनी खुद की सूची के साथ आ सकते हैं। इस सूची के बारे में बिंदु यह है कि आपको शायद इसे कमोबेश उसी क्रम में करना चाहिए, और यह भी कि यदि आप प्रत्येक परत को एक अच्छी कार्यशील स्थिति में लाने के लिए कुछ समय बिताते हैं, तो इससे आपको बाद में मदद मिलेगी क्योंकि चीजें और अधिक जटिल हो जाती हैं।

उपरोक्त सूची को सॉफ्टवेयर में इन वैचारिक परतों के लिए कमोबेश मैप किया जा सकता है।

• SLAM (एक साथ स्थानीयकरण और मानचित्रण)
• आंदोलन, रोटेशन का नियंत्रण और जागरूकता
• बुनियादी बाधा से बचाव
• सेंसर डेटा का नियंत्रण और पता लगाना
• आवश्यक आंदोलन आगे, पीछे, बाएं और दाएं, गति बढ़ाएं, धीमा करें, रोकें

जैसा कि आप देख सकते हैं, इस सूची के लिए, पहली वस्तुएँ ऊपरी, अधिक जटिल परतें होंगी जो अधिक सार मुद्दों और प्रश्नों से निपटती हैं, जैसे "मैं कहाँ हूँ" और "मैं कहाँ जा रहा हूँ", जबकि बाद वाले आइटम होंगे निचली सॉफ़्टवेयर परतें जो "सेंसर ए को कैसे बात करें / सुनें" या "इस पहिया को कैसे स्थानांतरित करें" को संभालती हैं।

अब, मैं यह नहीं कह रहा हूं कि जब आप एक परत पर शुरू करते हैं, तो आप इसे पूरा कर चुके होते हैं और फिर यह अगली परत पर होता है, कभी भी पिछली परत पर वापस नहीं जाना चाहिए। एक रोबोट परियोजना बहुत कुछ आधुनिक, पुनरावृत्त सॉफ्टवेयर विकास विधियों (फुर्तीली, SCRUM, आदि) की तरह हो सकती है।

मैं बस इतना कह रहा हूं कि प्रत्येक में समय निकालें। आपको प्रत्येक में कितना करना है, यह संतुलित करना होगा, और यह तय करना होगा कि आप समय और परेशानी के लायक एक निश्चित स्तर पर क्या प्रयास कर रहे हैं।

दो प्रतिस्पर्धी विचारों या दिशाओं के बीच एक निश्चित "संघर्ष" या "तनाव" है।

समस्या ए को हल करने के लिए मैं "प्लग-एन-प्ले" कहूंगा।

दूसरा DIY है (इसे स्वयं करें)। और वह इस दूसरे विचार के लिए सबसे अच्छा लेबल भी नहीं हो सकता है।

यहां प्रत्येक का एक उदाहरण दिया गया है, उम्मीद है कि आप दो विकल्पों के बीच तनाव या संघर्ष देखेंगे।

इस उदाहरण के लिए, आइए एक ही समय में हल करने के लिए SLAM, बाधा-परिहार, और आवश्यक बुनियादी आंदोलन सभी को एक समस्या के रूप में लें।

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

#1 बनाम #2 के बारे में क्या कहा जा सकता है? एक बात तो यह होगी कि #2 करके हमने और भी बहुत कुछ सीखा होगा। काम करने के लिए केवल ध्वनिक सेंसर होने की सीमाएं, हमें बहुत अधिक मुद्दों के बारे में सोचने के लिए मजबूर करती हैं।

दूसरी ओर, यदि हम #2 के माध्यम से चीजों को करने पर बहुत अधिक ध्यान केंद्रित कर रहे हैं, तो हम समय बर्बाद कर रहे हैं, क्योंकि हम ध्वनिक सेंसर से अधिक की मांग कर रहे हैं।

एक और अवधारणा या विचार के बारे में सोचना चाहिए: हार्डवेयर और सॉफ़्टवेयर का कौन सा मिश्रण "कैसे करें" के प्रश्नों का सबसे अच्छा उत्तर देता है, और सॉफ़्टवेयर (और हार्डवेयर?) का कौन सा मिश्रण "क्या", "कब", "कहां" के प्रश्न का उत्तर देता है।. क्योंकि "कैसे करें" आमतौर पर एक निचले स्तर का प्रश्न होता है, जिस पर "क्या", "कब", और "कहां" उत्तर पाने के लिए निर्भर करता है।

वैसे भी, उपरोक्त सभी कुछ सोचने के लिए ही थे।

मेरे मामले में, बहुत प्रयास के बाद और ट्रैक-घर्षण के लगातार कष्टप्रद मुद्दे और लगातार नियंत्रण और गति प्राप्त करने में असमर्थ होने के बाद, यह कुछ और करने का समय है।

इस प्रकार यह निर्देश योग्य - एक IMU।

लक्ष्य यह है कि यदि IMU कहता है कि रोबोट धुरी नहीं है, तो हम कर्तव्य चक्र को बढ़ाते हैं। यदि हम बहुत तेजी से धुरी कर रहे हैं, तो हम कर्तव्य चक्र को कम कर देते हैं।

चरण 1: IMU सेंसर

और इसलिए वालेस में जोड़ने वाला हमारा अगला सेंसर IMU है। कुछ शोध के बाद, मैं एक MPU6050 पर बस रहा था। लेकिन इस समय, MPU9050 (और इससे भी अधिक हाल ही में, MPU9250) एक बेहतर विचार की तरह लग रहा था।

मेरा जाने-माने स्रोत अमेज़ॅन (यू.एस. में) रहा है। इसलिए मैंने उनमें से दो का आदेश दिया।

वास्तव में मुझे जो मिला (ऐसा लगता है कि इस पर कोई नियंत्रण नहीं है; यही वह है जो मुझे अमेज़ॅन के बारे में पसंद नहीं है) दो एमपीयू 92/65 थे। मुझे पदनाम के बारे में थोड़ा आश्चर्य है। छवियों पर एक नज़र डालें; यह एक "परिवार" पदनाम प्रतीत होता है। किसी भी मामले में, मैं यही फंस गया हूं।

इसे जोड़ना बहुत सरल है - कनेक्टिंग ट्रैक्स के साथ एक प्रोटो बोर्ड प्राप्त करें, सेंसर को बोर्ड में मिलाएं, एक 10-पिन स्क्रू टर्मिनल ब्लॉक जोड़ें (मुझे पोलोलू से मेरा मिला)।

किसी भी व्यवधान को कम करने के लिए, मैंने इन सेंसरों को हर चीज़ से दूर रखने की कोशिश की।

इसका मतलब कुछ नायलॉन बोल्ट/नट का उपयोग करना भी था।

मैं I2C प्रोटोकॉल का उपयोग करने जा रहा हूं। उम्मीद है कि कुल तार की लंबाई बहुत खराब नहीं होगी।

बुनियादी कनेक्शन और वोल्टेज-स्तर आदि के बारे में कहीं और जानकारी है, इसलिए मैं इसे यहां नहीं दोहराऊंगा।

चरण 2: चीजें हमेशा साफ, आसान नहीं होती हैं

इस लेखन में, इस विशेष MPU-92/65 के लिए बहुत कुछ ऑनलाइन नहीं लगता है। जो उपलब्ध है, अधिकांश सेंसर की तरह, Arduino का उपयोग करने वाले उदाहरण प्रतीत होते हैं।

मैं एक साफ-सुथरी प्रक्रिया पेश करके इन इंस्ट्रक्शंस को थोड़ा अलग बनाने की कोशिश करता हूं, क्योंकि चीजें हमेशा तुरंत काम नहीं करती हैं।

मुझे लगता है कि ये निर्देश सीधे ए-बी-सी की तुलना में एक ब्लॉग के समान हैं, 1-2-3 "यह है कि आप इसे कैसे करते हैं"।

चरण 3: प्रारंभिक परीक्षण

पिछले चरण की छवियों से, सेंसर में जाने वाले लाल और काले तार निश्चित रूप से VCC (5V) और GND हैं। हरे और पीले तार I2C कनेक्शन हैं।

यदि आपने अन्य I2C प्रोजेक्ट किए हैं, या इन श्रृंखलाओं का अनुसरण कर रहे हैं, तो आप पहले से ही "i2cdetect" के बारे में जानते हैं, और यह जानने के लिए पहला कदम है कि क्या रास्पबेरी नया सेंसर देख सकता है।

जैसा कि आप इस चरण में छवियों से देख सकते हैं, हमारा पहला प्रयास असफल रहा। IMU प्रकट नहीं होता है (डिवाइस आईडी 0x68 होना चाहिए)।

हालाँकि, अच्छी खबर यह है कि I2C बस चल रही है। हम एक उपकरण 0x20 देखते हैं और यह MCP23017 पोर्ट विस्तारक है (वर्तमान में HCSR04 ध्वनिक सेंसर के लिए जिम्मेदार)।

छवि में देखना आसान नहीं है, लेकिन मैंने समान रंगीन हरे और पीले तारों को IMU से MCP23017 से जोड़ा (चित्र में नीचे बाईं ओर देखें)

हमें कुछ समस्या निवारण करना होगा।

चरण 4: समस्या निवारण

वोल्टमीटर पर निरंतरता सेटिंग का उपयोग करते हुए (उच्च स्वर वाला वाला), मैंने VCC(5V), GND, SDA और SCL कनेक्शन का परीक्षण किया। वे अच्छे थे।

अगला प्रयास I2C बस से MCP23017 को डिस्कनेक्ट करने का था, बस में केवल MPU-92/65 को छोड़कर। यह निष्फल साबित हुआ - "i2cdetect" ने तब कोई उपकरण नहीं दिखाया।

तो, इसके बाद, मैंने सेंसर को टोटेम पोल से अनमाउंट किया, और इसे सीधे 5V-to-3V द्विदिश बस में फिर से तार दिया; यानी, सीधे रास्पबेरी के लिए। (छोटे तार?)

और वोइला। इस बार सफलता मिली है। हम 0x68 को "i2cdetect" का उपयोग करते हुए देखते हैं।

लेकिन हम अभी तक नहीं जानते कि इस बार क्यों काम किया। क्या यह तारों की लंबाई हो सकती है? पिछला स्थान?

नोट: इससे कोई फर्क नहीं पड़ता कि ADO को ग्राउंडेड किया गया था या नहीं। यह हो सकता है कि ऑन-बोर्ड पुलअप और पुल-डाउन रेसिस्टर्स हों। FSYNC के लिए भी यही सच हो सकता है।

इसके बाद, मैंने MCP23017 को फिर से कनेक्ट किया। तो अब हमारे पास I2C बस में दो डिवाइस हैं। (छवि देखें)। सफल, अब हम 0x20 और 0x68 दोनों को i2cdetect के साथ देखते हैं।

समस्या निवारण के दौरान जो हुआ, उसके बारे में वीडियो कुछ और बताते हैं।

चरण 5: सेंसर का डेटा पढ़ना

विभिन्न दृष्टिकोण

मैंने सेंसर से उपयोगी जानकारी प्राप्त करने के लिए कई तरीके अपनाने का फैसला किया। यहाँ वे हैं, किसी भी क्रम में नहीं:

1. कुछ बुनियादी प्रोग्रामिंग का प्रयास करें
2. रजिस्टरों पर कुछ ऑनलाइन दस्तावेज देखें
3. दूसरों के उदाहरण और / या कोड पर एक नज़र डालें

ये दृष्टिकोण क्यों? क्यों न सिर्फ कुछ मौजूदा पुस्तकालय या कोड की तलाश करें?

कुछ विचारों का प्रयोग और प्रयास करके, हम न केवल इस विशेष सेंसर के बारे में कुछ ज्ञान को बेहतर ढंग से अवशोषित कर सकते हैं, बल्कि कुछ तकनीक, कौशल और कुछ नया करने के बारे में सोचने के तरीके भी प्राप्त कर सकते हैं, और कुछ ऐसा जो बहुत अधिक दस्तावेज नहीं हो सकता है; कुछ ऐसा जिसमें बहुत से अज्ञात हों।

साथ ही, एक बार जब हमने अपने कुछ विचारों के साथ खेला और आजमाया और कुछ अंतर्दृष्टि प्राप्त की, तो हम किसी और के कोड या लाइब्रेरी का मूल्यांकन करने की बेहतर स्थिति में हैं।

उदाहरण के लिए, जीथब में एमपीयू 9250 के लिए कुछ सी ++ कोड देखने के बाद, मुझे एहसास हुआ कि यह मुझे इंटरप्ट्स का उपयोग करने के लिए मजबूर कर रहा है, जिसे मैं अभी तक नहीं करना चाहता हूं।

साथ ही, यह कैलिब्रेशन जैसी अतिरिक्त चीजों के साथ आता है; फिर से, कुछ ऐसा जिसमें मुझे अभी तक दिलचस्पी नहीं है।

यह हो सकता है कि सरल प्रश्न का उत्तर देने के लिए मुझे क्या करने की आवश्यकता है "क्या रोबोट हां या नहीं में घूम रहा है" का उत्तर केवल कुछ रजिस्टरों को पढ़कर दिया जा सकता है।

रजिस्टर

इस लेखन में, ऐसा लगता है कि इस सेंसर पर बहुत कुछ उपलब्ध नहीं है। वास्तव में, यदि आप इस निर्देश के साथ आने वाली छवियों पर एक नज़र डालते हैं, और वास्तविक चिप्स पर शिलालेखों को करीब से देखते हैं, तो यह मुझे आश्चर्यचकित करता है कि क्या यह दस्तक नहीं है। मैं इनवेन्स से जो कुछ भी देखता हूं उससे संबंधित नहीं हूं। भले ही, मैंने उन मॉडलों के लिए रजिस्टर-सूचना को देखना चुना जो मुझे मिले: MPU-6050, और MPU-9250।

दोनों ही मामलों में, निम्नलिखित दोनों के लिए समान है। और शुरुआत के लिए, हम मानते हैं कि यह इस MPU-92/65 के लिए भी ऐसा ही होगा।

५९ से ६४ - एक्सेलेरोमीटर माप

65, 66 - तापमान माप 67 से 72 - जाइरोस्कोप माप 73 से 96 - बाहरी सेंसर डेटा

ध्यान देने योग्य बात: MPU-6050 में मैग्नेटोमीटर नहीं है, जबकि MPU-9250 (और हम इसे भी मानते हैं) में एक है।

कुछ और दिलचस्प, उम्मीद के मुताबिक उपयोगी जानकारी रजिस्टर-दस्तावेज़ से प्राप्त हुई:

मैग्नेटोमीटर जानकारी:

मैग्नेटोमीटर आईडी: 0x48 रजिस्टर 00 से 09: 00H WIA 0 1 0 0 1 0 0 0 0 01H जानकारी INFO7 INFO6 INFO5 INFO4 INFO3 INFO2 INFO1 INFO0 02H ST1 0 0 0 0 0 0 DOR DRDY 03H HX 04H HX7 HX6 HX5 HX4 HX3 HX HXH HX15 HX14 HX13 HX12 HX11 HX10 HX9 HX8 05H HYL HY7 HY6 HY5 HY4 HY3 HY2 HY1 HY0 06H HYH HY15 HY14 HY13 HY12 HY11 HY10 HY9 HY8 07h एचजेडएल HZ7 HZ6 HZ5 HZ4 HZ3 HZ2 HZ1 HZ0 08H HZH HZ15 HZ14 HZ13 HZ12 HZ11 HZ10 HZ9 HZ8 09h ST2 0 0 0 BITM HOFL 0 0 0 प्रत्येक रजिस्टर का क्या अर्थ है इसका एक ब्रेकडाउन: HXL [7: 0]: X-अक्ष माप डेटा कम 8 बिट HXH [15: 8]: X-अक्ष माप डेटा उच्चतर 8 बिट HYL [7: 0]: वाई-अक्ष माप डेटा कम 8 बिट एचवाईएच [15: 8]: वाई-अक्ष माप डेटा उच्च 8 बिट एचजेडएल [7: 0]: जेड-अक्ष माप डेटा कम 8 बिट एचजेडएच [15: 8]: जेड-अक्ष माप डेटा उच्च 8 बिट

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

रजिस्टर डॉक्स से एक और जानकारी यह है कि ऐसा लग रहा था कि लगभग 100 या तो रजिस्टर ही थे। तो एक युक्ति एक साधारण प्रोग्राम लिखना हो सकता है जो डिवाइस (0x68) तक पहुंचता है और अनुक्रमिक रूप से रजिस्टरों की एक श्रृंखला को पढ़ने का प्रयास करता है, उनके अर्थ के संबंध में, केवल यह देखने के लिए कि कौन सा डेटा देखा जा सकता है।

और फिर, एक ही कोड का उपयोग करके लगातार पास करें, और एक पास बनाम अगले डेटा की तुलना करें।

विचार यह है कि हम संभवत: ऐसे किसी भी रजिस्टर को समाप्त कर सकते हैं जिसमें कोई डेटा नहीं है (शून्य या एफएफ?)

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

अंत में, हम फिर धीरे से सेंसर के साथ चीजों की कोशिश कर सकते हैं, जैसे कि इसे कुहनी से (एक्सेलेरोमीटर, जाइरो), या उस पर फूंक मारना (तापमान), या इसे घुमाना (पिछले दो प्लस मैग्नेटोमीटर) और देखें कि इसका मूल्यों पर क्या प्रभाव पड़ता है।

मैं जितना संभव हो सके वायरिंगपीआई लाइब्रेरी का उपयोग करना पसंद करता हूं। इसमें I2C के लिए सपोर्ट है।

पहली दौड़:

/********************************************************************************

* निर्माण करने के लिए: gcc first.test.mpu9265.c -o first.test.mpu9265 -lwiringPi * * चलाने के लिए: sudo./first.test.mpu9265 * * यह प्रोग्राम MCP23017 से (संभव) रजिस्टरों की एक श्रृंखला का उत्पादन करता है, * और फिर MPU9265 (या उस 0x68 पते पर कोई अन्य MPU) से * * मैंने इसका उपयोग यह सत्यापित करने के लिए किया कि क्या मैं सेंसर से भी पढ़ सकता हूं, क्योंकि मुझे पहले से ही * MCP23017 पर भरोसा था। *********************** ***************/#शामिल करें #शामिल करें #शामिल करें #शामिल करें int मुख्य (int argc, char** argv) { डालता है ("आइए देखें कि MCP23017 @ 0x20 का क्या कहना है:"); त्रुटि = 0; इंट डिवाइसआईडी1 = 0x20; int fd1 = वायरिंगPiI2CSetup(deviceId1); अगर (-1 == fd1) {fprintf (stderr, "वायरिंग नहीं खोल सकताPi I2C डिवाइस: %s\n", स्ट्रेरर (इरनो)); वापसी १; } के लिए (int reg=0;reg<300;reg++) { fprintf(stderr, "%d", वायरिंगPiI2CReadReg8(fd1, reg));fflush(stderr); देरी(10); } डालता है(""); डालता है ("आइए देखें कि MPU9265 @ 0x20 का क्या कहना है:"); त्रुटि = 0; इंट डिवाइसआईडी2 = 0x68; int fd2 = वायरिंगPiI2CSetup(deviceId2); अगर (-1 == fd2) {fprintf (stderr, "वायरिंग नहीं खोल सकताPi I2C डिवाइस: %s\n", strerror (errno)); वापसी १; } के लिए (int reg=0;reg<300;reg++) { fprintf(stderr, "%d", वायरिंगPiI2CReadReg8(fd2, reg));fflush(stderr); देरी(10); } डालता है(""); वापसी 0; }

दूसरा रन:

/********************************************************************************

* निर्माण करने के लिए: gcc second.test.mpu9265.c -o second.test.mpu9265 -lwiringPi * * चलाने के लिए: sudo./second.test.mpu9265 * * यह प्रोग्राम रीड वैल्यू के साथ रजिस्टर नंबर को आउटपुट करता है। * * यह आउटपुट को फ़ाइल में पाइप (रीडायरेक्ट) करने के लिए उपयोगी बनाता है, और फिर * तुलना करने के लिए कई रन किए जा सकते हैं। यह कुछ अंतर्दृष्टि दे सकता है * कौन से रजिस्टर महत्वपूर्ण हैं, और डेटा कैसे व्यवहार कर सकता है। *********************** ***************/#शामिल करें #शामिल करें #शामिल करें #शामिल करें #include int main(int argc, char** argv) {इंट डिवाइस आईडी = -1; अगर (0) {} और अगर (!strncmp(argv[1], "0x20", strlen("0x20"))) { deviceId = 0x20; } और अगर (!strncmp(argv[1], "0x68", strlen("0x68"))) { deviceId = 0x68; } और अगर (!strncmp(argv[1], "0x69", strlen("0x69"))) { deviceId = 0x69; } डालता है ("आइए देखें कि MPU9265 @ 0x20 का क्या कहना है:"); त्रुटि = 0; इंट एफडी = वायरिंगपीआई 2 सीसेटअप (डिवाइस आईडी); अगर (-1 == fd) {fprintf (stderr, "वायरिंग नहीं खोल सकताPi I2C डिवाइस: %s\n", strerror (errno)); वापसी १; } के लिए (int reg=0;reg<300;reg++) { fprintf(stderr, "%d:%d\n", reg, वायरिंगPiI2CReadReg8(fd, reg));fflush(stderr); देरी(10); } वापसी 0; }

तीसरा रन:

/********************************************************************************

* बनाने के लिए: gcc थर्ड.टेस्ट.mpu9265.c -othird.test.mpu9265 -lwiringPi * * रन करने के लिए: sudo./third.test.mpu9265 * * यह प्रोग्राम दूसरे प्रोग्राम का परिणाम है। यह केवल * रजिस्टरों से पढ़ता है जो एक रन और अगले के बीच के अंतर को दर्शाता है।*********************** ***************/#शामिल करें #शामिल करें #शामिल करें #शामिल करें #include int main(int argc, char** argv) {इंट डिवाइस आईडी = -1; अगर (0) { } और अगर (!strncmp(argv[1], "0x68", strlen("0x68"))) { deviceId = 0x68; } और अगर (!strncmp(argv[1], "0x69", strlen("0x69"))) { deviceId = 0x69; } डालता है ("आइए देखें कि MPU9265 @ 0x20 का क्या कहना है:"); त्रुटि = 0; इंट एफडी = वायरिंगपीआई 2 सीसेटअप (डिवाइस आईडी); अगर (-1 == fd) {fprintf (stderr, "वायरिंग नहीं खोल सकताPi I2C डिवाइस: %s\n", strerror (errno)); वापसी १; } के लिए (int reg=61;reg<=73;reg++) { fprintf(stderr, "%d:%d\n", reg, वायरिंगPiI2CReadReg8(fd, reg));fflush(stderr); देरी(10); } के लिए (int reg=111;reg<=112;reg++) { fprintf(stderr, "%d:%d\n", reg, वायरिंगPiI2CReadReg8(fd, reg));fflush(stderr); देरी(10); } के लिए (int reg=189;reg<=201;reg++) { fprintf(stderr, "%d:%d\n", reg, वायरिंगPiI2CReadReg8(fd, reg));fflush(stderr); देरी(10); } के लिए (int reg=239;reg<=240;reg++) { fprintf(stderr, "%d:%d\n", reg, वायरिंगPiI2CReadReg8(fd, reg));fflush(stderr); देरी(10); } वापसी 0; }

तो हमने अब तक क्या सीखा? रंगीन हाइलाइट किए गए क्षेत्रों वाली तालिका की छवि इंगित करती है कि आउटपुट रजिस्टरों के पहले सेट से मेल खाता प्रतीत होता है।

अब तक के नतीजे नए सवाल पैदा कर सकते हैं।

प्रश्न: "बाहरी" समूह के लिए केवल एक ही रजिस्टर परिणाम क्यों है?

प्रश्न: वो सभी अज्ञात रजिस्टर कौन से हैं "??????"

प्रश्न: चूंकि कार्यक्रम बाधित नहीं है, क्या इसने डेटा का अनुरोध बहुत धीमा कर दिया है? बहुत तेज़?

प्रश्न: क्या हम सेंसर के साथ चीजों को चलाने की कोशिश करके परिणामों को प्रभावित कर सकते हैं?

चरण 6: आइए रीडिंग / डेटा में और अधिक जानकारी प्राप्त करें

मुझे लगता है कि किसी और चीज से पहले अगला कदम कार्यक्रम को बढ़ाने के लिए है:

• कितना लूप विलंब (एमएस) में लचीला हो
• प्रति रजिस्टर एक रनिंग एवरेज देने के लिए कितने रीडिंग में लचीला होना चाहिए

(मुझे प्रोग्राम को एक फाइल के रूप में संलग्न करना था। इसे यहां डालने में एक समस्या लग रही थी। "चौथा.टेस्ट.mpu9265.c")

औसत के लिए पिछले 10 रीडिंग का उपयोग करते हुए, 10ms लूप पर यहां एक रन है:

sudo./fourth.test.mpu9265 0x68 10 10

61:255 0 255 0 255 0 255 0 0 0: 102 62:204 112 140 164 148 156 188 248 88 228: 167 63:189 188 189 187 189 188 188 188 188 189: 188 64: 60 40 16 96 208 132 116 252 172 36: 112 65: 7 7 7 7 7 7 7 7 7 7: 7 66:224 224 224 240 160 208 224 208 144 96: 195 67: 0 0 0 0 0 0 0 0 0 0: 0 68:215 228 226 228 203 221 239 208 214 187: 216 69: 0 255 0 255 255 0 255 0 0 0: 102 70:242 43 253 239 239 45 206 28 247 207: 174 71: 0 255 255 0 255 255 255 255 255 255: 204 72: 51 199 19 214 11 223 21 236 193 8: 117 73: 0 0 0 0 0 0 0 0 0 0: 0 111: 46 149 91 199 215 46 142 2 233 199: 132 112: 0 0 0 0 0 0 0 0 0 0: 0 189:255 0 255 0 255 0 0 255 0 255: 127 190: 76 36 240 36 100 0 164 164 152 244: 121 191:188 188 188 188 187 188 187 189 187 189: 187 192: 8 48 48 196 96 220 144 0 76 40: 87 193: 7 7 7 7 7 8 7 7 7 7: 7 194:208 224 144 240 176 240 224 208 240 224: 212 195: 0 0 0 0 0 0 0 0 0 0: 0 196:243 184 233 200 225 192 189 242 188 203: 209 197:255 0 0 0 255 0 255 0 0 255: 102 198:223 39 247 43 245 22 255 221 0 6: 130 199: 0 255 255 255 0 255 255 255 255 0: 178 200:231 225 251 1 252 20 211 216 218 16: 164 201: 0 0 0 0 0 0 0 0 0 0: 0 239: 21 138 196 87 26 89 16 245 187 144: 114 240: 0 0 0 0 0 0 0 0 0 0: 0

पहला, सबसे बायां कॉलम रजिस्टर नंबर है। फिर उस रजिस्टर की अंतिम 10 रीडिंग आएं। अंत में, अंतिम कॉलम प्रत्येक पंक्ति के लिए औसत है।

ऐसा लगता है कि रजिस्टर ६१, ६९, ७१, १८९, १९७, और १९९ या तो केवल बाइनरी हैं, या तैयार / तैयार नहीं हैं, या वे १६-बिट मान (ऋणात्मक?) के उच्च बाइट हैं।

अन्य दिलचस्प अवलोकन:

• रजिस्टर ६५, १९३ - बहुत स्थिर और समान मूल्य
• रजिस्टर 63, 191 - बहुत स्थिर और समान मान
• रजिस्टर 73, 112, 195, 201, 240 - सभी शून्य पर

आइए इन अवलोकनों को पहले की बहुरंगी, हाइलाइट की गई तालिका छवि से संबंधित करें।

रजिस्टर 65 - तापमान

रजिस्टर 193 - ??????

रजिस्टर 63 - एक्सेलेरोमीटर

रजिस्टर 191 - ??????

रजिस्टर 73 - बाहरी

रजिस्टर 112 और चालू - ??????

खैर, हमारे पास अभी भी अज्ञात हैं, हालांकि, हमने कुछ उपयोगी सीखा है।

रजिस्टर ६५ (तापमान) और रजिस्टर ६३ (एक्सेलेरोमीटर) दोनों बहुत स्थिर थे। यह ऐसी चीज है जिसकी हम अपेक्षा करेंगे। मैंने सेंसर को छुआ नहीं है; यह किसी भी आकस्मिक कंपन के अलावा हिल नहीं रहा है, क्योंकि रोबोट उसी टेबल पर आराम कर रहा है जिस पर मेरा कंप्यूटर है।

इनमें से प्रत्येक तापमान/एक्सेलेरोमीटर रजिस्टरों के लिए हम एक दिलचस्प परीक्षण कर सकते हैं। उस परीक्षण के लिए, हमें कार्यक्रम के एक और संस्करण की आवश्यकता है।

चरण 7: हम तापमान और त्वरण को प्रभावित करने में सक्षम हैं

पिछले चरणों में हमने तापमान के लिए कम से कम एक रजिस्टर और त्वरण के लिए एक रजिस्टर को संकुचित कर दिया था।

कार्यक्रम के इस अगले संस्करण ("पांचवें.टेस्ट.mpu9265.c") के साथ, हम वास्तव में दोनों रजिस्टरों के लिए एक बदलाव देख सकते हैं। कृपया वीडियो देखें।

अधिक खुदाई

यदि हम वापस जाते हैं और रजिस्टर की जानकारी पर एक नज़र डालते हैं, तो हम देखते हैं कि ये हैं:

• जाइरोस्कोप के लिए तीन 16 बिट आउटपुट
• एक्सेलेरोमीटर के लिए तीन 16 बिट आउटपुट
• मैग्नेटोमीटर के लिए तीन 16 बिट आउटपुट
• तापमान के लिए एक 16 बिट आउटपुट

हालांकि, हमारे सरल परीक्षण कार्यक्रमों द्वारा प्राप्त परिणाम सभी एकल 8 बिट आउटपुट थे। (एकल रजिस्टर)।

तो आइए उसी दृष्टिकोण को और अधिक आजमाएं, लेकिन इस बार 8 के बजाय 16 बिट्स पढ़ रहे हैं।

हमें शायद नीचे जैसा कुछ करना होगा। आइए एक उदाहरण के रूप में तापमान का उपयोग करें, क्योंकि यह केवल एक 16 बिट आउटपुट है।

// फाइल डिस्क्रिप्टर एफडी प्राप्त करें …

int tempRegHi = ६५; इंट टेम्परेगलो = ६६; int hiByte = वायरिंगPiI2CReadReg8 (fd, tempRegHi); int loByte = वायरिंगPiI2CReadReg8 (fd, tempRegLo); इंट परिणाम = हायबाइट << 8; // हाय ऑर्डर 8 बिट्स को 16 बिट वैल्यू रिजल्ट के ऊपरी हिस्से में डालें |= loByte; // अब लो ऑर्डर में 8 बिट्स जोड़ें, एक पूर्ण 16 बिट संख्या प्रदान करें // उस नंबर को प्रिंट करें या पहले से डिस्प्ले हॉरिजॉन्टल ग्राफिंग फ़ंक्शन का उपयोग करें

हमारे पिछले चरणों से हमने देखा है कि रजिस्टर ६५ काफी स्थिर है, जबकि रजिस्टर ६६ बहुत शोर है। चूंकि 65 हाय ऑर्डर बाइट है, और 66 निम्न ऑर्डर बाइट है, जो समझ में आता है।

पढ़ने के लिए, हम रजिस्टर 65 के डेटा को इस रूप में ले सकते हैं, लेकिन हम रजिस्टर 66 के मूल्यों को औसत कर सकते हैं।

या हम पूरे परिणाम को औसत कर सकते हैं।

इस भाग के लिए अंतिम वीडियो देखें; यह पूरे 16 बिट तापमान मान को पढ़ने का प्रदर्शन करता है। कोड "छठा.टेस्ट.mpu9265.c" है

चरण 8: एक्सेलेरोमीटर और जायरोस्कोप

इस खंड के वीडियो एक परीक्षण कार्यक्रम "सेवेंथ.टेस्ट.एमपीयू9265.सी" का उपयोग करते हुए एक्सेलेरोमीटर और जाइरोस्कोप से आउटपुट दिखाते हैं। वह कोड 1, 2, या 3 लगातार बाइट-जोड़े (हाय और लो बाइट्स) पढ़ सकता है और मानों को एक 16 बिट मान में परिवर्तित कर सकता है। इस प्रकार, हम किसी एक अक्ष को पढ़ सकते हैं, या हम उनमें से दो को एक साथ पढ़ सकते हैं (और यह परिवर्तनों का योग है), या हम तीनों को पढ़ सकते हैं (और यह परिवर्तनों का योग है)।

इस चरण के लिए, इस निर्देश के लिए, मैं केवल एक सरल प्रश्न का उत्तर देना चाहता हूं: "क्या रोबोट घूमता / धुरी था?"। मैं किसी सटीक मान की तलाश में नहीं हूं, जैसे कि, क्या यह 90 डिग्री घूमता है। यह बाद में आएगा जब हमें SLAM करना होगा, लेकिन साधारण बाधा-परिहार और यादृच्छिक गति के लिए इसकी आवश्यकता नहीं है।

चरण 9: (कार्य प्रगति पर है) मैग्नेटोमीटर

i2cdetect टूल का उपयोग करते समय, MPU9265 तालिका में 0x68 के रूप में दिखाई देता है:

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- --

IMU के मैग्नेटोमीटर भाग से पढ़ने के लिए अतिरिक्त चरणों की आवश्यकता होती है।

इनवेसेंस रजिस्टरों से पीडीएफ दस्तावेज़:

रजिस्टर 37 से 39 - I2C गुलाम 0 नियंत्रण

• रजिस्टर 37 - I2C_SLV0_ADDR
• रजिस्टर 38 - I2C_SLV0_REG
• रजिस्टर 39 - I2C_SLV0_CTRL