Wallace - self -outonome robot - deel 5 - Voeg IMU by: 9 stappe

2024 Outeur: John Day | [email protected]. Laas verander: 2024-01-30 07:26

Ons gaan voort met Wallace. Die naam Wallace kom van 'n mengsel van "Wall-E", en van 'n vorige projek (stemherkenning), en by die gebruik van die "espeak" -funksie klink dit 'n bietjie Brits. En soos 'n valet of 'n butler. En dit is die einddoel: dat hierdie projek iets nuttigs kan word. Dus "Wallace".

Wallace kan rondbeweeg, hy kan hindernisse vermy deur IR -afstandsensors te gebruik (onlangs het hulle op een of ander manier gebraai (?)). tyd, tesame met 'n MCP23017-uitbreiding), en laastens kan veranderinge in die motorstroom opspoor om te weet wanneer dit in iets vasloop.

Benewens die sensors "onthou" Wallace die 100 bewegings en het hy 'n paar rudimentêre ontledings gemaak met behulp van die bewegingsgeskiedenis.

Die doel tot dusver vir Wallace is om bloot te probeer vorentoe beweeg, en om te weet wanneer dit in 'n herhalende patroon (soos in 'n hoek) vassteek en nie regtig vorentoe beweeg nie.

Ek het verskeie herhalings vir beweging en navigasie ondergaan, en die konstante hoofpyn was tydens rotasie.

Aangesien Wallace 'n gevolgde robot is, en ek wou dinge makliker in die sagteware hou (vir later), het ek hom net laat draai/draai. Pas dus die gelyke, maar teenoorgestelde krag / dienssiklus toe op die motors.

Die probleem is te danke aan die ontwerp van die Agent 390 -robotplatform. Die bandbande is geneig om teen die kante te vryf. En erger, die een kant doen dit meer as die ander.

Op die vloer en reguit loop, was dit nie 'n probleem nie. Dit verskyn op matte. Ek het besluit om Wallace van die matte af te hou nadat die spore vuil geword het (dit is baie maklik om vuil op te neem).

Die werklike probleem is as u op die vloer draai.

As ek die sagteware op 'n hoë vlak werk siklus toepas, draai dit min of meer konsekwent. Gedurende 'n lae dienssiklus kan dit egter draai of nie. Of dit kan 'n bietjie draai en dan vertraag. Die draai -aksie blyk onbeheerbaar te wees via die sagteware, of op sy beste baie moeilik.

Die probleem verskyn tydens navigasie en rondbeweeg of weg van hindernisse. Dit kan óf te wild wegswaai, óf dit kan vashaak as u probeer om baie klein skofte te maak sonder om regtig te beweeg.

Bogenoemde verduideliking het hierdie instruksies dus gemotiveer.

Aanvanklik wou ek die instelling van 'n bewegingswaarnemingseenheid (IMU) afskakel, of vertraag, omdat dit A) ingewikkeld is, B) lawaaierig, C) foute mettertyd kan begin, ensovoorts, ens. was dat ons baie goed kon vaar deur vooruit te spring na IR-sensors op tydstye. En ons kon - met behulp van lasers kon ons weet of die robot draai of nie, deur die veranderinge in afstand na te gaan.

Eintlik sou ons dit ook (soort) kon doen met die akoestiese sensors.

Dit alles is egter 'n baie indirekte, ingewikkelde manier om 'n eenvoudige vraag te beantwoord: "het ons gedraai of nie?"

Dit het vir my gelyk asof die sprong om die ToF -lasersensors te gebruik, my na die volgende vlak van sagteware sou neem; naamlik SLAM (Simultaneous Localization and Mapping). Ek was nog nie gereed om daarheen te gaan nie.

Dit is 'n goeie ding om 'n robotprojek in lae uit te voer, met die eerste (onderste) lae eenvoudiger en die laasgenoemde (boonste) meer abstrak en moeiliker kwessies.

Aan lae kan so iets gedink word:

1. robot fisiese raam / meganiese strukturele basis
2. rudimentêre dryfstelsel (Framboos, Roboclaw, motors, bekabeling, ens., basiese sagteware, deur sleutelbord aangedrewe)
3. noodsaaklike stroombane om sensors te ondersteun (tweerigtingspanningsveranderaar, poortuitbreider, E-stop, kragverspreiding, ens.)
4. hindernis-vermydingsensors (akoesties, IR)
5. noodsaaklike, basiese posisionering en beweging - opsporing (versnellingsmeter, gyro, magnetometer, motorkodeerders, wielkodeerders)

U kan u eie lys opstel. Die punte van hierdie lys is dat u dit waarskynlik min of meer in die volgorde moet doen, en dat as u tyd op elke laag spandeer om elkeen in 'n goeie werkende toestand te kom, dit u later sal kan help, aangesien dinge ingewikkelder raak.

Bogenoemde lys kan min of meer gekoppel word aan hierdie konseptuele lae in sagteware.

• SLAM (gelyktydige lokalisering en kartering)
• Beheer en bewustheid van beweging, rotasie
• Basiese hindernisvermyding
• Beheer en opsporing van sensordata
• Noodsaaklike beweging vorentoe, agtertoe, links en regs, versnel, vertraag, stop

Soos u kan sien, sou die eerste items in hierdie lys die boonste, meer ingewikkelde lae wees wat meer abstrakte kwessies en vrae aanpak, soos 'waar is ek' en 'waarheen gaan ek', terwyl laasgenoemde items die laer sagteware lae wat die "hoe om te praat/luister na sensor A" of "hoe om hierdie wiel te beweeg" hanteer.

Nou, ek sê nie dat as u met 'n laag begin nie, u dit sal voltooi en dan op die volgende laag is, om nooit weer na die vorige laag terug te keer nie. 'N Robotprojek kan baie soos moderne, iteratiewe sagteware -ontwikkelingsmetodes (agile, SCRUM, ens) lyk.

Ek sê net om tyd by elkeen te neem. U sal moet balanseer hoeveel u by elkeen moet doen, en besluit wat u op 'n sekere laag probeer, wat die moeite werd is.

Daar is 'n sekere 'konflik' of 'spanning' tussen twee mededingende idees of rigtings.

Die een is wat ek 'plug-n-play' sou noem om probleem A.

Die ander een is DIY (doen dit self). En dit is miskien nie eens die beste etiket vir hierdie ander idee nie.

Hier is 'n voorbeeld van elkeen, hopelik sien u die spanning of konflik tussen die twee keuses.

Laat ons in hierdie voorbeeld SLAM, vermyding van struikelblokke en noodsaaklike basiese bewegings as een probleem op dieselfde tyd oplos.

1. As ons besluit om die plug-n-play-roete te volg, spring ons onmiddellik (afhangende van die begroting) na dinge soos die top-gemonteerde roterende lasers, of diepte-van-veld-kamera, of ToF-lasers, en die IMU (onderwerp hiervan) Leerbaar).
2. As ons daarenteen die tweede pad wil volg, kan ons probeer om elke moontlike bietjie inligting uit sommige akoestiese sensors of IR -sensors te onttrek, of glad nie sensors nie - ons gebruik net motorstroommonitering (stamp)

Wat kan gesê word oor #1 vs #2? Een ding sou wees dat ons baie meer geleer het deur nommer 2 te doen. Die beperkings om slegs akoestiese sensors te hê om mee te werk, dwing ons om na te dink oor baie meer kwessies.

Aan die ander kant, as ons te gefokus is om dinge te doen via nommer 2, kan ons tyd mors, want ons vra meer as wat ons moet van akoestiese sensors.

Nog 'n konsep of idee om oor na te dink: watter mengsel van hardeware en sagteware beantwoord die beste vrae oor 'hoe om', en watter mengsel van sagteware (en hardeware?) Beantwoord die vraag 'wat', 'wanneer', 'waar'. Omdat 'hoe om' gewoonlik 'n laer vlak is, waarop 'wat', 'wanneer' en 'waar' afhang om 'n antwoord te kry.

In elk geval, al die bogenoemde was net iets om oor na te dink.

In my geval, na baie moeite en met die konstante, irriterende probleem van spoorwrywing en nie in staat is om konstante beheer en beweging te kry nie, is dit tyd om iets anders te doen.

Dus is hierdie Instrueerbare - 'n IMU.

Die doel is dat as die IMU sê dat die robot NIE draai nie, ons die dienssiklus verhoog. As ons te vinnig draai, verminder ons die dienssiklus.

Stap 1: Die IMU -sensor

En dus is ons volgende sensor om by Wallace te voeg, die IMU. Na 'n bietjie navorsing, het ek besluit op 'n MPU6050. Maar op hierdie tydstip lyk die MPU9050 (en nog meer onlangs, die MPU9250) na 'n nog beter idee.

My bron is Amazon (in die VSA). So ek het twee van hulle bestel.

Wat ek eintlik gekry het (dit lyk asof daar geen beheer hieroor is nie; dit is wat ek nie van Amazon hou nie) was twee MPU92/65. Ek wonder 'n bietjie oor die benaming. Kyk na die beelde; dit blyk 'n 'familie' benaming te wees. Dit is in elk geval waarmee ek vas is.

Dit is baie eenvoudig om dit by te voeg -kry 'n protobord met verbindingsbane, soldeer die sensor aan boord, voeg 'n 10 -pins skroefklemmenblok by (ek het myne van Pololu gekry).

Om enige inmenging tot die minimum te beperk, het ek probeer om hierdie sensors van alles af weg te hou.

Dit beteken ook die gebruik van 'n paar nylonboute/moere.

Ek gaan die I2C protokol gebruik. Hopelik sal die totale draadlengte nie te erg wees nie.

Daar is elders baie inligting oor die basiese verbindings en spanningsvlakke, ens, so ek sal dit nie hier herhaal nie.

Stap 2: Dinge is nie altyd skoon, maklik nie

By hierdie skrywe blyk dit dat daar nie baie aanlyn is vir hierdie spesifieke MPU-92/65 nie. Wat beskikbaar is, net soos met die meeste sensors, blyk voorbeelde te wees van Arduino.

Ek probeer om hierdie instruksies 'n bietjie anders te maak deur 'n nie-so-skoon proses aan te bied, want dinge werk nie altyd dadelik nie.

Ek veronderstel dat hierdie instruksies meer op 'n blog lyk as reguit A-B-C, 1-2-3 "dit is hoe u dit doen".

Stap 3: Aanvanklike toets

Uit die beelde in die vorige stap is die rooi en swart drade na die sensors natuurlik VCC (5V) en GND. Die groen en geel drade is die I2C -verbindings.

As u ander I2C -projekte gedoen het of hierdie reeks gevolg het, weet u reeds van 'i2cdetect', en dit is die eerste stap om te weet of die framboos die nuwe sensor kan sien.

Soos u kan sien uit die beelde in hierdie stap, was ons eerste poging onsuksesvol. Die IMU verskyn nie (moet toestel -ID 0x68 wees).

Die goeie nuus is egter dat die I2C -bus werk. Ons sien wel een toestel 0x20 en dit is die MCP23017 -poortuitbreider (tans verantwoordelik vir die HCSR04 -akoestiese sensors).

Dit is nie maklik om in die prent te sien nie, maar ek het dieselfde groen en geel drade van die IMU aan die MCP23017 gekoppel (sien links onder in die prent)

Ons sal probleme moet oplos.

Stap 4: Probleemoplossing

Met behulp van die kontinuïteitsinstelling op 'n voltmeter (die met die hoë toon), het ek VCC (5V), GND, SDA en SCL verbindings getoets. Die was goed.

Die volgende poging was om die MCP23017 van die I2C-bus te ontkoppel, en slegs die MPU-92/65 op die bus te laat. Dit was vrugteloos - 'i2cdetect' het toe geen toestelle getoon nie.

Dus het ek die sensor van die totempaal afgehaal en weer direk na die 5V-tot-3V-tweerigtingbus gekoppel; dit wil sê, direk na die Framboos. (korter drade?).

En voila. Hierdie keer is daar sukses. Ons sien dat 0x68 verskyn met 'i2cdetect'.

Maar ons weet nog nie hoekom dit hierdie keer gewerk het nie. Kan dit die lengte van die drade wees? Die vorige ligging?

Let wel: dit het geen verskil gemaak of ADO gegrond is of nie. Dit kan wees dat daar aan boord pullup- en aftrekweerstands is. Dieselfde geld moontlik vir FSYNC.

Daarna het ek die MCP23017 weer verbind. Nou het ons twee toestelle op die I2C -bus. (sien prent). Sukses, ons sien nou beide 0x20 en 0x68 met i2cdetect.

Die video's gee meer inligting oor wat tydens die probleemoplossing gebeur het.

Stap 5: Lees die sensor se data

Verskeie benaderings

Ek het besluit om verskeie benaderings te neem om nuttige inligting uit die sensor te kry. Hier is hulle, nie in enige volgorde nie:

1. probeer basiese programmering
2. kyk na 'n paar aanlyn dokumentasie oor registers
3. kyk na ander se voorbeelde en / of kode

Waarom hierdie benaderings? Waarom soek u nie net 'n bestaande biblioteek of kode nie?

Deur te eksperimenteer en 'n paar idees te probeer, kan ons beter kennis oor hierdie spesifieke sensor opneem, maar ook tegniek, vaardigheid en denkwyses kry om iets nuuts aan te pak, en iets wat nie veel dokumentasie bevat nie; iets wat baie onbekendes kan hê.

As ons eers met ons eie idees gespeel en beproef en insig gekry het, is ons beter in staat om die kode of biblioteek van iemand anders te evalueer.

Nadat ek byvoorbeeld na 'n C ++ - kode vir die MPU9250 in github gekyk het, het ek besef dat dit my dwing om onderbrekings te gebruik, wat ek nog nie wil doen nie.

Dit bevat ook ekstra dinge soos kalibrasie; weer iets waarin ek nog nie belangstel nie.

Dit is moontlik dat wat ek moet doen om die eenvoudige vraag "die robot wat ja of nee draai" te beantwoord, eenvoudig beantwoord kan word deur net 'n paar registers te lees.

Registers

By hierdie skrywe blyk dit dat daar nie veel beskikbaar is op hierdie sensor nie. As u na die beelde van hierdie instruksies kyk en die inskripsies op die werklike skyfies noukeurig bekyk, laat ek my wonder of dit nie 'n afslag is nie. Ek hou niks van wat ek sien in verband met Invense nie. Hoe dan ook, ek het gekies om na die register-inligting te kyk vir die modelle wat ek gevind het: die MPU-6050 en die MPU-9250.

In beide gevalle is die volgende vir beide dieselfde. En om mee te begin, neem ons aan dat dit ook dieselfde sal wees vir hierdie MPU-92/65.

59 tot 64 - versnellingsmetermetings

65, 66 - temperatuurmetings 67 tot 72 - gyroscoopmetings 73 tot 96 - eksterne sensordata

'N Opmerking: die MPU-6050 het blykbaar NIE 'n magnetometer nie, terwyl die MPU-9250 (en ons neem ook aan hierdie een) wel 'n magnetometer het.

Nog 'n paar interessante, hopelik nuttige inligting uit die registerdokument:

Magnetometer inligting:

magnetometer ID: 0x48 registers 00 tot 09: 00H WIA 0 1 0 0 1 0 0 0 01H INFO INFO7 INFO6 INFO5 INFO4 INFO3 INFO2 INFO1 INFO0 02H ST1 0 0 0 0 0 0 DOR DRDY 03H HXL HX7 HX6 HX5 HX4 HX3 HX2 HX1 HX0 HXH HX15 HX14 HX13 HX12 HX11 HX10 HX9 HX8 05H HYL HY7 HY6 HY5 HY4 HY3 HY2 HY1 HY0 06H HYH HY15 HY14 HY13 HY HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ ST2 0 0 0 BITM HOFL 0 0 0 'n uiteensetting van wat elke register beteken: HXL [7: 0]: X-as-metingsdata laer 8bit HXH [15: 8]: X-as-metingsdata hoër 8bit HYL [7: 0]: Y-as-metingsdata laer 8bit HYH [15: 8]: Y-as-metingsdata hoër 8bit HZL [7: 0]: Z-as-metingsdata laer 8bit HZH [15: 8]: Z-as-metingsdata hoër 8 bit

Programmering

'N Ander bietjie inligting uit die registerdokumente is dat dit ongeveer 100 registers was. Een taktiek kan dus wees om 'n eenvoudige program met toegang tot die toestel (0x68) te skryf en probeer om 'n reeks registers agtereenvolgens te lees, sonder om die betekenis daarvan in ag te neem, net om te sien watter data gesien kan word.

Doen dan opeenvolgende passe met dieselfde kode, en vergelyk die data van die een pas teenoor die volgende.

Die idee is dat ons waarskynlik enige registers kan verwyder wat blykbaar geen data het nie (nulle of VF?) Of wat absoluut nooit verander nie, en ons kan ook fokus op die wat wel verander.

Dan kyk ons na slegs diegene wat verander, en voeg 'n gemiddelde funksie by wat die nuutste N van die register gemiddeld is, om te sien of daar werklik 'n vaste waarde vir die register is. Dit sou aanvaar dat ons die sensor baie stil hou, en op dieselfde plek.

Uiteindelik kan ons dinge met die sensor saggies probeer, soos om dit te versnel (versnellingsmeter, gyro), of daarop te blaas (temperatuur), of om dit te draai (die vorige twee plus magnetometer) en te sien watter uitwerking dit op die waardes het.

Ek hou daarvan om soveel as moontlik die wiringPi -biblioteek te gebruik. Dit het ondersteuning vir I2C.

Eerste lopie:

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

* om te bou: gcc first.test.mpu9265.c -o first.test.mpu9265 -lwiringPi * * om uit te voer: sudo./first.test.mpu9265 * * hierdie program lewer net 'n reeks (moontlike) registers uit die MCP23017, * en dan vanaf die MPU9265 (of enige ander MPU by die 0x68 -adres) * * Ek het dit gebruik om te kontroleer of ek selfs van die sensor kon lees, aangesien ek reeds * vertroue gehad het in die MCP23017. ************************************************* ****************************/ #include #include #include #include #include int main (int argc, char ** argv) {puts ("Kom ons kyk wat MCP23017 @ 0x20 te sê het:"); errno = 0; int deviceId1 = 0x20; int fd1 = wiringPiI2CSetup (deviceId1); if (-1 == fd1) {fprintf (stderr, "Kan nie wiringPi I2C-toestel oopmaak: %s / n", strerror (errno)); opgawe 1; } vir (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d", wiringPiI2CReadReg8 (fd1, reg)); fflush (stderr); vertraging (10); } sit (""); sit ("Kom ons kyk wat MPU9265 @ 0x20 te sê het:"); errno = 0; int deviceId2 = 0x68; int fd2 = wiringPiI2CSetup (deviceId2); if (-1 == fd2) {fprintf (stderr, "Kan nie wiringPi I2C-toestel oopmaak: %s / n", strerror (errno)); opgawe 1; } vir (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d", wiringPiI2CReadReg8 (fd2, reg)); fflush (stderr); vertraging (10); } sit (""); terugkeer 0; }

Die tweede lopie:

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

* om te bou: gcc second.test.mpu9265.c -o second.test.mpu9265 -lwiringPi * * om uit te voer: sudo./second.test.mpu9265 * * Hierdie program lewer die registernommer saam met die waarde wat gelees word. * * Dit maak dit nuttig om die uitvoer na 'n lêer te lei (herlei), en dan kan * verskeie lopies gedoen word om dit te vergelyk. Dit kan 'n bietjie insig gee in * watter register belangrik is en hoe die data kan optree. ************************************************* ****************************/ #include #include #include #include #include #include int main (int argc, char ** argv) {int deviceId = -1; if (0) {} anders if (! strncmp (argv [1], "0x20", strlen ("0x20"))) {deviceId = 0x20; } anders as (! strncmp (argv [1], "0x68", strlen ("0x68"))) {deviceId = 0x68; } anders as (! strncmp (argv [1], "0x69", strlen ("0x69"))) {deviceId = 0x69; } sit ("Kom ons kyk wat MPU9265 @ 0x20 te sê het:"); errno = 0; int fd = wiringPiI2CSetup (deviceId); if (-1 == fd) {fprintf (stderr, "Kan nie wiringPi I2C-toestel oopmaak: %s / n", strerror (errno)); opgawe 1; } vir (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); vertraging (10); } gee 0 terug; }

Die derde lopie:

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

* om te bou: gcc third.test.mpu9265.c -o third.test.mpu9265 -lwiringPi * * om uit te voer: sudo./third.test.mpu9265 * * Hierdie program is die gevolg van die tweede een. Dit lees slegs uit die * registers wat 'n verskil tussen een lopie en die volgende aandui.************************************************* ****************************/ #include #include #include #include #include #include int main (int argc, char ** argv) {int deviceId = -1; as (0) {} anders as (! strncmp (argv [1], "0x68", strlen ("0x68"))) {deviceId = 0x68; } anders as (! strncmp (argv [1], "0x69", strlen ("0x69"))) {deviceId = 0x69; } sit ("Kom ons kyk wat MPU9265 @ 0x20 te sê het:"); errno = 0; int fd = wiringPiI2CSetup (deviceId); if (-1 == fd) {fprintf (stderr, "Kan nie wiringPi I2C-toestel oopmaak: %s / n", strerror (errno)); opgawe 1; } vir (int reg = 61; reg <= 73; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); vertraging (10); } vir (int reg = 111; reg <= 112; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); vertraging (10); } vir (int reg = 189; reg <= 201; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); vertraging (10); } vir (int reg = 239; reg <= 240; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); vertraging (10); } gee 0 terug; }

So, wat het ons tot dusver geleer? Die beeld van die tabel met gekleurde gemerkte gebiede dui aan dat die uitset lyk by die eerste stelle registers.

Die resultate tot dusver kan nuwe vrae oplewer.

Vraag: waarom is daar slegs een registerresultaat vir die 'eksterne' groep?

Vraag: wat is al die onbekende registers "??????"

Vraag: Het die data te stadig gevra omdat die program nie onderbrekingsgedrewe is nie? te vinnig?

Vraag: kan ons die resultate beïnvloed deur dinge met die sensor self te probeer terwyl dit werk?

Stap 6: Kom ons kyk meer na die lesings / data

Ek dink die volgende stap voor enigiets anders is om die program uit te brei na:

• wees buigsaam in hoeveel lusvertraging (ms)
• wees buigsaam oor hoeveel lesings 'n lopende gemiddelde per register moet gee

(Ek moes die program as 'n lêer heg. Dit was 'n probleem om dit hier in te voeg. "Four.test.mpu9265.c")

Hier is 'n weergawe met behulp van die laaste 10 lesings vir 'n gemiddelde op 'n lus van 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

Die eerste kolom links, is die registernommer. Dan kom die laaste 10 lesings vir die register. Laastens is die laaste kolom die gemiddelde vir elke ry.

Dit lyk asof registers 61, 69, 71, 189, 197 en 199 óf slegs binêre is, óf gereed / nie gereed nie, óf dit is die hoë greep van 'n 16-biswaarde (negatief?).

Ander interessante waarnemings:

• registreer 65, 193 - baie bestendig en dieselfde waarde
• register 63, 191 - baie bestendig en dieselfde waarde
• registers 73, 112, 195, 201, 240 - alles op nul

Kom ons bring hierdie waarnemings terug na die veelkleurige, gemerkte tafelbeeld van vroeër.

Registreer 65 - temperatuur

Registreer 193 - ??????

Registreer 63 - versnellingsmeter

Registreer 191 - ??????

Registreer 73 - ekstern

Registreer 112 en verder - ??????

Wel, ons het nog steeds onbekendes, maar ons het iets nuttigs geleer.

Register 65 (temperatuur) en register 63 (versnellingsmeter) was albei baie bestendig. Dit is iets wat ons sou verwag. Ek het nie aan die sensor geraak nie; Dit beweeg nie, behalwe toevallige trillings, aangesien die robot op dieselfde tafel as my rekenaar rus.

Daar is een interessante toets vir elk van hierdie temperatuur-/versnellingsmeterregisters. Vir die toets het ons nog 'n weergawe van die program nodig.

Stap 7: Ons kan temperatuur en versnelling beïnvloed

In die vorige stappe het ons ten minste een register vir temperatuur en een vir versnelling verminder.

Met hierdie volgende weergawe van die program ("5th.test.mpu9265.c") kan ons 'n verandering in beide registers sien plaasvind. Kyk asseblief na die video's.

Meer grawe

As ons teruggaan na die registerinligting, sien ons dat daar die volgende is:

• drie 16 bis -uitsette vir die gyroscoop
• drie 16 bis uitsette vir versnellingsmeter
• drie 16 bis uitsette vir magnetometer
• een 16 bis -uitset vir temperatuur

Die resultate wat ons met ons eenvoudige toetsprogramme behaal het, was egter almal enkele 8 bis -uitsette. (enkele registers).

Kom ons probeer meer van dieselfde benadering, maar hierdie keer lees ons 16 bisse in plaas van 8.

Ons sal waarskynlik iets soos hieronder moet doen. Kom ons gebruik die temperatuur as 'n voorbeeld, aangesien dit slegs een 16 -bis -uitset is.

// verkry lêerbeskrywing fd …

int tempRegHi = 65; int tempRegLo = 66; int hiByte = wiringPiI2CReadReg8 (fd, tempRegHi); int loByte = wiringPiI2CReadReg8 (fd, tempRegLo); int resultaat = hiByte << 8; // plaas die hi -orde 8 bisse in die boonste gedeelte van 'n resultaat van 16 bis | = loByte; // Voeg nou 8 bisse in die volgorde in, wat 'n volledige 16 bis getal oplewer // druk die getal af of gebruik die horisontale grafiese funksie van voor af

Uit ons vorige stappe het ons gesien dat register 65 redelik rotsvas is, terwyl register 66 baie raserig is. Aangesien 65 die hi -orde -byte is, en 66 die lae -orde -byte, is dit sinvol.

Vir die lees kan ons die data van die register van 65 neem soos dit is, maar ons kan die waardes van die register 66 gemiddeld gebruik.

Of ons kan die totale resultaat net gemiddeld maak.

Kyk na die laaste video vir hierdie deel; dit toon die lees van die hele 16 bit temperatuur waarde. Die kode is "sixth.test.mpu9265.c"

Stap 8: die versnellingsmeter en die gyroscoop

Die video's vir hierdie afdeling toon die uitset van die versnellingsmeter en die gyroscoop met 'n toetsprogram "seventh.test.mpu9265.c". Die kode kan 1, 2 of 3 opeenvolgende byte-pare (hi- en lo-grepe) lees en die waardes omskakel na 'n enkele waarde van 16 bis. Ons kan dus enige enkele as lees, of ons kan twee van hulle saam lees (en dit som die veranderings op), of ons kan al drie lees (en dit som die veranderings op).

Om te herhaal, vir hierdie fase, vir hierdie Instructable, wil ek net 'n eenvoudige vraag beantwoord: "het die robot gedraai/gedraai?". Ek soek nie 'n presiese waarde nie, soos: draai dit 90 grade. Dit kom later as ons SLAM kan doen, maar dit is nie nodig vir eenvoudige vermyding van hindernisse en willekeurige beweging nie.

Stap 9: (werk aan die gang) die magnetometer

as u die i2cdetect -instrument gebruik, verskyn die MPU9265 as 0x68 in die tabel:

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

Daar is ekstra stappe nodig om uit die magnetometergedeelte van die IMU te lees.

Uit die Invesense -registers PDF -dokument:

REGISTERS 37 TOT 39 - I2C SLAVE 0 BEHEER

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