Wallace - DIY autonomní robot - Část 5 - Přidat IMU: 9 kroků

2024 Autor: John Day | [email protected]. Naposledy změněno: 2024-01-30 08:22

Pokračujeme společně s Wallace. Jméno Wallace pochází ze směsi „Wall-E“a z předchozího projektu (rozpoznávání hlasu) a při použití nástroje „espeak“to znělo trochu britsky. A jako komorník nebo komorník. A to je konečný cíl: aby se tento projekt proměnil v něco užitečného. Tedy „Wallace“.

Wallace se může pohybovat, dokáže se vyhýbat překážkám pomocí infračervených senzorů vzdálenosti (nedávno se nějak smažili (?) (Musí se na to podívat, až budu mít příležitost), má také nějaké akustické senzory vzdálenosti (tři z nich se pokazily současně čas, spolu s expandérem MCP23017) a konečně dokáže detekovat změny v proudu motoru, aby věděl, kdy do něčeho narazí.

Kromě senzorů si Wallace „pamatuje“100 tahů a má základní analýzu pomocí historie pohybu.

Dosavadním cílem pro Wallace je pouze pokusit se pokračovat v pohybu vpřed a vědět, kdy je zaseknutý v nějakém opakujícím se vzoru (například v rohu) a ve skutečnosti se nepohybuje vpřed.

Prošel jsem několika iteracemi pohybu a navigace a při otáčení došlo k neustálé bolesti hlavy.

Vzhledem k tomu, že Wallace je sledovaný robot, a chtěl jsem zachovat věci v softwaru jednodušší (na později), abych se mohl otočit, nechal jsem ho otočit/otočit na místě. Na motory tedy aplikujte stejný, ale opačný cyklus výkon / zátěž.

Vyskytnutý problém je způsoben konstrukcí platformy robota Agent 390. Pásy pásu mají tendenci se třít o boky. A co je horší, jedna strana to dělá více než druhá.

Na podlaze a rovně to nebyl problém. Ukazuje se to na koberci. Rozhodl jsem se držet Wallace mimo koberce poté, co se jeho stopy začervenaly (velmi snadno zachytí špínu).

Skutečný problém je při otáčení na podlaze.

Pokud mám software použít vysoký pracovní cyklus, pak se víceméně důsledně otáčí. Během cyklu nízkého zatížení se však může, ale nemusí, skutečně otočit. Nebo se může na chvíli otočit a pak zpomalit. Zdá se, že otočná akce je prostřednictvím softwaru nekontrolovatelná, nebo přinejlepším velmi obtížná.

Problém se objevuje během navigace a pohybu kolem nebo od překážek. Může se buď houpat příliš divoce, nebo se může zaseknout při pokusu o velmi malé posuny, aniž by se skutečně pohnul.

A tak výše uvedené vysvětlení motivovalo tento Instructable.

Zpočátku jsem chtěl upustit od zavedení jednotky snímání pohybu (IMU) nebo ji odložit, protože jsou A) komplikované, B) hlučné, C) chyby se mohou časem zavést atd. Atd. Moje myšlenka byla bylo to, že bychom to mohli udělat velmi dobře skokem dopředu na IR laserové senzory doby letu. A mohli bychom - pomocí laserů bychom mohli sledovat, zda se robot otáčí nebo ne, sledováním změn vzdálenosti.

Ve skutečnosti bychom to také mohli (trochu) udělat nyní, s akustickými senzory.

To vše je však velmi nepřímý a komplikovaný způsob, jak odpovědět na jednoduchou otázku: „otočili jsme se nebo ne?“

Zdálo se mi, že skokem k použití laserových senzorů ToF se dostanu na další úroveň softwaru; jmenovitě SLAM (Simultánní lokalizace a mapování). Ještě jsem nebyl připraven tam jít.

Je dobré dělat projekt robota ve vrstvách, přičemž první (nižší) vrstvy jsou jednodušší a druhé (horní) vrstvy jsou abstraktnější a řeší obtížnější problémy.

Vrstvy lze uvažovat takto:

1. fyzický rám robota / mechanický konstrukční základ
2. základní systém pohonu (Raspberry, Roboclaw, motory, kabeláž atd., základní software, ovládaný klávesnicí)
3. základní obvody pro podporu senzorů (obousměrný měnič napětí, expandér portů, E-Stop, rozvod energie atd.)
4. snímače vyhýbání se překážkám (akustické, IR)
5. základní, základní polohování a pohyb - detekce (akcelerometr, gyroskop, magnetometr, enkodéry motoru, enkodéry kol)

Můžete si vymyslet vlastní seznam. Pointy tohoto seznamu jsou, že byste je pravděpodobně měli dělat víceméně v uvedeném pořadí, a také to, že pokud v každé vrstvě strávíte nějaký čas, abyste se dostali do dobrého pracovního stavu, mělo by vám to pomoci později, jak se věci budou komplikovat.

Výše uvedený seznam by mohl být více či méně mapován na tyto koncepční vrstvy v softwaru.

• SLAM (simultánní lokalizace a mapování)
• Kontrola a povědomí o pohybu, rotace
• Základní vyhýbání se překážkám
• Řízení a detekce dat ze senzorů
• Základní pohyb vpřed, vzad, vlevo a vpravo, zrychlení, zpomalení, zastavení

Jak vidíte, u tohoto seznamu by prvními položkami byly horní, komplikovanější vrstvy, které řeší abstraktnější problémy a otázky, jako například „kde jsem“a „kam jdu“, zatímco poslední položky by byly nižší softwarové vrstvy, které zvládají „jak mluvit/poslouchat senzor A“nebo „jak pohnout tímto kolem“.

Nyní neříkám, že když začnete na vrstvě, dokončíte ji a pak je na další vrstvě, nikdy se nevrátíte k předchozí. Projekt robota může být hodně podobný moderním, iterativním metodám vývoje softwaru (agilní, SCRUM atd.).

Jen říkám, abych si na každého udělal čas. Budete muset vyvážit, kolik toho u každého uděláte, a rozhodnout se, o co se v určité vrstvě pokoušíte, za čas a potíže.

Mezi dvěma soupeřícími myšlenkami nebo směry existuje určitý „konflikt“nebo „napětí“.

Jedním z nich je to, co bych pro řešení problému A nazval „plug-n-play“.

Ten druhý je DIY (udělejte si sami). A to možná ani není nejlepší označení pro tento další nápad.

Zde je příklad každého, doufejme, že uvidíte napětí nebo konflikt mezi těmito dvěma možnostmi.

V tomto příkladu spojme SLAM, vyhýbání se překážkám a základní základní pohyb jako jeden problém, který je třeba vyřešit současně.

1. Pokud se rozhodneme jít cestou plug-n-play, okamžitě skočíme (v závislosti na rozpočtu) na věci, jako jsou rotační lasery namontované nahoře nebo kamera s hloubkou ostrosti nebo lasery ToF a IMU (téma tohoto Instructable).
2. Pokud naopak chceme jít druhou cestou, můžeme se pokusit extrahovat všechny možné informace z některých akustických senzorů nebo IR senzorů, nebo vůbec žádné senzory - použijeme pouze monitorování proudu motoru (náraz)

Co lze říci o #1 vs #2? Jedna věc by byla, že se díky č. 2 naučíme mnohem více. Omezení práce pouze s akustickými senzory nás nutí přemýšlet o mnohem více problémech.

Na druhou stranu, pokud jsme příliš soustředění na to, abychom dělali věci prostřednictvím č. 2, možná ztrácíme čas, protože od akustických senzorů požadujeme více, než bychom měli.

Ještě jeden koncept nebo myšlenka k zamyšlení: Jaká směs hardwaru a softwaru nejlépe odpovídá na otázky „jak“a jaká kombinace softwaru (a hardwaru?) Odpovídá na otázku „co“, „kdy“, „kde“. Protože „jak na to“je obvykle otázka nižší úrovně, na které závisí „co“, „kdy“a „kde“, aby bylo možné získat odpověď.

Každopádně všechno výše uvedené bylo jen k zamyšlení.

V mém případě, po velkém úsilí a neustálém nepříjemném problému tření na trati a neschopnosti získat konzistentní kontrolu a pohyb, je na čase udělat něco jiného.

Tedy tento Instructable - IMU.

Cílem je, aby pokud IMU říká, že se robot NETOČÍ, zvýšíme pracovní cyklus. Pokud se otáčíme příliš rychle, snižujeme pracovní cyklus.

Krok 1: Senzor IMU

A tak náš další senzor, který je třeba přidat do Wallace, je IMU. Po nějakém výzkumu jsem se usadil na MPU6050. Ale v této době se MPU9050 (a ještě nedávno MPU9250) zdálo jako ještě lepší nápad.

Mým zdrojem byl Amazon (v USA). Objednal jsem tedy dva z nich.

Co jsem ve skutečnosti dostal (zdá se, že nad tím není žádná kontrola; to se mi na Amazonu nelíbí) byly dva MPU92/65. Trochu by mě zajímalo to označení. Podívejte se na obrázky; zdá se, že jde o označení „rodiny“. V každém případě se toho držím.

Přidání je velmi jednoduché -získejte proto desku s propojovacími dráhami, připájejte senzor k desce, přidejte 10pólovou šroubovou svorkovnici (tu moji mám od Pololu).

Abych minimalizoval jakékoli rušení, pokusil jsem se tyto senzory umístit mimo vše ostatní.

To také znamenalo použití některých nylonových šroubů/matic.

Budu používat protokol I2C. Naštěstí celková délka drátu nebude tak špatná.

Jinde je spousta informací o základních připojeních a úrovních napětí atd., Takže to zde nebudu opakovat.

Krok 2: Věci nejsou vždy čisté, snadné

Při tomto psaní se nezdá, že by pro tento konkrétní MPU-92/65 bylo online hodně. To, co je k dispozici, stejně jako u většiny senzorů, se zdá být příkladem používání Arduina.

Snažím se tyto Instructables trochu odlišit představením nepříliš čistého procesu, protože věci nefungují vždy hned.

Předpokládám, že tyto Instructables jsou více podobné blogu než přímo A-B-C, 1-2-3 „takhle se to dělá“.

Krok 3: Počáteční test

Z obrázků v předchozím kroku jsou červené a černé vodiče k senzorům samozřejmě VCC (5V) a GND. Zelený a žlutý vodič jsou připojení I2C.

Pokud jste dělali jiné projekty I2C nebo jste sledovali tyto série, pak už víte o „i2cdetect“, a to je první krok k tomu, abyste věděli, zda Raspberry vidí nový senzor.

Jak můžete vidět z obrázků v tomto kroku, náš první pokus byl neúspěšný. IMU se nezobrazí (mělo by to být ID zařízení 0x68).

Dobrou zprávou však je, že autobus I2C funguje. Vidíme jedno zařízení 0x20 a je to expandér portů MCP23017 (v současné době je zodpovědný za akustická čidla HCSR04).

Na obrázku to není snadné vidět, ale připojil jsem stejně barevné zelené a žluté vodiče z IMU k MCP23017 (viz vlevo dole na obrázku)

Budeme muset provést nějaké řešení potíží.

Krok 4: Odstraňování problémů

Pomocí nastavení kontinuity na voltmetru (ten s vysokým tónem) jsem testoval připojení VCC (5V), GND, SDA a SCL. To byly dobré.

Dalším pokusem bylo odpojit MCP23017 od sběrnice I2C a ponechat na sběrnici pouze MPU-92/65. To se ukázalo jako neplodné - „i2cdetect“pak neukázal žádná zařízení.

Dále jsem tedy odpojil snímač od totemu a znovu jej zapojil přímo do obousměrné sběrnice 5 V až 3 V; tj. přímo na Malinu. (kratší dráty?).

A voila. Tentokrát je úspěch. Vidíme, že 0x68 se zobrazuje pomocí „i2cdetect“.

Zatím ale nevíme, proč to tentokrát fungovalo. Může to být délka vodičů? Předchozí umístění?

Poznámka: Nezáleží na tom, zda ADO bylo uzemněno nebo ne. Je možné, že na palubě jsou vytahovací a stahovací odpory. Totéž může platit pro FSYNC.

Dále jsem znovu připojil MCP23017. Nyní tedy máme na sběrnici I2C dvě zařízení. (viz obrázek). Úspěšně, nyní vidíme i 0c20 i 0x68 s i2cdetect.

Videa pojednávají o trochu více o tom, co se stalo během řešení potíží.

Krok 5: Čtení dat senzoru

Různé přístupy

Rozhodl jsem se použít několik přístupů k získávání užitečných informací ze senzoru. Tady jsou, v žádném pořadí:

1. zkuste nějaké základní programování
2. projděte si nějakou online dokumentaci o registrech
3. podívejte se na příklady a / nebo kódy ostatních

Proč tyto přístupy? Proč nehledat nějakou existující knihovnu nebo kód?

Experimentováním a zkoušením některých myšlenek můžeme lépe absorbovat určité znalosti nejen o tomto konkrétním senzoru, ale také získat určitou techniku, dovednosti a způsoby uvažování o řešení něčeho nového a něčeho, co nemusí mít mnoho dokumentace; něco, co může mít spoustu neznámých.

Jakmile jsme si také pohráli a vyzkoušeli některé z našich vlastních nápadů a získali nějaký přehled, jsme v lepší pozici vyhodnotit kód nebo knihovnu někoho jiného.

Například když jsem se podíval na nějaký kód C ++ pro MPU9250 v githubu, uvědomil jsem si, že mě to nutí používat přerušení, což zatím nechci dělat.

Také přichází s dalšími věcmi, jako je kalibrace; opět něco, co mě zatím nezajímá.

Je možné, že to, co musím udělat, abych odpověděl na jednoduchou otázku „rotuje robot ano nebo ne“, by se dalo velmi jednoduše zodpovědět prostým přečtením některých registrů.

Registry

V době psaní tohoto článku se zdá, že toho senzoru není mnoho k dispozici. Ve skutečnosti, když se podíváte na obrázky, které jsou součástí tohoto Instructable, a pozorně se podíváte na nápisy na skutečných žetonech, přemýšlím, jestli to není knock-off. To, co vidím, nespojuji s ničím z Invense. Bez ohledu na to jsem se rozhodl podívat se na informace o registrech u modelů, které jsem našel: MPU-6050 a MPU-9250.

V obou případech je následující pro oba stejné. A pro začátek předpokládáme, že to bude stejné i pro tento MPU-92/65.

59 až 64 - měření akcelerometru

65, 66 - měření teploty 67 až 72 - měření gyroskopem 73 až 96 - data externího senzoru

Poznámka: MPU-6050 NENÍ vybaven magnetometrem, zatímco MPU-9250 (a předpokládáme, že i tento) ano.

Další zajímavé, doufejme užitečné informace získané z registrového dokumentu:

Informace o magnetometru:

magnetometr id: 0x48 registruje 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 HZHZ ST2 0 0 0 BITM HOFL 0 0 0 rozpis toho, co každý registr znamená: HXL [7: 0]: data měření osy X nižší 8bit HXH [15: 8]: data měření osy X vyšší 8bit HYL [7: 0]: Data měření osy Y nižší 8bit HYH [15: 8]: Data měření osy Y vyšší 8bit HZL [7: 0]: Data měření osy Z nižší 8bit HZH [15: 8]: Data měření osy Z vyšší 8 bitů

Programování

Jedna další informace z registrů je, že se zdálo, že existuje jen asi 100 registrů. Jednou z taktik by tedy mohlo být napsat jednoduchý program, který přistupuje k zařízení (0x68) a pokouší se číst sérii registrů postupně, bez ohledu na jejich význam, jen aby viděl, jaká data lze vidět.

A pak proveďte po sobě jdoucí průchody pomocí stejného kódu a porovnejte data z jednoho průchodu s druhým.

Myšlenka je taková, že bychom pravděpodobně mohli odstranit všechny registry, které se zdají být bez dat (nuly nebo FF?) Nebo které se absolutně nikdy nemění, a mohli bychom se také zaměřit na ty, které se mění.

Potom se podíváme pouze na ty, které se mění, přidejte funkci zprůměrování, která zprůměruje nejnovější N čtení tohoto registru, abychom zjistili, zda pro tento registr ve skutečnosti existuje určitá ustálená hodnota. To by předpokládalo, že udržujeme senzor velmi nehybný a na stejném místě.

Nakonec jsme si mohli jemně vyzkoušet věci se senzorem, jako je šťouchnutí (akcelerometr, gyroskop), nebo foukání na něj (teplota), nebo otáčení (předchozí dva plus magnetometr) a zjistit, jaký to má vliv na hodnoty.

Rád používám knihovnu wiringPi co nejvíce. Má podporu pro I2C.

První běh:

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

* k sestavení: gcc first.test.mpu9265.c -o first.test.mpu9265 -lwiringPi * * ke spuštění: sudo./first.test.mpu9265 * * tento program pouze vygeneruje z MCP23017 rozsah (možných) registrů, * a poté z MPU9265 (nebo z jakéhokoli jiného MPU na této adrese 0x68) * * Použil jsem to k ověření, zda mohu dokonce číst ze senzoru, protože jsem již * měl důvěru v MCP23017. ******************************************************* *****************************/ #include #include #include #include #include int main (int argc, char ** argv) {put („Podívejme se, co říká MCP23017 @ 0x20:“); errno = 0; int deviceId1 = 0x20; int fd1 = wiringPiI2CSetup (deviceId1); if (-1 == fd1) {fprintf (stderr, "Nelze otevřít wiringPi I2C zařízení: %s / n", strerror (errno)); návrat 1; } for (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d", wiringPiI2CReadReg8 (fd1, reg)); fflush (stderr); zpoždění (10); } put (""); put ("Podívejme se, co říká MPU9265 @ 0x20:"); errno = 0; int deviceId2 = 0x68; int fd2 = wiringPiI2CSetup (deviceId2); if (-1 == fd2) {fprintf (stderr, "Nelze otevřít wiringPi I2C zařízení: %s / n", strerror (errno)); návrat 1; } for (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d", wiringPiI2CReadReg8 (fd2, reg)); fflush (stderr); zpoždění (10); } put (""); návrat 0; }

Druhý běh:

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

* k sestavení: gcc second.test.mpu9265.c -o second.test.mpu9265 -lwiringPi * * ke spuštění: sudo./second.test.mpu9265 * * Tento program vydá číslo registru vedle načtené hodnoty. * * Díky tomu je užitečné propojit (přesměrovat) výstup do souboru a poté * provést několik běhů pro porovnání. Mohlo by to poskytnout určitý přehled o tom, * jaké registry jsou důležité a jak se data mohou chovat. ******************************************************* *****************************/ #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; } put („Podívejme se, co říká MPU9265 @ 0x20:“); errno = 0; int fd = wiringPiI2CSetup (deviceId); if (-1 == fd) {fprintf (stderr, "Nelze otevřít wiringPi I2C zařízení: %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); zpoždění (10); } návrat 0; }

Třetí běh:

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

* stavět: gcc third.test.mpu9265.c -o third.test.mpu9265 -lwiringPi * * spustit: sudo./third.test.mpu9265 * * Tento program je výsledkem druhého. Čte pouze z registrů *, které indikují rozdíl mezi jedním a druhým spuštěním.******************************************************* *****************************/ #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; } put („Podívejme se, co říká MPU9265 @ 0x20:“); errno = 0; int fd = wiringPiI2CSetup (deviceId); if (-1 == fd) {fprintf (stderr, "Nelze otevřít wiringPi I2C zařízení: %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); zpoždění (10); } for (int reg = 111; reg <= 112; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); zpoždění (10); } for (int reg = 189; reg <= 201; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); zpoždění (10); } for (int reg = 239; reg <= 240; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); zpoždění (10); } návrat 0; }

Co jsme se tedy zatím naučili? Obrázek tabulky s barevně zvýrazněnými oblastmi naznačuje, že se zdá, že výstup odpovídá prvním sadám registrů.

Dosavadní výsledky mohou generovat nové otázky.

Otázka: proč existuje pouze jeden výsledek registrace pro „externí“skupinu?

Otázka: co jsou to všechny ty neznámé registry "??????"

Otázka: Jelikož program není řízen přerušením, vyžadoval data příliš pomalu? příliš rychle?

Otázka: můžeme ovlivnit výsledky zkoušením věcí se samotným senzorem, jak běží?

Krok 6: Pojďme kopat více do naměřených hodnot / dat

Myslím, že dalším krokem před čímkoli jiným je vylepšit program na:

• být flexibilní v tom, kolik smyčkového zpoždění (ms)
• být flexibilní v tom, kolik naměřených hodnot poskytne průběžný průměr na registr

(Program jsem musel připojit jako soubor. Zdálo se, že je problém jej vložit sem. "4th.test.mpu9265.c")

Zde je běh s použitím průměrných 10 posledních odečtů ve smyčce 10 ms:

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

První sloupec úplně vlevo je číslo registru. Pak přijde posledních 10 odečtů pro tento registr. Nakonec poslední sloupec je průměrem pro každý řádek.

Vypadá to, že registry 61, 69, 71, 189, 197 a 199 jsou buď pouze binární, nebo připravené / nepřipravené, nebo jsou vysokým bajtem 16bitové hodnoty (záporné?).

Další zajímavé postřehy:

• registry 65, 193 - velmi stabilní a stejná hodnota
• registr 63, 191 - velmi stabilní a stejná hodnota
• registry 73, 112, 195, 201, 240 - vše na nule

Vraťme tato pozorování zpět k vícebarevnému, zvýrazněnému tabulkovému obrazu z dřívější doby.

Registr 65 - teplota

Registrace 193 - ??????

Zaregistrujte 63 - akcelerometr

Zaregistrujte se 191 - ??????

Registr 73 - externí

Zaregistrujte se na čísle 112 a dále - ??????

Stále máme neznámo, nicméně něco užitečného jsme se naučili.

Registr 65 (teplota) a registr 63 (akcelerometr) byly velmi stabilní. To je něco, co bychom očekávali. Nedotkl jsem se senzoru; nepohybuje se, kromě náhodných vibrací, protože robot odpočívá na stejném stole jako můj počítač.

Pro každý z těchto registrů teploty/akcelerometru existuje jeden zajímavý test. Pro tento test potřebujeme ještě další verzi programu.

Krok 7: Jsme schopni ovlivnit teplotu a zrychlení

V předchozích krocích jsme zúžili alespoň jeden registr pro teplotu a jeden pro zrychlení.

Díky této další verzi programu („5th.test.mpu9265.c“) můžeme vidět, že u obou registrů dochází ke změně. Podívejte se na videa.

Více kopání

Pokud se vrátíme a podíváme se na informace z registru, zjistíme, že existují:

• tři 16bitové výstupy pro gyroskop
• tři 16bitové výstupy pro akcelerometr
• tři 16bitové výstupy pro magnetometr
• jeden 16bitový výstup pro teplotu

Výsledky získané našimi jednoduchými testovacími programy však byly všechny jednotlivé 8bitové výstupy. (jednotlivé registry).

Pojďme tedy zkusit více stejného přístupu, ale tentokrát číst 16 bitů místo 8.

Pravděpodobně budeme muset udělat něco jako níže. Jako příklad použijeme teplotu, protože je to pouze jeden 16bitový výstup.

// získat popisovač souboru fd…

int tempRegHi = 65; int tempRegLo = 66; int hiByte = wiringPiI2CReadReg8 (fd, tempRegHi); int loByte = wiringPiI2CReadReg8 (fd, tempRegLo); int result = hiByte << 8; // vložte do horní části výsledku 16bitové hodnoty hi bit 8 bitů | = loByte; // nyní přidejte do pořadí 8 bitů, čímž získáte úplné 16bitové číslo // vytiskněte toto číslo nebo použijte funkci horizontálního zobrazení grafu dříve

Z našich předchozích kroků jsme viděli, že registr 65 je docela stabilní, zatímco registr 66 je velmi hlučný. Protože 65 je bajt hi order a 66 byte nižšího řádu, dává to smysl.

Pro čtení můžeme data registru 65 brát tak, jak jsou, ale mohli bychom průměrovat hodnoty registru 66.

Nebo můžeme celý výsledek průměrovat.

Podívejte se na poslední video k této části; ukazuje načtení celé 16bitové hodnoty teploty. Kód je "šestý.test.mpu9265.c"

Krok 8: Akcelerometr a gyroskop

Videa pro tuto sekci ukazují výstup z akcelerometru a gyroskopu pomocí testovacího programu „Seventh.test.mpu9265.c“. Tento kód může číst 1, 2 nebo 3 po sobě jdoucí bajtové páry (hi a lo bytes) a převádí hodnoty na jednu 16bitovou hodnotu. Můžeme tedy přečíst libovolnou jednotlivou osu, nebo můžeme přečíst dvě z nich dohromady (a součet změn), nebo můžeme přečíst všechny tři (a součet změn).

Abych zopakoval, pro tuto fázi, pro tento Instructable, jen hledám odpověď na jednoduchou otázku: „otočil/otočil se robot?“. Nehledám žádnou přesnou hodnotu, jako například, otočilo se to o 90 stupňů. To přijde později, až se začneme věnovat SLAM, ale není to nutné pro jednoduché vyhýbání se překážkám a náhodný pohyb.

Krok 9: (nedokončená práce) magnetometr

při použití nástroje i2cdetect se MPU9265 v tabulce zobrazí jako 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: -- -- -- -- -- -- -- --

Čtení z části magnetometru IMU vyžaduje další kroky.

Z registrů Invesense PDF doc:

REGISTRACE 37 AŽ 39 - I2C SLAVE 0 CONTROL

• REGISTRACE 37 - I2C_SLV0_ADDR
• REGISTRACE 38 - I2C_SLV0_REG
• REGISTRACE 39 - I2C_SLV0_CTRL