Wallace - DIY Autonomous Robot - Del 5 - Tilføj IMU: 9 trin

2024 Forfatter: John Day | [email protected]. Sidst ændret: 2024-01-30 08:29

Vi fortsætter sammen med Wallace. Navnet Wallace kom fra en blanding af "Wall-E" og fra et tidligere projekt (stemmegenkendelse), og ved brug af "espeak" -værktøjet lød det lidt britisk. Og som en betjent eller en butler. Og det er det endelige mål: at dette projekt bliver til noget nyttigt. Altså "Wallace".

Wallace kan bevæge sig rundt, han kan undgå forhindringer ved hjælp af IR -afstandssensorer (for nylig stegte de på en eller anden måde (?) (Skal undersøge det, når jeg får en chance), har også nogle akustiske afstandssensorer (tre af dem gik dårligt på samme tid) tid, sammen med en MCP23017 ekspander), og endelig kan detektere ændringer i motorstrøm for at vide, hvornår den støder ind i noget.

Ud over sensorerne "husker" Wallace de 100 træk og har nogle rudimentære analyser ved hjælp af bevægelseshistorien.

Målet hidtil for Wallace er blot at forsøge at blive ved med at bevæge sig fremad, og at vide, hvornår det sidder fast i et gentaget mønster (f.eks. I et hjørne) og ikke rigtigt komme videre.

Jeg har gennemgået flere iterationer for bevægelse og navigation, og den konsekvente hovedpine har været under rotation.

Da Wallace er en sporet robot, og jeg ønskede at holde tingene enklere i softwaren (til senere), for at vende, har jeg bare ham til at dreje/rotere på plads. Påfør således motorerne lige, men modsat effekt / driftscyklus.

Problemet skyldes designet af Agent 390 -robotplatformen. Sporbælterne har en tendens til at gnide mod siderne. Og værre, den ene side gør det mere end den anden.

På gulvbelægning og gå lige, det har ikke været et problem. Det viser sig på gulvtæpper. Jeg valgte at holde Wallace væk fra gulvtæppet, efter at sporene blev snavsede (de tager ekstremt let snavs op).

Det virkelige problem er, når der drejes på gulve.

Hvis jeg har softwaren til at anvende en høj cyklus på et højt niveau, så vender den mere eller mindre konsekvent. I løbet af en lavdriftscyklus kan den dog faktisk dreje. Eller det kan dreje lidt og derefter bremse. Den svingende handling ser ud til at være ukontrollabel via softwaren eller i bedste fald meget vanskelig.

Problemet viser sig under navigation og bevæger sig rundt eller væk fra forhindringer. Det kan enten svinge for vildt væk, eller det kan sidde fast i forsøget på at foretage meget små skift uden egentlig at flytte sig.

Og derfor motiverede ovenstående forklaring denne instruktive.

I første omgang havde jeg ønsket at undlade eller forsinke introduktionen af en bevægelsesfølende enhed (IMU), fordi de er A) komplicerede, B) støjende, C) fejl kan blive introduceret over tid osv. Osv. Min tanke havde været, at vi kunne gøre det meget godt ved at springe frem til IR-lasersensorer, der var tid til flyvning. Og vi kunne - ved hjælp af lasere kunne vi vide, om robotten roterede eller ej, ved at spore ændringerne i afstanden.

Faktisk kunne vi også (slags) gøre det nu med de akustiske sensorer.

Alt dette er imidlertid en meget indirekte, kompliceret måde at besvare et enkelt spørgsmål: "har vi roteret eller ej?"

Det forekom mig, at springe til at bruge ToF lasersensorer ville tage mig til det næste niveau af software; nemlig SLAM (Simultan lokalisering og kortlægning). Jeg var ikke klar til at tage derhen endnu.

Det er en god ting at lave et robotprojekt i lag, hvor de første (nederste) lag er enklere, og de sidste (øverste) lag er mere abstrakte og tackler mere vanskelige spørgsmål.

Lag kan tænkes på noget som dette:

1. robot fysisk ramme / mekanisk strukturelt grundlag
2. rudimentært drevsystem (Hindbær, Roboclaw, motorer, kabler osv., Basissoftware, tastaturdrevet)
3. væsentlige kredsløb til understøttelse af sensorer (tovejs spændingsskifter, portudvidelse, E-Stop, strømfordeling osv.)
4. forhindringssensorer (akustisk, IR)
5. væsentlig, grundlæggende positionering og bevægelse - detektion (accelerometer, gyro, magnetometer, motorkodere, hjulkodere)

Du kan komme med din egen liste. Punkterne ved denne liste er, at du sandsynligvis burde gøre disse mere eller mindre i den rækkefølge, og også at hvis du bruger lidt tid på hvert lag for at få hver til en god arbejdstilstand, bør det hjælpe dig senere, da tingene bliver mere komplicerede.

Ovenstående liste kan mere eller mindre kortlægges til disse konceptuelle lag i software.

• SLAM (samtidig lokalisering og kortlægning)
• Kontrol og bevidsthed om bevægelse, rotation
• Grundlæggende forhindring af forhindringer
• Kontrol og registrering af sensordata
• Væsentlig bevægelse fremad, bagud, venstre og højre, fremskynde, sænke, stoppe

Som du kan se, for denne liste, ville de første emner være de øvre, mere komplicerede lag, der tackler mere abstrakte spørgsmål og spørgsmål, såsom "hvor er jeg" og "hvor skal jeg hen", mens sidstnævnte elementer ville være lavere softwarelag, der håndterer "hvordan man taler/lytter til sensor A" eller "hvordan man bevæger dette hjul".

Nu siger jeg ikke, at når du starter på et lag, har du fuldført det, og så er det på det næste lag, for aldrig at vende tilbage til det forrige. Et robotprojekt kan meget lig moderne, iterative softwareudviklingsmetoder (agile, SCRUM osv.).

Jeg siger bare at tage tid til hver. Du bliver nødt til at afbalancere, hvor meget du skal gøre for hver, og beslutte, hvad du forsøger på et bestemt lag, der er værd at bruge tid og besvær.

Der er en vis "konflikt" eller "spænding" mellem to konkurrerende ideer eller retninger.

Det ene er, hvad jeg vil kalde "plug-n-play" for at løse problem A.

Den anden er DIY (gør det selv). Og det er måske ikke engang den bedste etiket til denne anden idé.

Her er et eksempel på hver, forhåbentlig vil du se spændingen eller konflikten mellem de to valg.

For dette eksempel, lad os klippe SLAM, forhindring af forhindring og væsentlig grundlæggende bevægelse alt sammen som et problem, der skal løses på samme tid.

1. Hvis vi beslutter os for at gå plug-n-play-ruten, hopper vi straks (afhængigt af budget) til ting som de topmonterede roterende lasere eller dybdeskarphedskameraer eller ToF-lasere og IMU (emne for dette Kan instrueres).
2. Hvis vi derimod vil gå den anden vej, kan vi prøve at udtrække alle mulige oplysninger fra nogle akustiske sensorer eller IR -sensorer eller slet ingen sensorer - vi bruger bare motorstrømovervågning (bump)

Hvad kan man sige om #1 vs #2? En ting ville være, at vi vil have lært meget mere ved at gøre #2. Begrænsningerne ved kun at have akustiske sensorer at arbejde med tvinger os til at tænke på mange flere spørgsmål.

På den anden side, hvis vi er for fokuserede på at gøre ting via #2, spilder vi muligvis tid, fordi vi beder om mere end vi burde fra akustiske sensorer.

Endnu et koncept eller en idé at tænke over: Hvilken blanding af hardware og software besvarer bedst spørgsmålene om "hvordan man", og hvilken blanding af software (og hardware?) Besvarer spørgsmålet om "hvad", "hvornår", "hvor". Fordi "hvordan" typisk er et spørgsmål på lavere niveau, som "hvad", "hvornår" og "hvor" afhænger af for at få et svar.

Alligevel var alt ovenstående bare noget at tænke på.

I mit tilfælde, efter en stor indsats og med det konsekvente irriterende problem med sporfriktion og ude af stand til at få konsekvent kontrol og bevægelse, er det tid til at gøre noget andet.

Således dette instruerbare - en IMU.

Målet er, at hvis IMU siger, at robotten IKKE drejer, øger vi arbejdscyklussen. Hvis vi svinger for hurtigt, reducerer vi arbejdscyklussen.

Trin 1: IMU -sensoren

Og så er vores næste sensor at tilføje til Wallace IMU. Efter lidt research besluttede jeg mig for en MPU6050. Men på dette tidspunkt virkede MPU9050 (og endnu mere for nylig MPU9250) som en endnu bedre idé.

Min kilde har været Amazon (i USA). Så jeg bestilte to af dem.

Hvad jeg faktisk fik (der synes ikke at være kontrol over dette; det er det, jeg ikke kan lide ved Amazon) var to MPU92/65. Jeg undrer mig lidt over betegnelsen. Tag et kig på billederne; det ser ud til at være en "familie" betegnelse. Det er i hvert fald det, jeg sidder fast med.

Det er meget enkelt at tilføje det -få et prototavle med forbindelsesspor, lod lod sensoren til bord, tilføj en 10 -polet skrueklemme (jeg har min fra Pololu).

For at minimere forstyrrelser forsøgte jeg at placere disse sensorer væk fra alt andet.

Det betød også at bruge nogle nylonbolte/møtrikker.

Jeg vil bruge I2C protokollen. Forhåbentlig vil den samlede ledningslængde ikke være så dårlig.

Der er masser af information andre steder om de grundlæggende forbindelser og spændingsniveauer osv., Så det vil jeg ikke gentage her.

Trin 2: Tingene er ikke altid rene, lette

Ved denne skrivning synes der ikke at være meget online for denne særlige MPU-92/65. Hvad der er tilgængeligt, ligesom med de fleste sensorer, ser ud til at være eksempler, der bruger Arduino.

Jeg forsøger at gøre disse instruktioner lidt anderledes ved at præsentere en ikke-så-ren proces, fordi tingene ikke altid fungerer med det samme.

Jeg formoder, at disse instruktører mere ligner en blog end lige A-B-C, 1-2-3 "sådan gør du det".

Trin 3: Indledende test

Fra billederne i det foregående trin er de røde og sorte ledninger, der går til sensorerne, naturligvis VCC (5V) og GND. De grønne og gule ledninger er I2C -forbindelserne.

Hvis du har udført andre I2C -projekter eller har fulgt med i disse serier, så kender du allerede til "i2cdetect", og det er det første trin for at vide, om hindbæret kan se den nye sensor.

Som du kan se fra billederne i dette trin, var vores første forsøg mislykkedes. IMU'en vises ikke (skal være enheds -id 0x68).

Den gode nyhed er dog, at I2C -bussen kører. Vi ser en enhed 0x20, og det er MCP23017 portudvidelsen (i øjeblikket ansvarlig for HCSR04 akustiske sensorer).

Det er ikke let at se på billedet, men jeg forbandt de samme farvede grønne og gule ledninger fra IMU til MCP23017 (se nederst til venstre i billedet)

Vi bliver nødt til at foretage nogle fejlfinding.

Trin 4: Fejlfinding

Ved hjælp af kontinuitetsindstillingen på et voltmeter (den med den høje tone) testede jeg VCC (5V), GND, SDA og SCL-forbindelser. De var gode.

Næste forsøg var at afbryde MCP23017 fra I2C-bussen og kun efterlade MPU-92/65 på bussen. Det viste sig at være nytteløst - "i2cdetect" viste derefter ingen enheder.

Så derefter afmonterede jeg sensoren fra totempæl og tilsluttede den igen direkte til 5V-til-3V tovejs-bussen; dvs. direkte til hindbæret. (kortere ledninger?).

Og voila. Denne gang er der succes. Vi ser 0x68 dukke op ved hjælp af "i2cdetect".

Men vi ved endnu ikke, hvorfor det virkede denne gang. Kan det være længden på ledningerne? Den tidligere placering?

Bemærk: Det gjorde ingen forskel, om ADO var jordet eller ej. Det kan være, at der er indbyggede pullup- og pull-down-modstande. Det samme kan være tilfældet for FSYNC.

Dernæst tilsluttede jeg MCP23017 igen. Så nu har vi to enheder på I2C -bussen. (se billede). Succes, vi ser nu både 0x20 og 0x68 med i2cdetect.

Videoerne går lidt mere ind på, hvad der skete under fejlfinding.

Trin 5: Læsning af sensordata

Forskellige tilgange

Jeg besluttede at tage flere tilgange til at få nyttig information fra sensoren. Her er de, ikke i nogen rækkefølge:

1. prøv noget grundlæggende programmering
2. gennemse online dokumentation om registre
3. tag et kig på andres eksempler og / eller kode

Hvorfor disse tilgange? Hvorfor ikke bare lede efter et eksisterende bibliotek eller en kode?

Ved at eksperimentere og prøve nogle ideer kan vi bedre absorbere noget viden om ikke kun denne særlige sensor, men også få en vis teknik, dygtighed og måder at tænke på at tackle noget nyt og noget, der måske ikke har meget dokumentation; noget der kan have en masse ubekendte.

Når vi har leget med og afprøvet nogle af vores egne ideer og fået indsigt, er vi også bedre i stand til at evaluere andres kode eller bibliotek.

For eksempel efter at have set på en C ++ - kode til MPU9250 i github, indså jeg, at det tvang mig til at bruge afbrydelser, som jeg endnu ikke ønsker at gøre.

Det kommer også med ekstra ting som kalibrering; igen, noget jeg endnu ikke er interesseret i.

Det kan være, at det, jeg skal gøre for at besvare det enkle spørgsmål "er robotten, der roterer ja eller nej", kunne besvares meget enkelt ved blot at læse nogle registre.

Registre

Ved denne skrivning synes der ikke at være meget tilgængeligt på denne sensor. Faktisk, hvis du tager et kig på de billeder, der følger med denne Instructable, og ser nærmere på inskriptionerne på de faktiske chips, får det mig til at spekulere på, om dette ikke er en knock-off. Jeg relaterer ikke det, jeg ser, til noget fra Invense. Uanset hvad valgte jeg at se på register-informationen for de modeller, jeg fandt: MPU-6050 og MPU-9250.

I begge tilfælde er følgende det samme for begge. Og til at begynde med antager vi, at det også vil være det samme for denne MPU-92/65.

59 til 64 - accelerometermålinger

65, 66 - temperaturmålinger 67 til 72 - gyroskopmålinger 73 til 96 - eksterne sensordata

Et bemærkelsesværdigt element: MPU-6050 ser ud til IKKE at have et magnetometer, mens MPU-9250 (og vi går også ud fra, at dette også er) har et.

Nogle mere interessante, forhåbentlig nyttige oplysninger hentet fra registerdokumentet:

Magnetometer Info:

magnetometer id: 0x48 registrerer 00 til 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 HX15 HX14 HX13 HX12 HX11 HX10 HX9 HX8 05H HYL HY7 HY6 HY5 HY4 HY3 HY2 HY1 HY0 06H HYH HY15 HY14 HY13 HYZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ ST2 0 0 0 BITM HOFL 0 0 0 en oversigt over, hvad hvert register betyder: HXL [7: 0]: X-akse måledata lavere 8bit HXH [15: 8]: X-akse måledata højere 8bit HYL [7: 0]: Y-akse måledata lavere 8bit HYH [15: 8]: Y-akse måledata højere 8bit HZL [7: 0]: Z-akse måledata lavere 8bit HZH [15: 8]: Z-akse måledata højere 8bit

Programmering

En anden smule information fra registerdokumenterne er, at der tilsyneladende kun var omkring 100 registre. Så en taktik kan være at skrive et simpelt program, der får adgang til enheden (0x68) og forsøger at læse en række registre i rækkefølge uden at tage hensyn til deres betydning, bare for at se, hvilke data der kan ses.

Og gør derefter successive pas ved hjælp af den samme kode, og sammenlign dataene fra det ene pas vs det næste.

Ideen er, at vi sandsynligvis kunne fjerne alle registre, der tilsyneladende ikke har data (nuller eller FF?), Eller som absolut aldrig ændres, og vi kunne også fokusere på dem, der ændrer sig.

Derefter kigger vi kun på dem, der ændrer sig, og tilføjer en gennemsnitsfunktion, der gennemsnitligt viser de seneste N -læsninger for dette register, for at se om der faktisk er en bestemt stabil værdi for det pågældende register. Dette ville antage, at vi holder sensoren meget stille og på samme sted.

Endelig kunne vi derefter forsigtigt prøve ting med sensoren, såsom at trykke den (accelerometer, gyro) eller blæse på den (temperatur) eller rotere den (de to foregående plus magnetometer) og se, hvilken effekt dette har på værdierne.

Jeg kan bedst lide at bruge wiringPi -biblioteket så meget som muligt. Det har understøttelse af I2C.

Første løb:

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

* at bygge: gcc first.test.mpu9265.c -o first.test.mpu9265 -lwiringPi * * for at køre: sudo./first.test.mpu9265 * * dette program udsender bare en række (mulige) registre fra MCP23017, * og derefter fra MPU9265 (eller enhver anden MPU på den 0x68 adresse) * * Jeg brugte den til at validere, om jeg overhovedet kunne læse fra sensoren, da jeg allerede * havde tillid til MCP23017. ************************************************* ****************************/ #include #include #include #include #include int main (int argc, char ** argv) {puts ("Lad os se, hvad MCP23017 @ 0x20 har at sige:"); errno = 0; int deviceId1 = 0x20; int fd1 = wiringPiI2CSetup (deviceId1); hvis (-1 == fd1) {fprintf (stderr, "Kan ikke åbne wiringPi I2C-enhed: %s / n", strerror (errno)); return 1; } for (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d", wiringPiI2CReadReg8 (fd1, reg)); fflush (stderr); forsinkelse (10); } sætter (""); sætter ("Lad os se, hvad MPU9265 @ 0x20 har at sige:"); errno = 0; int deviceId2 = 0x68; int fd2 = wiringPiI2CSetup (deviceId2); hvis (-1 == fd2) {fprintf (stderr, "Kan ikke åbne wiringPi I2C-enhed: %s / n", strerror (errno)); return 1; } for (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d", wiringPiI2CReadReg8 (fd2, reg)); fflush (stderr); forsinkelse (10); } sætter (""); returnere 0; }

Andet løb:

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

* at bygge: gcc second.test.mpu9265.c -o second.test.mpu9265 -lwiringPi * * to run: sudo./second.test.mpu9265 * * Dette program udsender registernummeret ved siden af værdien læst. * * Dette gør det nyttigt at rør (omdirigere) output til en fil, og derefter * kan der udføres flere kørsler for at sammenligne. Det kan give et indblik i * hvilket register der er vigtigt, og hvordan dataene kan opføre sig. ************************************************* ****************************/ #include #include #include #include #include #include int main (int argc, char ** argv) {int deviceId = -1; hvis (0) {} ellers hvis (! strncmp (argv [1], "0x20", strlen ("0x20"))) {deviceId = 0x20; } ellers hvis (! strncmp (argv [1], "0x68", strlen ("0x68"))) {deviceId = 0x68; } ellers hvis (! strncmp (argv [1], "0x69", strlen ("0x69"))) {deviceId = 0x69; } sætter ("Lad os se, hvad MPU9265 @ 0x20 har at sige:"); errno = 0; int fd = wiringPiI2CSetup (deviceId); hvis (-1 == fd) {fprintf (stderr, "Kan ikke åbne wiringPi I2C-enhed: %s / n", strerror (errno)); return 1; } for (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); forsinkelse (10); } returner 0; }

Det tredje løb:

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

* at bygge: gcc third.test.mpu9265.c -o third.test.mpu9265 -lwiringPi * * for at køre: sudo./third.test.mpu9265 * * Dette program er et resultat af den anden. Det læser kun fra * registre, der angav en forskel mellem det ene løb og det næste.************************************************* ****************************/ #include #include #include #include #include #include int main (int argc, char ** argv) {int deviceId = -1; hvis (0) {} ellers hvis (! strncmp (argv [1], "0x68", strlen ("0x68"))) {deviceId = 0x68; } ellers hvis (! strncmp (argv [1], "0x69", strlen ("0x69"))) {deviceId = 0x69; } sætter ("Lad os se, hvad MPU9265 @ 0x20 har at sige:"); errno = 0; int fd = wiringPiI2CSetup (deviceId); hvis (-1 == fd) {fprintf (stderr, "Kan ikke åbne wiringPi I2C-enhed: %s / n", strerror (errno)); return 1; } for (int reg = 61; reg <= 73; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); forsinkelse (10); } for (int reg = 111; reg <= 112; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); forsinkelse (10); } for (int reg = 189; reg <= 201; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); forsinkelse (10); } for (int reg = 239; reg <= 240; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); forsinkelse (10); } returner 0; }

Så hvad har vi lært hidtil? Billedet af tabellen med farvede markerede områder angiver, at output synes at matche de første sæt registre.

Resultaterne hidtil kan generere nye spørgsmål.

Spørgsmål: Hvorfor er der kun ét registerresultat for den "eksterne" gruppe?

Spørgsmål: hvad er alle de ukendte registre "??????"

Spørgsmål: Da programmet ikke er afbrudt-drevet, bad det om data for langsomt? for hurtigt?

Spørgsmål: kan vi påvirke resultaterne ved at prøve ting med selve sensoren, mens den kører?

Trin 6: Lad os grave mere i læsninger / data

Jeg tror, at det næste trin før noget andet er at forbedre programmet til:

• være fleksibel i, hvor meget sløjfeforsinkelse (ms)
• være fleksibel i, hvor mange aflæsninger der skal give et løbende gennemsnit pr. register

(Jeg var nødt til at vedhæfte programmet som en fil. Det syntes at være et problem at indsætte det her. "Fjerde.test.mpu9265.c")

Her er en løbetur ved hjælp af de sidste 10 aflæsninger i et gennemsnit på en 10 ms loop:

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

Den første kolonne til venstre er registernummeret. Så kommer de sidste 10 aflæsninger for det pågældende register. Endelig er den sidste kolonne gennemsnittet for hver række.

Det ligner registre 61, 69, 71, 189, 197 og 199 enten kun binært eller klar / ikke klar, eller de er den høje byte af en 16-bit værdi (negativ?).

Andre interessante observationer:

• registre 65, 193 - meget stabil og samme værdi
• register 63, 191 - meget stabil og samme værdi
• registre 73, 112, 195, 201, 240 - alt sammen på nul

Lad os relatere disse observationer tilbage til det flerfarvede, fremhævede bordbillede fra tidligere.

Registrer 65 - temperatur

Registrer 193 - ??????

Registrer 63 - accelerometer

Registrer 191 - ??????

Register 73 - eksternt

Tilmeld 112 og videre - ??????

Godt, vi har stadig ubekendte, men vi har lært noget nyttigt.

Register 65 (temperatur) og register 63 (accelerometer) var begge meget stabile. Dette er noget, vi ville forvente. Jeg har ikke rørt sensoren; den bevæger sig ikke andet end tilfældige vibrationer, da robotten hviler på det samme bord som min computer.

Der er en interessant test, vi kan for hver af disse temperatur/accelerometer -registre. Til den test har vi brug for endnu en version af programmet.

Trin 7: Vi kan påvirke temperatur og acceleration

I de foregående trin indsnævrede vi mindst et register for temperatur og et for acceleration.

Med denne næste version af programmet ("5th.test.mpu9265.c") kan vi faktisk se, at der sker en ændring for begge registre. Se venligst videoerne.

Mere grave

Hvis vi går tilbage og kigger på registeroplysningerne, ser vi, at der er:

• tre 16 bit udgange til gyroskop
• tre 16 bit udgange til accelerometer
• tre 16 bit udgange til magnetometer
• en 16 bit udgang til temperatur

Resultaterne fra vores enkle testprogrammer var imidlertid alle enkelt 8 bit output. (enkelte registre).

Så lad os prøve mere af den samme tilgang, men denne gang læser vi 16 bits i stedet for 8.

Vi bliver sandsynligvis nødt til at gøre noget som nedenfor. Lad os bruge temperaturen som et eksempel, da det kun er en 16 bit output.

// hent filbeskrivelse fd …

int tempRegHi = 65; int tempRegLo = 66; int hiByte = wiringPiI2CReadReg8 (fd, tempRegHi); int loByte = wiringPiI2CReadReg8 (fd, tempRegLo); int resultat = hiByte << 8; // læg hi -ordren 8 bits i den øverste del af et 16 bit -værdiresultat | = loByte; // tilføj nu rækkefølgen 8 bits, hvilket giver et komplet 16 bit nummer // udskriv dette nummer eller brug displayets vandrette graffunktion fra før

Fra vores tidligere trin har vi set, at register 65 er ret stødigt, mens register 66 er meget støjende. Da 65 er hi -order -byte og 66 low -order -byte, giver det mening.

Til læsning kan vi tage register 65's data som de er, men vi kunne gennemsnitlige register 66's værdier.

Eller vi kan bare gennemsnitlige hele resultatet.

Tag et kig på den sidste video til denne del; det viser aflæsning af hele 16 bit temperaturværdien. Koden er "sixth.test.mpu9265.c"

Trin 8: Accelerometeret og gyroskopet

Videoerne til dette afsnit viser output fra accelerometeret og gyroskopet ved hjælp af et testprogram "seventh.test.mpu9265.c". Denne kode kan læse 1, 2 eller 3 på hinanden følgende byte-par (hi og lo bytes) og konverterer værdierne til en enkelt 16 bit værdi. Således kan vi læse enhver enkelt akse, eller vi kan læse to af dem sammen (og det summerer ændringerne), eller vi kan læse alle tre (og det summerer ændringerne).

For at gentage, for denne fase, for denne Instructable, søger jeg bare at besvare et simpelt spørgsmål: "roterede/drejede robotten?". Jeg leder ikke efter nogen præcis værdi, f.eks. Roterede den 90 grader. Det kommer senere, når vi kommer til at lave SLAM, men det er ikke påkrævet for simpel forhindring af forhindringer og tilfældig bevægelse.

Trin 9: (i gang) Magnetometeret

ved brug af i2cdetect -værktøjet vises MPU9265 som 0x68 i tabellen:

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: -- -- -- -- -- -- -- --

Der kræves ekstra trin for at læse fra magnetometerdelen af IMU.

Fra Invesense -registre PDF -dokument:

REGISTRE 37 TIL 39 - I2C SLAVE 0 KONTROL

• REGISTER 37 - I2C_SLV0_ADDR
• REGISTER 38 - I2C_SLV0_REG
• REGISTRE 39 - I2C_SLV0_CTRL