والاس - روبوت مستقل DIY - الجزء 5 - إضافة IMU: 9 خطوات

2024 مؤلف: John Day | [email protected]. آخر تعديل: 2024-01-30 07:40

نحن نسير مع والاس. جاء اسم والاس من مزيج من "Wall-E" ، ومن مشروع سابق (التعرف على الصوت) ، وباستخدام الأداة المساعدة "espeak" ، بدا الأمر بريطانيًا بعض الشيء. ومثل خادم أو خادم شخصي. وهذا هو الهدف النهائي: أن يتحول هذا المشروع إلى شيء مفيد. هكذا "والاس".

يمكن أن يتحرك والاس ، يمكنه تجنب العقبات باستخدام مستشعرات مسافة الأشعة تحت الحمراء (مؤخرًا ، بطريقة ما تقلى (؟) (يجب أن تنظر في ذلك عندما تسنح لي الفرصة) ، ولديها أيضًا بعض مستشعرات المسافة الصوتية (ثلاثة منها ساءت في نفس الوقت) الوقت ، جنبًا إلى جنب مع موسع MCP23017) ، وأخيرًا ، يمكنه اكتشاف التغييرات في تيار المحرك لمعرفة متى يصطدم بشيء ما.

بالإضافة إلى المستشعرات ، "يتذكر" والاس 100 حركة ، ولديه بعض التحليلات الأولية باستخدام تاريخ الحركة.

هدف والاس حتى الآن هو مجرد محاولة الاستمرار في المضي قدمًا ، ومعرفة متى يكون عالقًا في نمط متكرر (مثل الزاوية) وليس المضي قدمًا حقًا.

لقد مررت بالعديد من التكرارات للحركة والملاحة ، وكان الصداع المستمر أثناء الدوران.

نظرًا لأن والاس هو روبوت متعقب ، وأردت أن أبقي الأمور أبسط في البرنامج (لاحقًا) ، من أجل أن أقوم بالدوران في مكانه. وبالتالي ، قم بتطبيق دورة قوة / عمل متساوية ولكن معاكسة على المحركات.

ترجع المشكلة التي تمت مواجهتها إلى تصميم منصة الروبوت Agent 390. تميل أحزمة الجنزير إلى الاحتكاك بالجوانب. والأسوأ من ذلك ، أن أحد الأطراف يفعل ذلك أكثر من الآخر.

على الأرضيات والسير بشكل مستقيم ، لم تكن مشكلة. يظهر على السجاد. اخترت إبقاء والاس بعيدًا عن السجاد بعد أن أصبحت مساراته متسخة (تلتقط الأوساخ بسهولة شديدة).

المشكلة الحقيقية هي عند التمحور على الأرضيات.

إذا كان لدي برنامج يطبق دورة عمل عالية المستوى ، فإنه يتحول إلى حد ما أو أقل باستمرار. ومع ذلك ، خلال دورة العمل المنخفض ، قد يتحول أو لا يتحول في الواقع. أو قد يتحول قليلاً ثم يتباطأ. يبدو أن إجراء التمحور لا يمكن التحكم فيه عبر البرنامج ، أو في أحسن الأحوال صعب للغاية.

تظهر المشكلة أثناء التنقل والتنقل أو الابتعاد عن العوائق. يمكن أن تتأرجح بعيدًا جدًا ، أو يمكن أن تتعثر في محاولة إجراء نوبات دقيقة جدًا ، دون أن تتحرك حقًا.

ولذا فإن الشرح أعلاه حفز هذا Instructable.

في البداية ، كنت أرغب في الاستغناء عن أو تأخير إدخال وحدة استشعار الحركة (IMU) ، لأنها أخطاء أ) معقدة ، ب) صاخبة ، ج) يمكن أن تظهر بمرور الوقت ، وما إلى ذلك ، وما إلى ذلك. كان بإمكاننا القيام بعمل جيد للغاية من خلال القفز إلى الأمام إلى مستشعرات الليزر التي تعمل بالأشعة تحت الحمراء في وقت الرحلة. ويمكننا - باستخدام الليزر أن نعرف ما إذا كان الروبوت يدور أم لا ، من خلال تتبع التغيرات في المسافة.

في الواقع ، يمكننا أيضًا (نوعًا ما) القيام بذلك الآن ، باستخدام المستشعرات الصوتية.

ومع ذلك ، كل هذا هو طريقة معقدة وغير مباشرة للغاية للإجابة على سؤال واحد بسيط: "هل قمنا بالتناوب أم لا؟"

بدا لي أن القفز لاستخدام مستشعرات الليزر ToF سيأخذني إلى المستوى التالي من البرامج ؛ وهي SLAM (التعريب المتزامن ورسم الخرائط). لم أكن مستعدًا للذهاب إلى هناك بعد.

إنه لأمر جيد أن تقوم بمشروع روبوت في طبقات ، مع كون الطبقات الأولى (السفلية) أبسط ، والطبقات الأخيرة (العليا) أكثر تجريدًا وتعالج مشكلات أكثر صعوبة.

يمكن التفكير في الطبقات بشيء مثل هذا:

1. الإطار المادي للروبوت / الأساس الهيكلي الميكانيكي
2. نظام محرك بدائي (Raspberry ، Roboclaw ، محركات ، كابلات ، إلخ ، برامج أساسية ، تعمل بلوحة المفاتيح)
3. دارة أساسية لدعم المستشعرات (ناقل الحركة ثنائي الاتجاه ، موسع المنفذ ، E-Stop ، توزيع الطاقة ، إلخ)
4. مستشعرات تجنب العوائق (الصوتية ، IR)
5. تحديد الموقع والحركة الأساسيين - الكشف (مقياس التسارع ، الجيروسكوب ، مقياس المغنطيسية ، مشفرات المحركات ، أجهزة ترميز العجلة)

يمكنك الخروج بقائمتك الخاصة. تتمثل النقاط حول هذه القائمة في أنه ربما يجب عليك القيام بذلك بشكل أو بآخر بهذا الترتيب ، وأيضًا أنه إذا قضيت بعض الوقت في كل طبقة للوصول إلى حالة عمل جيدة ، فمن المفترض أن يساعدك ذلك لاحقًا لأن الأمور تصبح أكثر تعقيدًا.

يمكن تعيين القائمة أعلاه إلى حد ما لهذه الطبقات المفاهيمية في البرنامج.

• SLAM (التعريب المتزامن ورسم الخرائط)
• التحكم في الحركة والوعي بها ، الدوران
• تجنب العقبات الأساسية
• التحكم والكشف عن بيانات المستشعر
• حركة أساسية للأمام ، للخلف ، لليسار واليمين ، تسريع ، إبطاء ، توقف

كما ترى ، بالنسبة إلى هذه القائمة ، ستكون العناصر الأولى هي الطبقات العليا والأكثر تعقيدًا التي تتناول المزيد من القضايا والأسئلة المجردة ، مثل "أين أنا" و "إلى أين أنا ذاهب" ، بينما ستكون العناصر الأخيرة هي طبقات البرامج السفلية التي تتعامل مع "كيفية التحدث / الاستماع إلى المستشعر A" أو "كيفية تحريك هذه العجلة".

الآن ، أنا لا أقول أنه عندما تبدأ في طبقة ، ستكون قد أكملتها وبعد ذلك في الطبقة التالية ، ولن تعود أبدًا إلى الطبقة السابقة. يمكن أن يشبه مشروع الروبوت إلى حد كبير أساليب تطوير البرامج الحديثة والتكرارية (رشيق ، SCRUM ، إلخ).

أنا فقط أقول لأخذ الوقت في كل منهما. سيتعين عليك موازنة مقدار ما يجب القيام به في كل منها ، وتحديد ما تحاول القيام به في طبقة معينة يستحق الوقت والمتاعب.

هناك "صراع" أو "توتر" معين بين فكرتين أو اتجاهين متنافستين.

أحدهما هو ما يمكن أن أسميه "plug-n-play" لحل المشكلة أ.

الآخر هو DIY (افعلها بنفسك). وقد لا يكون هذا أفضل تسمية لهذه الفكرة الأخرى.

فيما يلي مثال على كل منها ، ونأمل أن ترى التوتر أو الصراع بين الخيارين.

في هذا المثال ، دعنا نضع SLAM وتجنب العوائق والحركة الأساسية الأساسية كلها كمشكلة واحدة يجب حلها في نفس الوقت.

1. إذا قررنا السير في مسار المكونات الإضافية ، فنحن نقفز فورًا (حسب الميزانية) إلى أشياء مثل أجهزة الليزر الدوارة المثبتة بالأعلى ، أو كاميرا عمق المجال ، أو ليزر ToF ، و IMU (موضوع هذا قابل للتوجيه).
2. من ناحية أخرى ، إذا أردنا السير في الطريق الثاني ، فقد نحاول استخراج كل جزء ممكن من المعلومات من بعض المستشعرات الصوتية أو مستشعرات الأشعة تحت الحمراء ، أو لا توجد مستشعرات على الإطلاق - نستخدم فقط مراقبة التيار الحركي (نتوء)

ماذا يمكن أن يقال عن # 1 مقابل # 2؟ شيء واحد هو أننا سنكون قد تعلمنا الكثير من خلال القيام بالرقم 2. القيود المفروضة على وجود أجهزة استشعار صوتية فقط للعمل معها ، تجبرنا على التفكير في الكثير من القضايا.

من ناحية أخرى ، إذا كنا نركز بشكل كبير على القيام بالأشياء من خلال # 2 ، فقد نضيع الوقت ، لأننا نطلب أكثر مما ينبغي من أجهزة الاستشعار الصوتية.

هناك مفهوم أو فكرة أخرى يجب التفكير فيها: أي مزيج من الأجهزة والبرامج يجيب بشكل أفضل على أسئلة "كيف" ، وما مزيج البرامج (والأجهزة؟) الذي يجيب على سؤال "ماذا" ، "متى" ، "أين". لأن "كيف" عادة ما يكون سؤالًا منخفض المستوى يعتمد عليه "ماذا" و "متى" و "أين" للحصول على إجابة.

على أي حال ، كل ما سبق كان مجرد شيء للتفكير فيه.

في حالتي ، بعد بذل الكثير من الجهد ووجود مشكلة مزعجة باستمرار وهي احتكاك المسار وعدم القدرة على التحكم والحركة بشكل متسق ، فقد حان الوقت للقيام بشيء آخر.

وبالتالي هذا Instructable - IMU.

الهدف هو أنه إذا قالت IMU أن الروبوت لا يتمحور ، فإننا نزيد دورة العمل. إذا كنا نتمحور بسرعة كبيرة ، فإننا نخفض دورة العمل.

الخطوة 1: مستشعر IMU

وبالتالي ، فإن المستشعر التالي الذي نضيفه إلى والاس هو IMU. بعد بعض البحث ، كنت أقوم بالاستقرار على MPU6050. ولكن في هذا الوقت ، بدا أن MPU9050 (ومؤخرًا MPU9250) تبدو فكرة أفضل.

كان مصدر الانتقال إلى Amazon (في الولايات المتحدة). لذلك طلبت اثنين منهم.

ما حصلت عليه في الواقع (يبدو أنه لا يوجد سيطرة على هذا ؛ هذا ما لا أحبه في أمازون) كانا هما MPU92 / 65. أتساءل قليلا عن التعيين. الق نظرة على الصور. يبدو أن هذا التعيين "الأسرة". على أي حال ، هذا ما أنا عالق به.

إضافته بسيطة للغاية - احصل على لوحة أولية مع مسارات متصلة ، ولحام المستشعر باللوحة ، وأضف كتلة طرفية لولبية ذات 10 سنون (حصلت على منجم من Pololu).

لتقليل أي تداخل ، حاولت وضع هذه المستشعرات بعيدًا عن أي شيء آخر.

هذا يعني أيضًا استخدام بعض البراغي / الصواميل من النايلون.

سأستخدم بروتوكول I2C. نأمل ألا يكون طول السلك الإجمالي سيئًا جدًا.

هناك الكثير من المعلومات في مكان آخر حول التوصيلات الأساسية ومستويات الجهد ، وما إلى ذلك ، لذلك لن أكرر ذلك هنا.

الخطوة 2: الأشياء ليست نظيفة دائمًا وسهلة

حتى كتابة هذه السطور ، لا يبدو أن هناك الكثير على الإنترنت من أجل MPU-92/65 على وجه التحديد. ما هو متاح ، تمامًا كما هو الحال مع معظم المستشعرات ، يبدو أنه أمثلة على استخدام Arduino.

أحاول أن أجعل هذه التعليمات مختلفة قليلاً من خلال تقديم عملية غير نظيفة ، لأن الأشياء لا تعمل دائمًا على الفور.

أفترض أن هذه Instructables تشبه المدونة أكثر من A-B-C المستقيمة ، 1-2-3 "هذه هي الطريقة التي تفعلها بها".

الخطوة 3: الاختبار الأولي

من الصور الموجودة في الخطوة السابقة ، فإن الأسلاك الحمراء والسوداء التي تذهب إلى المستشعرات هي بالطبع VCC (5V) و GND. الأسلاك الخضراء والصفراء هي وصلات I2C.

إذا كنت قد أنجزت مشاريع I2C أخرى ، أو كنت تتابع هذه السلسلة ، فأنت تعرف بالفعل "i2cdetect" ، وهذه هي الخطوة الأولى لمعرفة ما إذا كان بإمكان Raspberry رؤية المستشعر الجديد.

كما ترى من الصور في هذه الخطوة ، كانت محاولتنا الأولى غير ناجحة. لا يظهر IMU (يجب أن يكون معرف الجهاز 0x68).

ومع ذلك ، فإن الخبر السار هو أن ناقل I2C يعمل. نرى جهازًا واحدًا 0x20 وهو موسع منفذ MCP23017 (مسؤول حاليًا عن أجهزة الاستشعار الصوتية HCSR04).

ليس من السهل رؤيته في الصورة ، لكنني قمت بتوصيل نفس الأسلاك الملونة باللونين الأخضر والأصفر من وحدة IMU إلى MCP23017 (انظر أسفل اليسار في الصورة)

سيتعين علينا القيام ببعض استكشاف الأخطاء وإصلاحها.

الخطوة 4: استكشاف الأخطاء وإصلاحها

باستخدام إعداد الاستمرارية على مقياس الفولتميتر (ذي النغمة العالية) ، اختبرت اتصالات VCC (5V) و GND و SDA و SCL. كانت تلك جيدة.

كانت المحاولة التالية هي فصل MCP23017 عن ناقل I2C ، وترك MPU-92/65 فقط في الحافلة. ثبت أن ذلك غير مثمر - لم تظهر "i2cdetect" بعد ذلك أية أجهزة.

لذلك ، بعد ذلك ، قمت بفك المستشعر من عمود الطوطم ، وأعدت توصيله مباشرة بالحافلة ثنائية الاتجاه 5V إلى 3V ؛ أي مباشرة إلى التوت. (أسلاك أقصر؟).

وفويلا. هذه المرة هناك نجاح. نرى 0x68 تظهر باستخدام "i2cdetect".

لكننا لا نعرف حتى الآن سبب نجاحها هذه المرة. هل يمكن أن يكون طول الأسلاك؟ الموقع السابق؟

ملاحظة: لم يحدث أي فرق سواء تم تأريض ADO أم لا. يمكن أن يكون هناك مقاومات سحب وسحب على متن الطائرة. قد يكون الأمر نفسه صحيحًا بالنسبة لـ FSYNC.

بعد ذلك ، أعدت توصيل MCP23017. إذن لدينا الآن جهازان على ناقل I2C. (انظر الصورة). نجح ، نرى الآن كلاً من 0x20 و 0x68 مع i2cdetect.

تتناول مقاطع الفيديو أكثر قليلاً مما حدث أثناء استكشاف الأخطاء وإصلاحها.

الخطوة الخامسة: قراءة بيانات المستشعر

مناهج مختلفة

قررت اتباع طرق متعددة للحصول على معلومات مفيدة من المستشعر. ها هم ، ليس بأي ترتيب:

1. جرب بعض البرمجة الأساسية
2. ابحث في بعض الوثائق عبر الإنترنت على السجلات
3. ألق نظرة على أمثلة و / أو التعليمات البرمجية الخاصة بالآخرين

لماذا هذه الأساليب؟ لماذا لا تبحث فقط عن بعض المكتبات أو التعليمات البرمجية الموجودة؟

من خلال تجربة بعض الأفكار وتجربتها ، يمكننا بشكل أفضل استيعاب بعض المعرفة ليس فقط حول هذا المستشعر المحدد ، ولكن أيضًا اكتساب بعض التقنيات والمهارات وطرق التفكير في معالجة شيء جديد ، وشيء قد لا يحتوي على الكثير من الوثائق ؛ شيء قد يحتوي على الكثير من الأشياء المجهولة.

أيضًا ، بمجرد أن نلعب مع بعض أفكارنا وتجربناها واكتسبنا بعض الأفكار ، نكون في وضع أفضل لتقييم رمز أو مكتبة شخص آخر.

على سبيل المثال ، بعد النظر إلى بعض أكواد C ++ الخاصة بـ MPU9250 في جيثب ، أدركت أنه كان يجبرني على استخدام المقاطعات ، وهو ما لا أرغب في فعله بعد.

أيضًا ، يأتي مع أشياء إضافية مثل المعايرة ؛ مرة أخرى ، شيء لست مهتمًا به بعد.

قد يكون ما علي فعله للإجابة على السؤال البسيط "هو أن الروبوت يدور بنعم أو لا" يمكن الإجابة عليه ببساطة شديدة بمجرد قراءة بعض السجلات.

السجلات

حتى كتابة هذه السطور ، لا يبدو أنه يتوفر الكثير على هذا المستشعر. في الواقع ، إذا ألقيت نظرة على الصور التي تأتي مع Instructable ، وألقيت نظرة فاحصة على النقوش الموجودة على الرقائق الفعلية ، فهذا يجعلني أتساءل عما إذا لم تكن هذه نسخة مقلدة. أنا لا أقوم بربط ما أراه بأي شيء من Invense. بغض النظر ، اخترت إلقاء نظرة على معلومات التسجيل الخاصة بالنماذج التي وجدتها: MPU-6050 و MPU-9250.

في كلتا الحالتين ، ما يلي هو نفسه لكليهما. بالنسبة للمبتدئين ، نفترض أنه سيكون هو نفسه أيضًا لـ MPU-92/65.

59 إلى 64 - قياسات التسارع

65 ، 66 - قياسات درجة الحرارة من 67 إلى 72 - قياسات الجيروسكوب من 73 إلى 96 - بيانات المستشعر الخارجي

عنصر ملاحظة: يبدو أن MPU-6050 لا يحتوي على مقياس مغناطيسي ، في حين أن MPU-9250 (ونفترض أن هذا أيضًا) به واحد.

بعض المعلومات الأكثر إثارة للاهتمام والتي نأمل أن تكون مفيدة تم الحصول عليها من مستند السجل:

معلومات المغناطيسية:

معرّف مقياس المغنطيسية: تسجيلات 0x48 من 00 إلى 09:00 ساعة WIA 0 1 0 0 1 0 0 0 01H INFO7 INFO6 INFO5 INFO4 INFO3 INFO2 INFO1 INFO0 02H ST1 0 0 0 0 0 0 DOR DRDY 03H HXL HX7 HX6 HX5 HX4 HX3 HX2 04 HX1 HX0 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 HZ 07 HZ1 HZ0 HZ14 HZ ST2 0 0 0 BITM HOFL 0 0 تفصيل لما يعنيه كل سجل: HXL [7: 0]: بيانات قياس المحور X أقل 8 بت HXH [15: 8]: بيانات قياس المحور X أعلى 8 بت HYL [7: 0]: بيانات قياس المحور Y أقل بمقدار 8 بت HYH [15: 8]: بيانات قياس المحور Y أعلى بمقدار 8 بت HZL [7: 0]: بيانات قياس المحور Z أقل بمقدار 8 بت HZH [15: 8]: بيانات قياس المحور Z أعلى 8 بت

برمجة

جزء آخر من المعلومات من مستندات السجل هو أنه يبدو أن هناك حوالي 100 سجل فقط أو نحو ذلك. لذلك يمكن أن يكون أحد التكتيكات كتابة برنامج بسيط يصل إلى الجهاز (0x68) ويحاول قراءة سلسلة من السجلات بالتسلسل ، دون أي اعتبار لمعناها ، فقط لمعرفة البيانات التي يمكن رؤيتها.

وبعد ذلك ، قم بإجراء تمريرات متتالية ، باستخدام نفس الرمز ، وقارن البيانات من تمريرة مقابل الأخرى.

الفكرة هي أنه يمكننا على الأرجح حذف أي سجلات يبدو أنها لا تحتوي على بيانات (أصفار أو FF؟) أو التي لا تتغير مطلقًا ، ويمكننا أيضًا التركيز على تلك التي تتغير بالفعل.

بعد ذلك ، نحن ننظر فقط إلى تلك التي تتغير ، أضف دالة متوسط التي تحسب متوسط أحدث قراءات N لهذا السجل ، لمعرفة ما إذا كانت هناك بالفعل قيمة ثابتة معينة لهذا السجل. يفترض هذا أننا نحتفظ بالمستشعر ثابتًا جدًا وفي نفس المكان.

أخيرًا ، يمكننا بعد ذلك تجربة الأشياء بلطف باستخدام المستشعر ، مثل دفعه (مقياس التسارع ، الدوران) ، أو النفخ عليه (درجة الحرارة) ، أو تدويره (المقياسان السابقان بالإضافة إلى مقياس المغناطيسية) ومعرفة تأثير ذلك على القيم.

أحب استخدام مكتبة wiringPi قدر الإمكان. يدعم I2C.

الجولة الأولى:

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

* لبناء: gcc first.test.mpu9265.c -o first.test.mpu9265 -lwiringPi * * للتشغيل: sudo./first.test.mpu9265 * * ينتج هذا البرنامج مجموعة من السجلات (الممكنة) من MCP23017 ، * ثم من MPU9265 (أو أي MPU آخر على عنوان 0x68) * * استخدمته للتحقق مما إذا كان بإمكاني القراءة من المستشعر ، لأنني بالفعل * كان لدي ثقة في MCP23017. * *************************************************** ****************************** / #include #include #include #include int main (int argc، char ** argv) {يضع ("دعونا نرى ما يجب أن يقوله MCP23017 @ 0x20:")؛ errno = 0 ؛ معرف الجهاز 1 = 0x20 ؛ int fd1 = wiringPiI2CSetup (deviceId1) ؛ إذا (-1 == fd1) {fprintf (stderr، "لا يمكن فتح جهاز wiringPi I2C:٪ s / n"، strerror (errno)) ؛ العودة 1 ؛ } لـ (int reg = 0؛ reg <300؛ reg ++) {fprintf (stderr، "٪ d"، wiringPiI2CReadReg8 (fd1، reg))؛ fflush (stderr)؛ تأخير (10) ؛ } يضع ("")؛ يضع ("دعونا نرى ما يجب أن يقوله MPU9265 @ 0x20:") ؛ errno = 0 ؛ deviceId2 int = 0x68 ؛ int fd2 = wiringPiI2CSetup (deviceId2) ؛ إذا (-1 == fd2) {fprintf (stderr، "لا يمكن فتح جهاز wiringPi I2C:٪ s / n"، strerror (errno)) ؛ العودة 1 ؛ } لـ (int reg = 0؛ reg <300؛ reg ++) {fprintf (stderr، "٪ d"، wiringPiI2CReadReg8 (fd2، reg))؛ fflush (stderr)؛ تأخير (10) ؛ } يضع ("")؛ العودة 0 ؛ }

الجولة الثانية:

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

* لبناء: gcc second.test.mpu9265.c -o second.test.mpu9265 -lwiringPi * * للتشغيل: sudo./second.test.mpu9265 * * يقوم هذا البرنامج بإخراج رقم التسجيل إلى جانب القيمة المقروءة. * * هذا يجعل من المفيد توجيه (إعادة توجيه) الإخراج إلى ملف ، ثم * يمكن إجراء عدة عمليات للمقارنة. قد يعطي بعض الأفكار حول * ما هو السجل المهم ، وكيف يمكن أن تتصرف البيانات. * *************************************************** ****************************** / #include #include #include #include #include #include int main (int argc، char ** argv) {int deviceId = -1 ؛ if {0) {} else if (! strncmp (argv [1]، "0x20"، strlen ("0x20"))) {deviceId = 0x20؛ } else if (! strncmp (argv [1]، "0x68"، strlen ("0x68"))) {deviceId = 0x68؛ } else if (! strncmp (argv [1]، "0x69"، strlen ("0x69"))) {deviceId = 0x69؛ } يضع ("دعونا نرى ما يجب أن يقوله MPU9265 @ 0x20:")؛ errno = 0 ؛ int fd = wiringPiI2CSetup (deviceId) ؛ إذا (-1 == fd) {fprintf (stderr، "لا يمكن فتح جهاز wiringPi I2C:٪ s / n" ، strerror (errno)) ؛ العودة 1 ؛ } لـ (int reg = 0؛ reg <300؛ reg ++) {fprintf (stderr، "٪ d:٪ d / n"، reg، wiringPiI2CReadReg8 (fd، reg))؛ fflush (stderr)؛ تأخير (10) ؛ } إرجاع 0؛ }

الجولة الثالثة:

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

* لبناء: gcc third.test.mpu9265.c -o third.test.mpu9265 -lwiringPi * * للتشغيل: sudo./third.test.mpu9265 * * هذا البرنامج هو نتيجة البرنامج الثاني. يقرأ فقط من السجلات * التي تشير إلى اختلاف بين تشغيل واحد والتالي.* *************************************************** ****************************** / #include #include #include #include #include #include int main (int argc، char ** argv) {int deviceId = -1 ؛ if {0) {} else if (! strncmp (argv [1]، "0x68"، strlen ("0x68"))) {deviceId = 0x68؛ } else if (! strncmp (argv [1]، "0x69"، strlen ("0x69"))) {deviceId = 0x69؛ } يضع ("دعونا نرى ما يجب أن يقوله MPU9265 @ 0x20:")؛ errno = 0 ؛ int fd = wiringPiI2CSetup (deviceId) ؛ إذا (-1 == fd) {fprintf (stderr، "لا يمكن فتح جهاز wiringPi I2C:٪ s / n" ، strerror (errno)) ؛ العودة 1 ؛ } لـ (int reg = 61؛ reg <= 73؛ reg ++) {fprintf (stderr، "٪ d:٪ d / n"، reg، wiringPiI2CReadReg8 (fd، reg))؛ fflush (stderr)؛ تأخير (10) ؛ } لـ (int reg = 111؛ reg <= 112؛ reg ++) {fprintf (stderr، "٪ d:٪ d / n"، reg، wiringPiI2CReadReg8 (fd، reg))؛ fflush (stderr) ؛ تأخير (10) ؛ } لـ (int reg = 189؛ reg <= 201؛ reg ++) {fprintf (stderr، "٪ d:٪ d / n"، reg، wiringPiI2CReadReg8 (fd، reg))؛ fflush (stderr)؛ تأخير (10) ؛ } لـ (int reg = 239؛ reg <= 240؛ reg ++) {fprintf (stderr، "٪ d:٪ d / n"، reg، wiringPiI2CReadReg8 (fd، reg))؛ fflush (stderr) ؛ تأخير (10) ؛ } إرجاع 0؛ }

إذن ماذا تعلمنا حتى الآن؟ تشير صورة الجدول مع المساحات الملونة المميزة إلى أن الإخراج يبدو أنه يتطابق مع المجموعات الأولى من السجلات.

النتائج حتى الآن يمكن أن تولد أسئلة جديدة.

سؤال: لماذا توجد نتيجة تسجيل واحدة فقط للمجموعة "الخارجية"؟

سؤال: ما هي كل تلك السجلات المجهولة "؟؟؟؟؟؟"

سؤال: بما أن البرنامج لا يعتمد على المقاطعة ، فهل طلب البيانات بطيئًا جدًا؟ سريع جدا؟

سؤال: هل يمكننا التأثير على النتائج من خلال تجربة الأشياء باستخدام المستشعر نفسه أثناء تشغيله؟

الخطوة 6: دعنا نتعمق أكثر في القراءات / البيانات

أعتقد أن الخطوة التالية قبل أي شيء آخر هي تحسين البرنامج من أجل:

• كن مرنًا في مقدار تأخير الحلقة (مللي ثانية)
• كن مرنًا في تحديد عدد القراءات لإعطاء متوسط تشغيل لكل سجل

(اضطررت إلى إرفاق البرنامج كملف. يبدو أن هناك مشكلة في إدراجه هنا. "four.test.mpu9265.c")

إليك جولة باستخدام آخر 10 قراءات بمتوسط ، بحلقة 10 مللي ثانية:

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 قراءات لهذا السجل. أخيرًا ، العمود الأخير هو متوسط كل صف.

يبدو أن السجلات 61 ، و 69 ، و 71 ، و 189 ، و 197 ، و 199 إما ثنائية فقط ، أو جاهزة / غير جاهزة ، أو أنها البايت العالي لقيمة 16 بت (سالبة؟).

ملاحظات أخرى مثيرة للاهتمام:

• يسجل 65 ، 193 - ثابت جدا ونفس القيمة
• سجل 63 ، 191 - ثابت جدا ونفس القيمة
• السجلات 73 ، 112 ، 195 ، 201 ، 240 - كلها عند الصفر

دعنا نربط هذه الملاحظات مرة أخرى بصورة الجدول المظللة متعددة الألوان من قبل.

تسجيل 65 - درجة الحرارة

تسجيل 193 - ؟؟؟؟؟؟

سجل 63 - مقياس التسارع

تسجيل 191 - ؟؟؟؟؟؟

تسجيل 73 - خارجي

سجل 112 و - ؟؟؟؟؟؟

حسنًا ، لا يزال لدينا مجاهيل ، ومع ذلك ، فقد تعلمنا شيئًا مفيدًا.

سجل 65 (درجة الحرارة) وسجل 63 (مقياس التسارع) كانا ثابتين للغاية. هذا شيء نتوقعه. لم ألمس المستشعر ؛ إنه لا يتحرك ، بخلاف أي اهتزازات عرضية ، حيث يستقر الروبوت على نفس المنضدة مثل جهاز الكمبيوتر الخاص بي.

هناك اختبار واحد مثير يمكننا القيام به لكل من سجلات درجات الحرارة / مقياس التسارع هذه. لهذا الاختبار ، نحتاج إلى إصدار آخر من البرنامج.

الخطوة 7: نحن قادرون على التأثير في درجة الحرارة والتسارع

في الخطوات السابقة قمنا بتضييق نطاق سجل واحد على الأقل لدرجة الحرارة وآخر للتسريع.

مع هذا الإصدار التالي من البرنامج ("Fifth.test.mpu9265.c") ، يمكننا أن نرى تغييرًا يحدث لكلا السجلين. يرجى مشاهدة الفيديوهات.

المزيد من الحفر

إذا عدنا وألقينا نظرة على معلومات السجل ، نرى أن هناك:

• ثلاثة مخرجات 16 بت للجيروسكوب
• ثلاثة مخرجات 16 بت لمقياس التسارع
• ثلاثة مخرجات 16 بت لمقياس المغناطيسية
• خرج واحد 16 بت لدرجة الحرارة

ومع ذلك ، فإن النتائج التي تم الحصول عليها من خلال برامج الاختبار البسيطة لدينا كانت جميعها مخرجات فردية 8 بت. (سجلات فردية).

لذلك دعونا نجرب المزيد من نفس النهج ، لكن هذه المرة نقرأ 16 بت بدلاً من 8.

ربما يتعين علينا القيام بشيء مثل أدناه. لنستخدم درجة الحرارة كمثال ، حيث إنها ناتج واحد فقط 16 بت.

// الحصول على واصف الملف fd …

int tempRegHi = 65 ؛ int tempRegLo = 66 ؛ int hiByte = wiringPiI2CReadReg8 (fd ، tempRegHi) ؛ int loByte = wiringPiI2CReadReg8 (fd ، tempRegLo) ؛ نتيجة int = hiByte << 8 ؛ // ضع ترتيب hi 8 بت في الجزء العلوي من نتيجة قيمة 16 بت | = loByte؛ // الآن أضف 8 بتات بالترتيب الصغير ، مما ينتج عنه رقم 16 بت كامل // اطبع هذا الرقم أو استخدم وظيفة عرض الرسوم البيانية الأفقية من قبل

من خطواتنا السابقة ، رأينا أن السجل 65 ثابت جدًا ، في حين أن السجل 66 صاخب جدًا. نظرًا لأن 65 هو بايت الترتيب المرتفع ، و 66 هو بايت الترتيب المنخفض ، فهذا أمر منطقي.

للقراءة ، يمكننا أخذ بيانات السجل 65 كما هي ، لكن يمكننا حساب متوسط قيم السجل 66.

أو يمكننا فقط متوسط النتيجة بأكملها.

ألق نظرة على الفيديو الأخير لهذا الجزء ؛ يوضح قراءة قيمة درجة الحرارة 16 بت بأكملها. الرمز هو "six.test.mpu9265.c"

الخطوة الثامنة: مقياس التسارع والجيروسكوب

تُظهر مقاطع الفيديو الخاصة بهذا القسم الإخراج من مقياس التسارع والجيروسكوب ، باستخدام برنامج اختبار "7th.test.mpu9265.c". يمكن أن يقرأ هذا الرمز 1 أو 2 أو 3 أزواج بايت متتالية (hi و lo bytes) ويحول القيم إلى قيمة واحدة من 16 بت. وبالتالي ، يمكننا قراءة أي محور فردي ، أو يمكننا قراءة اثنين منهم معًا (ويلخص التغييرات) ، أو يمكننا قراءة الثلاثة (وهو يلخص التغييرات).

للتكرار ، في هذه المرحلة ، بالنسبة إلى Instructable ، أنا فقط أتطلع للإجابة على سؤال بسيط: "هل قام الروبوت بالتدوير / المحور؟". أنا لا أبحث عن أي قيمة محددة ، مثل هل استدارت 90 درجة. سيأتي ذلك لاحقًا عندما نبدأ في تنفيذ SLAM ، ولكنه ليس مطلوبًا لتفادي العوائق والحركة العشوائية.

الخطوة 9: (جاري العمل) مقياس المغناطيسية

عند استخدام أداة i2cdetect ، يظهر MPU9265 على أنه 0x68 في الجدول:

0 1 2 3 4 5 6 7 8 9 أ ب ج د هـ و

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

هناك خطوات إضافية مطلوبة للقراءة من جزء مقياس المغناطيسية بوحدة IMU.

من مستند PDF الخاص بتسجيلات Invesense:

التسجيلات 37 إلى 39 - I2C SLAVE 0 CONTROL

• سجل 37 - I2C_SLV0_ADDR
• التسجيل 38 - I2C_SLV0_REG
• التسجيل 39 - I2C_SLV0_CTRL