Wallace - Naredi sam avtonomnega robota - 5. del - Dodaj IMU: 9 korakov

2024 Avtor: John Day | [email protected]. Nazadnje spremenjeno: 2024-01-30 12:07

Nadaljujemo skupaj z Wallaceom. Ime Wallace je prišlo iz mešanice "Wall-E" in iz prejšnjega projekta (prepoznavanje glasu), pri uporabi pripomočka "espeak" pa je zvenelo nekoliko britansko. In kot sluga ali strežnik. In to je končni cilj: da se ta projekt spremeni v nekaj uporabnega. Tako "Wallace".

Wallace se lahko premika, izogiba se oviram z uporabo IR senzorjev razdalje (pred kratkim so nekako ocvrli (?) (To moram preveriti, ko dobim priložnost), ima tudi nekaj zvočnih senzorjev razdalje (trije so bili hkrati slabi čas, skupaj z razširjevalnikom MCP23017) in končno lahko zazna spremembe v toku motorja, da ugotovi, kdaj se v kaj zaleti.

Poleg senzorjev se Wallace "spomni" 100 potez in ima nekaj osnovnih analiz z uporabo zgodovine gibov.

Dosedanji cilj Wallacea je le poskušati nadaljevati naprej in vedeti, kdaj je obtičal v nekem ponavljajočem se vzorcu (na primer v kotu) in se v resnici ne premika naprej.

Šel sem skozi več ponovitev za gibanje in navigacijo, stalni glavobol pa je bil med rotacijo.

Ker je Wallace robot z gosenicami in sem želel stvari poenostaviti v programski opremi (za pozneje), da bi ga obrnil, ga preprosto obrnem/zavrtim. Tako za motorje uporabite enako, a nasprotno moč / obratovalni cikel.

Težava je nastala zaradi zasnove robotske platforme Agent 390. Gosenice se ponavadi drgnejo ob straneh. In še huje, ena stran to počne več kot druga.

Na tleh in naravnost ni bilo težav. Pojavi se na preprogah. Odločil sem se, da bom Wallacea obdržal s preprog, potem ko so sledi postale umazane (zelo enostavno pobirajo umazanijo).

Pravi problem je pri vrtenju na tleh.

Če programska oprema uporablja delovni cikel na visoki ravni, se bolj ali manj dosledno obrača. Vendar se lahko med nizkim obratovalnim ciklom dejansko obrne ali pa tudi ne. Ali pa se lahko nekoliko obrne in nato upočasni. Zdi se, da je vrtilno dejanje nenadzorovano s programsko opremo ali v najboljšem primeru zelo težko.

Težava se pokaže med navigacijo in premikanjem okoli ovir ali stran od njih. Lahko se preveč odmakne ali pa se zatakne, ko poskuša narediti zelo majhne premike, ne da bi se sploh premaknil.

Tako je zgornja razlaga motivirala to navodilo.

Sprva sem hotel opustiti ali odložiti uvedbo enote za zaznavanje gibanja (IMU), ker so A) zapletene, B) hrupne, C) sčasoma se lahko pojavijo napake itd itd. da bi lahko zelo dobro naredili s preskakovanjem IR laserskih senzorjev med letom. Z laserji bi lahko vedeli, ali se robot vrti ali ne, s sledenjem spremembam razdalje.

Pravzaprav bi to lahko (nekako) zdaj storili tudi z akustičnimi senzorji.

Vse to pa je zelo posreden in zapleten način odgovora na eno preprosto vprašanje: "ali smo se obrnili ali ne?"

Zdelo se mi je, da me bo skok z uporabo laserskih senzorjev ToF pripeljal na naslednjo stopnjo programske opreme; SLAM (simultana lokalizacija in preslikava). Nisem bil še pripravljen iti tja.

Dobro je narediti projekt robota v plasteh, pri čemer so prve (spodnje) plasti enostavnejše, slednje (zgornje) pa bolj abstraktne in se lotevajo težjih vprašanj.

Plasti si lahko zamislimo takole:

1. fizični okvir robota / mehanska konstrukcijska osnova
2. osnovni pogonski sistem (Raspberry, Roboclaw, motorji, ožičenje itd., osnovna programska oprema, tipkovnica)
3. bistveno vezje za podporo senzorjev (dvosmerni preklopnik napetosti, razširitvenik vrat, E-Stop, distribucija energije itd.)
4. senzorji za izogibanje oviram (akustični, IR)
5. bistveno, osnovno pozicioniranje in zaznavanje gibanja (merilnik pospeška, žiroskop, magnetometer, dajalniki motorjev, dajalniki koles)

Seznam lahko sestavite sami. Točke tega seznama so, da bi to verjetno morali narediti bolj ali manj v tem vrstnem redu, in tudi, da bi vam morali, če se stvari zapletejo, pomagati pozneje, če na vsakem sloju dosežete dobro delovno stanje.

Zgornji seznam bi lahko bolj ali manj preslikali v te konceptualne plasti v programski opremi.

• SLAM (hkratna lokalizacija in preslikava)
• Nadzor in zavedanje gibanja, rotacija
• Osnovno izogibanje oviram
• Nadzor in odkrivanje senzorskih podatkov
• Bistveno gibanje naprej, nazaj, levo in desno, pospešitev, upočasnitev, ustavitev

Kot lahko vidite, bi bile na tem seznamu prve postavke zgornje, bolj zapletene plasti, ki obravnavajo bolj abstraktna vprašanja in vprašanja, na primer "kje sem" in "kam grem", medtem ko bi bile zadnje postavke nižje programske plasti, ki obravnavajo "kako govoriti/poslušati senzor A" ali "kako premakniti to kolo".

Ne pravim, da ko boste začeli pri plasti, jo boste dokončali in potem je na naslednji plasti, da se nikoli ne vrnete na prejšnjo. Robotski projekt je lahko zelo podoben sodobnim, ponavljajočim se metodam razvoja programske opreme (agilni, SCRUM itd.).

Pravim, da si vzamete čas za vsako. Boste morali uravnotežiti, koliko morate narediti pri vsakem, in se odločiti, kaj poskušate na določeni plasti, vredno časa in težav.

Obstajata določen "konflikt" ali "napetost" med dvema konkurenčnima idejama ali smermi.

Eno bi rekel "plug-n-play" za rešitev problema A.

Drugi je DIY (naredi sam). In to morda niti ni najboljša oznaka za to drugo idejo.

Tukaj je primer vsakega, upam, da boste videli napetost ali konflikt med obema izbirama.

Za ta primer združimo SLAM, izogibanje oviram in bistveno osnovno gibanje kot eno težavo, ki jo je treba rešiti hkrati.

1. Če se odločimo za pot plug-n-play, takoj skočimo (odvisno od proračuna) na stvari, kot so tisti vrteči se rotacijski laserji ali kamera za globinsko ostrino ali ToF laserji in IMU (tema tega Navodila).
2. Če pa želimo iti po drugi poti, lahko poskusimo iz nekaterih akustičnih senzorjev ali IR -senzorjev izvleči vse možne podatke, ali pa sploh ne iz senzorjev - uporabljamo samo nadzor toka motorja (udar)

Kaj lahko rečemo o #1 proti #2? Ena stvar bi bila, da se bomo s #2 naučili veliko več. Omejitve uporabe samo zvočnih senzorjev nas silijo k razmišljanju o veliko več vprašanjih.

Po drugi strani pa, če smo preveč osredotočeni na opravljanje stvari prek št. 2, morda zapravljamo čas, saj od zvočnih senzorjev zahtevamo več, kot bi morali.

Še en koncept ali zamisel za razmislek: Katera mešanica strojne in programske opreme najbolje odgovarja na vprašanja "kako" in katera mešanica programske opreme (in strojne opreme?) Odgovarja na vprašanje "kaj", "kdaj", "kje". Ker je "kako" običajno vprašanje nižje ravni, od katerega so "kaj", "kdaj" in "kje" odvisne, da dobimo odgovor.

Kakorkoli že, vse zgoraj je bilo le nekaj za razmisliti.

V mojem primeru je po dolgem naporu in stalnem nadležnem vprašanju trenja tira in nezmožnosti doslednega nadzora in gibanja čas, da naredim nekaj drugega.

Tako je ta Instructable - IMU.

Cilj je, da če IMU pove, da se robot NE vrti, povečamo delovni cikel. Če se vrtimo prehitro, zmanjšamo delovni cikel.

Korak: Senzor IMU

Naslednji senzor, ki ga moramo Wallaceu dodati, je IMU. Po nekaj raziskavah sem se odločil za MPU6050. Toda takrat se je MPU9050 (in še nedavno MPU9250) zdela še boljša ideja.

Moj vir je Amazon (v ZDA). Tako sem naročil dva.

V resnici sem dobil (zdi se, da nad tem ni nadzora; to mi pri Amazonu ni všeč) sta bili dve MPU92/65. Malce me zanima ime. Oglejte si slike; zdi se, da je to "družinska" oznaka. V vsakem primeru se tega držim.

Dodajanje je zelo preprosto -dobite proto ploščo s povezovalnimi tirnicami, spajkajte senzor na ploščo, dodajte 10 -polni vijačni priključni blok (svojega sem dobil od Pololuja).

Da bi čim bolj zmanjšali motnje, sem te senzorje poskušal postaviti stran od vsega drugega.

To je pomenilo tudi uporabo nekaterih najlonskih vijakov/matic.

Uporabil bom protokol I2C. Upajmo, da skupna dolžina žice ne bo slaba.

Druge informacije o osnovnih povezavah in napetostnih ravneh itd. Je veliko, zato tega tukaj ne bom ponovil.

2. korak: Stvari niso vedno čiste, enostavne

Ob tem pisanju se zdi, da na spletu ni veliko tega posebnega MPU-92/65. Tako kot pri večini senzorjev se zdi, da so primeri uporabe Arduina.

Poskušam narediti te Instructables nekoliko drugačne s predstavitvijo ne tako čistega procesa, ker stvari ne delujejo vedno takoj.

Predvidevam, da so ti Instructables bolj podobni blogu kot naravnost A-B-C, 1-2-3 "tako to počneš".

3. korak: Začetni test

Na podlagi slik v prejšnjem koraku sta rdeča in črna žica, ki gredo do senzorjev, seveda VCC (5V) in GND. Zelena in rumena žica sta priključki I2C.

Če ste delali druge projekte I2C ali ste spremljali te serije, potem že poznate "i2cdetect" in to je prvi korak, da ugotovite, ali lahko malina vidi novo tipalo.

Kot lahko vidite iz slik v tem koraku, je bil naš prvi poskus neuspešen. IMU se ne prikaže (mora biti ID naprave 0x68).

Dobra novica pa je, da avtobus I2C deluje. Vidimo eno napravo 0x20 in to je razširitvenik vrat MCP23017 (trenutno odgovoren za akustične senzorje HCSR04).

Na sliki ni lahko videti, vendar sem povezal iste barvne zelene in rumene žice iz IMU na MCP23017 (glej spodaj levo na sliki)

Odpraviti bomo morali nekaj težav.

4. korak: Odpravljanje težav

Z uporabo nastavitve kontinuitete na voltmetru (tistem z visokim tonom) sem preizkusil povezave VCC (5V), GND, SDA in SCL. To so bile dobre.

Naslednji poskus je bil odklopiti MCP23017 od vodila I2C, pri čemer je na vodilu ostal samo MPU-92/65. To se je izkazalo za brezplodno - "i2cdetect" potem ni pokazal nobenih naprav.

Nato sem senzor demontiral s totemskega pola in ga ponovno priključil naravnost na dvosmerno vodilo 5V do 3V; torej naravnost do maline. (krajše žice?).

In voila. Tokrat je uspeh. Vidimo, da se 0x68 prikaže z "i2cdetect".

Ampak še ne vemo, zakaj je tokrat uspelo. Je to lahko dolžina žic? Prejšnja lokacija?

Opomba: Ni pomembno, ali je bil ADO utemeljen ali ne. Morda obstajajo vgrajeni upogibni in izvlečni upori. Enako lahko velja za FSYNC.

Nato sem ponovno priključil MCP23017. Tako imamo zdaj dve vodili na vodilu I2C. (glej sliko). Uspelo, zdaj vidimo i 0x20 in 0x68 z i2cdetect.

Videoposnetki podrobneje opisujejo dogajanje med odpravljanjem težav.

5. korak: Branje podatkov senzorja

Različni pristopi

Odločil sem se za več pristopov k pridobivanju koristnih informacij od senzorja. Tu so, ne v nobenem vrstnem redu:

1. poskusite nekaj osnovnega programiranja
2. poglejte nekaj spletne dokumentacije o registrih
3. poglejte primere in / ali kodo drugih

Zakaj ti pristopi? Zakaj preprosto ne poiščete obstoječe knjižnice ali kode?

Z eksperimentiranjem in preizkušanjem nekaterih idej lahko bolje absorbiramo nekaj znanja ne le o tem posebnem senzorju, ampak tudi pridobimo nekaj tehnike, spretnosti in načinov razmišljanja o reševanju nečesa novega in nečesa, kar morda nima veliko dokumentacije; nekaj, kar ima lahko veliko neznank.

Ko smo se že poigrali in preizkusili nekaj lastnih idej ter pridobili vpogled, smo v boljšem položaju, da ocenimo kodo ali knjižnico nekoga drugega.

Na primer, ko sem si ogledal nekaj kode C ++ za MPU9250 v githubu, sem spoznal, da me sili v uporabo prekinitev, česar pa še ne želim storiti.

Na voljo so tudi dodatne stvari, kot je kalibracija; spet nekaj, kar me še ne zanima.

Morda bi lahko odgovoril na preprosto vprašanje "ali se robot vrti z da ali ne" zelo preprosto, če bi prebral nekaj registrov.

Registri

Zdi se, da ob tem pisanju na tem senzorju ni veliko na voljo. Pravzaprav, če pogledate slike, ki so priložene temu Instructableu, in natančno pogledate napise na dejanskih čipih, se sprašujem, če to ni knock-off. Ne povezujem tega, kar vidim, z ničemer iz Invensa. Ne glede na to sem se odločil pogledati podatke o registru za modele, ki sem jih našel: MPU-6050 in MPU-9250.

V obeh primerih je naslednje enako. Za začetek predvidevamo, da bo enako tudi za ta MPU-92/65.

59 do 64 - meritve merilnika pospeška

65, 66 - meritve temperature 67 do 72 - meritve žiroskopa 73 do 96 - podatki zunanjega senzorja

Opomba: Zdi se, da MPU-6050 Nima magnetometra, medtem ko ima MPU-9250 (in predvidevamo, da tudi ta), magnetometra.

Še nekaj zanimivih, upajmo, uporabnih informacij, pridobljenih iz registra registra:

Podatki o magnetometru:

ID magnetometra: 0x48 registri 00 do 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 H3 HX4 H3 HXH HX15 HX14 HX13 HZ8 HZ6 HZ6 HZ8 HZ6 ST2 0 0 0 BITM HOFL 0 0 0 razčlenitev, kaj pomeni vsak register: HXL [7: 0]: merilni podatki osi X nižji 8-bitni HXH [15: 8]: merilni podatki osi X višji 8-bitni HYL [7: 0]: Merilni podatki osi Y nižji 8-bitni HYH [15: 8]: merilni podatki osi Y višji 8-bitni HZL [7: 0]: merilni podatki osi Z nižji 8-bitni HZH [15: 8]: višji merilni podatki osi Z 8bit

Programiranje

Še en podatek iz registrskih dokumentov je, da je bilo videti le približno 100 registrov. Ena taktika bi lahko bila napisati preprost program, ki dostopa do naprave (0x68) in poskuša zaporedoma prebrati vrsto registrov, ne glede na njihov pomen, samo da bi videl, katere podatke je mogoče videti.

Nato naredite zaporedne prehode z isto kodo in primerjajte podatke enega prehoda z naslednjim.

Ideja je, da bi verjetno lahko odstranili vse registre, za katere se zdi, da nimajo podatkov (ničle ali FF?) Ali da se nikoli ne spremenijo, in se lahko osredotočimo tudi na tiste, ki se spreminjajo.

Nato pogledamo le tiste, ki se spremenijo, dodamo funkcijo povprečenja, ki povpreči najnovejše N odčitkov tega registra, da vidimo, ali dejansko obstaja določena stalna vrednost za ta register. To bi predvidevalo, da senzor držimo zelo mirno in na istem mestu.

Nazadnje bi lahko nato s senzorjem nežno preizkusili stvari, na primer potiskali ga (merilnik pospeška, žiroskop), pihali nanj (temperatura) ali ga zavrteli (prejšnja dva plus magnetometer) in videli, kako to vpliva na vrednosti.

Najraje uporabljam knjižnico wiringPi. Ima podporo za I2C.

Prvi tek:

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

* za izdelavo: gcc first.test.mpu9265.c -o first.test.mpu9265 -lwiringPi * * za zagon: sudo./first.test.mpu9265 * * ta program samo prikaže vrsto (možnih) registrov iz MCP23017, * in nato iz MPU9265 (ali katerega koli drugega MPU na tem naslovu 0x68) * * Uporabil sem ga za preverjanje, ali lahko sploh berem iz senzorja, saj sem že * imel zaupanje v MCP23017. ************************************************** **************************/ #include #include #include #include #include int main (int argc, char ** argv) {Put ("Poglejmo, kaj ima povedati MCP23017 @ 0x20:"); errno = 0; int deviceId1 = 0x20; int fd1 = ožičenjePiI2CSetup (deviceId1); if (-1 == fd1) {fprintf (stderr, "Ne morem odpreti ožičenjaPi I2C naprava: %s / n", strerror (errno)); vrnitev 1; } za (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d", wiringPiI2CReadReg8 (fd1, reg)); fflush (stderr); zamuda (10); } postavlja (""); Put ("Poglejmo, kaj ima povedati MPU9265 @ 0x20:"); errno = 0; int deviceId2 = 0x68; int fd2 = wiringPiI2CSetup (deviceId2); if (-1 == fd2) {fprintf (stderr, "Ne morem odpreti ožičenjaPi I2C naprava: %s / n", strerror (errno)); vrnitev 1; } za (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d", wiringPiI2CReadReg8 (fd2, reg)); fflush (stderr); zamuda (10); } postavlja (""); vrnitev 0; }

Drugi tek:

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

* za izdelavo: gcc second.test.mpu9265.c -o second.test.mpu9265 -lwiringPi * * za zagon: sudo./second.test.mpu9265 * * Ta program skupaj z odčitano vrednostjo prikaže številko registra. * * Zaradi tega je koristno prenašati (preusmeriti) izhod v datoteko, nato pa * za primerjavo lahko izvedete več zagonov. Morda bo dal vpogled v * kateri register je pomemben in kako se lahko obnašajo podatki. ************************************************** **************************/ #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 ("Poglejmo, kaj ima povedati MPU9265 @ 0x20:"); errno = 0; int fd = wiringPiI2CSetup (deviceId); if (-1 == fd) {fprintf (stderr, "Naprave ožičenjaPi I2C ni mogoče odpreti: %s / n", strerror (errno)); vrnitev 1; } za (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); zamuda (10); } return 0; }

Tretji tek:

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

* za izdelavo: gcc third.test.mpu9265.c -o third.test.mpu9265 -lwiringPi * * za zagon: sudo./third.test.mpu9265 * * Ta program je rezultat drugega. Bere samo iz registrov *, ki kažejo na razliko med enim in drugim tekom.************************************************** **************************/ #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 ("Poglejmo, kaj ima povedati MPU9265 @ 0x20:"); errno = 0; int fd = wiringPiI2CSetup (deviceId); if (-1 == fd) {fprintf (stderr, "Naprave ožičenjaPi I2C ni mogoče odpreti: %s / n", strerror (errno)); vrnitev 1; } za (int reg = 61; reg <= 73; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); zamuda (10); } za (int reg = 111; reg <= 112; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); zamuda (10); } for (int reg = 189; reg <= 201; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); zamuda (10); } za (int reg = 239; reg <= 240; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); zamuda (10); } return 0; }

Kaj smo se torej naučili do sedaj? Slika tabele z barvno označenimi območji kaže, da se zdi, da se izhod ujema s prvimi nizi registrov.

Dosedanji rezultati lahko ustvarijo nova vprašanja.

Vprašanje: zakaj obstaja samo en rezultat registra za "zunanjo" skupino?

Vprašanje: kaj so vsi ti neznani registri "??????"

Vprašanje: ali program ne zahteva prekinitev, ali je zahteval podatke prepočasi? prehitro?

Vprašanje: ali lahko vplivamo na rezultate tako, da preizkusimo stvari s samim senzorjem, ko teče?

6. korak: Poglejmo več v odčitke / podatke

Mislim, da je naslednji korak pred vsem drugim izboljšati program na:

• biti prilagodljiv glede na zakasnitev zanke (ms)
• prilagodite se glede števila odčitkov, da dobite tekoče povprečje na register

(Program sem moral priložiti kot datoteko. Zdi se, da je pri vstavljanju tukaj težava. "4th.test.mpu9265.c")

Tukaj je preskus z uporabo zadnjih 10 odčitkov v povprečju pri 10 ms zanki:

sudo./4th.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

Prvi, skrajno levi stolpec je registrska številka. Nato sledi zadnjih 10 odčitkov za ta register. Končno je zadnji stolpec povprečje za vsako vrstico.

Videti je, da so registri 61, 69, 71, 189, 197 in 199 bodisi samo binarni bodisi pripravljeni / nepripravljeni ali pa so visoki bajt 16-bitne vrednosti (negativno?).

Druga zanimiva opažanja:

• registri 65, 193 - zelo enakomerna in enaka vrednost
• register 63, 191 - zelo enakomerna in enaka vrednost
• registri 73, 112, 195, 201, 240 - vse na nič

Povežimo ta opažanja z večbarvno, poudarjeno podobo mize od prej.

Register 65 - temperatura

Register 193 - ??????

Register 63 - merilnik pospeška

Register 191 - ??????

Register 73 - zunanji

Registrirajte 112 in naprej - ??????

No, še vedno imamo neznance, vendar smo se naučili nekaj koristnega.

Register 65 (temperatura) in register 63 (merilnik pospeška) sta bila zelo stabilna. To je nekaj, kar bi pričakovali. Senzorja se nisem dotaknil; ne premika se, razen naključnih vibracij, saj robot počiva na isti mizi kot moj računalnik.

Za vsak od teh registrov temperature/merilnika pospeška lahko naredimo en zanimiv test. Za ta test potrebujemo še eno različico programa.

7. korak: Na temperaturo in pospeševanje lahko vplivamo

V prejšnjih korakih smo zožili vsaj en register za temperaturo in enega za pospešek.

S to naslednjo različico programa ("5th.test.mpu9265.c") lahko dejansko vidimo spremembo obeh registrov. Oglejte si videoposnetke.

Več kopanja

Če se vrnemo nazaj in si ogledamo podatke v registru, vidimo, da obstajajo:

• tri 16 -bitne izhode za žiroskop
• trije 16 -bitni izhodi za merilnik pospeška
• tri 16 -bitne izhode za magnetometer
• en 16 -bitni izhod za temperaturo

Vendar so bili rezultati, pridobljeni z našimi preprostimi preskusnimi programi, posamezni 8 -bitni izhodi. (enotni registri).

Poskusimo torej več istega pristopa, vendar tokrat branje 16 bitov namesto 8.

Verjetno bomo morali narediti nekaj podobnega spodaj. Kot primer uporabimo temperaturo, saj gre le za en 16 -bitni izhod.

// pridobim deskriptor datoteke fd …

int tempRegHi = 65; int tempRegLo = 66; int hiByte = wiringPiI2CReadReg8 (fd, tempRegHi); int loByte = wiringPiI2CReadReg8 (fd, tempRegLo); int rezultat = hiByte << 8; // damo 8 bitov najvišjega reda v zgornji del rezultata 16 -bitne vrednosti | = loByte; // zdaj dodamo 8 bitov v lo zaporedju, tako da dobimo celotno 16 -bitno število // natisnemo to številko ali uporabimo funkcijo horizontalnega grafičnega prikaza od prej

Iz prejšnjih korakov smo videli, da je register 65 precej stabilen, medtem ko je register 66 zelo hrupen. Ker je 65 bajt hi vrstnega reda, 66 pa bajt nizkega reda, je to smiselno.

Za branje lahko vzamemo podatke registra 65 takšni, kot so, lahko pa povprečje vrednosti registra 66 v povprečju.

Ali pa lahko le povprečimo celoten rezultat.

Oglejte si zadnji videoposnetek tega dela; prikazuje branje celotne vrednosti 16 -bitne temperature. Koda je "six.test.mpu9265.c"

8. korak: Merilnik pospeška in žiroskop

Videoposnetki za ta razdelek prikazujejo izhod iz merilnika pospeška in žiroskopa s testnim programom "sevennth.test.mpu9265.c". Ta koda lahko bere 1, 2 ali 3 zaporedne bajtske pare (hi in lo bajtov) in vrednosti pretvori v eno samo 16-bitno vrednost. Tako lahko beremo katero koli os, ali pa dve skupaj (in povzame spremembe), ali pa vse tri (in povzame spremembe).

Da ponovim, za to fazo, za ta Instructable, želim samo odgovoriti na preprosto vprašanje: "ali se je robot vrtel/zasukal?". Ne iščem nobene natančne vrednosti, na primer, ali se je zasukala za 90 stopinj. To se bo zgodilo kasneje, ko bomo začeli izvajati SLAM, vendar to ni potrebno za preprosto izogibanje oviram in naključno gibanje.

9. korak: (v teku) magnetometer

pri uporabi orodja i2cdetect se MPU9265 v tabeli prikaže kot 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: -- -- -- -- -- -- -- --

Za branje iz dela magnetometra IMU so potrebni dodatni koraki.

Dokumenti PDF iz registra Invesense:

REGISTRI 37 DO 39 - I2C SLAVE 0 CONTROL

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