Wallace - Uradi sam autonomni robot - 5. dio - Dodaj IMU: 9 koraka

2024 Autor: John Day | [email protected]. Zadnja promjena: 2024-01-30 09:36

Nastavljamo zajedno s Wallaceom. Ime Wallace potječe od mješavine "Wall-E", te iz prethodnog projekta (prepoznavanje glasa), a upotrebom pomoćnog programa "espeak" zvučalo je pomalo britanski. I poput sobarice ili batlera. I to je krajnji cilj: da se ovaj projekt pretvori u nešto korisno. Tako "Wallace".

Wallace se može kretati, može izbjeći prepreke pomoću infracrvenih senzora udaljenosti (nedavno su se nekako ispržili (?) (To moram provjeriti kad mi se ukaže prilika), ima i neke akustičke senzore udaljenosti (tri su se pokvarila u isto vrijeme vrijeme, zajedno s MCP23017 ekspanderom), i na kraju, može otkriti promjene struje motora kako bi znao kada se na njega naleti.

Osim senzora, Wallace se "sjeća" 100 poteza i ima neke rudimentarne analize pomoću povijesti kretanja.

Wallaceov je cilj do sada samo pokušavati nastaviti napredovati i znati kada je zaglavljen u nekom ponavljajućem obrascu (kao što je u kutu), a zapravo ne ide naprijed.

Prošao sam nekoliko iteracija za kretanje i navigaciju, a stalna glavobolja je bila tijekom rotacije.

Budući da je Wallace robot s gusjenicama, a ja sam htio pojednostaviti stvari u softveru (za kasnije), kako bih se okrenuo, samo sam ga zakrenuo/rotirao. Stoga primijenite jednake, ali suprotne cikluse snage / radnog ciklusa na motore.

Do problema je došlo zbog dizajna robotske platforme Agent 390. Pojasevi gusjenica imaju tendenciju trljanja o strane. I što je još gore, jedna strana to čini više od druge.

Na podovima i ravno, to nije bio problem. Pojavljuje se na tepisima. Odlučio sam držati Wallacea dalje od tepiha nakon što su tragovi postali prljavi (izuzetno lako skupljaju prljavštinu).

Pravi problem je pri okretanju na podu.

Ako softver primjenjujem radni ciklus na visokoj razini, tada se on manje -više dosljedno okreće. Međutim, tijekom niskog radnog ciklusa može se dogoditi da se okrene, ali i ne mora. Ili se može malo okrenuti, a zatim usporiti. Čini se da se radnja zakretanja ne može kontrolirati putem softvera, ili u najboljem slučaju vrlo teška.

Problem se pojavljuje tijekom navigacije i kretanja oko ili od prepreka. Može se ili previše odmaći, ili može zaglaviti pokušavajući napraviti vrlo male smjene, a da se zapravo ni ne pomakne.

I tako je gornje objašnjenje motiviralo ovaj Instructable.

U početku sam htio odustati od uvođenja jedinice za osjet kretanja (IMU) ili odgoditi njezino uvođenje jer su A) komplicirani, B) bučni, C) s vremenom se mogu uvesti greške itd. Itd. mogli smo biti jako dobri skokom naprijed do IR laserskih senzora za vrijeme leta. Pomoću lasera mogli smo znati je li robot rotirao ili ne, praćenjem promjena udaljenosti.

Zapravo, to bismo sada mogli (nekako) i učiniti, s akustičnim senzorima.

Međutim, sve je to vrlo neizravan, kompliciran način odgovora na jedno jednostavno pitanje: "jesmo li se rotirali ili nismo?"

Činilo mi se da će me skakanje pomoću ToF laserskih senzora odvesti na sljedeću razinu softvera; naime SLAM (Simultana lokalizacija i mapiranje). Nisam još bio spreman otići tamo.

Dobro je raditi projekt robota u slojevima, pri čemu su prvi (donji) slojevi jednostavniji, a potonji (gornji) slojevi apstraktniji i rješavaju teža pitanja.

Slojevi se mogu zamisliti ovako:

1. fizički okvir robota / mehanička konstrukcijska osnova
2. osnovni sustav pogona (malina, roboclaw, motori, ožičenje itd., osnovni softver, pomoću tipkovnice)
3. bitna kola za podršku senzorima (dvosmjerni prekidač napona, proširivač priključaka, E-Stop, raspodjela energije itd.)
4. senzori za izbjegavanje prepreka (akustični, infracrveni)
5. bitno, osnovno pozicioniranje i detekcija kretanja (akcelerometar, žiroskop, magnetometar, davači motora, davači kotača)

Možete sastaviti vlastiti popis. Točke ovog popisa su da biste to trebali učiniti manje -više tim redoslijedom, a također i da ako provedete neko vrijeme na svakom sloju kako biste svaki doveli u dobro radno stanje, to bi vam kasnije moglo pomoći jer se stvari kompliciraju.

Gornji popis mogao bi se više -manje preslikati na te konceptualne slojeve u softveru.

• SLAM (simultana lokalizacija i mapiranje)
• Kontrola i svijest o kretanju, rotacija
• Osnovno izbjegavanje prepreka
• Kontrola i otkrivanje podataka senzora
• Bitno kretanje naprijed, natrag, lijevo i desno, ubrzanje, usporavanje, zaustavljanje

Kao što vidite, za ovaj popis prve stavke bili bi gornji, složeniji slojevi koji se bave apstraktnijim pitanjima i pitanjima, poput "gdje sam" i "kamo idem", dok bi potonje stavke bile niže slojeve softvera koji upravljaju "kako razgovarati/slušati senzor A" ili "kako pomicati ovaj kotač".

Ne kažem da kada započnete na sloju, dovršit ćete ga, a zatim se nalazi na sljedećem sloju, da se nikada ne vratite na prethodni. Robotski projekt može biti sličan modernim, iterativnim metodama razvoja softvera (agilni, SCRUM, itd.).

Samo kažem da odvojite vrijeme za svaku. Morat ćete uravnotežiti koliko ćete raditi na svakom od njih i odlučiti je što pokušavate na određenom sloju vrijedno vremena i truda.

Postoji određeni "sukob" ili "napetost" između dvije konkurentne ideje ili smjera.

Jedno je ono što bih ja nazvao "plug-n-play" za rješavanje problema A.

Drugi je DIY (uradi sam). A to možda i nije najbolja oznaka za ovu drugu ideju.

Evo primjera svakog, nadamo se da ćete vidjeti napetost ili sukob između dva izbora.

Za ovaj primjer, skupimo SLAM, izbjegavanje prepreka i bitno osnovno kretanje kao jedan problem koji treba riješiti u isto vrijeme.

1. Odlučimo li ići putem plug-n-play, odmah ćemo (ovisno o proračunu) prijeći na stvari poput onih vrhunski rotirajućih lasera, ili kamere s dubinskom oštrinom, ili ToF lasera, te IMU (tema ove Instruktivno).
2. S druge strane, ako želimo ići drugim putem, možemo pokušati izvući svaki mogući dio informacija iz nekih akustičkih senzora ili infracrvenih senzora, ili ih uopće nema - koristimo samo nadzor struje motora (udar)

Što se može reći o #1 vs #2? Jedno bi bilo da ćemo naučiti mnogo više radeći #2. Ograničenja rada samo s akustičkim senzorima tjeraju nas da razmišljamo o puno više pitanja.

S druge strane, ako smo previše usredotočeni na obavljanje poslova putem br. 2, možda gubimo vrijeme jer od akustičnih senzora tražimo više nego što bismo trebali.

Još jedan koncept ili ideja o kojoj treba razmisliti: Koja mješavina hardvera i softvera najbolje odgovara na pitanja "kako", a koja mješavina softvera (i hardvera?) Odgovara na pitanje "što", "kada", "gdje". Jer "kako" je obično pitanje niže razine o kojem ovisi "što", "kada" i "gdje" kako bi se dobio odgovor.

U svakom slučaju, sve gore navedeno bilo je samo nešto o čemu je potrebno razmisliti.

U mom slučaju, nakon puno truda i stalnog dosadnog problema trenja kolosijeka te nemogućnosti dosljedne kontrole i kretanja, vrijeme je da učinite nešto drugo.

Stoga je ovaj Instructable - IMU.

Cilj je da ako IMU kaže da se robot NE okreće, povećavamo radni ciklus. Ako se okrećemo prebrzo, smanjujemo radni ciklus.

Korak 1: IMU senzor

Naš sljedeći senzor Wallaceu je IMU. Nakon nekog istraživanja, odlučio sam se za MPU6050. No tada se u ovom trenutku činilo da je MPU9050 (a još nedavno i MPU9250) još bolja ideja.

Moj izvor je Amazon (u SAD-u). Zato sam naručio dvije.

Ono što sam zapravo dobio (čini se da nema kontrole nad ovim; to mi se ne sviđa kod Amazona) bila su dva MPU92/65. Pitam se malo oko naziva. Pogledajte slike; čini se da je to "obiteljska" oznaka. U svakom slučaju, na tome sam zapeo.

Dodavanje je vrlo jednostavno -nabavite proto ploču sa spojnim stazama, lemite senzor na ploču, dodajte 10 -pinski vijčani terminalni blok (ja sam svoj dobio od Pololua).

Kako bih umanjio sve smetnje, pokušao sam smjestiti ove senzore dalje od svega ostalog.

To je također značilo korištenje nekih najlonskih vijaka/matica.

Koristit ću I2C protokol. Nadajmo se da ukupna duljina žice neće biti loša.

Na drugim mjestima ima dosta informacija o osnovnim vezama i razinama napona itd., Pa to ovdje neću ponavljati.

Korak 2: Stvari nisu uvijek čiste, jednostavne

Čini se da u vrijeme pisanja ovog članka nema puno interneta za ovaj MPU-92/65. Čini se da je ono što je dostupno, baš kao i kod većine senzora, primjeri korištenja Arduina.

Pokušavam učiniti ove Instructables malo drugačijima prezentirajući ne tako čist proces, jer stvari ne funkcioniraju uvijek odmah.

Pretpostavljam da su ti Instructables više slični blogu nego ravni A-B-C, 1-2-3 "ovako se radi".

Korak 3: Početni test

Iz slika u prethodnom koraku, crvene i crne žice koje idu do senzora su naravno VCC (5V) i GND. Zelena i žuta žica su I2C veze.

Ako ste radili druge I2C projekte ili ste ih pratili zajedno s ovim serijama, onda već znate za "i2cdetect", a to je prvi korak da saznate može li malina vidjeti novi senzor.

Kao što možete vidjeti iz slika u ovom koraku, naš prvi pokušaj bio je neuspješan. IMU se ne pojavljuje (trebao bi biti ID uređaja 0x68).

Međutim, dobra vijest je da I2C sabirnica radi. Vidimo jedan uređaj 0x20 i to je proširivač porta MCP23017 (trenutno je odgovoran za akustičke senzore HCSR04).

Nije lako vidjeti na slici, ali spojio sam iste boje zelene i žute žice od IMU -a na MCP23017 (vidi donji lijevi dio slike)

Morat ćemo riješiti neke probleme.

Korak 4: Rješavanje problema

Koristeći postavku kontinuiteta na voltmetru (onom s visokim tonom), testirao sam VCC (5V), GND, SDA i SCL veze. To su bile dobre.

Sljedeći pokušaj bio je odvojiti MCP23017 od sabirnice I2C, ostavljajući samo MPU-92/65 u sabirnici. To se pokazalo besplodnim - "i2cdetect" tada nije pokazao nikakve uređaje.

Dakle, zatim sam odmontirao senzor s totemskog stupa i ponovno ga spojio ravno na dvosmjernu sabirnicu 5V do 3V; tj. ravno u Malinu. (kraće žice?).

I voila. Ovaj put ima uspjeha. Vidimo da se 0x68 prikazuje pomoću "i2cdetect".

No, još ne znamo zašto je ovaj put uspjelo. Može li to biti duljina žica? Prethodno mjesto?

Napomena: Nije bilo razlike je li ADO utemeljen ili ne. Moguće je da postoje ugrađeni pullup i pull-down otpornici. Isto bi moglo biti istina i za FSYNC.

Zatim sam ponovno spojio MCP23017. Dakle, sada imamo dva uređaja na I2C sabirnici. (vidi sliku). Uspješno, sada vidimo i 0x20 i 0x68 s i2cdetect.

Videozapisi unose nešto više u ono što se dogodilo tijekom rješavanja problema.

Korak 5: Čitanje podataka senzora

Razni pristupi

Odlučio sam poduzeti više pristupa za dobivanje korisnih informacija od senzora. Evo ih, ni u kojem redoslijedu:

1. isprobajte osnovno programiranje
2. pregledajte neku internetsku dokumentaciju o registrima
3. pogledajte tuđe primjere i / ili kôd

Zašto ti pristupi? Zašto jednostavno ne potražite neku postojeću biblioteku ili kôd?

Eksperimentiranjem i isprobavanjem nekih ideja možemo bolje usvojiti određena znanja ne samo o ovom posebnom senzoru, već i steći određenu tehniku, vještinu i načine razmišljanja o rješavanju nečeg novog i nečega što možda nema puno dokumentacije; nešto što može imati puno nepoznanica.

Također, nakon što smo se poigrali i isprobali neke svoje ideje i stekli uvid, u boljoj smo poziciji procijeniti tuđi kod ili biblioteku.

Na primjer, nakon što sam pogledao neki C ++ kôd za MPU9250 u githubu, shvatio sam da me tjera na korištenje prekida, što još ne želim učiniti.

Također, dolazi s dodatnim stvarima poput kalibracije; opet nešto što me još ne zanima.

Možda se na ono što moram učiniti da odgovorim na jednostavno pitanje "rotira li robot da ili ne" može odgovoriti vrlo jednostavno samo čitanjem nekih registara.

Registri

Čini se da tijekom ovog pisanja na ovom senzoru nema mnogo dostupnog. Zapravo, ako pogledate slike koje dolaze s ovim Instructable-om i pomno pogledate natpise na stvarnim čipovima, pitat ću se nije li ovo knock-off. Ne povezujem ono što vidim ni s čim iz Invensea. Bez obzira na to, odlučio sam pogledati podatke o registru za modele koje sam pronašao: MPU-6050 i MPU-9250.

U oba slučaja slijedi isto za oba. I za početak, pretpostavljamo da će isto biti i za ovaj MPU-92/65.

59 do 64 - mjerenja akcelerometra

65, 66 - mjerenja temperature 67 do 72 - mjerenja žiroskopa 73 do 96 - podaci vanjskog senzora

Napomena: Čini se da MPU-6050 NEMA magnetometar, dok MPU-9250 (a pretpostavljamo i ovaj) ima takav.

Još neke zanimljive, nadam se korisne informacije prikupljene iz registra registra:

Podaci 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 HX HZ HZ HZ HZ HZ HZ HZ HZ HZ ST2 0 0 0 BITM HOFL 0 0 0 raščlamba onoga što svaki registar znači: HXL [7: 0]: mjerni podaci osi X manji 8 bit HXH [15: 8]: mjerni podaci osi X viši 8 bitni HYL [7: 0]: Mjerni podaci osi Y manji 8 bit HYH [15: 8]: Mjerni podaci osi Y veći 8 bit HZL [7: 0]: Mjerni podaci osi Z manji 8 bit HZH [15: 8]: Mjerni podaci osi Z veći 8bit

Programiranje

Još jedan podatak iz registarskih dokumenata je da se činilo da postoji samo oko 100 registara. Tako bi jedna taktika mogla biti pisanje jednostavnog programa koji pristupa uređaju (0x68) i pokušava čitati niz registra uzastopno, bez obzira na njihovo značenje, samo da bi se vidjeli kakvi se podaci mogu vidjeti.

Zatim učinite uzastopne prolaze koristeći isti kôd i usporedite podatke iz jednog prolaza u odnosu na sljedeći.

Ideja je da bismo vjerojatno mogli eliminirati sve registre za koje se čini da nemaju podatke (nule ili FF?) Ili koji se apsolutno nikada ne mijenjaju, a mogli bismo se i usredotočiti na one koji se mijenjaju.

Zatim, gledamo samo one koji se mijenjaju, dodajući funkciju usrednjavanja koja daje prosjek najnovijih N očitanja tog registra, kako bismo vidjeli postoji li uistinu određena stalna vrijednost za taj registar. To bi pretpostavilo da senzor držimo vrlo mirnim i na istom mjestu.

Konačno, tada smo mogli lagano isprobati stvari sa senzorom, poput gurkanja (akcelerometar, žiroskop), ili puhanja na njemu (temperatura), ili zakretanja (prethodna dva plus magnetometar) i vidjeti kakav učinak to ima na vrijednosti.

Volim koristiti biblioteku wiringPi što je više moguće. Ima podršku za I2C.

Prva vožnja:

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

* za izgradnju: gcc first.test.mpu9265.c -o first.test.mpu9265 -lwiringPi * * za pokretanje: sudo./first.test.mpu9265 * * ovaj program samo izbacuje niz (mogućih) registara iz MCP23017, * a zatim iz MPU9265 (ili bilo kojeg drugog MPU -a na toj adresi 0x68) * * Koristio sam ga za provjeru mogu li uopće čitati sa senzora, budući da sam već * imao povjerenje u MCP23017. ************************************************** ****************************/ #include #include #include #include #include int main (int argc, char ** argv) {Put ("Pogledajmo što MCP23017 @ 0x20 ima za reći:"); errno = 0; int deviceId1 = 0x20; int fd1 = ožičenjePiI2CSetup (deviceId1); if (-1 == fd1) {fprintf (stderr, "Ne mogu otvoriti ožičenjePi I2C uređaj: %s / n", strerror (errno)); return 1; } za (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d", wiringPiI2CReadReg8 (fd1, reg)); fflush (stderr); kašnjenje (10); } stavlja (""); Put ("Pogledajmo što MPU9265 @ 0x20 ima za reći:"); errno = 0; int deviceId2 = 0x68; int fd2 = ožičenjePiI2CSetup (deviceId2); if (-1 == fd2) {fprintf (stderr, "Ne mogu otvoriti ožičenjePi I2C uređaj: %s / n", strerror (errno)); return 1; } za (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d", wiringPiI2CReadReg8 (fd2, reg)); fflush (stderr); kašnjenje (10); } stavlja (""); return 0; }

Druga vožnja:

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

* za izgradnju: gcc second.test.mpu9265.c -o second.test.mpu9265 -lwiringPi * * za pokretanje: sudo./second.test.mpu9265 * * Ovaj program prikazuje broj registra zajedno s pročitanom vrijednošću. * * To čini korisnim prijenos (preusmjeravanje) rezultata u datoteku, a zatim * može se obaviti nekoliko izvođenja, za usporedbu. To bi moglo dati uvid u to * koji su registri važni i kako bi se podaci mogli ponašati. ************************************************** ****************************/ #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 ("Pogledajmo što MPU9265 @ 0x20 ima za reći:"); errno = 0; int fd = ožičenjePiI2CSetup (ID uređaja); if (-1 == fd) {fprintf (stderr, "Ne mogu otvoriti ožičenjePi I2C uređaj: %s / n", strerror (errno)); return 1; } za (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); kašnjenje (10); } return 0; }

Treća vožnja:

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

* za izradu: gcc third.test.mpu9265.c -o third.test.mpu9265 -lwiringPi * * za pokretanje: sudo./third.test.mpu9265 * * Ovaj program je rezultat drugog. Ona samo čita iz * registara koji su ukazivali na razliku između jedne i druge vožnje.************************************************** ****************************/ #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 ("Pogledajmo što MPU9265 @ 0x20 ima za reći:"); errno = 0; int fd = ožičenjePiI2CSetup (ID uređaja); if (-1 == fd) {fprintf (stderr, "Ne mogu otvoriti ožičenjePi I2C uređaj: %s / n", strerror (errno)); return 1; } za (int reg = 61; reg <= 73; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); kašnjenje (10); } za (int reg = 111; reg <= 112; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); kašnjenje (10); } za (int reg = 189; reg <= 201; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); kašnjenje (10); } za (int reg = 239; reg <= 240; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); kašnjenje (10); } return 0; }

Što smo do sada naučili? Slika tablice s označenim područjima u boji ukazuje da se čini da izlaz odgovara prvim skupovima registara.

Dosadašnji rezultati mogu generirati nova pitanja.

Pitanje: zašto postoji samo jedan rezultat registra za "vanjsku" skupinu?

Pitanje: koji su to svi ti nepoznati registri "??????"

Pitanje: budući da program nije vođen prekidima, je li zahtjevao podatke presporo? prebrzo?

Pitanje: Možemo li utjecati na rezultate pokušavajući sa samim senzorom dok radi?

Korak 6: Kopajmo više u očitanja / podatke

Mislim da je sljedeći korak prije svega poboljšanje programa na:

• biti fleksibilan u pogledu kašnjenja petlje (ms)
• biti fleksibilan u tome koliko očitavanja dati tekući prosjek po registru

(Morao sam priložiti program kao datoteku. Činilo se da je problem umetanjem ovdje. "4th.test.mpu9265.c")

Evo pokusa koji koristi prosječno zadnjih 10 očitanja, u petlji od 10 ms:

sudo./četvrti.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

Prva, krajnja lijeva kolona je broj registra. Zatim slijedi posljednjih 10 očitanja za taj registar. Konačno, posljednji stupac je prosjek za svaki redak.

Čini se da su registri 61, 69, 71, 189, 197 i 199 ili samo binarni, ili spremni / nisu spremni, ili su visoki bajt 16-bitne vrijednosti (negativan?).

Druga zanimljiva zapažanja:

• registri 65, 193 - vrlo postojana i iste vrijednosti
• registar 63, 191 - vrlo postojan i iste vrijednosti
• registri 73, 112, 195, 201, 240 - sve na nuli

Povežimo ova zapažanja s višebojnom, istaknutom slikom stola od ranije.

Registar 65 - temperatura

Registrirajte se 193 - ??????

Registar 63 - mjerač ubrzanja

Registar 191 - ??????

Registar 73 - vanjski

Registrirajte 112 i dalje - ??????

Pa, još uvijek imamo nepoznanica, međutim, naučili smo nešto korisno.

Registar 65 (temperatura) i registar 63 (mjerač ubrzanja) bili su vrlo stabilni. Ovo je nešto što bismo očekivali. Nisam dodirnuo senzor; ne miče se, osim slučajnih vibracija, jer robot leži na istom stolu kao i moje računalo.

Postoji jedan zanimljiv test za svaki od ovih registara temperature/akcelerometra. Za taj test potrebna nam je još jedna verzija programa.

Korak 7: Možemo utjecati na temperaturu i ubrzanje

U prethodnim smo koracima suzili barem jedan registar za temperaturu i jedan za ubrzanje.

S ovom sljedećom verzijom programa ("5th.test.mpu9265.c") možemo vidjeti promjenu u oba registra. Molimo pogledajte video zapise.

Više Kopanje

Ako se vratimo i pogledamo podatke iz registra, vidimo da postoje:

• tri 16 -bitna izlaza za žiroskop
• tri 16 bitna izlaza za akcelerometar
• tri 16 bitna izlaza za magnetometar
• jedan 16 -bitni izlaz za temperaturu

Međutim, rezultati dobiveni pomoću naših jednostavnih programa ispitivanja bili su pojedinačni 8 -bitni izlazi. (jedinstveni registri).

Pokušajmo više s istim pristupom, ali ovaj put čitajući 16 bita umjesto 8.

Vjerojatno ćemo morati učiniti nešto poput dolje. Upotrijebimo temperaturu kao primjer, budući da je to samo jedan 16 -bitni izlaz.

// dobivanje deskriptora datoteke fd …

int tempRegHi = 65; int tempRegLo = 66; int hiByte = wiringPiI2CReadReg8 (fd, tempRegHi); int loByte = wiringPiI2CReadReg8 (fd, tempRegLo); int rezultat = hiByte << 8; // stavi hi bit red 8 bita u gornji dio rezultata od 16 bita vrijednosti | = loByte; // sada dodajemo 8 bita u lo redoslijedu, dajući potpuni 16 -bitni broj // ispišite taj broj ili upotrijebite funkciju horizontalnog grafičkog prikaza od ranije

Iz naših prethodnih koraka vidjeli smo da je registar 65 prilično stabilan, dok je registar 66 vrlo bučan. Budući da je 65 bajt hi reda, a 66 bajt niskog reda, to ima smisla.

Za čitanje možemo uzeti podatke registra 65 takvi kakvi jesu, ali bismo mogli prosječno ocijeniti vrijednosti registra 66.

Ili možemo samo prosjek cijelog rezultata.

Pogledajte posljednji video za ovaj dio; pokazuje čitanje cijele vrijednosti temperature od 16 bita. Kôd je "šesti.test.mpu9265.c"

Korak 8: Akcelerometar i žiroskop

Video zapisi u ovom odjeljku prikazuju izlaz iz akcelerometra i žiroskopa, koristeći testni program "seventh.test.mpu9265.c". Taj kôd može čitati 1, 2 ili 3 uzastopna parova bajtova (hi i lo bajtova) i pretvara vrijednosti u jednu vrijednost od 16 bita. Dakle, možemo čitati bilo koju pojedinačnu os, ili možemo pročitati dvije zajedno (i to zbraja promjene), ili možemo pročitati sve tri (i sažimaju promjene).

Da ponovim, za ovu fazu, za ovaj Instructable, samo želim odgovoriti na jednostavno pitanje: "je li se robot rotirao/zakrenuo?". Ne tražim nikakvu preciznu vrijednost, na primjer, je li se rotirala za 90 stupnjeva. To će doći kasnije kada počnemo raditi SLAM, ali nije potrebno za jednostavno izbjegavanje prepreka i nasumično kretanje.

Korak 9: (rad u tijeku) Magnetometar

kada koristite alat i2cdetect, MPU9265 se prikazuje kao 0x68 u tablici:

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 očitavanje magnetometarskog dijela IMU -a potrebni su dodatni koraci.

Iz registra Invesense PDF doc:

REGISTRI 37 DO 39 - I2C SLAVE 0 UPRAVLJANJE

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