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

2024 Autor: John Day | [email protected]. Zadnja izmjena: 2024-01-30 08:08

Nastavljamo zajedno s Wallaceom. Ime Wallace potječe od kombinacije "Wall-E" i iz prethodnog projekta (prepoznavanje glasa), a upotrebom pomoćnog programa "espeak" zvučalo je pomalo britanski. I kao sobar ili batler. I to je krajnji cilj: da se ovaj projekat pretvori u nešto korisno. Tako "Wallace".

Wallace se može kretati, može izbjegavati prepreke pomoću IC 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 konačno, može otkriti promjene u struji motora kako bi znao kada se na njega naleti.

Osim senzora, Wallace "pamti" 100 poteza i ima neke rudimentarne analize koristeći povijest pokreta.

Dosadašnji cilj Wallacea je samo pokušati nastaviti napredovati i znati kada je zaglavljen u nekom ponavljajućem obrascu (kao što je u uglu), a zapravo ne ide naprijed.

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

Budući da je Wallace robot sa gusjenicama, i htio sam 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 visokom nivou, tada se on manje -više dosljedno okreće. Međutim, za vrijeme niskog radnog ciklusa može se dogoditi da se okrene, a možda i ne. Ili se može malo okrenuti, a zatim usporiti. Čini se da se okretna radnja ne može kontrolirati putem softvera, ili u najboljem slučaju vrlo teška.

Problem se javlja tokom navigacije i kretanja oko ili od prepreka. Može se ili previše zamahati, 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 pojaviti greške itd itd. da smo mogli biti jako dobri skokom unaprijed do IR laserskih senzora za vrijeme leta. Pomoću lasera mogli smo znati je li robot rotiran ili ne, praćenjem promjena udaljenosti.

U stvari, to bismo sada mogli (nekako) i učiniti, sa akustičnim senzorima.

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

Činilo mi se da će me skok na ToF laserske senzore odvesti na sljedeći nivo 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 sistem pogona (Malina, Roboclaw, motori, kablovi itd., osnovni softver, na tastaturi)
3. neophodna kola za podršku senzorima (dvosmjerni prekidač napona, proširivač porta, E-Stop, distribucija energije itd.)
4. senzori za izbjegavanje prepreka (akustični, infracrveni)
5. bitno, osnovno pozicioniranje i kretanje - detekcija (akcelerometar, žiroskop, magnetometar, enkoderi motora, davači kotača)

Možete napraviti vlastitu listu. Primjedbe na ovoj listi 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 kako se stvari kompliciraju.

Gornja lista bi se mogla više -manje preslikati na ove konceptualne slojeve u softveru.

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

Kao što vidite, za ovu listu prve stavke bili bi gornji, složeniji slojevi koji se bave apstraktnijim pitanjima i pitanjima, poput "gdje sam" i "gdje 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, da ste ga dovršili, 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 izbalansirati koliko ćete raditi na svakom, i odlučiti je šta 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, spojimo SLAM, izbjegavanje prepreka i osnovno osnovno kretanje kao jedan problem koji treba riješiti u isto vrijeme.

1. Ako odlučimo ići putem plug-n-play, odmah prelazimo (ovisno o proračunu) na stvari poput onih montiranih na vrhu 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 drugom rutom, 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)

Šta se može reći o #1 vs #2? Jedna stvar bi bila da ćemo naučiti mnogo više radeći #2. Ograničenja upotrebe samo akustičkih senzora tjeraju nas da razmišljamo o mnogo više pitanja.

S druge strane, ako smo previše fokusirani 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 "šta", "kada", "gdje". Jer "kako" je obično pitanje nižeg nivoa o kojem ovisi "šta", "kada" i "gdje" kako bi se dobio odgovor.

U svakom slučaju, o svemu gore navedenom samo je trebalo razmišljati.

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

Dakle, 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 koji treba dodati Wallaceu je IMU. Nakon nekog istraživanja, odlučio sam se za MPU6050. Ali tada, u to vrijeme, MPU9050 (a još nedavno, MPU9250) činilo se kao još bolja ideja.

Moj izvor je Amazon (u SAD-u). Pa sam naručio dva.

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

Dodavanje je vrlo jednostavno -nabavite proto ploču sa spojnim trakama, lemite senzor na ploču, dodajte 10 -pinski vijčani terminal (moj sam nabavio iz 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 dužina žice neće biti loša.

Na drugim mjestima ima dosta informacija o osnovnim vezama i naponskim razinama itd., Pa to neću ovdje 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 su dostupni, baš kao i većina senzora, primjeri korištenja Arduina.

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

Pretpostavljam da su ti Instructables više slični blogu nego pravi 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 pratili ove serije, onda već znate za "i2cdetect", a to je prvi korak da saznate da li malina može vidjeti novi senzor.

Kao što možete vidjeti na slikama 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 sam spojio 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 je bilo dobro.

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

Dakle, zatim sam odmontirao senzor sa totemskog pola i ponovno ga spojio ravno na dvosmjernu sabirnicu 5V do 3V; odnosno ravno do maline. (kraće žice?).

I voila. Ovog puta uspeh je postignut. Vidimo da se 0x68 prikazuje pomoću "i2cdetect".

Ali još ne znamo zašto je ovaj put upalilo. Je li to možda dužina žica? Prethodna lokacija?

Napomena: Nije bilo razlike da li je 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 sa i2cdetect.

Video zapisi govore nešto više o onome što se dogodilo tokom rješavanja problema.

Korak 5: Čitanje podataka senzora

Razni pristupi

Odlučio sam uzeti više pristupa za dobijanje korisnih informacija od senzora. Evo ih, ni u kom redoslijedu:

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

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

Eksperimentirajući i isprobavajući neke ideje, 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 mnogo dokumentacije; nešto što može imati mnogo 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 na ovom pisanju nema mnogo dostupnog na ovom senzoru. Zapravo, ako pogledate slike koje dolaze s ovim Instructable-om, i pomno pogledate natpise na stvarnim čipovima, pitam se nije li ovo knock-off. Ne povezujem ono što vidim ni sa č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. Za početak, pretpostavljamo da će isto biti i za ovaj MPU-92/65.

59 do 64 - mjerenje 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 isti.

Još neke zanimljive, nadam se korisne informacije prikupljene iz dokumenta 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 HZH HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ ST2 0 0 0 BITM HOFL 0 0 0 pregled onoga što svaki registar znači: HXL [7: 0]: Podaci o mjerenju na osi X niži za 8 bita HXH [15: 8]: Mjerni podaci osi X veći za 8 bita HYL [7: 0]: Mjerni podaci osi Y osi niži 8bit HYH [15: 8]: Mjerni podaci osi Y veći 8 bit HZL [7: 0]: Podaci mjerenja osi Z manji 8 bit HZH [15: 8]: Podaci mjerenja 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.

A zatim, napravite uzastopne prolaze, koristeći isti kôd, i uporedite podatke iz jednog prolaska sa sljedećim.

Ideja je da bismo vjerojatno mogli eliminirati sve registre za koje izgleda 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čitavanja tog registra, kako bismo vidjeli postoji li uistinu određena stalna vrijednost za taj registar. Ovo bi pretpostavilo da senzor držimo vrlo mirnim i na istoj lokaciji.

Konačno, tada smo mogli lagano isprobati stvari sa senzorom, poput gurkanja (akcelerometar, žiroskop), ili puhanja na njemu (temperatura), ili rotiranja (prethodna dva plus magnetometar) i vidjeti kakav utjecaj 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 prikazuje 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 ("Hajde da vidimo šta MCP23017 @ 0x20 ima da kaže:"); errno = 0; int deviceId1 = 0x20; int fd1 = wiringPiI2CSetup (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 ("Hajde da vidimo šta MPU9265 @ 0x20 ima da kaže:"); errno = 0; int deviceId2 = 0x68; int fd2 = wiringPiI2CSetup (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 sa pročitanom vrijednošću. * * Ovo čini korisnim prijenos (preusmjeravanje) izlaza u datoteku, a zatim * može se obaviti nekoliko izvođenja, za usporedbu. To bi moglo dati neki 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 ("Hajde da vidimo šta MPU9265 @ 0x20 ima da kaže:"); errno = 0; int fd = wiringPiI2CSetup (deviceId); 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 izgradnju: gcc third.test.mpu9265.c -o third.test.mpu9265 -lwiringPi * * za pokretanje: sudo./third.test.mpu9265 * * Ovaj program je rezultat drugog. Čita samo 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 ("Hajde da vidimo šta MPU9265 @ 0x20 ima da kaže:"); errno = 0; int fd = wiringPiI2CSetup (deviceId); 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; }

Dakle, šta smo do sada naučili? Slika tabele sa obojenim označenim područjima ukazuje da izgleda da izlaz odgovara prvim skupovima registara.

Dosadašnji rezultati mogu generirati nova pitanja.

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

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

Pitanje: budući da program nije vođen prekidima, da li je zahtijevao 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 broju očitavanja kako bi dao 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./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

Prva, krajnja lijeva kolona je broj registra. Zatim slijedi posljednjih 10 očitanja tog registra. Konačno, posljednja kolona je prosjek za svaki red.

Izgleda 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?).

Ostala zanimljiva zapažanja:

• registri 65, 193 - vrlo stabilne i iste vrijednosti
• registar 63, 191 - vrlo stabilan 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 - akcelerometar

Registrirajte se 191 - ??????

Registar 73 - vanjski

Registrujte 112 i dalje - ??????

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

Registar 65 (temperatura) i registar 63 (akcelerometar) bili su vrlo stabilni. To je nešto što bismo očekivali. Nisam dodirnuo senzor; ne kreće se, osim bilo kojih sporednih vibracija, jer robot leži na istom stolu kao i moj računar.

Postoji jedan zanimljiv test koji možemo obaviti 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 koracima suzili smo barem jedan registar za temperaturu i jedan za ubrzanje.

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

More Digging

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 izlaz od 16 bita 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 navedenog. 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; // stavljamo red za visoki red 8 bita u gornji dio rezultata od 16 bita | = loByte; // sada dodajemo 8 bita po redoslijedu lo, dajući potpuni 16 -bitni broj // ispisujemo taj broj ili koristimo funkciju prikaza horizontalnog grafikona 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 procijeniti cijeli rezultat.

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

Korak 8: Akcelerometar i žiroskop

Video zapisi u ovom odjeljku prikazuju izlaz sa akcelerometra i žiroskopa, koristeći testni program "sedmi.test.mpu9265.c". Taj kôd može čitati 1, 2 ili 3 uzastopna bajt-para (hi i lo bajtova) i pretvara vrijednosti u jednu 16-bitnu vrijednost. Dakle, možemo čitati bilo koju pojedinačnu osu, ili možemo pročitati dvije zajedno (i to sumira promjene), ili možemo pročitati sve tri (i sumira promjene).

Da ponovim, za ovu fazu, za ovaj Instructable, samo želim odgovoriti na jednostavno pitanje: "da li se robot rotirao/okrenuo?". Ne tražim nikakvu preciznu vrijednost, na primjer, je li se rotirala za 90 stepeni. 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 toku) 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: -- -- -- -- -- -- -- --

Potrebni su dodatni koraci za očitavanje iz magnetometarskog dijela IMU -a.

Iz registra Invesense PDF doc:

REGISTRI 37 DO 39 - I2C SLAVE 0 CONTROL

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