Wallace - DIY Avtomatik Robot - 5 -ci hissə - IMU əlavə edin: 9 addım

2024 Müəllif: John Day | [email protected]. Son dəyişdirildi: 2024-01-30 07:47

Wallace ilə birlikdə davam edirik. Wallace adı "Wall-E" qarışığından və əvvəlki bir layihədən (səs tanıma) gəldi və "espeak" yardım proqramından istifadə edərkən bir az ingiliscə səsləndi. Və bir vale və ya uşağa bənzəyir. Və son məqsəd budur: bu layihənin faydalı bir şeyə çevrilməsi. Beləliklə "Wallace".

Wallace hərəkət edə bilər, IR məsafə sensorlarını istifadə edərək maneələrdən qaça bilər (son vaxtlar bir şəkildə qızardılar (?) (Bir şansım olanda buna baxmalıyam), bəzi akustik məsafə sensörləri də var (onlardan üçü eyni anda pis getdi) zaman, bir MCP23017 genişləndiricisi ilə birlikdə) və nəhayət, bir şeyə çarpıldığını bilmək üçün motor cərəyanındakı dəyişiklikləri aşkar edə bilər.

Sensorlara əlavə olaraq, Wallace 100 hərəkəti "xatırlayır" və hərəkət tarixindən istifadə edərək bəzi rudimentar təhlillərə malikdir.

Wallace üçün indiyə qədərki məqsəd, sadəcə irəliləməyə çalışmaq və bəzi təkrarlanan modellərdə (məsələn, bir küncdə) ilişib qaldığınızı və həqiqətən irəliyə getmədiyinizi bilməkdir.

Hərəkət və naviqasiya üçün bir neçə dəfə təkrarlamışam və ardıcıl baş ağrısı fırlanma zamanı olmuşdur.

Wallace izlənilən bir robot olduğuna görə, proqramda (daha sonra) işlərin daha sadə olmasını istədim, onu çevirmək üçün onu yerində döndərmək/döndürmək lazımdır. Beləliklə, mühərriklərə bərabər, lakin əks güc / iş dövrü tətbiq edin.

Qarşılaşılan problem Agent 390 robot platformasının dizaynıdır. Yol kəmərləri yan tərəflərə sürtməyə meyllidir. Və daha da pisi, bir tərəf bunu digərindən daha çox edir.

Döşəmə və düz gedərkən heç bir problem olmadı. Xalçada görünür. Parçaları ləkələndikdən sonra Wallace -ı xalçadan uzaq tutmağı seçdim (kirləri çox asan yığırlar).

Döşəmə üzərində dönərkən əsl problemdir.

Proqramın yüksək səviyyəli bir iş dövrü tətbiq etməsi varsa, o zaman az -çox ardıcıl olaraq çevrilir. Bununla birlikdə, aşağı vəzifə dövrü əslində dönə bilər və ya dönə bilməz. Ya da bir az dönüb sonra yavaşlaya bilər. Dönmə hərəkəti proqram vasitəsilə idarə oluna bilməz və ya ən yaxşı halda çox çətin görünür.

Problem naviqasiya zamanı və maneələrin ətrafında və ya uzaqlaşarkən özünü göstərir. Ya çox vəhşicəsinə yellənə bilər, ya da hərəkət etmədən çox dəqiqəlik dəyişikliklər etməyə çalışaraq ilişə bilər.

Və beləliklə yuxarıdakı izahat bu Təlimatlandırmanı motivasiya etdi.

Başlanğıcda, hərəkət algılayıcı qurğunun (IMU) tətbiqindən imtina etmək və ya gecikdirmək istəyirdim, çünki onlar A) mürəkkəb, B) səs-küylü, C) səhvlər zamanla tətbiq oluna bilər və s. Uçuş zamanı IR lazer sensorlarına atlayaraq çox yaxşı işlər görə biləcəyik. Lazerlərdən istifadə edərək robotun dönüb -dönmədiyini məsafədəki dəyişiklikləri izləyərək bilə bilərdik.

Əslində, bunu da (bir növ) akustik sensorlar ilə edə bilərdik.

Ancaq bunların hamısı sadə bir suala cavab vermək üçün çox dolayı, mürəkkəb bir yoldur: "biz rotasiya etmişik, ya yox?"

Mənə elə gəlirdi ki, ToF lazer sensörlərindən istifadə etməklə tullanmaq məni proqramın növbəti səviyyəsinə aparacaq; yəni SLAM (Eşzamanlı Yerləşdirmə və Xəritəçəkmə). Hələ ora getməyə hazır deyildim.

Birinci (aşağı) təbəqələrin daha sadə, sonuncu (yuxarı) təbəqələrin isə daha mücərrəd olması və daha çətin məsələlərin həlli ilə qat -qat robot layihəsi etmək yaxşı bir işdir.

Layerlər belə bir şey haqqında düşünmək olar:

1. robotun fiziki çərçivəsi / mexaniki struktur əsası
2. əsas sürücü sistemi (Moruq, Roboclaw, mühərriklər, kabellər və s., əsas proqram, klaviatura ilə idarə olunan)
3. Sensorları dəstəkləmək üçün əsas sxemlər (iki istiqamətli gərginlik dəyişdiricisi, port genişləndiricisi, E-Stop, güc paylanması və s.)
4. maneələrdən qaçınma sensorları (akustik, IR)
5. əsas, əsas yerləşdirmə və hərəkət - aşkarlama (akselerometr, girro, maqnitometr, motor kodlayıcıları, təkər kodlayıcıları)

Öz siyahınızla gələ bilərsiniz. Bu siyahıdakı məqamlar, ehtimal ki, bunları daha çox və ya daha az ardıcıllıqla etməlisiniz və hər birini yaxşı bir iş vəziyyətinə gətirmək üçün hər bir təbəqədə bir az vaxt keçirsəniz, işlər daha mürəkkəbləşdikcə sizə kömək etməlidir.

Yuxarıdakı siyahı, bu və ya daha çox proqramdakı bu konseptual təbəqələrlə əlaqələndirilə bilər.

• SLAM (Eşzamanlı Yerləşdirmə və Xəritəçəkmə)
• Hərəkətin Nəzarəti və Məlumatı, Rotasiya
• Əsas maneələrin qarşısının alınması
• Sensor Məlumatlarına Nəzarət və Algılama
• İrəli, Geri, Sol və Sağ, Sürətləndirin, Yavaşlayın, Durun

Gördüyünüz kimi, bu siyahı üçün ilk maddələr "haradayam" və "hara gedirəm" kimi daha mücərrəd məsələləri və sualları həll edən yuxarı, daha mürəkkəb təbəqələr olardı, sonuncu maddələr isə "A sensorunu necə danışmaq/dinləmək" və ya "bu təkəri necə hərəkət etdirmək" ilə məşğul olan aşağı proqram qatları.

İndi demirəm ki, bir təbəqəyə başladığınız zaman onu tamamlayacaqsınız və sonra bir sonrakı təbəqəyə keçəcəksiniz, heç vaxt əvvəlki qatına qayıtmayın. Bir robot layihəsi müasir, təkrarlanan proqram inkişaf etdirmə üsullarına (çevik, SCRUM və s.) Bənzəyir.

Sadəcə hər birinizə vaxt ayırın deyirəm. Hər birində nə qədər edəcəyinizi balanslaşdırmalısınız və vaxta və problemə dəyər olan müəyyən bir təbəqədə nəyə cəhd etdiyinizə qərar verməlisiniz.

İki rəqabət aparan fikir və ya istiqamət arasında müəyyən bir "münaqişə" və ya "gərginlik" var.

Biri, A problemini həll etmək üçün "plug-n-play" adlandıracağım şeydir.

Digəri DIYdir (özünüz edin). Və bu başqa bir fikir üçün ən yaxşı etiket ola bilməz.

Burada hər birinin bir nümunəsi var, inşallah iki seçim arasındakı gərginliyi və ya ziddiyyəti görəcəksiniz.

Bu nümunə üçün, SLAM-ı, maneələrdən qaçınmağı və əsas əsas hərəkəti eyni anda həll etmək üçün bir problem olaraq toplayaq.

1. Plug-n-play marşrutuna getməyə qərar verəriksə, dərhal (büdcədən asılı olaraq) yuxarıya fırlanan fırlanan lazerlər, sahə dərinliyi kamerası və ya ToF lazerləri və IMU (bu mövzu) Təlimat verilə bilər).
2. Digər tərəfdən, ikinci marşruta getmək istəsək, bəzi akustik sensorlar və ya İQ sensorlarından mümkün olan hər şeyi çıxarmağa çalışa bilərik və ya heç bir sensoru yoxdur - sadəcə motor cərəyanı monitorinqindən istifadə edirik.

#1 vs #2 haqqında nə demək olar? Bir şey olardı ki, #2 edərək daha çox şey öyrənmiş olarıq. İşləmək üçün yalnız akustik sensorlara malik olmaq məhdudiyyətləri bizi daha çox məsələlər üzərində düşünməyə vadar edir.

Digər tərəfdən, #2 vasitəsi ilə işlər görməyə çox diqqət yetirsək, vaxt itirə bilərik, çünki akustik sensorlardan istədiyimizdən çox şey istəyirik.

Düşünmək lazım olan başqa bir fikir və ya fikir: Hansı aparat və proqram qarışığı "necə" suallarına ən yaxşı cavab verir və hansı proqram qarışığı (və aparat?) "Nə", "nə vaxt", "harada" suallarına cavab verir.. Çünki "necə", ümumiyyətlə "nə", "nə vaxt" və "harada" cavab almaq üçün asılı olduğu daha aşağı səviyyəli bir sualdır.

Hər halda, yuxarıda göstərilənlərin hamısı düşünmək üçün bir şey idi.

Mənim vəziyyətimdə, çox səy göstərdikdən və ardıcıl əsəbiləşdirici iz sürtünmə problemi yaşadıqdan və ardıcıl idarəetmə və hərəkət əldə edə bilmədikdən sonra başqa bir şey etmək vaxtıdır.

Belə ki, bu Təlimatlı - bir IMU.

Məqsəd odur ki, İB robotun dönmədiyini söyləsə, vəzifə dövrünü artırırıq. Çox sürətli dönsək, vəzifə dövrünü azaldarıq.

Addım 1: IMU Sensoru

Və buna görə də Wallace -ə əlavə edəcəyimiz növbəti sensör IMU'dur. Bir az araşdırmadan sonra bir MPU6050 üzərində qərarlaşdım. Ancaq sonra bu zaman MPU9050 (və hətta son zamanlarda MPU9250) daha yaxşı bir fikir kimi görünürdü.

Gedəcəyim mənbə Amazon idi (ABŞ-da). Ona görə də onlardan ikisini sifariş etdim.

Əslində əldə etdiyim şey (buna heç bir nəzarət yoxdur; Amazon haqqında bəyənmədiyim budur) iki MPU92/65 idi. Təyinatla bağlı bir az maraqlanıram. Şəkillərə baxın; bu "ailə" təyinatı kimi görünür. Hər halda, ilişib qaldığım budur.

Əlavə etmək çox sadədir -birləşdirən yolları olan bir proto lövhə alın, sensoru taxtaya lehimləyin, 10 pinli vintli terminal bloku əlavə edin (mənimkini Pololudan aldım).

Hər hansı bir müdaxiləni minimuma endirmək üçün bu sensorları hər şeydən uzaqlaşdırmağa çalışdım.

Bu da bəzi neylon boltlar/qoz -fındıq istifadə etmək demək idi.

I2C protokolundan istifadə edəcəyəm. Ümid edirik ki, ümumi tel uzunluğu çox pis olmayacaq.

Başqa yerdə əsas əlaqələr və gərginlik səviyyələri və s. Haqqında çoxlu məlumatlar var, buna görə də burada təkrarlamayacağam.

Addım 2: İşlər həmişə təmiz, asan olmur

Bu yazıda, bu xüsusi MPU-92/65 üçün İnternetdə çox şey olmadığı görünür. Əksər sensorlarda olduğu kimi, Arduino istifadə edən nümunələr də var.

Təmiz olmayan bir proses təqdim edərək bu Təlimatları bir az fərqli etməyə çalışıram, çünki işlər həmişə dərhal işləmir.

Düşünürəm ki, bu Təlimatlar bir A-B-C-dən daha çox bloqa bənzəyir, 1-2-3 "bunu belə edirsən".

Addım 3: İlkin Test

Əvvəlki addımdakı şəkillərdən, sensorlara gedən qırmızı və qara tellər təbii ki VCC (5V) və GND -dir. Yaşıl və sarı tellər I2C əlaqələridir.

Başqa I2C layihələri etmisinizsə və ya bu seriyalarla birlikdə izləmisinizsə, deməli "i2cdetect" haqqında məlumatınız var və bu, Moruqun yeni sensoru görə biləcəyini bilmək üçün ilk addımdır.

Bu addımdakı görüntülərdən də göründüyü kimi, ilk cəhdimiz uğursuz oldu. IMU görünmür (cihaz id 0x68 olmalıdır).

Ancaq yaxşı xəbər, I2C avtobusunun işlək olmasıdır. Bir cihaz 0x20 görürük və bu MCP23017 port genişləndiricisidir (hazırda HCSR04 akustik sensorlarından məsuldur).

Şəkildə görmək asan deyil, amma eyni rəngli yaşıl və sarı telləri IMU -dan MCP23017 -ə bağladım (şəklin aşağı soluna baxın)

Bir az problem həll etməliyik.

Addım 4: Problemlərin aradan qaldırılması

Bir voltmetrdə (yüksək tonlu olan) davamlılıq parametrini istifadə edərək VCC (5V), GND, SDA və SCL əlaqələrini sınadım. Bunlar yaxşıdı.

Növbəti cəhd, avtobusda yalnız MPU-92/65 buraxaraq MCP23017-ni I2C avtobusundan ayırmaq oldu. Bu nəticəsiz qaldı - "i2cdetect" sonra heç bir cihaz göstərmədi.

Beləliklə, sonra sensoru totem dirəyindən ayırdım və yenidən 5V-dan 3V-ə qədər iki istiqamətli avtobusa bağladım; yəni birbaşa Moruq. (daha qısa tellər?).

Və voila. Bu dəfə uğur var. 0x68 "i2cdetect" istifadə edərək göründüyünü görürük.

Amma bu dəfə niyə işlədiyini hələ bilmirik. Tellərin uzunluğu ola bilərmi? Əvvəlki yer?

Qeyd: ADO -nun əsaslandırılmasının heç bir fərqi yoxdur. Gəmidə çəkmə və aşağıya endirmə rezistorları ola bilər. Eyni şey FSYNC üçün də doğru ola bilər.

Sonra, MCP23017-ni yenidən bağladım. Beləliklə, indi I2C avtobusunda iki cihazımız var. (şəkilə bax). Uğurlu, indi i2cdetect ilə həm 0x20, həm də 0x68 görürük.

Videolar problemlərin aradan qaldırılması zamanı baş verənlərdən bir az daha çox bəhs edir.

Addım 5: Sensor Verilərinin Oxunması

Müxtəlif yanaşmalar

Sensordan faydalı məlumatlar əldə etmək üçün bir çox yanaşma aparmaq qərarına gəldim. Budur, heç bir qaydada deyil:

1. bəzi əsas proqramlaşdırmanı sınayın
2. Qeydlərdəki bəzi onlayn sənədlərə baxın
3. başqalarının nümunələrinə və / və ya kodlarına baxın

Niyə bu yanaşmalar? Niyə yalnız mövcud bir kitabxana və ya kod axtarmırsınız?

Təcrübə edərək və bəzi fikirləri sınayaraq, yalnız bu xüsusi sensor haqqında bəzi məlumatları daha yaxşı mənimsəyə bilərik, həm də yeni bir şeylə və çoxlu sənədləri olmayan bir şeylə məşğul olmaq üçün bəzi texnika, bacarıq və düşüncə tərzləri əldə edə bilərik; bilinməyən bir çox şey ola biləcək bir şey.

Ayrıca, öz fikirlərimizlə oynadıqdan və sınaqdan keçirdikdən və bəzi fikirlər əldə etdikdən sonra, başqasının kodunu və ya kitabxanasını qiymətləndirmək üçün daha yaxşı bir mövqedəyik.

Məsələn, githubdakı MPU9250 üçün bəzi C ++ kodlarına baxdıqdan sonra başa düşdüm ki, hələ də etmək istəmədiyim fasilələrdən istifadə etməyə məcbur edir.

Ayrıca, kalibrləmə kimi əlavə şeylərlə gəlir; yenə də, hələ maraqlanmadığım bir şey.

Ola bilsin ki, "robotun bəli və ya yox fırlanmasıdır" sadə sualına cavab vermək üçün etməli olduğum şey, sadəcə bəzi qeydləri oxuyaraq cavablandırıla bilər.

Qeydlər

Bu yazıda bu sensorda çox şey olmadığı görünür. Əslində, bu Təlimatla gələn şəkillərə baxsanız və əsl çiplərdəki yazılara yaxından baxsanız, bunun bir vuruş olmadığını düşünürəm. Gördüklərimi Invense -dən heç nə ilə əlaqələndirmirəm. Nə olursa olsun, tapdığım modellər üçün qeyd məlumatlarına baxmağı seçdim: MPU-6050 və MPU-9250.

Hər iki halda, aşağıdakılar hər ikisi üçün eynidir. Yeni başlayanlar üçün bu MPU-92/65 üçün də eyni olacağını düşünürük.

59 - 64 - akselerometr ölçmələri

65, 66 - temperaturun ölçülməsi 67 ilə 72 - jiroskopun ölçülərinin 73 ilə 96 arasında - xarici sensor məlumatları

Qeyd: MPU-6050-nin maqnitometri YOXDUR, MPU-9250-də isə (və biz də bunu hesab edirik) belə yoxdur.

Qeydiyyat sənədindən daha maraqlı, inşallah faydalı məlumatlar əldə edildi:

Maqnitometr məlumatı:

maqnitometr id: 0x48 00 -dan 09: 00 -a qədər W WIA 0 1 0 0 1 0 0 0 01H INFO INFO7 INFO6 INFO5 INFO4 INFO3 INFO2 INFO1 INFO0 02H ST1 0 0 0 0 0 0 DOR DRDY 03H HXL HX7 HX6 HX5 HX4 HX4 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 Hiz HZ HZ HZ Hz ST2 0 0 0 BITM HOFL 0 0 0 hər bir qeydin nə demək olduğunu bölüşdürmək: HXL [7: 0]: X-ox ölçü məlumatları daha aşağı 8bit HXH [15: 8]: X-ox ölçü məlumatları daha yüksək 8bit HYL [7: 0]: Y-oxu ölçmə məlumatları aşağı 8bit HYH [15: 8]: Y-ox ölçü məlumatları daha yüksək 8bit HZL [7: 0]: Z-ox ölçü məlumatları aşağı 8bit HZH [15: 8]: Z-ox ölçü məlumatları daha yüksək 8 bit

Proqramlaşdırma

Qeyd sənədlərindən başqa bir məlumat, yalnız 100 -ə yaxın qeydin olduğu görünürdü. Beləliklə, bir taktika, cihaza daxil olan (0x68) sadə bir proqram yazmaq və hansı məlumatların görülə biləcəyini görmək üçün mənasını nəzərə almadan bir sıra qeydləri ardıcıl olaraq oxumağa çalışmaq ola bilər.

Və sonra eyni kodu istifadə edərək ardıcıl keçidlər edin və məlumatları bir keçiddən digərinə müqayisə edin.

Fikir, ehtimal ki, heç bir məlumatı olmayan (sıfır və ya FF?) Və ya heç vaxt dəyişməyən hər hansı bir qeydiyyatı ləğv edə bilərik və dəyişiklik edənlərə də diqqət yetirə bilərik.

Sonra, yalnız dəyişənləri nəzərdən keçirdiyimiz biri, bu qeydin son N oxunuşunu ortalayan bir ortalama funksiyasını əlavə edərək, əslində bu qeyd üçün sabit bir dəyərin olub olmadığını öyrənməkdir. Bu, sensoru çox hərəkətsiz və eyni yerdə saxladığımızı güman edir.

Nəhayət, daha sonra sensoru itələmək (akselerometr, girro) və ya üzərinə üfürmək (temperatur) və ya fırlatmaq (əvvəlki iki artı maqnitometr) kimi şeyləri yumşaq bir şəkildə sınaya bilərik və bunun dəyərlərə necə təsir etdiyini görə bilərik.

Mümkün qədər wiringPi kitabxanasından istifadə etməyi sevirəm. I2C dəstəyi var.

İlk qaçış:

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

* qurmaq üçün: gcc first.test.mpu9265.c -o first.test.mpu9265 -lwiringPi * * çalıştırmak üçün: sudo./first.test.mpu9265 * * bu proqram yalnız MCP23017 -dən bir sıra (mümkün) qeydlər buraxır., * və sonra MPU9265 -dən (və ya 0x68 ünvanındakı hər hansı digər MPU -dan) * * MCP23017 -ə güvəndiyim üçün sensordan oxuya bilsəm belə doğrulamaq üçün istifadə etdim. ************************************************ ****************************/ #include #include #include #include #include int main (int argc, char ** argv) {qoyur ("MCP23017 @ 0x20 nə deyəcəyini görək:"); errno = 0; int deviceId1 = 0x20; int fd1 = wiringPiI2CSetup (deviceId1); if (-1 == fd1) {fprintf (stderr, "WiringPi I2C cihazını açmaq mümkün deyil: %s / n", strerror (səhv))); qayıt 1; } üçün (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d", wiringPiI2CReadReg8 (fd1, reg)); fflush (stderr); gecikmə (10); } qoyur (""); qoyur ("Gəlin MPU9265 @ 0x20 nə deyəcəyini görək:"); errno = 0; int deviceId2 = 0x68; int fd2 = wiringPiI2CSetup (deviceId2); if (-1 == fd2) {fprintf (stderr, "WiringPi I2C cihazı açıla bilmir: %s / n", strerror (səhv))); qayıt 1; } üçün (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d", wiringPiI2CReadReg8 (fd2, reg)); fflush (stderr); gecikmə (10); } qoyur (""); qaytarma 0; }

İkinci qaçış:

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

* qurmaq üçün: gcc second.test.mpu9265.c -o second.test.mpu9265 -lwiringPi * * çalıştırmak üçün: sudo./second.test.mpu9265 * * Bu proqram oxunan dəyərin yanında qeyd nömrəsini çıxarır. * * Bu, çıxışı bir fayla yönləndirməyi (yönləndirməyi) və sonra müqayisə etmək üçün * bir neçə dəfə edilə bilər. Hansı reyestrin vacib olduğu və məlumatların necə davranacağı haqqında bir az fikir verə bilər. ************************************************ ****************************/ #include #include #include #include #include #include int main (int argc, char **) argv) {int deviceId = -1; if (0) {} başqa if (! strncmp (argv [1], "0x20", strlen ("0x20"))) {deviceId = 0x20; } başqa halda (! strncmp (argv [1], "0x68", strlen ("0x68"))) {deviceId = 0x68; } başqa əgər (! strncmp (argv [1], "0x69", strlen ("0x69"))) {deviceId = 0x69; } qoyur ("Gəlin MPU9265 @ 0x20 nə deyəcəyini görək:"); errno = 0; int fd = wiringPiI2CSetup (deviceId); if (-1 == fd) {fprintf (stderr, "WiringPi I2C cihazını açmaq mümkün deyil: %s / n", strerror (səhv))); qayıt 1; } üçün (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); gecikmə (10); } 0 qaytar; }

Üçüncü qaçış:

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

* qurmaq: gcc üçüncü.test.mpu9265.c -o üçüncü.test.mpu9265 -lwiringPi * * çalıştırmak üçün: sudo./third.test.mpu9265 * * Bu proqram ikincisinin nəticəsidir. Yalnız * bir qeydlə digərindən bir fərqi göstərən qeydlərdən oxunur.************************************************ ****************************/ #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; } başqa əgər (! strncmp (argv [1], "0x69", strlen ("0x69"))) {deviceId = 0x69; } qoyur ("Gəlin MPU9265 @ 0x20 nə deyəcəyini görək:"); errno = 0; int fd = wiringPiI2CSetup (deviceId); if (-1 == fd) {fprintf (stderr, "WiringPi I2C cihazını açmaq mümkün deyil: %s / n", strerror (səhv))); qayıt 1; } üçün (int reg = 61; reg <= 73; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); gecikmə (10); } üçün (int reg = 111; reg <= 112; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); gecikmə (10); } üçün (int reg = 189; reg <= 201; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); gecikmə (10); } üçün (int reg = 239; reg <= 240; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); gecikmə (10); } 0 qaytar; }

Bəs indiyə qədər nə öyrəndik? Rəngli vurgulanmış sahələri olan cədvəlin görüntüsü, çıxışın ilk qeyd dəstlərinə uyğun gəldiyini göstərir.

İndiyə qədərki nəticələr yeni suallar yarada bilər.

Sual: niyə "xarici" qrup üçün yalnız bir qeyd nəticəsi var?

Sual: bilinməyən bütün qeydlər nədir? "??????"

Sual: Proqram fasilələrlə idarə olunmadığı üçün çox yavaş məlumat istədi? çox sürətli?

Sual: işləyərkən sensorun özü ilə hər şeyi sınayaraq nəticələrə təsir edə bilərikmi?

Addım 6: Gəlin oxunuşlara / məlumatlara daha çox nəzər salaq

Düşünürəm ki, hər şeydən əvvəl növbəti addım proqramı təkmilləşdirməkdir:

• nə qədər loop gecikməsində çevik olun (ms)
• hər bir qeyd başına işləyən orta hesab vermək üçün neçə oxunuşda çevik olun

(Proqramı bir fayl olaraq əlavə etməli idim. Buraya daxil etməkdə problem olduğu görünürdü. "4th.test.mpu9265.c")

Budur, son 10 oxunuşu orta hesabla 10 ms döngədə istifadə edərək:

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

İlk, ən sol sütun qeyd nömrəsidir. Sonra həmin reyestr üçün son 10 oxunuş gəlir. Nəhayət, son sütun hər bir satır üçün ortalamadır.

61, 69, 71, 189, 197 və 199 qeydləri ya ikili, ya da hazır / hazır deyil və ya 16 bitlik dəyərin yüksək baytına bənzəyir (mənfi?).

Digər maraqlı müşahidələr:

• qeydiyyat 65, 193 - çox sabit və eyni dəyər
• qeydiyyat 63, 191 - çox sabit və eyni dəyər
• qeydlər 73, 112, 195, 201, 240 - hamısı sıfırdadır

Bu müşahidələri əvvəlki çox rəngli, vurgulanmış masa görüntüsü ilə əlaqələndirək.

Qeydiyyat 65 - temperatur

Qeydiyyat 193 - ??????

Qeydiyyat 63 - akselerometr

Qeydiyyat 191 - ??????

Qeydiyyat 73 - xarici

112 və daha sonra qeydiyyatdan keçin - ??????

Hələ bilinməyənlərimiz var, amma faydalı bir şey öyrəndik.

Qeyd 65 (temperatur) və qeyd 63 (akselerometr) hər ikisi çox sabit idi. Bu gözlədiyimiz bir şeydir. Sensora toxunmadım; Robot mənim kompüterimlə eyni masada oturduğu üçün təsadüfi titrəmələrdən başqa hərəkət etmir.

Bu temperatur/akselerometr qeydlərinin hər biri üçün edə biləcəyimiz bir maraqlı test var. Bu test üçün proqramın başqa bir versiyasına ehtiyacımız var.

Addım 7: Temperatur və Sürətlənməni təsir edə bilərik

Əvvəlki addımlarda ən az bir temperatur və bir sürətlənmə qeydini daraltmışdıq.

Proqramın bu növbəti versiyası ilə ("5th.test.mpu9265.c"), əslində hər iki qeyd üçün bir dəyişiklik olduğunu görə bilərik. Zəhmət olmasa videolara baxın.

Daha çox qazma

Geri qayıdıb reyestr məlumatlarına nəzər salsaq görərik:

• jiroskop üçün üç 16 bitlik çıxış
• akselerometr üçün üç 16 bitlik çıxış
• maqnitometr üçün üç 16 bitlik çıxış
• temperatur üçün bir 16 bitlik çıxış

Ancaq sadə test proqramlarımızın əldə etdiyi nəticələrin hamısı tək 8 bitlik nəticələr idi. (tək qeydlər).

Eyni yanaşmanı daha çox sınayaq, amma bu dəfə 8 yox, 16 bit oxuyaq.

Yəqin ki, aşağıda olduğu kimi bir şey etməli olacağıq. Nümunə olaraq temperaturdan istifadə edək, çünki bu yalnız 16 bitlik bir çıxışdır.

// fayl təsviri fd əldə edin …

int tempRegHi = 65; int tempRegLo = 66; int hiByte = wiringPiI2CReadReg8 (fd, tempRegHi); int loByte = wiringPiI2CReadReg8 (fd, tempRegLo); int nəticə = hiByte << 8; // 16 bitlik dəyər nəticəsinin yuxarı hissəsinə 8 bit qoyun | = loByte; // indi tam 16 bitlik bir rəqəm verən 8 bit əlavə edin.

Əvvəlki addımlarımızdan gördük ki, qeydiyyat 65 olduqca qaya dayanıqlıdır, qeydiyyat 66 isə çox səs -küylüdür. 65 yüksək sifariş baytı, 66 aşağı sıralı bayt olduğu üçün bu məntiqlidir.

Oxumaq üçün, qeydiyyat 65-in məlumatlarını olduğu kimi götürə bilərik, ancaq reyestr 66-nın dəyərlərini orta hesabla çıxara bilərik.

Və ya bütün nəticəni orta hesabla hesablaya bilərik.

Bu hissə üçün son videoya baxın; bütün 16 bit temperatur dəyərinin oxunmasını nümayiş etdirir. Kod "altıncı.test.mpu9265.c" dir

Addım 8: Akselerometr və Giroskop

Bu hissədəki videolar "yeddinci.test.mpu9265.c" test proqramından istifadə edərək akselerometr və giroskopdan çıxışı göstərir. Bu kod 1, 2 və ya 3 ardıcıl bayt cütünü (hi və lo bayt) oxuya bilər və dəyərləri vahid 16 bit dəyərinə çevirir. Beləliklə, hər hansı bir oxu oxuya bilərik və ya ikisini birlikdə oxuya bilərik (və dəyişiklikləri ümumiləşdirir) və ya hər üçünü oxuya bilərik (və dəyişiklikləri ümumiləşdirir).

Bir daha demək istəyirəm ki, bu mərhələ üçün, bu Təlimatlandırıcı üçün, sadəcə olaraq, bir sadə suala cavab axtarıram: "robot döndü/döndü?". 90 dərəcə döndüyü kimi dəqiq bir dəyər axtarmıram. SLAM etməyə başladıqda bu daha sonra gələcək, ancaq sadə maneələrdən qaçınmaq və təsadüfi hərəkətlər üçün bu lazım deyil.

Addım 9: (iş gedir) Maqnitometr

i2cdetect alətindən istifadə edərkən MPU9265 cədvəldə 0x68 olaraq göstərilir:

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 -nun magnetometr hissəsindən oxumaq üçün əlavə addımlar lazımdır.

PDF doc Invesense qeydlərindən:

QEYDİYYATÇILAR 37-39 - I2C SLAVE 0 NƏZARƏT

• QEYDİYYAT 37 - I2C_SLV0_ADDR
• QEYDİYYAT 38 - I2C_SLV0_REG
• QEYDİYYAT 39 - I2C_SLV0_CTRL