Wallace - DIY -itsenäinen robotti - Osa 5 - Lisää IMU: 9 vaihetta

2024 Kirjoittaja: John Day | [email protected]. Viimeksi muokattu: 2024-01-30 09:02

Jatkamme Wallacen kanssa. Nimi Wallace tuli sekoituksesta "Wall-E" ja edellisestä projektista (äänentunnistus), ja "espeak" -apuohjelmassa se kuulosti hieman brittiläiseltä. Ja kuten palvelija tai hovimestari. Ja se on lopullinen tavoite: että tämä projekti muuttuu hyödylliseksi. Siis "Wallace".

Wallace voi liikkua, hän voi välttää esteitä käyttämällä IR -etäisyysantureita (äskettäin ne jotenkin paistoivat (?) (Täytyy tutkia sitä, kun saan tilaisuuden)), ja siinä on myös joitain akustisia etäisyysantureita (kolme niistä meni huonosti samaan aikaan aika, yhdessä MCP23017-laajennuksen kanssa) ja lopuksi voi havaita muutokset moottorivirrassa tietääkseen, milloin se törmää johonkin.

Anturien lisäksi Wallace "muistaa" 100 liikettä, ja hänellä on alkeellinen analyysi liikehistorian avulla.

Toistaiseksi Wallacen tavoitteena on vain yrittää jatkaa eteenpäin ja tietää, milloin se on juuttunut johonkin toistuvaan kuvioon (kuten nurkkaan) eikä todellakaan mene eteenpäin.

Olen käynyt läpi useita liikkeen ja navigoinnin iteraatioita, ja jatkuva päänsärky on ollut pyörimisen aikana.

Koska Wallace on seurattu robotti, ja halusin pitää asiat yksinkertaisempina ohjelmistossa (myöhempää käyttöä varten), jotta voisin kääntää hänet vain kääntämään/kiertämään. Käytä siis yhtäläistä, mutta päinvastaista teho / käyttöjaksoa moottoreihin.

Ongelma johtuu Agent 390 -robottialustan suunnittelusta. Kiskohihnat taipuvat hankaamaan sivuja vasten. Ja mikä pahempaa, toinen puoli tekee niin enemmän kuin toinen.

Lattialla ja suoraan menossa se ei ole ollut ongelma. Se näkyy matoissa. Päätin pitää Wallacen pois matosta sen jälkeen, kun sen kappaleet ovat saaneet mustan (ne keräävät likaa erittäin helposti).

Todellinen ongelma on, kun käännetään lattiaa.

Jos minulla on ohjelmisto soveltaa korkean tason toimintajaksoa, se kääntyy enemmän tai vähemmän jatkuvasti. Pienen käyttöjakson aikana se voi kuitenkin kääntyä tai ei. Tai se voi kääntyä hetkeksi ja sitten hidastaa. Kääntötoiminto näyttää olevan hallitsematon ohjelmiston avulla tai parhaimmillaan erittäin vaikea.

Ongelma ilmenee navigoinnin aikana ja esteiden ympäri liikkuessa. Se voi heilua liian villisti pois tai se voi jäädä jumiin yrittäessään tehdä pieniä muutoksia ilman, että edes liikkuu.

Ja niin yllä oleva selitys motivoi tätä Instructablea.

Alun perin halusin luopua liiketunnistusyksikön (IMU) käyttöönotosta tai viivästyttää sen käyttöönottoa, koska ne ovat A) monimutkaisia, B) meluisia, C) virheitä voi tulla ajan myötä jne. Jne. Ajatukseni oli Voimme pärjätä erittäin hyvin hyppäämällä lennon aikaisten IR-lasersensorien eteen. Ja me voisimme - laserien avulla tiesimme, pyöriikö robotti vai ei, seuraamalla etäisyyden muutoksia.

Itse asiassa voisimme (tavallaan) tehdä sen nyt myös akustisten antureiden avulla.

Kaikki tämä on kuitenkin hyvin epäsuora, monimutkainen tapa vastata yhteen yksinkertaiseen kysymykseen: "olemme kiertäneet vai emme?"

Minusta tuntui, että siirtyminen ToF -lasersensorien käyttöön vie minut seuraavalle ohjelmistotasolle; nimittäin SLAM (samanaikainen lokalisointi ja kartoitus). En ollut vielä valmis menemään sinne.

On hyvä tehdä robottiprojekti kerroksittain, kun ensimmäiset (alemmat) kerrokset ovat yksinkertaisempia ja jälkimmäiset (ylemmät) kerrokset ovat abstraktimpia ja käsittelevät vaikeampia asioita.

Kerroksia voidaan ajatella seuraavasti:

1. robotin fyysinen runko / mekaaninen rakenteellinen perusta
2. alkeellinen käyttöjärjestelmä (Vadelma, Roboclaw, moottorit, kaapelointi jne., perusohjelmisto, näppäimistöohjattu)
3. olennaiset piirit antureiden tukemiseen (kaksisuuntainen jännitteenvaihtaja, portin laajennin, E-Stop, virranjakelu jne.)
4. esteiden välttämisen anturit (akustinen, IR)
5. välttämätön perusasemointi ja liike - havaitseminen (kiihtyvyysmittari, gyroskooppi, magnetometri, moottorianturit, pyöränkooderit)

Voit keksiä oman listasi. Tämän luettelon kohdat ovat, että sinun pitäisi todennäköisesti tehdä nämä enemmän tai vähemmän tässä järjestyksessä, ja myös, että jos vietät jonkin aikaa kullakin kerroksella saadaksesi jokaisen toimivaan tilaan, sen pitäisi auttaa sinua myöhemmin, kun asiat muuttuvat monimutkaisemmiksi.

Yllä oleva luettelo voitaisiin enemmän tai vähemmän yhdistää näihin ohjelmistokäsitteisiin.

• SLAM (samanaikainen lokalisointi ja kartoitus)
• Liikkeen hallinta ja tietoisuus, kierto
• Perus esteiden välttäminen
• Anturitietojen valvonta ja havaitseminen
• Olennainen liike eteenpäin, taaksepäin, vasemmalle ja oikealle, nopeuta, hidasta, pysäytä

Kuten näette, tässä luettelossa ensimmäiset kohdat olisivat ylemmät, monimutkaisemmat kerrokset, jotka käsittelevät abstraktimpia kysymyksiä ja kysymyksiä, kuten "missä olen" ja "minne olen menossa", kun taas jälkimmäiset kohdat olisivat alemmat ohjelmistokerrokset, jotka käsittelevät "kuinka puhua/kuunnella anturia A" tai "miten tätä pyörää liikutetaan".

Nyt en sano, että kun aloitat kerroksesta, olet suorittanut sen ja sitten se on seuraavassa kerroksessa, älä koskaan palaa edelliseen. Robottiprojekti voi olla paljon kuin nykyaikaiset, iteratiiviset ohjelmistokehitysmenetelmät (ketterä, SCRUM jne.).

Sanon vain, että vie aikaa jokaiselle. Sinun on tasapainotettava, kuinka paljon tehdä kussakin, ja päättää, mitä yrität tietyllä kerroksella, joka kannattaa aikaa ja vaivaa.

Kahden kilpailevan idean tai suunnan välillä on tietty "konflikti" tai "jännitys".

Yksi on se, mitä kutsuisin "plug-n-play" -ratkaisuksi ongelman A ratkaisemiseksi.

Toinen on DIY (tee se itse). Ja se ei ehkä ole edes paras merkki tälle toiselle ajatukselle.

Tässä on esimerkki jokaisesta, toivottavasti näet jännityksen tai ristiriidan kahden valinnan välillä.

Tässä esimerkissä kerrotaan SLAM, esteiden välttäminen ja välttämätön perusliike yhdeksi ongelmaksi samaan aikaan.

1. Jos päätämme mennä plug-n-play-reitille, siirrymme heti (budjetista riippuen) sellaisiin asioihin, kuten ylhäältä asennetut pyörivät laserit, terävyysaluekamera tai ToF-laserit ja IMU (tämän aihe Ohjeellinen).
2. Jos toisaalta haluamme mennä toista reittiä, voimme yrittää poimia kaikki mahdolliset tiedot joistakin akustisista antureista tai infrapuna -antureista tai ei ollenkaan - käytämme vain moottorin virranvalvontaa (bump)

Mitä voidaan sanoa numeroista 1 ja 2? Yksi asia olisi, että opimme paljon enemmän tekemällä #2. Rajoitukset, jotka koskevat vain akustisten antureiden käyttöä, pakottavat meidät miettimään paljon muita asioita.

Toisaalta, jos olemme liian keskittyneitä asioiden tekemiseen numeron 2 kautta, saatamme tuhlata aikaa, koska pyydämme enemmän kuin meidän pitäisi akustisista antureista.

Vielä yksi ajatus ajatuksesta: Mikä laitteisto- ja ohjelmistoseos vastaa parhaiten kysymyksiin "miten", ja mikä seos ohjelmistoja (ja laitteistoja?) Vastaa kysymyksiin "mitä", "milloin", "missä". Koska "miten" on tyypillisesti alemman tason kysymys, josta "mitä", "milloin" ja "missä" riippuu vastauksen saamisesta.

Joka tapauksessa kaikki edellä mainitut olivat vain ajattelemisen aihetta.

Minun tapauksessani, kun olen tehnyt paljon työtä ja minulla on johdonmukainen ärsyttävä ongelma radan kitkasta ja kyvyttömyys saada johdonmukaista hallintaa ja liikettä, on aika tehdä jotain muuta.

Näin tämä opastettava - IMU.

Tavoitteena on, että jos IMU sanoo, että robotti EI pyöri, nostamme käyttöjaksoa. Jos käännämme liian nopeasti, lyhennämme käyttöjaksoa.

Vaihe 1: IMU -anturi

Ja seuraava Wallaceen lisättävä anturi on IMU. Jonkin tutkimuksen jälkeen päädyin MPU6050: een. Mutta silloin tällä hetkellä MPU9050 (ja vielä äskettäin MPU9250) näytti vielä paremmalta idealta.

Lähteeni on ollut Amazon (Yhdysvalloissa). Joten tilasin niistä kaksi.

Sain itse asiassa (ei näytä olevan mitään valvontaa tähän; en pidä Amazonista) kaksi MPU92/65. Ihmettelen hieman nimitystä. Katso kuvia; se näyttää olevan "perheen" nimitys. Joka tapauksessa olen siihen jumissa.

Sen lisääminen on hyvin yksinkertaista -hanki proto -kortti, jossa on liitäntäkiskot, juota anturi levyyn, lisää 10 -nastainen ruuviliitin (sain omani Pololusta).

Häiriöiden minimoimiseksi yritin sijoittaa nämä anturit pois kaikesta muusta.

Tämä tarkoitti myös joidenkin nylonpulttien/muttereiden käyttöä.

Aion käyttää I2C -protokollaa. Toivottavasti langan kokonaispituus ei ole huono.

Muualla on paljon tietoa peruskytkennöistä ja jännitetasoista jne., Joten en toista tätä täällä.

Vaihe 2: Asiat eivät ole aina puhtaita, helppoja

Tässä kirjoituksessa ei näytä olevan paljon verkossa tälle MPU-92/65: lle. Käytettävissä olevat, kuten useimmat anturit, näyttävät olevan esimerkkejä Arduinon käytöstä.

Yritän tehdä näistä ohjeista hieman erilaisia esittämällä ei-niin puhdasta prosessia, koska asiat eivät aina toimi heti.

Oletan, että nämä ohjeet ovat enemmän samankaltaisia kuin blogi kuin suora A-B-C, 1-2-3 "näin teet sen".

Vaihe 3: Alkutesti

Edellisen vaiheen kuvista antureihin menevät punaiset ja mustat johdot ovat tietysti VCC (5V) ja GND. Vihreä ja keltainen johto ovat I2C -liitännät.

Jos olet tehnyt muita I2C -projekteja tai olet seurannut näitä sarjoja, tiedät jo "i2cdetect" -toiminnon, ja tämä on ensimmäinen askel tietää, näkeekö Vadelma uuden anturin.

Kuten tämän vaiheen kuvista näkyy, ensimmäinen yrityksemme epäonnistui. IMU ei tule näkyviin (sen pitäisi olla laitetunnus 0x68).

Hyvä uutinen on kuitenkin se, että I2C -väylä toimii. Näemme yhden laitteen 0x20 ja se on MCP23017 -portin laajennin (tällä hetkellä vastuussa HCSR04 -akustisista antureista).

Se ei ole helppo nähdä kuvassa, mutta liitin samat värilliset vihreät ja keltaiset johdot IMU: sta MCP23017: een (katso kuvan vasen alareuna)

Meidän on tehtävä joitakin vianmäärityksiä.

Vaihe 4: Vianetsintä

Käytin volttimittarin jatkuvuusasetusta (korkean äänen sävy), testasin VCC (5V), GND, SDA ja SCL -liitäntöjä. Ne olivat hyviä.

Seuraavaksi yritettiin irrottaa MCP23017 I2C-väylästä jättäen vain MPU-92/65 väylälle. Se osoittautui tuloksettomaksi - "i2cdetect" ei sitten näyttänyt mitään laitteita.

Joten seuraavaksi irrotin anturin totemipylväästä ja johdotin sen suoraan 5V-3V kaksisuuntaiseen väylään; eli suoraan vadelmaan. (lyhyemmät johdot?).

Ja voila. Tällä kertaa menestystä. Näemme, että 0x68 näkyy "i2cdetect" -toiminnolla.

Mutta emme vielä tiedä, miksi se toimi tällä kertaa. Voisiko se olla johtimien pituus? Edellinen sijainti?

Huomautus: Ei ollut väliä, oliko ADO maadoitettu vai ei. Voi olla, että junassa on pullup- ja pull-down -vastuksia. Sama voi koskea FSYNC: tä.

Seuraavaksi liitin MCP23017 uudelleen. Joten nyt meillä on kaksi laitetta I2C -väylässä. (katso kuva). Menestys, nyt näemme sekä 0x20 että 0x68 i2cdetectin avulla.

Videot kertovat hieman enemmän siitä, mitä vianmäärityksen aikana tapahtui.

Vaihe 5: Anturin tietojen lukeminen

Erilaisia lähestymistapoja

Päätin käyttää useita tapoja saada hyödyllistä tietoa anturista. Tässä ne ovat, ei missään järjestyksessä:

1. kokeile perusohjelmointia
2. selaa joitain online -asiakirjoja rekistereistä
3. katso muiden esimerkkejä ja / tai koodia

Miksi nämä lähestymistavat? Miksi et etsi vain olemassa olevaa kirjastoa tai koodia?

Kokeilemalla ja kokeilemalla joitain ideoita voimme paremmin omaksua tietoa tästä anturista, mutta myös saada jonkin tekniikan, taidon ja ajattelutavan käsitellä jotain uutta ja jotain, jolla ei ehkä ole paljon asiakirjoja; jotain, jolla voi olla paljon tuntemattomia.

Lisäksi, kun olemme leikkineet ja kokeilleet joitain omia ideoitamme ja saaneet oivalluksia, voimme paremmin arvioida jonkun muun koodia tai kirjastoa.

Esimerkiksi kun katsoin Githubissa MPU9250: n jotakin C ++ -koodia, tajusin, että se pakotti minut käyttämään keskeytyksiä, joita en vielä halua tehdä.

Sen mukana tulee myös muita asioita, kuten kalibrointi; taas asia, josta en ole vielä kiinnostunut.

Voi olla, että mitä minun on tehtävä vastatakseni yksinkertaiseen kysymykseen "onko robotti pyörii kyllä vai ei", voitaisiin vastata hyvin yksinkertaisesti vain lukemalla joitain rekistereitä.

Rekisterit

Tässä kirjoituksessa tällä anturilla ei näytä olevan paljon saatavilla. Itse asiassa, jos katsot tämän Instructable-ohjelman mukana tulevia kuvia ja tarkastelet tarkasti todellisten pelimerkkien merkintöjä, se saa minut ihmettelemään, onko tämä koputus. En yhdistä näkemääni mihinkään Invenseen. Siitä huolimatta päätin tarkastella löytämieni mallien rekisteritietoja: MPU-6050 ja MPU-9250.

Molemmissa tapauksissa seuraava on sama molemmille. Ja aluksi oletamme, että se on sama myös tämän MPU-92/65: n kohdalla.

59-64 - kiihtyvyysmittarin mittaukset

65, 66 - lämpötilamittaukset 67--72 - gyroskooppimittaukset 73--96 - ulkoisten anturien tiedot

Huomautus: MPU-6050: ssä EI ole magnetometriä, kun taas MPU-9250: ssä (ja oletamme myös tämän) on sellainen.

Muutamia mielenkiintoisia, toivottavasti hyödyllisiä tietoja kerättiin rekisteriasiakirjasta:

Magnetometrin tiedot:

magnetometrin tunnus: 0x48 rekisteröi 00 - 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 H0 HXH HX15 HX14 HX13 HX12 HX11 HX10 HX9 HX8 05H HYL HY7 HY6 HY5 HY4 HY3 HY2 HY1 HY0 06H HYH HY15 HY14 HY13 HY12 HY11 HY10 HY10 ST2 0 0 0 BITM HOFL 0 0 0 erittely kunkin rekisterin merkityksestä: HXL [7: 0]: X-akselin mittaustiedot alemmat 8 bit HXH [15: 8]: X-akselin mittaustiedot korkeammat 8 bit HYL [7: 0]: Y-akselin mittaustiedot alemmat 8-bittinen HYH [15: 8]: Y-akselin mittaustiedot korkeammat 8-bittinen HZL [7: 0]: Z-akselin mittaustiedot pienemmät 8-bittinen HZH [15: 8]: Z-akselin mittaustiedot korkeammat 8 bittiä

Ohjelmointi

Toinen rekisteritiedoista saatu tieto on, että rekistereitä näytti olevan vain noin 100. Joten yksi taktiikka voisi olla kirjoittaa yksinkertainen ohjelma, joka käyttää laitetta (0x68) ja yrittää lukea useita rekistereitä peräkkäin, ottamatta huomioon niiden merkitystä, vain nähdäkseen mitä tietoja voidaan nähdä.

Ja sitten, suorita peräkkäiset passit käyttäen samaa koodia ja vertaa tietoja yhdestä passista toiseen.

Ajatuksena on, että voisimme luultavasti poistaa kaikki rekisterit, joilla ei näytä olevan tietoja (nollat tai FF?) Tai jotka eivät koskaan muutu, ja voisimme myös keskittyä niihin, jotka muuttuvat.

Sitten, kun tarkastelemme vain niitä, jotka muuttuvat, lisää keskiarvotoiminto, joka keskittää kyseisen rekisterin viimeisimmät N -lukemat, nähdäkseen, onko kyseisellä rekisterillä itse asiassa tietty vakaa arvo. Tämä olettaisi, että pidämme anturin hyvin paikallaan ja samassa paikassa.

Lopuksi voisimme sitten kokeilla varovasti asioita anturilla, kuten työntää sitä (kiihtyvyysmittari, gyroskooppi) tai puhaltaa sitä (lämpötila) tai kiertää sitä (kaksi edellistä plus magnetometriä) ja nähdä, miten tämä vaikuttaa arvoihin.

Käytän mielelläni wiringPi -kirjastoa mahdollisimman paljon. Se tukee I2C: tä.

Ensimmäinen juoksu:

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

* rakentaa: gcc first.test.mpu9265.c -o first.test.mpu9265 -lwiringPi * * ajaa: sudo./first.test.mpu9265 * * tämä ohjelma antaa vain joukon (mahdollisia) rekistereitä MCP23017: stä, * ja sitten MPU9265: stä (tai mistä tahansa muusta MPU: sta kyseisellä 0x68 -osoitteella) ************************************************** ****************************/ #Sisällytä #sisällytä #sisällytä #sisällytä #sisällytä int pää {put ("Katsotaanpa mitä MCP23017 @ 0x20 sanoo:"); virhe = 0; int deviceId1 = 0x20; int fd1 = wiringPiI2CSetup (deviceId1); if (-1 == fd1) {fprintf (stderr, "WiringPi I2C -laitetta ei voi avata: %s / n", strerror (errno)); paluu 1; } for (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d", wiringPiI2CReadReg8 (fd1, reg)); fflush (stderr); viive (10); } laittaa (""); put ("Katsotaanpa mitä MPU9265 @ 0x20 sanoo:"); virhe = 0; int deviceId2 = 0x68; int fd2 = wiringPiI2CSetup (deviceId2); if (-1 == fd2) {fprintf (stderr, "WiringPi I2C -laitetta ei voi avata: %s / n", strerror (errno)); paluu 1; } for (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d", wiringPiI2CReadReg8 (fd2, reg)); fflush (stderr); viive (10); } laittaa (""); palauta 0; }

Toinen ajo:

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

* rakentaa: gcc second.test.mpu9265.c -o second.test.mpu9265 -lwiringPi * * suoritettavaksi: sudo./second.test.mpu9265 * * Tämä ohjelma tulostaa rekisterinumeron luetun arvon rinnalle. * * Tämän vuoksi on hyödyllistä ohjata (uudelleenohjata) tulostus tiedostoon ja sitten * tehdä useita ajoja vertailtavaksi. Se voi antaa jonkin verran tietoa * siitä, mitkä rekisterit ovat tärkeitä ja miten tiedot voivat toimia. ************************************************** ******************************************************** argv) {int deviceId = -1; jos (0) {} muu jos (! 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; } esittää ("Katsotaanpa mitä MPU9265 @ 0x20 sanoo:"); virhe = 0; int fd = wiringPiI2CSetup (deviceId); if (-1 == fd) {fprintf (stderr, "WiringPi I2C -laitetta ei voi avata: %s / n", strerror (errno)); paluu 1; } for (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); viive (10); } palauta 0; }

Kolmas juoksu:

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

* rakentaa: gcc kolmas.test.mpu9265.c -o kolmas.test.mpu9265 -lwiringPi * * suoritettavaksi: sudo./third.test.mpu9265 * * Tämä ohjelma on seurausta toisesta. Se lukee vain * rekistereistä, jotka osoittivat eron ajon ja seuraavan välillä.************************************************** ******************************************************** argv) {int deviceId = -1; jos (0) {} muu jos (! strncmp (argv [1], "0x68", strlen ("0x68"))) {deviceId = 0x68; } else if (! strncmp (argv [1], "0x69", strlen ("0x69"))) {deviceId = 0x69; } esittää ("Katsotaanpa mitä MPU9265 @ 0x20 sanoo:"); virhe = 0; int fd = wiringPiI2CSetup (deviceId); if (-1 == fd) {fprintf (stderr, "WiringPi I2C -laitetta ei voi avata: %s / n", strerror (errno)); paluu 1; } for (int reg = 61; reg <= 73; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); viive (10); } for (int reg = 111; reg <= 112; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); viive (10); } for (int reg = 189; reg <= 201; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); viive (10); } for (int reg = 239; reg <= 240; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); viive (10); } palauta 0; }

Joten mitä olemme oppineet tähän mennessä? Taulukon kuva, jossa on värillisiä korostettuja alueita, osoittaa, että tulos näyttää vastaavan ensimmäisiä rekisterisarjoja.

Tähänastiset tulokset voivat synnyttää uusia kysymyksiä.

Kysymys: miksi "ulkoiselle" ryhmälle on vain yksi rekisteritulos?

Kysymys: mitkä ovat kaikki ne tuntemattomat rekisterit "??????"

Kysymys: koska ohjelma ei ole keskeytysvetoinen, pyysikö se tietoja liian hitaasti? liian nopea?

Kysymys: Voimmeko vaikuttaa tuloksiin kokeilemalla asioita itse anturilla sen ollessa käynnissä?

Vaihe 6: Kaivetaan lisää lukemiin / tietoihin

Mielestäni seuraava askel ennen kaikkea on parantaa ohjelmaa:

• ole joustava silmukaviiveen suhteen (ms)
• olla joustava sen suhteen, kuinka monta lukemaa antaa juokseva keskiarvo rekisteriä kohti

(Minun oli liitettävä ohjelma tiedostona. Näytti olevan ongelma sen lisäämisessä tähän. "4th.test.mpu9265.c")

Tässä on juoksu käyttäen viimeistä 10 lukemaa keskimäärin 10 ms: n silmukalla:

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

Ensimmäinen vasen sarake on rekisterinumero. Sitten tulevat rekisterin viimeiset 10 lukemaa. Lopuksi viimeinen sarake on kunkin rivin keskiarvo.

Näyttää siltä, että rekisterit 61, 69, 71, 189, 197 ja 199 ovat joko vain binäärisiä tai valmiita / ei valmiita tai ne ovat 16-bittisen arvon korkea tavu (negatiivinen?).

Muita mielenkiintoisia havaintoja:

• rekisterit 65, 193 - erittäin tasainen ja sama arvo
• rekisteri 63, 191 - erittäin tasainen ja sama arvo
• rekisterit 73, 112, 195, 201, 240 - kaikki nollassa

Yhdistetään nämä havainnot takaisin aikaisemman monivärisen, korostetun taulukon kuvaan.

Rekisteröi 65 - lämpötila

Rekisteröi 193 - ??????

Rekisteri 63 - kiihtyvyysmittari

Rekisteröi 191 - ??????

Rekisteri 73 - ulkoinen

Rekisteröi 112 ja siitä eteenpäin - ??????

Meillä on vielä tuntemattomia, mutta olemme oppineet jotain hyödyllistä.

Rekisteri 65 (lämpötila) ja rekisteri 63 (kiihtyvyysmittari) olivat molemmat erittäin vakaita. Tätä odotimme. En ole koskenut anturiin; se ei liiku, paitsi satunnaisia värähtelyjä, koska robotti lepää samalla pöydällä tietokoneen kanssa.

Voimme tehdä yhden mielenkiintoisen testin jokaiselle näistä lämpötila-/kiihtyvyysmittarirekisteristä. Tätä testiä varten tarvitsemme vielä toisen version ohjelmasta.

Vaihe 7: Voimme vaikuttaa lämpötilaan ja kiihtyvyyteen

Edellisissä vaiheissa kavensimme ainakin yhtä lämpötilarekisteriä ja yhtä kiihtyvyyttä varten.

Ohjelman seuraavan version ("4th.test.mpu9265.c") avulla voimme todella nähdä muutoksen tapahtuvan molemmissa rekistereissä. Katso videot.

Lisää kaivamista

Jos palaamme taaksepäin ja tarkastelemme rekisterin tietoja, näemme, että on olemassa:

• kolme 16 -bittistä lähtöä gyroskoopille
• kolme 16 -bittistä lähtöä kiihtyvyysanturille
• kolme 16 -bittistä lähtöä magnetometrille
• yksi 16 -bittinen lähtö lämpötilaa varten

Yksinkertaisten testiohjelmiemme tulokset olivat kuitenkin yksittäisiä 8 -bittisiä ulostuloja. (yksittäiset rekisterit).

Joten yritetään enemmän samaa lähestymistapaa, mutta tällä kertaa luetaan 16 bittiä 8 sijasta.

Meidän on todennäköisesti tehtävä jotain alla olevan kaltaista. Käytämme lämpötilaa esimerkkinä, koska se on vain yksi 16 -bittinen lähtö.

// hae tiedostonkuvaaja fd …

int tempRegHi = 65; int tempRegLo = 66; int hiByte = wiringPiI2CReadReg8 (fd, tempRegHi); int loByte = wiringPiI2CReadReg8 (fd, tempRegLo); int tulos = hiByte << 8; // laita hi -order 8 bittiä 16 -bittisen arvon tuloksen yläosaan | = loByte; // lisää nyt lo -järjestykseen 8 bittiä, jolloin saat täydellisen 16 -bittisen numeron // tulosta numero tai käytä näytön vaakasuuntaista piirtotoimintoa aiemmasta

Aiemmista vaiheistamme olemme nähneet, että rekisteri 65 on melko kallioinen, kun taas rekisteri 66 on erittäin meluisa. Koska 65 on hi -order -tavu ja 66 -low -tavu, se on järkevää.

Luettavaksi voimme ottaa rekisterin 65 tiedot sellaisenaan, mutta voimme keskimäärin rekisteröidä 66: n arvot.

Tai voimme vain laskea koko tuloksen.

Katso tämän osan viimeinen video; se osoittaa koko 16 -bittisen lämpötila -arvon lukemisen. Koodi on "sixth.test.mpu9265.c"

Vaihe 8: Kiihtyvyysmittari ja gyroskooppi

Tämän osion videoissa näytetään kiihtyvyysmittarin ja gyroskoopin ulostulo testiohjelmalla "sevenh.test.mpu9265.c". Tämä koodi voi lukea 1, 2 tai 3 peräkkäistä tavuparia (hi ja lo tavua) ja muuntaa arvot yhdeksi 16-bittiseksi arvoksi. Siten voimme lukea minkä tahansa yksittäisen akselin tai voimme lukea kaksi niistä yhdessä (ja se summaa muutokset) tai voimme lukea kaikki kolme (ja se summaa muutokset).

Toistaakseni, tässä vaiheessa, tässä Instructable -ohjelmassa, haluan vain vastata yksinkertaiseen kysymykseen: "pyörikö robotti/kääntyi?". En etsi mitään tarkkaa arvoa, kuten onko se kääntynyt 90 astetta. Se tulee myöhemmin, kun pääsemme tekemään SLAMia, mutta sitä ei vaadita yksinkertaiseen esteiden välttämiseen ja satunnaisiin liikkeisiin.

Vaihe 9: (käynnissä oleva työ) Magnetometri

Kun käytät i2cdetect -työkalua, MPU9265 näkyy taulukossa muodossa 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: -- -- -- -- -- -- -- --

IMU: n magnetometriosan lukeminen vaatii lisävaiheita.

Invesense -rekistereistä PDF -dokumentti:

REKISTERIT 37 - 39 - I2C SLAVE 0 CONTROL

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