Wallace - DIY robot autonom - Pjesa 5 - Shto IMU: 9 hapa

2024 Autor: John Day | [email protected]. E modifikuara e fundit: 2024-01-30 12:24

Ne po vazhdojmë së bashku me Wallace. Emri Wallace erdhi nga një përzierje e "Wall-E", dhe nga një projekt i mëparshëm (njohja e zërit), dhe duke përdorur mjetin "espeak", ai tingëllonte pak britanik. Dhe si një shërbëtor ose shërbëtor. Dhe ky është qëllimi përfundimtar: që ky projekt të kthehet në diçka të dobishme. Kështu "Wallace".

Wallace mund të lëvizë, ai mund të shmangë pengesat duke përdorur sensorë të distancës IR (kohët e fundit, disi ata u skuqën (?) (Duhet ta shikoni atë kur të më jepet rasti), gjithashtu ka disa sensorë akustikë të distancës (tre prej tyre u keqësuan në të njëjtën kohë koha, së bashku me një zgjerues MCP23017), dhe së fundi, mund të zbulojë ndryshimet në rrymën motorike për të ditur kur është përplasur me diçka.

Përveç sensorëve, Wallace "mban mend" 100 lëvizjet dhe ka disa analiza rudimentare duke përdorur historinë e lëvizjes.

Qëllimi deri më tani për Wallace është thjesht të përpiqet të vazhdojë të ecë përpara dhe të dijë kur është mbërthyer në një model të përsëritur (të tillë si në një qoshe) dhe nuk shkon vërtet përpara.

Kam kaluar disa përsëritje për lëvizjen dhe lundrimin, dhe dhimbja e vazhdueshme e kokës ka qenë gjatë rrotullimit.

Meqenëse Wallace është një robot i gjurmuar, dhe unë doja t’i mbaja gjërat më të thjeshta në softuer (për më vonë), në mënyrë që të kthehem unë thjesht e bëj atë të rrotullohet/rrotullohet në vend. Kështu, aplikoni cikël të barabartë por të kundërt të fuqisë / funksionit për motorët.

Problemi i hasur është për shkak të dizajnit të platformës së robotëve Agent 390. Rripat e pista priren të fërkohen në anët. Dhe më keq, njëra palë e bën këtë më shumë se tjetra.

Në dysheme dhe duke shkuar drejt, nuk ka qenë problem. Ajo shfaqet në qilima. Zgjodha ta mbaja Wallace larg qilimave pasi gjurmët e tij u bënë të zymta (ato marrin grimca jashtëzakonisht lehtë).

Problemi i vërtetë është kur rrotulloheni në dysheme.

Nëse e kam softuerin të zbatojë një cikël detyre të nivelit të lartë, atëherë ai pak a shumë vazhdimisht kthehet. Sidoqoftë, gjatë një cikli të ulët të punës, ai mund ose nuk mund të kthehet në të vërtetë. Ose mund të kthehet për pak dhe pastaj të ngadalësohet. Veprimi rrotullues duket të jetë i pakontrollueshëm përmes softuerit, ose në rastin më të mirë shumë i vështirë.

Problemi shfaqet gjatë lundrimit dhe lëvizjes ose largimit nga pengesat. Ai ose mund të lëkundet shumë jashtë mase, ose mund të ngecet duke u përpjekur të bëjë ndërrime shumë të vogla, pa lëvizur fare.

Dhe kështu shpjegimi i mësipërm e motivoi këtë Udhëzues.

Fillimisht, doja të hiqja dorë ose të vonoja prezantimin e një njësie të ndjeshmërisë së lëvizjes (IMU), sepse ato janë A) të komplikuara, B) të zhurmshme, C) gabimet mund të futen me kalimin e kohës, etj, etj. Mendimi im kishte ishte se ne mund të bënim shumë mirë duke u hedhur përpara në sensorët lazer IR të kohës së fluturimit. Dhe ne mundemi - duke përdorur lazer mund të dimë nëse roboti rrotullohet apo jo, duke ndjekur ndryshimet në distancë.

Në fakt, ne gjithashtu (mund ta bëjmë) tani, me sensorët akustikë.

Sidoqoftë, e gjithë kjo është një mënyrë shumë indirekte, e ndërlikuar për t'iu përgjigjur një pyetjeje të thjeshtë: "a kemi rrotulluar apo jo?"

Më dukej se kërcimi për të përdorur sensorët lazer ToF do të më çonte në nivelin tjetër të softuerit; domethënë, SLAM (Lokalizimi dhe Hartimi i Njëkohshëm). Ende nuk isha gati të shkoja atje.

Thingshtë një gjë e mirë të bësh një projekt robot në shtresa, ku shtresat e para (të poshtme) janë më të thjeshta, dhe shtresat e fundit (të sipërme) janë më abstrakte dhe trajtojnë çështje më të vështira.

Shtresat mund të mendohen për diçka si kjo:

1. kornizë fizike robot / bazë strukturore mekanike
2. sistemi fillestar i vozitjes (mjedër, Roboclaw, motorë, kabllo, etj, softuer bazë, i drejtuar nga tastiera)
3. qarqe thelbësore për të mbështetur sensorët (ndërruesi i tensionit me dy drejtime, zgjeruesi i portit, ndalesa elektronike, shpërndarja e energjisë, etj)
4. sensorë të shmangies së pengesave (akustike, IR)
5. pozicionimi dhe lëvizja thelbësore, themelore - zbulimi (përshpejtues, xhiro, magnetometër, kodues motorësh, kodues të rrotave)

Mund të dalësh me listën tënde. Pikat në lidhje me këtë listë janë se ju ndoshta duhet t'i bëni këto pak a shumë në atë mënyrë, dhe gjithashtu se nëse kaloni ca kohë në secilën shtresë për të arritur secilën në një gjendje të mirë pune, kjo duhet t'ju ndihmojë më vonë pasi gjërat bëhen më të ndërlikuara.

Lista e mësipërme mund të jetë pak a shumë e lidhur me këto shtresa konceptuale në softuer.

• SLAM (Lokalizimi dhe hartëzimi i njëkohshëm)
• Kontrolli dhe Ndërgjegjësimi i Lëvizjes, Rrotullimi
• Shmangia e Pengesave Themelore
• Kontrolli dhe Zbulimi i të Dhënave të Sensorit
• Lëvizja Thelbësore Përpara, Prapa, Majtas dhe Djathtas, Shpejtoni, Ngadalësoni, Ndaloni

Siç mund ta shihni, për këtë listë, artikujt e parë do të ishin shtresat e sipërme, më të komplikuara që trajtojnë çështje dhe pyetje më abstrakte, të tilla si "ku jam" dhe "ku po shkoj", ndërsa artikujt e fundit do të ishin shtresa të ulëta të softuerit që trajtojnë "si të flasim/dëgjojmë sensorin A" ose "si ta lëvizim këtë rrotë".

Tani, nuk po them që kur të filloni në një shtresë, do ta keni përfunduar dhe pastaj është në shtresën tjetër, për të mos u kthyer kurrë në atë të mëparshme. Një projekt robot mund të jetë shumë i ngjashëm me metodat moderne, përsëritëse të zhvillimit të softuerit (të shkathët, SCRUM, etj).

Unë thjesht them që të marr kohë për secilën. Ju do të duhet të balanconi sa të bëni në secilën, dhe të vendosni se çfarë po përpiqeni në një shtresë të caktuar që ia vlen kohën dhe mundimin.

Ekziston një "konflikt" ose "tension" midis dy ideve ose drejtimeve konkurruese.

Njëra është ajo që unë do ta quaja "plug-n-play" për të zgjidhur problemin A.

Tjetri është DIY (bëjeni vetë). Dhe kjo mund të mos jetë as etiketa më e mirë për këtë ide tjetër.

Këtu keni një shembull të secilës, shpresojmë se do të shihni tensionin ose konfliktin midis dy zgjedhjeve.

Për këtë shembull, le të grumbullojmë SLAM, shmangien e pengesave dhe lëvizjen themelore thelbësore, të gjitha si një problem për t'u zgjidhur në të njëjtën kohë.

1. Nëse vendosim të shkojmë në rrugën plug-n-play, ne menjëherë kërcejmë (në varësi të buxhetit) për gjëra të tilla si ato lazer rrotullues të montuar në krye, ose kamera të thellësisë së fushës, ose lazerët ToF, dhe IMU (tema e kësaj I udhëzueshëm).
2. Nëse ne, nga ana tjetër, duam të shkojmë në rrugën e dytë, mund të përpiqemi të nxjerrim çdo informacion të mundshëm nga disa sensorë akustikë ose sensorë IR, ose aspak sensorë - ne thjesht përdorim monitorimin e rrymës motorike (përplasje)

Çfarë mund të thuhet për #1 vs #2? Një gjë do të ishte që ne do të kemi mësuar shumë më tepër duke bërë numrin 2. Kufizimet për të pasur vetëm sensorë akustikë për të punuar, na detyrojnë të mendojmë për shumë më tepër çështje.

Nga ana tjetër, nëse jemi shumë të fokusuar në bërjen e gjërave përmes numrit 2, mund të humbim kohë, sepse kërkojmë më shumë sesa duhet nga sensorët akustikë.

Një koncept ose ide më shumë për të menduar: Cila përzierje e harduerit dhe softuerit i përgjigjet më së miri pyetjeve të "si" dhe cila përzierje e softuerit (dhe harduerit?) I përgjigjet pyetjes "çfarë", "kur", "ku" Me Sepse "si" është zakonisht një pyetje e nivelit më të ulët nga e cila varet "çfarë", "kur" dhe "ku" për të marrë një përgjigje.

Sidoqoftë, të gjitha sa më sipër ishin vetëm diçka për të menduar.

Në rastin tim, pas shumë përpjekjesh dhe duke pasur çështjen e vazhdueshme të bezdisshme të fërkimit të pistave dhe paaftësinë për të marrë kontroll dhe lëvizje të qëndrueshme, është koha për të bërë diçka tjetër.

Kështu kjo Instructable - një IMU.

Qëllimi është që nëse IMU thotë se roboti NUK po rrotullohet, ne rrisim ciklin e punës. Nëse rrotullohemi shumë shpejt, zvogëlojmë ciklin e punës.

Hapi 1: Sensori IMU

Dhe kështu sensori ynë i ardhshëm për t'i shtuar Wallace është IMU. Pas disa kërkimeve, unë isha duke u vendosur në një MPU6050. Por atëherë në këtë kohë, MPU9050 (dhe madje edhe kohët e fundit, MPU9250) dukej si një ide edhe më e mirë.

Burimi im i parë ka qenë Amazon (në SHBA). Kështu që unë porosita dy prej tyre.

Ajo që mora në fakt (duket se nuk ka kontroll mbi këtë; kjo është ajo që nuk më pëlqen në Amazon) ishin dy MPU92/65. Pyes veten pak për përcaktimin. Hidhini një sy imazheve; që duket të jetë një përcaktim "familjar". Në çdo rast, kjo është ajo me të cilën jam mbërthyer.

Shtimi i tij është shumë i thjeshtë -merrni një bord proto me shirita lidhës, lidhni sensorin në bord, shtoni një bllok terminali me vida me 10 kunja (unë e mora nga Pololu).

Për të minimizuar çdo ndërhyrje, unë u përpoqa t'i vendos këto sensorë larg çdo gjëje tjetër.

Kjo gjithashtu nënkuptonte përdorimin e disa bulonave/arrave prej najloni.

Unë do të përdor protokollin I2C. Shpresojmë që gjatësia totale e telit të mos jetë shumë e keqe.

Ka shumë informacione diku tjetër në lidhje me lidhjet themelore dhe nivelet e tensionit, etj, kështu që unë nuk do ta përsëris këtu.

Hapi 2: Gjërat nuk janë gjithmonë të pastra, të lehta

Në këtë shkrim, nuk duket të ketë shumë në internet për këtë MPU-92/65 të veçantë. Ajo që është në dispozicion, ashtu si me shumicën e sensorëve, duket se janë shembuj duke përdorur Arduino.

Unë përpiqem t'i bëj këto udhëzime pak më ndryshe duke paraqitur një proces jo aq të pastër, sepse gjërat jo gjithmonë funksionojnë menjëherë.

Unë mendoj se këto udhëzime janë më shumë të ngjashme me një blog sesa drejtpërdrejt A-B-C, 1-2-3 "kështu e bëni këtë".

Hapi 3: Testi fillestar

Nga imazhet në hapin e mëparshëm, telat kuq e zi që shkojnë te sensorët janë natyrisht VCC (5V) dhe GND. Telat e gjelbër dhe të verdhë janë lidhjet I2C.

Nëse keni bërë projekte të tjera I2C, ose keni qenë duke ndjekur së bashku me këto seri, atëherë tashmë dini për "i2cdetect" dhe ky është hapi i parë për të ditur nëse Raspberry mund të shohë sensorin e ri.

Siç mund ta shihni nga imazhet në këtë hap, përpjekja jonë e parë ishte e pasuksesshme. IMU nuk shfaqet (duhet të jetë ID e pajisjes 0x68).

Sidoqoftë, lajmi i mirë është se autobusi I2C po funksionon. Ne shohim një pajisje 0x20 dhe është zgjeruesi i portit MCP23017 (aktualisht përgjegjës për sensorët akustikë HCSR04).

Nuk është e lehtë të shihet në imazh, por unë lidha të njëjtat tela me ngjyrë të gjelbër dhe të verdhë nga IMU në MCP23017 (shih më poshtë majtas në imazh)

Ne do të duhet të bëjmë disa probleme për zgjidhjen e problemeve.

Hapi 4: Zgjidhja e problemeve

Duke përdorur cilësimin e vazhdimësisë në një voltmetër (ai me tonin e lartë), unë testova lidhjet VCC (5V), GND, SDA dhe SCL. Ato ishin të mira.

Përpjekja tjetër ishte shkëputja e MCP23017 nga autobusi I2C, duke lënë vetëm MPU-92/65 në autobus. Kjo doli e pafrytshme - "i2cdetect" atëherë nuk tregoi pajisje.

Kështu, më tej, e çmontova sensorin nga shtylla totem dhe e rilidhja direkt në autobusin dydrejtimësh 5V-në-3V; dmth, drejtpërdrejt te Mjedra. (tela më të shkurtër?).

Dhe voila. Këtë herë ka sukses. Ne shohim që 0x68 shfaqet duke përdorur "i2cdetect".

Por ne ende nuk e dimë pse funksionoi këtë herë. Mund të jetë gjatësia e telave? Vendndodhja e mëparshme?

Shënim: Nuk kishte ndonjë ndryshim nëse ADO ishte i bazuar apo jo. Mund të ketë rezistenca tërheqëse dhe tërheqëse në bord. E njëjta gjë mund të jetë e vërtetë për FSYNC.

Tjetra, lidha përsëri MCP23017. Pra, tani kemi dy pajisje në autobusin I2C. (shiko imazhin). Suksese, tani shohim si 0x20 ashtu edhe 0x68 me i2cdetect.

Videot përfshijnë pak më shumë se çfarë ndodhi gjatë zgjidhjes së problemeve.

Hapi 5: Leximi i të dhënave të sensorit

Qasje të ndryshme

Vendosa të marr qasje të shumta për marrjen e informacionit të dobishëm nga sensori. Këtu ata janë, jo në asnjë mënyrë:

1. provoni disa programime bazë
2. shikoni disa dokumentacione online mbi regjistrat
3. hidhini një sy shembujve dhe / ose kodit të të tjerëve

Pse këto qasje? Pse të mos kërkoni vetëm ndonjë bibliotekë ose kod ekzistues?

Duke eksperimentuar dhe provuar disa ide, ne mund të thithim më mirë disa njohuri jo vetëm për këtë sensor të veçantë, por gjithashtu të fitojmë disa teknika, aftësi dhe mënyra të të menduarit për të trajtuar diçka të re, dhe diçka që mund të mos ketë shumë dokumentacion; diçka që mund të ketë shumë të panjohura.

Gjithashtu, pasi të kemi luajtur dhe të provojmë disa nga idetë tona dhe të kemi një njohuri, ne jemi në një pozicion më të mirë për të vlerësuar kodin ose bibliotekën e dikujt tjetër.

Për shembull, pasi shikova një kod C ++ për MPU9250 në github, kuptova se po më detyronte të përdor ndërprerje, gjë që ende nuk dua ta bëj.

Gjithashtu, vjen me gjëra shtesë si kalibrimi; përsëri, diçka që nuk më intereson ende.

Mund të ndodhë që ajo që duhet të bëj për t'iu përgjigjur pyetjes së thjeshtë "a është roboti që rrotullohet po ose jo" mund të përgjigjet shumë thjesht duke lexuar disa regjistra.

Regjistrat

Në këtë shkrim, nuk duket të ketë shumë në dispozicion në këtë sensor. Në fakt, nëse i hidhni një sy imazheve që vijnë me këtë Instructable dhe i hidhni një sy nga afër mbishkrimet në patate të skuqura aktuale, më bën të pyes veten nëse kjo nuk është një nok-off. Unë nuk e lidh atë që shoh me asgjë nga Invense. Pavarësisht, unë zgjodha të shikoja informacionin e regjistrit për modelet që gjeta: MPU-6050 dhe MPU-9250.

Në të dy rastet, sa vijon është e njëjtë për të dy. Dhe për fillestarët, ne supozojmë se do të jetë gjithashtu e njëjtë për këtë MPU-92/65.

59 në 64 - matjet e përshpejtuesit

65, 66 - matjet e temperaturës 67 në 72 - matjet e xhiroskopit 73 deri në 96 - të dhëna të jashtme të sensorit

Një artikull i shënimit: MPU-6050 duket se NUK ka një magnetometër, ndërsa MPU-9250 (dhe supozojmë se edhe ky) ka një të tillë.

Disa informacione më interesante, me shpresë të dobishme të mbledhura nga dokumenti i regjistrit:

Informacioni i magnetometrit:

magnetometri id: 0x48 regjistron 00 deri 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 HXHXHXHXHXHXHXHXHXHXHXHXHXHX 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 07HZ HZHZHZ HZHZHZ HZHZHZHZHZHZHZHZHZHZHZHZHZHZHZHZHZHZHZHZHZHZHZHZHZHZHZHZHZHZHZHZHZHZHZHZHZ ST2 0 0 0 BITM HOFL 0 0 0 një ndarje të asaj që do të thotë secili regjistër: HXL [7: 0]: Të dhënat e matjes së boshtit X më të ulëta 8bit HXH [15: 8]: Të dhëna të matjes të boshtit X më të larta 8bit HYL [7: 0]: Të dhënat e matjes të boshtit Y më të ulëta 8bit HYH [15: 8]: Të dhënat e matjes së boshtit Y më të larta 8bit HZL [7: 0]: Të dhënat e matjes së boshtit Z më të ulëta 8bit HZH [15: 8]: Të dhënat e matjes të boshtit Z më të larta 8bit

Programimi

Një informacion tjetër nga dokumentet e regjistrit është se dukej se kishte vetëm rreth 100 regjistra. Pra, një taktikë mund të jetë të shkruani një program të thjeshtë që hyn në pajisje (0x68) dhe përpiqet të lexojë një seri regjistrash në mënyrë të njëpasnjëshme, pa marrë parasysh kuptimin e tyre, vetëm për të parë se çfarë të dhënash mund të shihen.

Dhe pastaj, bëni kalime të njëpasnjëshme, duke përdorur të njëjtin kod dhe krahasoni të dhënat nga një kalim me tjetrin.

Ideja është që ne ndoshta mund të eliminojmë çdo regjistër që duket se nuk ka të dhëna (zero apo FF?) Ose që absolutisht nuk ndryshojnë kurrë, dhe ne gjithashtu mund të përqëndrohemi në ato që ndryshojnë.

Pastaj, një që po shikojmë vetëm ato që ndryshojnë, shtoni në një funksion mesatarizimin që mesatarizon leximet e fundit të N të atij regjistri, për të parë nëse në fakt ka një vlerë të caktuar të qëndrueshme për atë regjistër. Kjo do të supozonte se ne po e mbajmë sensorin shumë të qetë, dhe në të njëjtin vend.

Së fundi, ne mund të provojmë butësisht gjëra me sensorin, të tilla si shtyrja e tij (akselerometër, xhiro), ose fryrja në të (temperatura), ose rrotullimi i tij (dy magnetometrat e mëparshëm plus) dhe të shohim se çfarë efekti ka kjo në vlerat.

Më pëlqen të përdor bibliotekën wiringPi sa më shumë që të jetë e mundur. Ka mbështetje për I2C.

Vrapimi i parë:

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

* për të ndërtuar: gcc first.test.mpu9265.c -o first.test.mpu9265 -lwiringPi * * për të ekzekutuar: sudo./first.test.mpu9265 * * ky program vetëm nxjerr një sërë regjistrash (të mundshëm) nga MCP23017, * dhe pastaj nga MPU9265 (ose ndonjë MPU tjetër në atë adresë 0x68) * * E kam përdorur për të vërtetuar nëse mund të lexoja edhe nga sensori, pasi që tashmë * kisha besim në MCP23017. ********************************************** **************************/ #include #include #include #include #includ int main (int argc, char ** argv) {vendos ("Le të shohim se çfarë thotë MCP23017 @ 0x20:"); errno = 0; int pajisjeId1 = 0x20; int fd1 = instalime elektrikePiI2CSetup (pajisjaId1); if (-1 == fd1) {fprintf (stderr, "Nuk mund të hap pajisjen e instalimeve elektrikePi I2C: %s / n", strerror (errno)); kthehu 1; } për (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d", instalime elektrikePiI2CReadReg8 (fd1, reg)); fflush (stderr); vonesa (10); } vendos (""); vë ("Le të shohim se çfarë thotë MPU9265 @ 0x20:"); errno = 0; int pajisjeId2 = 0x68; int fd2 = instalime elektrikePiI2CSetup (pajisjaId2); if (-1 == fd2) {fprintf (stderr, "Nuk mund të hap pajisjen e instalimeve elektrikePi I2C: %s / n", strerror (errno)); kthehu 1; } për (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d", instalime elektrikePiI2CReadReg8 (fd2, reg)); fflush (stderr); vonesa (10); } vendos (""); kthimi 0; }

Vrapimi i dytë:

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

* për të ndërtuar: gcc second.test.mpu9265.c -o second.test.mpu9265 -lwiringPi * * për të ekzekutuar: sudo./second.test.mpu9265 * * Ky program nxjerr numrin e regjistrit krahas vlerës së lexuar. * * Kjo e bën të dobishme tubimin (përcjelljen) e daljes në një skedar, dhe më pas * disa drejtime mund të bëhen, për t'u krahasuar. Mund të japë një pasqyrë në * se cili regjistër është i rëndësishëm dhe si mund të sillen të dhënat. ********************************************** *************************** # #Include #Include #Include #Include #Include #Include int main (int argc, char ** argv) {int deviceId = -1; nëse (0) {} tjetër nëse (! strncmp (argv [1], "0x20", strlen ("0x20"))) {deviceId = 0x20; } tjetër nëse (! strncmp (argv [1], "0x68", strlen ("0x68"))) {deviceId = 0x68; } tjetër nëse (! strncmp (argv [1], "0x69", strlen ("0x69"))) {deviceId = 0x69; } vendos ("Le të shohim se çfarë thotë MPU9265 @ 0x20:"); errno = 0; int fd = instalime elektrikePiI2CSetup (pajisjaId); if (-1 == fd) {fprintf (stderr, "Nuk mund të hap pajisjen e instalimeve elektrikePi I2C: %s / n", strerror (errno)); kthehu 1; } për (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d:%d / n", reg, instalime elektrikePiI2CReadReg8 (fd, reg)); fflush (stderr); vonesa (10); } kthimi 0; }

Vrapimi i tretë:

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

* për të ndërtuar: gcc third.test.mpu9265.c -o third.test.mpu9265 -lwiringPi * * për të ekzekutuar: sudo./third.test.mpu9265 * * Ky program është rezultat i programit të dytë. Lexohet vetëm nga regjistrat * që treguan një ndryshim midis një drejtimi dhe tjetrit.********************************************** *************************** # #Include #Include #Include #Include #Include #Include int main (int argc, char ** argv) {int deviceId = -1; nëse (0) {} tjetër nëse (! strncmp (argv [1], "0x68", strlen ("0x68"))) {deviceId = 0x68; } tjetër nëse (! strncmp (argv [1], "0x69", strlen ("0x69"))) {deviceId = 0x69; } vendos ("Le të shohim se çfarë thotë MPU9265 @ 0x20:"); errno = 0; int fd = instalime elektrikePiI2CSetup (pajisjaId); if (-1 == fd) {fprintf (stderr, "Nuk mund të hap pajisjen e instalimeve elektrikePi I2C: %s / n", strerror (errno)); kthehu 1; } për (int reg = 61; reg <= 73; reg ++) {fprintf (stderr, "%d:%d / n", reg, instalime elektrikePiI2CReadReg8 (fd, reg)); fflush (stderr); vonesa (10); } për (int reg = 111; reg <= 112; reg ++) {fprintf (stderr, "%d:%d / n", reg, instalime elektrikePiI2CReadReg8 (fd, reg)); fflush (stderr); vonesa (10); } për (int reg = 189; reg <= 201; reg ++) {fprintf (stderr, "%d:%d / n", reg, instalime elektrikePiI2CReadReg8 (fd, reg)); fflush (stderr); vonesa (10); } për (int reg = 239; reg <= 240; reg ++) {fprintf (stderr, "%d:%d / n", reg, instalime elektrikePiI2CReadReg8 (fd, reg)); fflush (stderr); vonesa (10); } kthimi 0; }

Pra, çfarë mësuam deri më tani? Imazhi i tabelës me zona të theksuara me ngjyra tregon se dalja duket se përputhet me grupet e para të regjistrave.

Rezultatet e deritanishme mund të gjenerojnë pyetje të reja.

Pyetje: pse ka vetëm një rezultat regjistrimi për grupin "e jashtëm"?

Pyetje: cilat janë të gjithë ata regjistra të panjohur "??????"

Pyetje: meqenëse programi nuk drejtohet nga ndërprerja, a kërkoi të dhëna shumë të ngadalta? shume shpejt?

Pyetje: a mund të ndikojmë në rezultatet duke provuar gjëra me vetë sensorin ndërsa funksionon?

Hapi 6: Le të gërmojmë më shumë në leximet / të dhënat

Unë mendoj se hapi tjetër para çdo gjëje tjetër është përmirësimi i programit në:

• jini fleksibël në sa vonesë lak (ms)
• jini fleksibël në sa lexime për të dhënë një mesatare të funksionimit për regjistër

(Më duhej ta bashkëngjitja programin si një skedar. Dukej se ishte një problem duke e futur këtu. "4th.test.mpu9265.c")

Këtu keni një vrap duke përdorur mesatarisht 10 leximet e fundit, në një lak 10ms:

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

Kolona e parë, më e majta është numri i regjistrit. Pastaj vijnë 10 leximet e fundit për atë regjistër. Së fundi, kolona e fundit është mesatarja për secilën rresht.

Duket se regjistrat 61, 69, 71, 189, 197 dhe 199 janë ose vetëm binarë, ose të gatshëm / jo gati, ose janë bajti i lartë i një vlere 16-bit (negative?).

Vëzhgime të tjera interesante:

• regjistrat 65, 193 - shumë të qëndrueshëm dhe me të njëjtën vlerë
• regjistri 63, 191 - shumë i qëndrueshëm dhe me të njëjtën vlerë
• regjistrat 73, 112, 195, 201, 240 - të gjitha në zero

Le t'i lidhim këto vëzhgime me imazhin e tabelës me shumë ngjyra, të theksuar nga më parë.

Regjistrohu 65 - temperatura

Regjistrohu 193 - ??????

Regjistri 63 - akselerometër

Regjistrohu 191 - ??????

Regjistri 73 - i jashtëm

Regjistrohuni 112 e tutje - ??????

Epo, ne ende kemi të panjohura, megjithatë, ne kemi mësuar diçka të dobishme.

Regjistri 65 (temperatura) dhe regjistri 63 (përshpejtuesi) ishin të dy shumë të qëndrueshëm. Kjo është diçka që do të prisnim. Unë nuk e kam prekur sensorin; nuk po lëviz, përveç çdo dridhje të rastësishme, pasi roboti po pushon në të njëjtën tryezë me kompjuterin tim.

Ekziston një test interesant që mund të bëjmë për secilin prej këtyre regjistrave të temperaturës/përshpejtuesit. Për atë test, ne kemi nevojë për një version tjetër të programit.

Hapi 7: Ne jemi në gjendje të ndikojmë në temperaturën dhe përshpejtimin

Në hapat e mëparshëm kemi ngushtuar të paktën një regjistër për temperaturën dhe një për përshpejtimin.

Me këtë version tjetër të programit ("5th.test.mpu9265.c"), ne në fakt mund të shohim një ndryshim të ndodhë për të dy regjistrat. Ju lutemi shikoni videot.

Më shumë gërmime

Nëse kthehemi dhe hedhim një vështrim në informacionin e regjistrit, shohim se ka:

• tre dalje 16 bit për xhiroskop
• tre dalje 16 bit për përshpejtues
• tre dalje 16 bit për magnetometër
• një dalje 16 bit për temperaturën

Sidoqoftë, rezultatet e marra nga programet tona të thjeshta të testimit ishin të gjitha dalje të vetme 8 bit. (regjistra të vetëm).

Pra, le të provojmë më shumë të njëjtën qasje, por këtë herë duke lexuar 16 bit në vend të 8.

Ndoshta do të na duhet të bëjmë diçka si më poshtë. Le të përdorim temperaturën si shembull, pasi është vetëm një dalje 16 bit.

// merrni përshkruesin e skedarit fd…

int tempRegHi = 65; int tempRegLo = 66; int hiByte = instalime elektrikePiI2CReadReg8 (fd, tempRegHi); int loByte = instalime elektrikePiI2CReadReg8 (fd, tempRegLo); int rezultati = hiByte << 8; // vendos rendin hi 8 bit në pjesën e sipërme të një rezultati të vlerës 16 bit | = loByte; // tani shtoni në rendin lo 8 bit, duke dhënë një numër të plotë 16 bit // printoni atë numër ose përdorni funksionin e grafikimit horizontal të ekranit nga më parë

Nga hapat tanë të mëparshëm kemi parë që regjistri 65 është mjaft i qëndrueshëm në shkëmb, ndërsa regjistri 66 është shumë i zhurmshëm. Meqenëse 65 është bajt i rendit të lartë, dhe 66 bajt i rendit të ulët, kjo ka kuptim.

Për të lexuar, ne mund të marrim të dhënat e regjistrit 65 ashtu siç janë, por mund të nxjerrim mesatarisht vlerat e regjistrit 66.

Ose thjesht mund të mesatarizojmë të gjithë rezultatin.

Hidhini një sy videos së fundit për këtë pjesë; demonstron leximin e të gjithë vlerës së temperaturës 16 bit. Kodi është "sixth.test.mpu9265.c"

Hapi 8: Përshpejtuesi dhe Xhiroskopi

Videot për këtë seksion tregojnë daljen nga përshpejtuesi dhe xhiroskopi, duke përdorur një program testimi "seventh.test.mpu9265.c". Ky kod mund të lexojë 1, 2 ose 3 bajt-çifte të njëpasnjëshëm (hi dhe lo bytes) dhe i konverton vlerat në një vlerë të vetme 16 bit. Kështu, ne mund të lexojmë çdo bosht të vetëm, ose mund të lexojmë dy prej tyre së bashku (dhe përmbledh ndryshimet), ose mund t'i lexojmë të tre (dhe përmbledh ndryshimet).

Për të përsëritur, për këtë fazë, për këtë Instructable, unë jam vetëm duke kërkuar t'i përgjigjem një pyetjeje të thjeshtë: "a rrotullohet/rrotullohet roboti?". Unë nuk jam duke kërkuar ndonjë vlerë të saktë, si p.sh., a rrotullohet 90 gradë. Kjo do të vijë më vonë kur të arrijmë të bëjmë SLAM, por nuk kërkohet për shmangien e thjeshtë të pengesave dhe lëvizjen e rastësishme.

Hapi 9: (punë në progres) Magnetometri

kur përdorni mjetin i2cdetect, MPU9265 shfaqet si 0x68 në 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: -- -- -- -- -- -- -- --

Kërkohen hapa shtesë për të lexuar nga pjesa magnetometër e IMU.

Nga regjistrat Invesense PDF PDF:

REGJISTRAT 37 deri 39 - KONTROLLI I2C SLAVE 0

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