Wallace - DIY autonómny robot - časť 5 - Pridajte IMU: 9 krokov

2025 Autor: John Day | [email protected]. Naposledy zmenené: 2025-01-13 06:58

Pokračujeme spolu s Wallaceom. Názov Wallace pochádza z mixu „Wall-E“a z predchádzajúceho projektu (rozpoznávanie hlasu) a pri použití pomôcky „espeak“to znelo trochu britsky. A ako komorník alebo komorník. A to je konečný cieľ: aby sa tento projekt zmenil na niečo užitočné. Teda „Wallace“.

Wallace sa môže pohybovať, dokáže sa vyhýbať prekážkam pomocou infračervených senzorov vzdialenosti (nedávno sa nejako vyprážali (?) (Musia sa na to pozrieť, keď mám šancu)), má tiež niekoľko akustických senzorov vzdialenosti (tri z nich sa pokazili súčasne čas, spolu s expandérom MCP23017) a nakoniec dokáže zistiť zmeny v prúde motora, aby vedel, kedy je do niečoho narazený.

Okrem senzorov si Wallace „pamätá“100 pohybov a má aj základnú analýzu pomocou histórie pohybov.

Cieľom pre Wallaceho je zatiaľ len snažiť sa ísť stále dopredu a vedieť, kedy je zaseknutý v nejakom opakujúcom sa vzore (napríklad v rohu) a v skutočnosti sa nepohne dopredu.

Prešiel som niekoľkými iteráciami pohybu a navigácie a pri otáčaní sa neustále vyskytovala bolesť hlavy.

Keďže Wallace je sledovaný robot a chcel som, aby to v softvéri bolo jednoduchšie (na neskôr), aby som sa mohol otočiť, nechal som ho otočiť/otočiť na mieste. Na motory teda aplikujte rovnaký, ale opačný výkon / pracovný cyklus.

Vyskytnutý problém je spôsobený konštrukciou platformy robota Agent 390. Pásy dráhy majú tendenciu sa trieť o boky. A čo je horšie, jedna strana to robí viac ako druhá.

Na podlahe a rovnej ceste to nebol problém. Ukazuje sa to na koberci. Rozhodol som sa udržať Wallace mimo koberca, potom, čo sa jeho stopy stanú špinavými (veľmi ľahko zachytávajú špinu).

Skutočný problém je pri otáčaní na podlahe.

Ak nechám softvér použiť vysoký pracovný cyklus, potom sa viac -menej dôsledne otáča. Počas cyklu nízkeho zaťaženia sa však môže, ale nemusí, skutočne otočiť. Alebo sa môže na chvíľu otočiť a potom spomaliť. Zdá sa, že otočná akcia je prostredníctvom softvéru nekontrolovateľná alebo prinajlepšom veľmi ťažká.

Problém sa prejavuje počas navigácie a pri pohybe okolo prekážok alebo mimo nich. Buď sa môže príliš divoko rozhojdať, alebo sa môže zaseknúť pri pokuse o veľmi malé posuny bez toho, aby sa skutočne dokonca hýbal.

A tak vyššie uvedené vysvetlenie motivovalo tento Instructable.

Pôvodne som chcel upustiť od zavedenia jednotky snímania pohybu (IMU) alebo ju odložiť, pretože sú A) komplikované, B) hlučné, C) chyby sa môžu časom zavádzať atď. Atď. Moja myšlienka bola bolo to, že by sme sa mohli veľmi dobre preskočiť na infračervené laserové senzory v čase letu. A mohli by sme - pomocou laserov by sme mohli sledovať, či sa robot otáča alebo nie, sledovaním zmien vzdialenosti.

V skutočnosti by sme to mohli (trochu) urobiť aj teraz, s akustickými senzormi.

To všetko je však veľmi nepriamy a komplikovaný spôsob odpovede na jednu jednoduchú otázku: „Otočili sme sa alebo nie?“

Zdalo sa mi, že skokom na laserové senzory ToF sa dostanem na ďalšiu úroveň softvéru; menovite SLAM (simultánna lokalizácia a mapovanie). Ešte som nebol pripravený ísť tam.

Je dobré robiť projekt robota vo vrstvách, pričom prvá (dolná) vrstva je jednoduchšia a druhá (horná) vrstva je abstraktnejšia a rieši náročnejšie problémy.

Vrstvy môžu byť myslené takto:

1. fyzický rám robota / mechanický konštrukčný základ
2. základný pohonný systém (Raspberry, Roboclaw, motory, kabeláž atď., Základný softvér, ovládaný klávesnicou)
3. nevyhnutné obvody na podporu senzorov (obojsmerný menič napätia, expandér portov, E-Stop, distribúcia energie atď.)
4. snímače vyhýbania sa prekážkam (akustické, IR)
5. základné, základné polohovanie a pohyb - detekcia (akcelerometer, gyroskop, magnetometer, enkodéry motora, enkodéry kolies)

Môžete si vytvoriť vlastný zoznam. Body v tomto zozname sú, že by ste ich pravdepodobne mali robiť viac -menej v uvedenom poradí a tiež to, že ak v každej vrstve strávite nejaký čas, aby ste každú dostali do dobrého pracovného stavu, malo by vám to pomôcť neskôr, keď sa veci skomplikujú.

Vyššie uvedený zoznam by mohol byť viac -menej mapovaný na tieto koncepčné vrstvy v softvéri.

• SLAM (simultánna lokalizácia a mapovanie)
• Kontrola a povedomie o pohybe, rotácia
• Základné vyhýbanie sa prekážkam
• Riadenie a detekcia údajov zo senzorov
• Zásadný pohyb vpred, vzad, vľavo a vpravo, zrýchlenie, spomalenie, zastavenie

Ako vidíte, pre tento zoznam by prvými položkami boli horné, komplikovanejšie vrstvy, ktoré sa zaoberajú abstraktnejšími problémami a otázkami, ako napríklad „kde som“a „kam idem“, zatiaľ čo posledné položky by boli nižšie softvérové vrstvy, ktoré zvládajú „ako hovoriť/počúvať senzor A“alebo „ako pohnúť týmto kolieskom“.

Teraz nehovorím, že keď začnete na vrstve, dokončíte ju a potom je na ďalšej vrstve, nikdy sa už nevrátite k predchádzajúcej. Projekt robota sa môže veľmi podobať moderným, iteračným metódam vývoja softvéru (agilný, SCRUM atď.).

Len hovorím, aby som si na každého urobil čas. Budete musieť vyvážiť, koľko musíte v každom z nich urobiť, a rozhodnúť sa, o čo sa v určitej vrstve pokúšate, čo stojí za čas a problémy.

Medzi dvoma navzájom si konkurujúcimi myšlienkami alebo smermi existuje určitý „konflikt“alebo „napätie“.

Jedným z nich je to, čo by som nazval „plug-n-play“na vyriešenie problému A.

Ten druhý je DIY (urobte to sami). A to nemusí byť ani najlepšie označenie pre tento ďalší nápad.

Tu je príklad každého z nich, dúfajme, že uvidíte napätie alebo konflikt medzi týmito dvoma možnosťami.

V tomto prípade spojme SLAM, vyhýbanie sa prekážkam a základný základný pohyb ako jeden problém, ktorý je potrebné súčasne vyriešiť.

1. Ak sa rozhodneme ísť cestou plug-n-play, okamžite skočíme (v závislosti od rozpočtu) na veci, ako sú rotačné lasery namontované na vrchu alebo kamera s hĺbkou ostrosti alebo lasery ToF a IMU (téma tejto Inštruovateľné).
2. Ak by sme naopak chceli ísť druhou cestou, môžeme sa pokúsiť extrahovať všetky možné informácie z niektorých akustických senzorov alebo IR senzorov, alebo žiadnych senzorov vôbec - použijeme iba monitorovanie prúdu motora (náraz)

Čo možno povedať o č. 1 proti č. 2? Jedna vec by bola, že cvičením č. 2 sa naučíme oveľa viac. Obmedzenia práce iba s akustickými senzormi nás nútia premýšľať o oveľa viac problémoch.

Na druhej strane, ak sa príliš sústredíme na robenie vecí prostredníctvom č. 2, možno mrháme časom, pretože od akustických senzorov požadujeme viac, ako by sme mali.

Ešte jeden koncept alebo myšlienka na zamyslenie: Aká zmes hardvéru a softvéru najlepšie odpovedá na otázky „ako“a aká kombinácia softvéru (a hardvéru?) Odpovedá na otázku „čo“, „kedy“, „kde“. Pretože „ako“je zvyčajne otázka nižšej úrovne, od ktorej závisí „čo“, „kedy“a „kde“, aby sa získala odpoveď.

Každopádne, všetky vyššie uvedené skutočnosti boli len na zamyslenie.

V mojom prípade, po veľkom úsilí a neustálom nepríjemnom probléme trenia na trati a neschopnosti získať konzistentnú kontrolu a pohyb, je načase urobiť niečo iné.

Preto je tento návod - IMU.

Cieľom je, aby ak IMU hovorí, že sa robot NEROTÁ, zvýšime pracovný cyklus. Ak sa otáčame príliš rýchlo, znížime pracovný cyklus.

Krok 1: Senzor IMU

A tak naším ďalším senzorom, ktorý by sme k Wallaceovi mali pridať, je IMU. Po troche výskumu som sa usadil na MPU6050. Potom však v tejto dobe MPU9050 (a ešte nedávno MPU9250) vyzeral ako ešte lepší nápad.

Mojím zdrojom je Amazon (v USA). Objednal som si teda dva z nich.

V skutočnosti som dostal (zdá sa, že nad tým nie je žiadna kontrola; to sa mi na Amazone nepáči) dva MPU92/65. Trochu sa čudujem nad označením. Pozrite sa na obrázky; zdá sa, že ide o označenie „rodiny“. V každom prípade sa toho držím.

Pridanie je veľmi jednoduché -získajte proto dosku s prepojovacími dráhami, spájkujte snímač na dosku, pridajte 10 -pólovú skrutkovaciu svorkovnicu (moju som dostal od Pololu).

Aby som minimalizoval akékoľvek rušenie, pokúsil som sa umiestniť tieto senzory mimo všetko ostatné.

To tiež znamenalo použitie niektorých nylonových skrutiek/matíc.

Budem používať protokol I2C. Našťastie celková dĺžka drôtu nebude taká zlá.

Na iných miestach je veľa informácií o základných spojeniach a úrovniach napätia atď., Preto to tu nebudem opakovať.

Krok 2: Veci nie sú vždy čisté, jednoduché

Pri tomto písaní sa zdá, že pre tento konkrétny MPU-92/65 nie je veľa online. To, čo je k dispozícii, rovnako ako u väčšiny senzorov, sa zdá byť príkladom používania Arduina.

Snažím sa tieto inštrukcie trochu odlíšiť predstavením nie práve čistého postupu, pretože veci nefungujú vždy hneď.

Domnievam sa, že tieto pokyny sú viac podobné blogu ako rovine A-B-C, 1-2-3 „takto sa to robí“.

Krok 3: Počiatočný test

Na obrázkoch v predchádzajúcom kroku sú červené a čierne vodiče k senzorom samozrejme VCC (5V) a GND. Zelený a žltý vodič sú pripojenia I2C.

Ak ste robili ďalšie projekty I2C alebo ste sa riadili týmito radami, potom už viete o „i2cdetect“, a to je prvý krok k poznaniu, či Raspberry vidí nový senzor.

Ako vidíte na obrázkoch v tomto kroku, náš prvý pokus bol neúspešný. IMU sa nezobrazí (malo by ísť o ID zariadenia 0x68).

Dobrou správou však je, že autobus I2C funguje. Vidíme jedno zariadenie 0x20 a je to expandér portov MCP23017 (v súčasnosti je zodpovedný za akustické snímače HCSR04).

Na obrázku to nie je ľahké vidieť, ale zapojil som rovnako farebné zelené a žlté vodiče z IMU do MCP23017 (pozri obrázok vľavo dole na obrázku)

Budeme musieť urobiť nejaké riešenie problémov.

Krok 4: Riešenie problémov

Použitím nastavenia kontinuity na voltmetri (ten s vysokým tónom) som testoval pripojenia VCC (5V), GND, SDA a SCL. To boli dobré.

Ďalším pokusom bolo odpojenie MCP23017 od zbernice I2C, pričom na zbernici zostal iba MPU-92/65. To sa ukázalo ako zbytočné - „i2cdetect“potom neukázal žiadne zariadenia.

Ďalej som teda odpojil snímač od totemu a znova ho zapojil priamo do obojsmernej zbernice 5 V až 3 V; tj. priamo na Malinu. (kratšie vodiče?).

A voila. Tentoraz je úspech. Vidíme, že 0x68 sa zobrazuje pomocou „i2cdetect“.

Zatiaľ však nevieme, prečo to tentoraz fungovalo. Mohla by to byť dĺžka drôtov? Predchádzajúce miesto?

Poznámka: Nezáleží na tom, či je ADO uzemnený alebo nie. Je možné, že na palube sú výsuvné a sťahovacie odpory. To isté môže platiť pre FSYNC.

Potom som znova pripojil MCP23017. Teraz teda máme na zbernici I2C dve zariadenia. (viď obrázok). Úspešné, teraz vidíme ixc aj 0x68 s i2cdetect.

Videá prinášajú trochu viac informácií o tom, čo sa stalo počas riešenia problémov.

Krok 5: Čítanie údajov senzora

Rôzne prístupy

Rozhodol som sa použiť niekoľko prístupov k získaniu užitočných informácií zo senzora. Tu sú, nie v žiadnom poradí:

1. Skúste základné programovanie
2. prezrite si online dokumentáciu k registrom
3. pozrite sa na príklady a / alebo kódy ostatných

Prečo tieto prístupy? Prečo nehľadať existujúcu knižnicu alebo kód?

Experimentovaním a skúšaním niektorých myšlienok dokážeme lepšie vstrebať niektoré znalosti nielen o tomto konkrétnom senzore, ale tiež získame určitú techniku, zručnosť a spôsoby uvažovania o riešení niečoho nového a niečoho, čo nemusí mať veľa dokumentácie; niečo, čo môže mať veľa neznámych.

Tiež, keď sme sa pohrali a vyskúšali niektoré z našich vlastných myšlienok a získali sme nejaký prehľad, máme lepšiu pozíciu na vyhodnotenie kódu alebo knižnice niekoho iného.

Napríklad po pohľade na nejaký kód C ++ pre MPU9250 v github som si uvedomil, že ma to núti používať prerušenia, čo sa mi zatiaľ nechce.

Tiež prichádza s ďalšími vecami, ako je kalibrácia; opäť niečo, čo ma ešte nezaujíma.

Je možné, že na to, aby som odpovedal na jednoduchú otázku „robot sa otáča áno alebo nie“, bolo možné veľmi jednoducho odpovedať prečítaním niektorých registrov.

Registre

Pri tomto písaní sa zdá, že na tomto senzore nie je veľa k dispozícii. V skutočnosti, keď sa pozriete na obrázky, ktoré sú dodávané s týmto Instructable, a pozriete sa zblízka na nápisy na skutočných čipoch, začne ma zaujímať, či to nie je knock-off. Nič, čo vidím, nespájam s Invense. Bez ohľadu na to som sa rozhodol pozrieť sa na informácie o registroch modelov, ktoré som našiel: MPU-6050 a MPU-9250.

V oboch prípadoch je nasledujúci pre oba rovnaké. A na začiatok predpokladáme, že to bude rovnaké aj pre tento MPU-92/65.

59 až 64 - merania akcelerometra

65, 66 - merania teploty 67 až 72 - merania gyroskopu 73 až 96 - údaje externého senzora

Poznámka: Zdá sa, že MPU-6050 NEMÁ magnetometer, zatiaľ čo MPU-9250 (a predpokladáme, že aj tento) ho nemá.

Niektoré ďalšie zaujímavé, dúfajme, že užitočné informácie, získané z registračného dokumentu:

Informácie o magnetometri:

magnetometer id: 0x48 registre 00 až 09: 00H 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 HX3 HX2 HX1 HX0 HXH HX14 HX1 HZZ ST2 0 0 0 BITM HOFL 0 0 0 rozpis toho, čo každý register znamená: HXL [7: 0]: namerané údaje osi X nižšie 8 bitov HXH [15: 8]: údaje merania osi X vyššie 8 bitov HYL [7: 0]: Údaje merania osi Y nižšie 8 bitov HYH [15: 8]: údaje merania osi Y vyššie 8 bitov HZL [7: 0]: údaje merania osi Z nižšie 8 bitov HZH [15: 8]: údaje merania osi Z vyššie 8 bitov

Programovanie

Jedna ďalšia informácia z dokumentov registrov je, že sa zdalo, že existuje len asi 100 registrov. Jednou z taktík by teda mohlo byť napísať jednoduchý program, ktorý pristúpi k zariadeniu (0x68) a pokúsi sa sekvenčne prečítať sériu registrov bez ohľadu na ich význam, aby zistil, aké údaje je možné vidieť.

A potom urobte postupné prechádzania pomocou rovnakého kódu a porovnajte údaje z jedného priechodu s druhým.

Ide o to, že by sme pravdepodobne mohli odstrániť všetky registre, ktoré zdanlivo neobsahujú žiadne údaje (nuly alebo FF?) Alebo ktoré sa absolútne nikdy nezmenia, a mohli by sme sa zamerať aj na tie, ktoré sa menia.

Potom sa pozeráme len na tie, ktoré sa menia, pridajte priemerovaciu funkciu, ktorá spriemeruje posledné N čítania tohto registra, aby ste zistili, či v skutočnosti pre tento register existuje určitá ustálená hodnota. To by predpokladalo, že udržujeme snímač veľmi nehybný a na rovnakom mieste.

Nakoniec by sme potom mohli jemne vyskúšať veci so senzorom, ako napríklad šťuchnutie do neho (akcelerometer, gyroskop), alebo naň fúkanie (teplota) alebo otáčanie (predchádzajúce dva plus magnetometer) a uvidíme, aký vplyv to má na hodnoty.

Rád používam knižnicu wiringPi čo najviac. Má podporu pre I2C.

Prvé spustenie:

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

* na zostavenie: gcc first.test.mpu9265.c -o first.test.mpu9265 -lwiringPi * * na spustenie: sudo./first.test.mpu9265 * * * z MCP23017 tento program vygeneruje iba rozsah (možných) registrov, * a potom z MPU9265 (alebo akéhokoľvek iného MPU na tej adrese 0x68) * * Použil som to na overenie, či môžem dokonca čítať zo senzora, pretože som už * dôveroval MCP23017. ****************************************** … ***************************************************************************************************** {put („Pozrime sa, čo má povedať MCP23017 @ 0x20:“); chyba = 0; int deviceId1 = 0x20; int fd1 = wiringPiI2CSetup (deviceId1); if (-1 == fd1) {fprintf (stderr, "Can't open wiringPi I2C device: %s / n", strerror (errno)); návrat 1; } for (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d", wiringPiI2CReadReg8 (fd1, reg)); fflush (stderr); oneskorenie (10); } put (""); put („Pozrime sa, čo hovorí MPU9265 @ 0x20:“); chyba = 0; int deviceId2 = 0x68; int fd2 = wiringPiI2CSetup (deviceId2); if (-1 == fd2) {fprintf (stderr, "Can't open wiringPi I2C device: %s / n", strerror (errno)); návrat 1; } for (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d", wiringPiI2CReadReg8 (fd2, reg)); fflush (stderr); oneskorenie (10); } put (""); návrat 0; }

Druhý beh:

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

* na zostavenie: gcc second.test.mpu9265.c -o second.test.mpu9265 -lwiringPi * * na spustenie: sudo./second.test.mpu9265 * * Tento program vydá číslo registra vedľa hodnoty čítanej. * * Vďaka tomu je užitočné presmerovať (presmerovať) výstup do súboru a potom * je možné vykonať niekoľko cyklov na porovnanie. Mohlo by to poskytnúť určitý prehľad o tom, * ktorý register je dôležitý a ako sa údaje môžu správať. ***************************************** … ******************************************************************************** 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; }} ("Pozrime sa, čo hovorí MPU9265 @ 0x20:"); chyba = 0; int fd = wiringPiI2CSetup (deviceId); if (-1 == fd) {fprintf (stderr, "Can't open wiringPi I2C device: %s / n", strerror (errno)); návrat 1; } for (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); oneskorenie (10); } vrátiť 0; }

Tretí beh:

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

* postaviť: gcc third.test.mpu9265.c -o third.test.mpu9265 -lwiringPi * * spustiť: sudo./third.test.mpu9265 * * Tento program je výsledkom druhého. Číta iba z registrov *, ktoré naznačujú rozdiel medzi jedným a druhým behom.***************************************** … ******************************************************************************** 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; }} ("Pozrime sa, čo hovorí MPU9265 @ 0x20:"); chyba = 0; int fd = wiringPiI2CSetup (deviceId); if (-1 == fd) {fprintf (stderr, "Can't open wiringPi I2C device: %s / n", strerror (errno)); návrat 1; } for (int reg = 61; reg <= 73; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); oneskorenie (10); } for (int reg = 111; reg <= 112; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); oneskorenie (10); } for (int reg = 189; reg <= 201; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); oneskorenie (10); } for (int reg = 239; reg <= 240; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); oneskorenie (10); } vrátiť 0; }

Čo sme sa teda doteraz dozvedeli? Obrázok tabuľky s farebne zvýraznenými oblasťami naznačuje, že sa zdá, že výstup zodpovedá prvým množinám registrov.

Doterajšie výsledky môžu generovať nové otázky.

Otázka: Prečo je pre „externú“skupinu iba jeden výsledok registrácie?

Otázka: Čo sú to všetky tie neznáme registre "??????"

Otázka: Pretože program nie je riadený prerušením, vyžiadal si údaje príliš pomaly? prirýchlo?

Otázka: Môžeme ovplyvniť výsledky skúšaním vecí so samotným senzorom, ktorý beží?

Krok 6: Poďme sa ponoriť do čítaní / údajov

Myslím si, že ďalším krokom pred čímkoľvek iným je vylepšiť program tak, aby:

• byť flexibilný v tom, koľko oneskorenia slučky (ms)
• byť flexibilný v tom, koľko odpočtov poskytne priebežný priemer na register

(Program som musel priložiť ako súbor. Zdá sa, že je problém ho vložiť sem. „4th.test.mpu9265.c“)

Tu je beh, pri ktorom sa v priemere použije 10 posledných meraní pri 10 ms slučke:

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

Prvý stĺpec úplne vľavo je číslo registra. Potom príde posledných 10 čítaní pre tento register. Nakoniec posledný stĺpec predstavuje priemer pre každý riadok.

Vyzerá to, že registre 61, 69, 71, 189, 197 a 199 sú buď iba binárne, alebo pripravené / nepripravené, alebo sú vysokým bajtom 16-bitovej hodnoty (záporné?).

Ďalšie zaujímavé postrehy:

• registre 65, 193 - veľmi stabilná a rovnaká hodnota
• register 63, 191 - veľmi stabilná a rovnaká hodnota
• registre 73, 112, 195, 201, 240 - všetko na nule

Vráťme tieto pozorovania späť k viacfarebnému, zvýraznenému tabuľkovému obrázku z predchádzajúceho obdobia.

Register 65 - teplota

Zaregistrovať sa 193 - ??????

Zaregistrujte sa 63 - akcelerometer

Zaregistrovať sa 191 - ??????

Register 73 - externý

Zaregistrujte sa na čísle 112 a ďalej - ??????

Stále máme neznáme, napriek tomu sme sa naučili niečo užitočné.

Register 65 (teplota) a register 63 (akcelerometer) boli veľmi stabilné. To je niečo, čo by sme očakávali. Nedotkol som sa senzora; nehýbe sa, okrem náhodných vibrácií, pretože robot spočíva na rovnakom stole ako môj počítač.

Pre každý z týchto registrov teploty/akcelerometra existuje jeden zaujímavý test. Na tento test potrebujeme ešte jednu verziu programu.

Krok 7: Sme schopní ovplyvniť teplotu a zrýchlenie

V predchádzajúcich krokoch sme zúžili najmenej jeden register pre teplotu a jeden pre zrýchlenie.

S touto ďalšou verziou programu ("5th.test.mpu9265.c") skutočne vidíme, že pre oba registre dochádza k zmene. Pozrite si videá.

Viac kopať

Ak sa vrátime a pozrieme sa na informácie z registra, zistíme, že existujú:

• tri 16 -bitové výstupy pre gyroskop
• tri 16 -bitové výstupy pre akcelerometer
• tri 16 -bitové výstupy pre magnetometer
• jeden 16 bitový výstup pre teplotu

Výsledky získané našimi jednoduchými testovacími programami však boli všetky jednotlivé 8 -bitové výstupy. (jednotlivé registre).

Skúsme teda použiť viac rovnakého prístupu, ale tentokrát čítajte 16 bitov namiesto 8.

Pravdepodobne budeme musieť urobiť niečo ako nižšie. Použime teplotu ako príklad, pretože je to iba jeden 16 -bitový výstup.

// získanie deskriptora súboru fd …

int tempRegHi = 65; int tempRegLo = 66; int hiByte = wiringPiI2CReadReg8 (fd, tempRegHi); int loByte = wiringPiI2CReadReg8 (fd, tempRegLo); int result = hiByte << 8; // vloženie 8 -bitového poradia do hornej časti výsledku so 16 -bitovou hodnotou | = loByte; // teraz pridajte v poradí 8 bitov, čím získate úplné 16 -bitové číslo // vytlačte toto číslo alebo použite funkciu horizontálneho zobrazovania grafu z predchádzajúceho

Z našich predchádzajúcich krokov sme videli, že register 65 je dosť stabilný, zatiaľ čo register 66 je veľmi hlučný. Pretože 65 je bajt hi order a 66 byte nízkeho poriadku, dáva to zmysel.

Na čítanie môžeme dáta registra 65 brať tak, ako sú, ale mohli by sme priemerovať hodnoty registra 66.

Alebo môžeme celý výsledok len spriemerovať.

Pozrite sa na posledné video k tejto časti; ukazuje čítanie celej 16 -bitovej hodnoty teploty. Kód je „šiesty.test.mpu9265.c“

Krok 8: Akcelerometer a gyroskop

Videá pre túto sekciu zobrazujú výstup z akcelerometra a gyroskopu pomocou testovacieho programu „siedmy.test.mpu9265.c“. Tento kód môže čítať 1, 2 alebo 3 po sebe idúce dvojice bajtov (hi a lo bytes) a prevádza hodnoty na jednu 16-bitovú hodnotu. Môžeme teda prečítať ľubovoľnú jednu os, alebo môžeme prečítať dve z nich spoločne (a súčet zmien), alebo môžeme prečítať všetky tri (a súčet zmien).

Aby som zopakoval, v tejto fáze a v tomto návode sa snažím zodpovedať jednoduchú otázku: „Rotoval/otáčal sa robot?“. Nehľadám žiadne presné hodnoty, ako napríklad, otočilo sa to o 90 stupňov. To príde neskôr, keď sa dostaneme k práci SLAM, ale nie je to potrebné na jednoduché vyhýbanie sa prekážkam a náhodný pohyb.

Krok 9: (nedokončená práca) magnetometer

keď používate nástroj i2cdetect, MPU9265 sa v tabuľke zobrazí ako 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: -- -- -- -- -- -- -- --

Na čítanie z časti magnetometra IMU sú potrebné ďalšie kroky.

Z registrov Invesense dokument PDF:

REGISTRÁCIE 37 AŽ 39 - I2C SLAVE 0 CONTROL

• REGISTRÁCIA 37 - I2C_SLV0_ADDR
• REGISTRÁCIA 38 - I2C_SLV0_REG
• REGISTRÁCIA 39 - I2C_SLV0_CTRL