Wallace - DIY autonoomne robot - 5. osa - lisage IMU: 9 sammu

2024 Autor: John Day | [email protected]. Viimati modifitseeritud: 2024-01-30 08:49

Me jätkame koos Wallace'iga. Nimi Wallace tulenes segust "Wall-E" ja eelmisest projektist (häältuvastus) ning utiliidi "espeak" kasutamisel kõlas see natuke brittlikult. Ja nagu toateenija või ülemteener. Ja see on lõppeesmärk: et sellest projektist saaks midagi kasulikku. Seega "Wallace".

Wallace saab ringi liikuda, ta saab vältida takistusi, kasutades IR kaugusandureid (hiljuti nad kuidagi praadisid (?) (Pean võimaluse korral seda uurima), tal on ka mõned akustilised kaugusandurid (kolm neist läksid samal ajal halvasti) koos MCP23017 laiendajaga) ja lõpuks suudab tuvastada muutusi mootorivoolus, et teada saada, millal see millegi vastu põrkab.

Lisaks anduritele "mäletab" Wallace 100 käiku ja tal on liikumise ajalugu kasutades algeline analüüs.

Siiani on Wallace'i eesmärk püüda lihtsalt edasi liikuda ja teada saada, millal see on mingis korduvas mustris kinni (näiteks nurgas) ja tegelikult edasi ei liigu.

Olen läbinud mitmeid kordusi liikumiseks ja navigeerimiseks ning pidev peavalu on olnud pöörlemise ajal.

Kuna Wallace on roomikrobot ja ma tahtsin tarkvara lihtsamaks muuta (hilisemaks), siis pööramiseks pean teda lihtsalt oma kohale pöörama/pöörlema. Seega rakendage mootoritele võrdset, kuid vastupidist võimsus- / töötsüklit.

Tekkinud probleem on tingitud Agent 390 robotplatvormi disainist. Rööbasteed kipuvad külgedele hõõruma. Ja veel hullem, üks pool teeb seda rohkem kui teine.

Põrandakatte ja otse minnes pole see probleem olnud. See ilmub vaipkattele. Valisin Wallace'i vaipadelt eemal hoidmiseks pärast seda, kui selle rajad on määrdunud (nad koguvad mustust väga lihtsalt).

Tõeline probleem on põrandakatete pööramisel.

Kui mul on tarkvara rakendada kõrgetasemelist töötsüklit, pöördub see enam -vähem järjekindlalt. Kuid madala töötsükli ajal võib see tegelikult pöörduda või mitte. Või võib see mõneks ajaks pöörduda ja seejärel aeglustada. Pöörlemistoiming tundub olevat tarkvara kaudu kontrollimatu või parimal juhul väga raske.

Probleem ilmneb navigeerimise ajal ja takistustest mööda liikudes. See võib kas liiga metsikult eemale liikuda või jääda jänni, üritades teha väikseid nihkeid, ilma et peaks isegi liikuma.

Ja nii ajendas ülaltoodud selgitus seda Instructable'i.

Algselt tahtsin loobuda liikumistundliku üksuse (IMU) kasutuselevõtmisest või selle kasutuselevõtmisest, sest need on A) keerulised, B) mürarikkad, C) vead võivad aja jooksul ilmneda jne jne. oli see, et saime väga hästi hakkama, hüpates edasi lennuaja IR-lasersensorite juurde. Ja me saaksime - laserite abil saaksime kauguse muutusi jälgides teada, kas robot pöörleb või mitte.

Tegelikult saaksime seda (omamoodi) ka praegu teha akustiliste anduritega.

See kõik on aga väga kaudne ja keeruline viis ühele lihtsale küsimusele vastamiseks: "kas oleme pöörlenud või mitte?"

Mulle tundus, et ToF -lasersensorite kasutamise hüppamine viib mind järgmisele tarkvara tasemele; nimelt SLAM (samaaegne lokaliseerimine ja kaardistamine). Ma ei olnud veel valmis sinna minema.

Robotiprojekti on hea teha kihiti, kus esimesed (alumised) kihid on lihtsamad ja viimased (ülemised) kihid on abstraktsemad ning tegelevad raskemate probleemidega.

Kihid võib välja mõelda järgmiselt:

1. roboti füüsiline raam / mehaaniline konstruktsioon
2. algeline ajamissüsteem (vaarikas, Roboclaw, mootorid, kaabeldus jne, baastarkvara, klaviatuuril töötav)
3. hädavajalikud vooluahelad andurite (kahesuunaline pingemuundur, pordilaiend, E-Stop, toitejaotus jne) toetamiseks
4. takistuste vältimise andurid (akustiline, IR)
5. oluline, põhiline positsioneerimine ja liikumise tuvastamine (kiirendusmõõtur, güroskoop, magnetomeeter, mootori kodeerijad, rattakooderid)

Võite koostada oma nimekirja. Selle loendi punktid on, et tõenäoliselt peaksite neid tegema enam -vähem selles järjekorras, ja ka see, et kui kulutate iga kihi jaoks mõnda aega, et saada igaüks heasse tööseisundisse, peaks see teid hiljem aitama, kui asjad keerulisemaks lähevad.

Ülaltoodud loendit saab tarkvara enam -vähem nende kontseptuaalsete kihtidega kaardistada.

• SLAM (samaaegne lokaliseerimine ja kaardistamine)
• Liikumise kontroll ja teadlikkus, pöörlemine
• Põhiline takistuste vältimine
• Andurite andmete kontroll ja tuvastamine
• Oluline liikumine edasi, tagasi, vasakule ja paremale, kiirendada, aeglustada, peatada

Nagu näete, oleksid selle loendi jaoks esimesed elemendid ülemised, keerukamad kihid, mis käsitlevad abstraktsemaid küsimusi ja küsimusi, näiteks "kus ma olen" ja "kuhu ma lähen", samas kui viimased punktid oleksid madalamad tarkvarakihid, mis käsitlevad "kuidas rääkida/kuulata sensorit A" või "kuidas seda ratast liigutada".

Nüüd ma ei ütle, et kui alustate kihist, olete selle lõpetanud ja siis on see järgmisel kihil, mitte kunagi tagasi eelmisele. Robotiprojekt võib sarnaneda kaasaegsetele iteratiivsetele tarkvaraarendusmeetoditele (vilgas, SCRUM jne).

Ma lihtsalt ütlen, et võtke igaühel aega. Peate tasakaalustama, kui palju igaühel teha, ja otsustama, mida proovite teatud kihil, mis on väärt aega ja vaeva.

Kahe konkureeriva idee või suuna vahel on teatav "konflikt" või "pinge".

Üks on see, mida ma nimetaksin probleemi A lahendamiseks "plug-n-play".

Teine on DIY (tee seda ise). Ja see ei pruugi isegi olla selle teise idee jaoks parim silt.

Siin on näide igast, loodetavasti näete pinget või konflikti kahe valiku vahel.

Selle näite puhul koondame SLAMi, takistuste vältimise ja olulised põhilised liikumised ühe probleemina, mida korraga lahendada.

1. Kui otsustame minna plug-n-play marsruudile, liigume kohe (olenevalt eelarvest) selliste asjade juurde nagu need ülalt paigaldatavad pöörlevad laserid või teravussügavuskaamera või ToF-laserid ja IMU (selle teema Juhendatav).
2. Kui me aga soovime minna teisele teele, siis võime proovida saada välja kõikvõimaliku teabe mõnest akustilisest andurist või infrapunaandurist või üldse mitte - kasutame lihtsalt mootorivoolu jälgimist (löök)

Mida saab öelda #1 vs #2 kohta? Üks asi oleks see, et me oleksime #2 tehes palju rohkem õppinud. Ainult akustiliste andurite kasutamise piirangud sunnivad meid mõtlema palju muudele probleemidele.

Teisest küljest, kui oleme liiga keskendunud asjade tegemisele #2 kaudu, võime raisata aega, sest küsime akustilistelt anduritelt rohkem, kui peaksime.

Veel üks mõte või mõte, millele mõelda: milline riistvara ja tarkvara segu vastab kõige paremini küsimustele "kuidas" ja milline tarkvara (ja riistvara?) Segu vastab küsimustele "mis", "millal", "kus". Sest "kuidas" on tavaliselt madalama taseme küsimus, millest vastuse saamiseks sõltuvad "mis", "millal" ja "kus".

Igatahes oli kõik eelnev vaid mõtlemisainet.

Minu puhul on pärast suuri jõupingutusi ja pidevat tüütut teekonna hõõrdumist ning suutmatust järjepidevat kontrolli ja liikumist saada, on aeg teha midagi muud.

Seega on see juhendatav - IMU.

Eesmärk on see, et kui IMU ütleb, et robot EI pööra, suurendame töötsüklit. Kui pöörame liiga kiiresti, vähendame töötsüklit.

Samm: IMU andur

Nii et meie järgmine andur, mida Wallace'i lisada, on IMU. Pärast mõningaid uuringuid otsustasin MPU6050 -ga. Kuid sel ajal tundus MPU9050 (ja veel hiljuti MPU9250) veelgi parem idee.

Minu peamine allikas on olnud Amazon (USA-s). Nii et ma tellisin neist kaks.

Tegelikult sain ma (tundub, et selle üle puudub kontroll; see ei meeldi mulle Amazoni puhul) kaks MPU92/65. Imestan natuke nimetuse üle. Vaadake pilte; see näib olevat "perekonna" nimetus. Igal juhul olen ma sellesse kinni jäänud.

Selle lisamine on väga lihtne -hankige ühendusplaatidega protoplaat, jootke andur plaadile, lisage 10 -kontaktiline kruviklemmiplokk (mina sain Pololult).

Häirete minimeerimiseks proovisin need andurid igast muust eemale asetada.

See tähendas ka mõningate nailonpoltide/mutrite kasutamist.

Kasutan I2C protokolli. Loodetavasti ei saa traadi kogupikkus liiga halb.

Mujal on palju teavet põhiühenduste ja pingetasemete jms kohta, nii et ma ei hakka seda siin kordama.

Samm: asjad pole alati puhtad ja lihtsad

Selle kirjutamise ajal ei tundu selle konkreetse MPU-92/65 jaoks palju võrgus olevat. See, mis on saadaval, nagu enamiku andurite puhul, näib olevat näide Arduino kasutamisest.

Püüan neid juhiseid veidi teistsuguseks muuta, esitades mitte nii puhta protsessi, sest asjad ei tööta alati kohe.

Ma arvan, et need juhendid sarnanevad rohkem ajaveebiga kui sirged A-B-C, 1-2-3 "see on see, kuidas te seda teete".

3. samm: esialgne test

Eelmise sammu piltide põhjal on anduritele suunduvad punased ja mustad juhtmed muidugi VCC (5V) ja GND. Rohelised ja kollased juhtmed on I2C ühendused.

Kui olete teinud muid I2C projekte või olete neid seeriaid jälginud, siis teate juba i2cdetecti kohta ja see on esimene samm teada saada, kas Vaarikas näeb uut andurit.

Nagu selle sammu piltidelt näete, oli meie esimene katse ebaõnnestunud. IMU ei ilmu (peaks olema seadme ID 0x68).

Hea uudis on aga see, et I2C buss töötab. Me näeme ühte seadet 0x20 ja see on MCP23017 pordi laiendaja (praegu vastutab HCSR04 akustiliste andurite eest).

Pildil pole seda lihtne näha, kuid ühendasin IMU -st samad värvilised rohelised ja kollased juhtmed MCP23017 -ga (vt pildil vasakul all)

Peame tegema mõned tõrkeotsingud.

4. samm: tõrkeotsing

Kasutades voltmeetri (kõrge tooniga) järjepidevuse seadistust, testisin VCC (5V), GND, SDA ja SCL ühendusi. Need olid head.

Järgmine katse oli MCP23017 I2C siinist lahti ühendada, jättes siinile ainult MPU-92/65. See osutus viljatuks - "i2cdetect" ei näidanud siis ühtegi seadet.

Niisiis, eemaldasin anduri totemipoolilt ja ühendasin selle uuesti otse 5V-3V kahesuunalise siiniga; st otse Vaarikale. (lühemad juhtmed?).

Ja voilaa. Seekord on edu. Näeme, et 0x68 kuvatakse "i2cdetect" abil.

Aga me ei tea veel, miks see seekord töötas. Kas see võib olla juhtmete pikkus? Eelmine asukoht?

Märkus: vahet polnud, kas ADO oli maandatud või mitte. Võib juhtuda, et pardal on tõmbe- ja tõmbetakistid. Sama võib kehtida ka FSYNC puhul.

Seejärel ühendasin MCP23017 uuesti. Nüüd on meil I2C siinil kaks seadet. (vaata pilti). Edu, nüüd näeme i2cdetectiga nii 0x20 kui ka 0x68.

Videod räägivad natuke rohkem sellest, mis tõrkeotsingu ajal juhtus.

Samm: anduri andmete lugemine

Erinevad lähenemised

Otsustasin, et kasutan andurilt kasulikku teavet mitmel viisil. Siin nad on, mitte mingis järjekorras:

1. proovige mõnda põhiprogrammeerimist
2. vaadake registrite veebipõhist dokumentatsiooni
3. vaadake teiste näiteid ja / või koodi

Miks need lähenemised? Miks mitte lihtsalt otsida mõnda olemasolevat raamatukogu või koodi?

Katsetades ja proovides mõningaid ideid, saame paremini omastada teadmisi mitte ainult selle konkreetse sensori kohta, vaid ka omandada teatud tehnika, oskused ja mõtteviisid millegi uuega tegelemiseks ning milleks ei pruugi olla palju dokumente; midagi, milles võib olla palju tundmatuid.

Samuti, kui oleme mõne oma ideega mänginud ja proovinud ning mõningast arusaamist saanud, on meil paremad võimalused kellegi teise koodi või raamatukogu hindamiseks.

Näiteks pärast githubis MPU9250 mõne C ++ koodi vaatamist mõistsin, et see sunnib mind kasutama katkestusi, mida ma veel ei soovi.

Lisaks on kaasas täiendavaid asju, nagu kalibreerimine; jällegi midagi, mis mind veel ei huvita.

Võib juhtuda, et mida ma pean tegema, et vastata lihtsale küsimusele „kas robot pöörleb jah või ei“, saaks vastata väga lihtsalt, lihtsalt lugedes mõnda registrit.

Registrid

Selle kirjutamise ajal ei tundu selle anduri kohta palju saadaval olevat. Tegelikult, kui vaatate selle juhendiga kaasasolevaid pilte ja vaatate tähelepanelikult tegelike kiipide pealdisi, paneb mind mõtlema, kas see pole löök. Ma ei seo seda, mida ma näen, millegi Invensega. Sellest hoolimata otsustasin vaadata leitud mudelite registriteavet: MPU-6050 ja MPU-9250.

Mõlemal juhul on järgmine mõlema puhul sama. Alustuseks eeldame, et see on sama ka selle MPU-92/65 puhul.

59 kuni 64 - kiirendusmõõturi mõõtmised

65, 66 - temperatuuri mõõtmised 67 kuni 72 - güroskoobi mõõtmised 73 kuni 96 - välisanduri andmed

Märkus: MPU-6050-l pole magnetomeetrit, samas kui MPU-9250-l (ja eeldame, et ka sellel) on see olemas.

Registridokumendist koguti veel mõnda huvitavat, loodetavasti kasulikku teavet:

Magnetomeetri teave:

magnetomeetri id: 0x48 registreerib 00 kuni 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 HY9 HY8 07H HZZ 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 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 HZH ST2 0 0 0 BITM HOFL 0 0 0 jaotus selle kohta, mida iga register tähendab: HXL [7: 0]: X-telje mõõtmisandmed madalamad 8bit HXH [15: 8]: X-telje mõõtmisandmed kõrgemad 8bit HYL [7: 0]: Y-telje mõõtmisandmed madalamad 8bit HYH [15: 8]: Y-telje mõõtmisandmed suuremad 8bit HZL [7: 0]: Z-telje mõõtmisandmed madalamad 8bit HZH [15: 8]: Z-telje mõõtmisandmed kõrgemad 8 bitti

Programmeerimine

Veel üks teave registri dokumentidest on see, et tundus, et seal on ainult umbes 100 registrit. Nii et üks taktika võiks olla kirjutada lihtne programm, mis pääseb seadmele juurde (0x68) ja üritab lugeda järjestikku registreid, arvestamata nende tähendust, lihtsalt selleks, et näha, milliseid andmeid on võimalik näha.

Seejärel tehke sama koodi kasutades järjestikuseid möödumisi ja võrrelge andmeid ühest ja järgmisest.

Mõte on selles, et me võiksime ilmselt kõrvaldada kõik registrid, millel näivad puuduvad andmed (nullid või FF?) Või mis absoluutselt kunagi ei muutu, ning võiksime keskenduda ka nendele, mis muutuvad.

Seejärel vaatame ainult neid, mis muutuvad, lisage keskmistamisfunktsioon, mis keskmistab selle registri viimased N lugemised, et näha, kas sellel registril on tegelikult kindel püsiväärtus. See eeldab, et hoiame andurit väga paigal ja samas kohas.

Lõpuks võiksime anduriga asju õrnalt proovida, näiteks nihutada (kiirendusmõõtur, güroskoop) või puhuda (temperatuur) või pöörata (kaks eelmist pluss magnetomeetrit) ja vaadata, milline on selle mõju väärtustele.

Mulle meeldib kasutada wiringPi raamatukogu nii palju kui võimalik. Sellel on I2C tugi.

Esimene jooks:

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

* ehitada: gcc first.test.mpu9265.c -o first.test.mpu9265 -lwiringPi * * käivitada: sudo./first.test.mpu9265 * * see programm väljastab MCP23017 -st lihtsalt (võimalikud) registrid, * ja seejärel MPU9265 -st (või muult MPU -lt sellel 0x68 -aadressil) * * Kasutasin seda, et kontrollida, kas suudan isegi andurilt lugeda, kuna mul oli juba * usaldus MCP23017 vastu. ************************************************* ****************************/ #include #include #include #include #include int main (int argc, char ** argv) {put ("Vaatame, mida MCP23017 @ 0x20 ütleb:"); viga = 0; int deviceId1 = 0x20; int fd1 = juhtmestikPiI2CSetup (seadmeId1); if (-1 == fd1) {fprintf (stderr, "WiringPi I2C seadet ei saa avada: %s / n", strerror (errno)); tagasitulek 1; } for (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d", wiringPiI2CReadReg8 (fd1, reg)); fflush (stderr); viivitus (10); } paneb (""); paneb ("Vaatame, mida MPU9265 @ 0x20 ütleb:"); viga = 0; int deviceId2 = 0x68; int fd2 = juhtmestikPiI2CSetup (seadmeId2); if (-1 == fd2) {fprintf (stderr, "WiringPi I2C seadet ei saa avada: %s / n", strerror (errno)); tagasitulek 1; } for (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d", wiringPiI2CReadReg8 (fd2, reg)); fflush (stderr); viivitus (10); } paneb (""); tagasitulek 0; }

Teine jooks:

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

* ehitada: gcc second.test.mpu9265.c -o second.test.mpu9265 -lwiringPi * * käivitada: sudo./second.test.mpu9265 * * See programm väljastab registrinumbri koos loetud väärtusega. * * See muudab kasulikuks väljundi torusse suunamise (ümbersuunamise) faili ja seejärel * saab võrrelda mitu korda. See võib anda ülevaate * sellest, millised registrid on olulised ja kuidas andmed võivad käituda. ************************************************* ****************************/ #include #include #include #include #include #include int main (int argc, char ** argv) {int seadmeId = -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; } paneb ("Vaatame, mida MPU9265 @ 0x20 ütleb:"); viga = 0; int fd = juhtmestikPiI2CSetup (seadmeId); if (-1 == fd) {fprintf (stderr, "WiringPi I2C seadet ei saa avada: %s / n", strerror (errno)); tagasitulek 1; } for (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); viivitus (10); } tagasitulek 0; }

Kolmas jooks:

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

* ehitada: gcc kolmas.test.mpu9265.c -o kolmas.test.mpu9265 -lwiringPi * * käivitada: sudo./third.test.mpu9265 * * See programm on teise tulemuse tulemus. See loeb ainult * registritest, mis näitasid erinevust ühe ja järgmise jooksu vahel.************************************************* ****************************/ #include #include #include #include #include #include int main (int argc, char ** argv) {int seadmeId = -1; if (0) {} else if (! strncmp (argv [1], "0x68", strlen ("0x68"))) {deviceId = 0x68; } else if (! strncmp (argv [1], "0x69", strlen ("0x69"))) {deviceId = 0x69; } paneb ("Vaatame, mida MPU9265 @ 0x20 ütleb:"); viga = 0; int fd = juhtmestikPiI2CSetup (seadmeId); if (-1 == fd) {fprintf (stderr, "WiringPi I2C seadet ei saa avada: %s / n", strerror (errno)); tagasitulek 1; } for (int reg = 61; reg <= 73; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); viivitus (10); } for (int reg = 111; reg <= 112; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); viivitus (10); } for (int reg = 189; reg <= 201; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); viivitus (10); } for (int reg = 239; reg <= 240; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); viivitus (10); } tagasitulek 0; }

Mida me siis siiani õppisime? Tabeli pilt värviliste esiletõstetud aladega näitab, et väljund näib ühtivat esimeste registrikomplektidega.

Senised tulemused võivad tekitada uusi küsimusi.

Küsimus: miks on "välise" rühma jaoks ainult üks registritulemus?

Küsimus: mis on kõik need tundmatud registrid "??????"

Küsimus: kuna programm ei ole katkestatud, kas see küsis andmeid liiga aeglaselt? liiga kiire?

Küsimus: kas me saame tulemusi mõjutada, kui proovime asju anduri endaga, kui see töötab?

6. samm: uurime rohkem näitu / andmeid

Ma arvan, et järgmine samm enne kõike muud on programmi täiustamine:

• olema paindlik, kui palju silmuse viivitust (ms)
• olema paindlik, kui palju näiteid anda jooksva keskmise kohta registri kohta

(Pidin programmi failina lisama. Tundus, et selle siia sisestamisel tekkis probleem. "4th.test.mpu9265.c")

Siin on jooks, kasutades keskmiselt 10 viimast lugemist 10 ms silmusel:

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

Esimene vasakpoolne veerg on registrinumber. Siis tulevad selle registri viimased 10 näitu. Lõpuks on viimane veerg iga rea keskmine.

Tundub, et registrid 61, 69, 71, 189, 197 ja 199 on kas ainult binaarsed või valmis / mitte valmis või on need 16-bitise väärtuse kõrge bait (negatiivne?).

Muud huvitavad tähelepanekud:

• registrid 65, 193 - väga stabiilne ja sama väärtus
• register 63, 191 - väga püsiv ja sama väärtus
• registrid 73, 112, 195, 201, 240 - kõik nulliga

Seostame need tähelepanekud tagasi mitmevärvilise, esile tõstetud tabelipildiga varasemast ajast.

Registreerige 65 - temperatuur

Registreeri 193 - ??????

Registreeri 63 - kiirendusmõõtur

Registreeri 191 - ??????

Register 73 - väline

Registreeri 112 ja edasi - ??????

Noh, meil on veel tundmatuid, aga oleme õppinud midagi kasulikku.

Register 65 (temperatuur) ja register 63 (kiirendusmõõtur) olid mõlemad väga ühtlased. See on midagi, mida me ootaksime. Ma pole andurit puudutanud; see ei liigu, välja arvatud juhuslikud vibratsioonid, kuna robot puhkab minu arvutiga samal laual.

Kõigi nende temperatuuri/kiirendusmõõturi registrite jaoks on üks huvitav test. Selle testi jaoks vajame veel ühte programmi versiooni.

Samm: võime mõjutada temperatuuri ja kiirendust

Eelmistes sammudes kitsendasime vähemalt ühte temperatuuri ja kiirenduse registrit.

Selle järgmise programmi versiooniga ("4th.test.mpu9265.c") näeme tegelikult muutust mõlema registri puhul. Palun vaadake videoid.

Veel kaevamist

Kui läheme tagasi ja vaatame registriteavet, näeme, et seal on:

• kolm 16 -bitist väljundit güroskoobi jaoks
• kolm 16 -bitist väljundit kiirendusmõõturi jaoks
• kolm 16 -bitist väljundit magnetomeetrile
• üks 16 -bitine väljund temperatuuri jaoks

Kuid meie lihtsate testprogrammide tulemused olid kõik üksikud 8 -bitised väljundid. (üksikud registrid).

Nii et proovime rohkem sama lähenemist, kuid seekord loeme 16 bitti 8 asemel.

Tõenäoliselt peame tegema midagi sellist, nagu allpool. Kasutame näitena temperatuuri, kuna see on ainult üks 16 -bitine väljund.

// hangi failikirjeldus fd …

int tempRegHi = 65; int tempRegLo = 66; int hiByte = juhtmestikPiI2CReadReg8 (fd, tempRegHi); int loByte = juhtmestikPiI2CReadReg8 (fd, tempRegLo); int tulemus = hiByte << 8; // pane hi -order 8 bitti 16 -bitise tulemuse ülemisse ossa | = loByte; // lisage nüüd järjekorras 8 bitti, andes täieliku 16 -bitise numbri // printige see number või kasutage ekraani horisontaalse graafiku funktsiooni

Varasematest sammudest nägime, et register 65 on üsna stabiilne, samas kui register 66 on väga mürarikas. Kuna 65 on hi järjekorra bait ja 66 madala järgu bait, on see mõttekas.

Lugemiseks võime võtta registri 65 andmed sellisena, nagu need on, kuid võiksime registri 66 väärtused keskmiselt välja lugeda.

Või võime lihtsalt keskmistada kogu tulemuse.

Vaadake selle osa viimast videot; see näitab kogu 16 -bitise temperatuuri väärtuse lugemist. Kood on "sixth.test.mpu9265.c"

Samm: kiirendusmõõtur ja güroskoop

Selle jaotise videod näitavad kiirendusmõõturi ja güroskoobi väljundit, kasutades testprogrammi "sevenh.test.mpu9265.c". See kood võib lugeda 1, 2 või 3 järjestikust baitpaari (hi ja lo baiti) ja teisendab väärtused üheks 16-bitiseks väärtuseks. Seega võime lugeda mis tahes üksikut telge või kahte neist koos (ja see võtab kokku muudatused) või lugeda kõiki kolme (ja see võtab kokku muutused).

Kordan veel kord, et selles etapis, selles juhendis, otsin ma lihtsalt vastust lihtsale küsimusele: "kas robot pöörles/pöörles?". Ma ei otsi mingit täpset väärtust, näiteks kas see pöörles 90 kraadi. See saabub hiljem, kui hakkame SLAM-i tegema, kuid seda ei nõuta lihtsate takistuste vältimiseks ja juhuslikeks liikumisteks.

9. samm: (pooleli olev töö) Magnetomeeter

tööriista i2cdetect kasutamisel kuvatakse tabelis MPU9265 kujul 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 magnetomeetri osast lugemiseks on vaja täiendavaid samme.

Invesense registritest PDF -dokument:

REGISTREERIMISED 37 kuni 39 - I2C SERVE 0 CONTROL

• REGISTER 37 - I2C_SLV0_ADDR
• REGISTREERI 38 - I2C_SLV0_REG
• REGISTER 39 - I2C_SLV0_CTRL