Wallace - DIY autonomais robots - 5. daļa - pievienojiet IMU: 9 soļi

2024 Autors: John Day | [email protected]. Pēdējoreiz modificēts: 2024-01-30 10:57

Mēs turpinām kopā ar Volesu. Nosaukums Wallace nāca no "Wall-E" sajaukuma un no iepriekšējā projekta (balss atpazīšana), un, izmantojot lietderību "espeak", tas izklausījās mazliet britiski. Un kā sulainis vai sulainis. Un tas ir gala mērķis: lai šis projekts pārvērstos par kaut ko noderīgu. Tādējādi "Wallace".

Wallace var pārvietoties, viņš var izvairīties no šķēršļiem, izmantojot IR attāluma sensorus (nesen viņi kaut kā apcepušies (?)) laiku, kopā ar MCP23017 paplašinātāju) un, visbeidzot, var noteikt motora strāvas izmaiņas, lai uzzinātu, kad tas kaut ko sasit.

Papildus sensoriem Volless "atceras" 100 gājienus, un viņam ir kāda elementāra analīze, izmantojot kustību vēsturi.

Līdzšinējais Wallace mērķis ir tikai mēģināt turpināt virzīties uz priekšu un zināt, kad tas ir iestrēdzis kādā atkārtotā modelī (piemēram, stūrī) un patiesībā netiek uz priekšu.

Esmu izgājis vairākas kustības un navigācijas atkārtojumus, un nemainīgas galvassāpes ir bijušas rotācijas laikā.

Tā kā Volless ir izsekots robots, un es vēlējos programmatūrā padarīt lietas vienkāršākas (vēlākai lietošanai), lai pagrieztos, es vienkārši lieku viņam pagriezties/pagriezties. Tādējādi motoriem piemēro vienādu, bet pretēju jaudas / darba ciklu.

Problēma radusies robota platformas Agent 390 konstrukcijas dēļ. Sliežu siksnas mēdz berzēties pret sāniem. Un vēl ļaunāk - viena puse to dara vairāk nekā otra.

Grīdas seguma un taisnas braukšanas gadījumā tā nav bijusi problēma. Tas parādās uz paklāja. Es izvēlējos atturēt Wallace no paklāja pēc tam, kad tā dziesmas kļuva netīras (tās ļoti viegli uztver netīrumus).

Patiesā problēma ir, pagriežot grīdas segumu.

Ja man ir programmatūra, kas piemēro augsta līmeņa darba ciklu, tad tā vairāk vai mazāk konsekventi griežas. Tomēr zema darba cikla laikā tas faktiski var pagriezties vai ne. Vai arī tas var nedaudz pagriezties un pēc tam palēnināties. Šķiet, ka pagrieziena darbība ir nekontrolējama, izmantojot programmatūru, vai labākajā gadījumā ļoti sarežģīta.

Problēma parādās navigācijas laikā un pārvietojoties apkārt šķēršļiem vai prom no tiem. Tas var vai nu šūpot pārāk mežonīgi, vai arī iestrēgt, mēģinot veikt ļoti nelielas maiņas, pat nekustoties.

Un tāpēc iepriekš minētais skaidrojums motivēja šo Instructable.

Sākotnēji es gribēju atteikties no kustības uztveršanas ierīces (IMU) ieviešanas vai aizkavēt tās ieviešanu, jo tās ir A) sarežģītas, B) trokšņainas, C) laika gaitā var tikt pieļautas kļūdas utt., Utt. bija ļoti labi, ja mēs varētu pāriet uz lidojuma laika IR lāzera sensoriem. Un mēs varētu - izmantojot lāzerus, mēs varētu uzzināt, vai robots griežas vai ne, izsekojot attāluma izmaiņām.

Patiesībā mēs varētu (kaut kā) to darīt arī tagad, izmantojot akustiskos sensorus.

Tomēr tas viss ir ļoti netiešs, sarežģīts veids, kā atbildēt uz vienu vienkāršu jautājumu: "vai mēs esam rotējuši vai nē?"

Man šķita, ka lecot izmantot ToF lāzera sensorus, tiks sasniegts nākamais programmatūras līmenis; proti, SLAM (vienlaicīga lokalizācija un kartēšana). Es vēl nebiju gatavs tur doties.

Laba lieta ir veikt robota projektu slāņos, un pirmais (apakšējais) slānis ir vienkāršāks, bet pēdējais (augšējais) ir abstraktāks un risina sarežģītākas problēmas.

Slāņus var iedomāties šādi:

1. robota fiziskais rāmis / mehāniskais strukturālais pamats
2. elementāra piedziņas sistēma (Raspberry, Roboclaw, motori, kabeļi utt., pamata programmatūra, ar tastatūru darbināms)
3. būtiska shēma sensoru atbalstam (divvirzienu sprieguma pārslēdzējs, ostas paplašinātājs, E-Stop, strāvas sadale utt.)
4. šķēršļu novēršanas sensori (akustiskie, IR)
5. būtiska, pamata pozicionēšanas un kustības noteikšana (akselerometrs, žiroskops, magnetometrs, motora kodētāji, riteņu kodētāji)

Jūs varat izveidot savu sarakstu. Šajā sarakstā ir tas, ka jums, iespējams, tas būtu jādara vairāk vai mazāk šādā secībā, kā arī, ja jūs pavadāt kādu laiku pie katra slāņa, lai panāktu labu darba stāvokli, tam vajadzētu jums palīdzēt vēlāk, jo lietas kļūst sarežģītākas.

Iepriekš minēto sarakstu varētu vairāk vai mazāk saistīt ar šiem programmatūras konceptuālajiem slāņiem.

• SLAM (vienlaicīga lokalizācija un kartēšana)
• Kustību kontrole un apzināšanās, rotācija
• Pamata šķēršļu novēršana
• Sensora datu kontrole un noteikšana
• Būtiska kustība uz priekšu, atpakaļ, pa kreisi un pa labi, paātrināt, palēnināt, apstāties

Kā redzat, šajā sarakstā pirmie būtu augšējie, sarežģītākie slāņi, kas risina abstraktākus jautājumus un jautājumus, piemēram, "kur es esmu" un "kur es eju", bet pēdējie būtu apakšējie programmatūras slāņi, kas apstrādā "kā runāt/klausīties sensoru A" vai "kā pārvietot šo riteni".

Tagad es nesaku, ka, sākot ar slāni, jūs to būsit pabeidzis un tad tas būs nākamajā slānī, lai nekad neatgrieztos pie iepriekšējā. Robotu projekts var līdzināties modernām, atkārtotām programmatūras izstrādes metodēm (veikls, SCRUM utt.).

Es tikai saku, ka katram jāpiešķir laiks. Jums būs jāsabalansē, cik daudz jādara katrā, un jāizlemj, ko jūs mēģināt noteiktā slānī, kas ir laika un problēmu vērts.

Pastāv zināms "konflikts" vai "spriedze" starp divām konkurējošām idejām vai virzieniem.

Viens ir tas, ko es sauktu par “plug-n-play”, lai atrisinātu A problēmu.

Otrs ir DIY (dari pats). Un tas var nebūt pat labākais apzīmējums šai citai idejai.

Šeit ir piemērs katram, cerams, ka redzēsit spriedzi vai konfliktu starp abām izvēlēm.

Šajā piemērā SLAM, izvairīšanās no šķēršļiem un būtiska pamata kustība tiks apvienota kā viena problēma, kas jāatrisina vienlaikus.

1. Ja mēs nolemjam iet plug-n-play ceļu, mēs nekavējoties (atkarībā no budžeta) pārietam pie tādām lietām kā augšpusē uzstādītie rotējošie lāzeri, lauka dziļuma kamera vai ToF lāzeri un IMU (šīs tēmas tēma) Pamācāms).
2. No otras puses, ja mēs vēlamies iet otro ceļu, mēs varam mēģināt iegūt visu iespējamo informācijas daļu no dažiem akustiskiem sensoriem vai IR sensoriem, vai arī nekādu sensoru - mēs vienkārši izmantojam motora strāvas uzraudzību (trieciens)

Ko var teikt par #1 vs #2? Viena lieta būtu tāda, ka, darot otro, mēs būtu iemācījušies daudz vairāk. Ierobežojumi darbam ar tikai akustiskiem sensoriem liek mums domāt par daudz vairākām problēmām.

No otras puses, ja mēs pārāk koncentrējamies uz lietām, izmantojot 2. numuru, mēs, iespējams, tērējam laiku, jo no akustiskajiem sensoriem prasām vairāk nekā vajadzētu.

Vēl viens jēdziens vai ideja, par kuru padomāt: kāds aparatūras un programmatūras maisījums vislabāk atbild uz jautājumiem "kā", un kāds programmatūras (un aparatūras?) Maisījums atbild uz jautājumu "kas", "kad", "kur". Tā kā “kā” parasti ir zemāka līmeņa jautājums, uz kuru atbilde ir atkarīga no “kas”, “kad” un “kur”.

Jebkurā gadījumā viss iepriekš minētais bija tikai par ko padomāt.

Manā gadījumā, pēc lielām pūlēm un pastāvīga kaitinoša sliežu ceļa berzes problēma un nespēja iegūt konsekventu kontroli un kustību, ir pienācis laiks darīt kaut ko citu.

Tādējādi šis Instructable - IMU.

Mērķis ir - ja IMU saka, ka robots NAV griežas, mēs palielinām darba ciklu. Ja mēs pagriežamies pārāk ātri, mēs samazinām darba ciklu.

1. darbība: IMU sensors

Un tāpēc mūsu nākamais sensors, ko pievienot Wallace, ir IMU. Pēc dažiem pētījumiem es apmetos uz MPU6050. Bet tad šajā laikā MPU9050 (un vēl nesen MPU9250) šķita vēl labāka ideja.

Mans avots ir bijis Amazon (ASV). Tāpēc es pasūtīju divus no tiem.

Faktiski es saņēmu (šķiet, ka to nevar kontrolēt; tas ir tas, kas man nepatīk Amazon) - divi MPU92/65. Es mazliet brīnos par apzīmējumu. Apskatiet attēlus; šķiet, ka tas ir "ģimenes" apzīmējums. Jebkurā gadījumā tas ir tas, ar ko esmu iestrēdzis.

Pievienošana ir ļoti vienkārša -iegūstiet prototipu ar savienojošiem sliežu ceļiem, pielodējiet sensoru pie tāfeles, pievienojiet 10 kontaktu skrūvju spaiļu bloku (es to ieguvu no Pololu).

Lai samazinātu jebkādus traucējumus, es centos novietot šos sensorus prom no visa cita.

Tas nozīmēja arī dažu neilona skrūvju/uzgriežņu izmantošanu.

Es izmantošu I2C protokolu. Cerams, ka kopējais stieples garums nebūs pārāk slikts.

Citur ir daudz informācijas par pamata savienojumiem un sprieguma līmeņiem utt., Tāpēc es to šeit neatkārtošu.

2. solis: lietas ne vienmēr ir tīras, vienkāršas

Šajā rakstā šķiet, ka tiešsaistē nav daudz šī konkrētā MPU-92/65. Tas, kas ir pieejams, tāpat kā lielākajai daļai sensoru, šķiet, ir piemēri, izmantojot Arduino.

Es cenšos padarīt šīs instrukcijas nedaudz atšķirīgas, prezentējot ne tik tīru procesu, jo lietas ne vienmēr darbojas uzreiz.

Es domāju, ka šie norādījumi ir vairāk līdzīgi emuāram nekā taisni A-B-C, 1-2-3 "šādi jūs to darāt".

3. darbība: sākotnējā pārbaude

No attēliem iepriekšējā solī sarkanie un melnie vadi, kas iet uz sensoriem, protams, ir VCC (5V) un GND. Zaļie un dzeltenie vadi ir I2C savienojumi.

Ja esat veicis citus I2C projektus vai sekojis līdzi šīm sērijām, tad jūs jau zināt par “i2cdetect”, un tas ir pirmais solis, lai uzzinātu, vai Raspberry var redzēt jauno sensoru.

Kā redzams no šī soļa attēliem, mūsu pirmais mēģinājums bija neveiksmīgs. IMU neparādās (jābūt ierīces ID 0x68).

Tomēr labā ziņa ir tā, ka I2C autobuss darbojas. Mēs redzam vienu ierīci 0x20, un tas ir MCP23017 portu paplašinātājs (pašlaik atbildīgs par HCSR04 akustiskajiem sensoriem).

Attēlā to nav viegli saskatīt, bet es savienoju to pašu krāsaino zaļo un dzelteno vadu no IMU ar MCP23017 (sk. Apakšējo kreiso attēlu)

Mums būs jāveic dažas problēmu novēršanas darbības.

4. darbība. Problēmu novēršana

Izmantojot voltmetra nepārtrauktības iestatījumu (tas, kuram ir augsts tonis), es pārbaudīju VCC (5V), GND, SDA un SCL savienojumus. Tie bija labi.

Nākamais mēģinājums bija atvienot MCP23017 no I2C kopnes, autobusā atstājot tikai MPU-92/65. Tas izrādījās neauglīgi - "i2cdetect" pēc tam neuzrādīja ierīces.

Tātad, pēc tam es atvienoju sensoru no totēma pola un atkal pievienoju to tieši pie 5V līdz 3V divvirzienu kopnes; i., tieši uz Aveņu. (īsāki vadi?).

Un voila. Šoreiz ir panākumi. Mēs redzam, ka 0x68 tiek parādīts, izmantojot "i2cdetect".

Bet mēs vēl nezinām, kāpēc šoreiz tas izdevās. Vai tas varētu būt vadu garums? Iepriekšējā atrašanās vieta?

Piezīme. Nav nekādas atšķirības, vai ADO bija pamatots vai nē. Iespējams, ka ir iebūvēti pullup un nolaižami rezistori. Tas pats varētu attiekties uz FSYNC.

Pēc tam es atkārtoti pievienoju MCP23017. Tātad tagad mums ir divas ierīces I2C kopnē. (skat. attēlu). Veiksmīgi, tagad mēs redzam gan 0x20, gan 0x68 ar i2cdetect.

Videoklipos sīkāk aprakstīts, kas notika problēmu novēršanas laikā.

5. darbība: sensora datu nolasīšana

Dažādas pieejas

Es nolēmu izmantot vairākas pieejas, lai no sensora iegūtu noderīgu informāciju. Šeit tie ir, nevis kādā secībā:

1. izmēģiniet pamata programmēšanu
2. apskatiet reģistru tiešsaistes dokumentāciju
3. apskatiet citu piemērus un / vai kodu

Kāpēc šīs pieejas? Kāpēc ne tikai meklēt kādu esošu bibliotēku vai kodu?

Eksperimentējot un izmēģinot dažas idejas, mēs varam labāk apgūt zināšanas par ne tikai šo konkrēto sensoru, bet arī iegūt kādu tehniku, prasmes un domāšanas veidus, kā risināt kaut ko jaunu, un kaut ko, kam, iespējams, nav daudz dokumentācijas; kaut kas tāds, kam var būt daudz nezināmā.

Turklāt, kad esam izspēlējuši un izmēģinājuši dažas savas idejas un guvuši zināmu ieskatu, mēs varam labāk novērtēt kāda cita kodu vai bibliotēku.

Piemēram, pēc github MPU9250 C ++ koda izpētīšanas es sapratu, ka tas liek man izmantot pārtraukumus, ko es vēl nevēlos darīt.

Turklāt tam ir papildu lietas, piemēram, kalibrēšana; atkal kaut kas mani vēl neinteresē.

Var gadīties, ka tas, kas man jādara, lai atbildētu uz vienkāršo jautājumu "vai robots rotē jā vai nē", varētu atbildēt ļoti vienkārši, vienkārši izlasot dažus reģistrus.

Reģistri

Šajā rakstā šķiet, ka šim sensoram nav daudz pieejams. Patiesībā, ja paskatās uz attēliem, kas pievienoti šai instrukcijai, un rūpīgi aplūko faktisko mikroshēmu uzrakstus, man liek aizdomāties, vai tas nav sitiens. Es nesaistu redzēto ar neko no Invense. Neatkarīgi no tā es izvēlējos aplūkot atrasto modeļu reģistra informāciju: MPU-6050 un MPU-9250.

Abos gadījumos tālāk minētais abiem ir vienāds. Un iesācējiem mēs pieņemam, ka tas būs tāds pats arī šim MPU-92/65.

59 līdz 64 - akselerometra mērījumi

65, 66 - temperatūras mērījumi no 67 līdz 72 - žiroskopa mērījumi no 73 līdz 96 - ārējo sensoru dati

Piezīme: šķiet, ka MPU-6050 NAV magnetometra, bet MPU-9250 (un mēs pieņemam, ka arī šis) ir.

Vēl kāda interesanta, cerams, noderīga informācija, kas iegūta no reģistra dokumenta:

Informācija par magnetometru:

magnetometra id: 0x48 reģistrē 00 līdz 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 -metil HY7 HY6 HY5 HY4 HY3 HY2 HY1 HY0 06H HYH HY15 HY14 HY13 HY12 HY11 HY10 HY9 HY8 07H HZL HZ7 HZ6 HZ5 HZ4 HZ3 HZ2 HZ1 HZ0 08h HZH HZ15 HZ14 HZ13 HZ12 HZ11 HZ10 HZ9 HZ8 09H ST2 0 0 0 BITM HOFL 0 0 0 katra reģistra nozīmes sadalījums: HXL [7: 0]: X ass mērījumu dati zemāki 8 biti HXH [15: 8]: X ass mērījumu dati augstāki 8 bitu HYL [7: 0]: Y ass mērījumu dati zemāki 8 bitu HYH [15: 8]: Y ass mērījumu dati augstāki 8 bitu HZL [7: 0]: Z ass mērījumu dati zemāki 8 bitu HZH [15: 8]: Z ass mērījumu dati augstāki 8 bitu

Programmēšana

Vēl viena informācija no reģistra dokumentiem ir tāda, ka šķita, ka ir tikai aptuveni 100 reģistru. Tātad viena taktika varētu būt vienkāršas programmas uzrakstīšana, kas piekļūst ierīcei (0x68) un mēģina secīgi lasīt reģistru sēriju, neņemot vērā to nozīmi, tikai lai redzētu, kādus datus var redzēt.

Un pēc tam veiciet secīgas piespēles, izmantojot to pašu kodu, un salīdziniet datus no vienas caurlaides pret nākamo.

Ideja ir tāda, ka mēs, iespējams, varētu likvidēt visus reģistrus, kuros, šķiet, nav datu (nulles vai FF?) Vai kas absolūti nekad nemainās, un mēs varētu arī koncentrēties uz tiem, kas mainās.

Pēc tam mēs skatāmies tikai tos, kas mainās, pievienojiet vidējo funkciju, kas nosaka šī reģistra jaunākos N lasījumus, lai noskaidrotu, vai šim reģistram patiesībā ir noteikta stabila vērtība. Tas pieņemtu, ka mēs noturam sensoru ļoti nekustīgi un tajā pašā vietā.

Visbeidzot, pēc tam mēs varētu viegli izmēģināt lietas, izmantojot sensoru, piemēram, pabīdīt to (akselerometrs, žiroskops), pūst uz to (temperatūra) vai pagriezt (iepriekšējie divi plus magnetometrs) un redzēt, kā tas ietekmē vērtības.

Man patīk pēc iespējas izmantot bibliotēku wiringPi. Tam ir atbalsts I2C.

Pirmais skrējiens:

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

* veidot: gcc first.test.mpu9265.c -o first.test.mpu9265 -lwiringPi * * palaist: sudo./first.test.mpu9265 * * šī programma tikai izvada virkni (iespējamu) reģistru no MCP23017, * un pēc tam no MPU9265 (vai jebkura cita MPU šajā 0x68 adresē) * * Es to izmantoju, lai pārbaudītu, vai es pat spēju lasīt no sensora, jo man jau bija * uzticība MCP23017. ************************************************* ****************************/ #include #include #include #include #include int main (int argc, char ** argv) {Put ("Redzēsim, kas sakāms MCP23017 @ 0x20:"); kļūda = 0; int deviceId1 = 0x20; int fd1 = wiringPiI2CSetup (deviceId1); if (-1 == fd1) {fprintf (stderr, "Nevar atvērt wiringPi I2C ierīci: %s / n", strerror (kļūda)); atgriešanās 1; } for (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d", wiringPiI2CReadReg8 (fd1, reg)); fflush (stderr); kavēšanās (10); } liek (""); liek ("Paskatīsimies, kas sakāms MPU9265 @ 0x20:"); kļūda = 0; int deviceId2 = 0x68; int fd2 = wiringPiI2CSetup (deviceId2); if (-1 == fd2) {fprintf (stderr, "Nevar atvērt wiringPi I2C ierīci: %s / n", strerror (kļūda)); atgriešanās 1; } for (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d", wiringPiI2CReadReg8 (fd2, reg)); fflush (stderr); kavēšanās (10); } liek (""); atgriezties 0; }

Otrais brauciens:

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

* veidot: gcc second.test.mpu9265.c -o second.test.mpu9265 -lwiringPi * * palaist: sudo./second.test.mpu9265 * * Šī programma izvada reģistra numuru līdzās nolasītajai vērtībai. * * Tādējādi ir lietderīgi caurvadīt (novirzīt) izvadi uz failu, un pēc tam * var veikt vairākas darbības, lai salīdzinātu. Tas varētu sniegt ieskatu *, kāds reģistrs ir svarīgs un kā dati varētu rīkoties. ************************************************* ****************************/ #include #include #include #include #include #include int main (int argc, char ** argv) {int deviceId = -1; ja (0) {} cits ja (! strncmp (argv [1], "0x20", strlen ("0x20"))) {deviceId = 0x20; } cits if (! strncmp (argv [1], "0x68", strlen ("0x68"))) {deviceId = 0x68; } cits if (! strncmp (argv [1], "0x69", strlen ("0x69"))) {deviceId = 0x69; } liek ("Paskatīsimies, kas sakāms MPU9265 @ 0x20:"); kļūda = 0; int fd = wiringPiI2CSetup (deviceId); if (-1 == fd) {fprintf (stderr, "Nevar atvērt wiringPi I2C ierīci: %s / n", strerror (kļūda)); atgriešanās 1; } for (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); kavēšanās (10); } atgriezties 0; }

Trešais brauciens:

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

* veidot: gcc third.test.mpu9265.c -o third.test.mpu9265 -lwiringPi * * palaist: sudo./third.test.mpu9265 * * Šī programma ir otrā rezultāta rezultāts. Tas tiek lasīts tikai no * reģistriem, kas norādīja atšķirību starp vienu un nākamo palaišanu.************************************************* ****************************/ #include #include #include #include #include #include int main (int argc, char ** argv) {int deviceId = -1; ja (0) {} cits ja (! strncmp (argv [1], "0x68", strlen ("0x68"))) {deviceId = 0x68; } cits if (! strncmp (argv [1], "0x69", strlen ("0x69"))) {deviceId = 0x69; } liek ("Paskatīsimies, kas sakāms MPU9265 @ 0x20:"); kļūda = 0; int fd = wiringPiI2CSetup (deviceId); if (-1 == fd) {fprintf (stderr, "Nevar atvērt wiringPi I2C ierīci: %s / n", strerror (kļūda)); atgriešanās 1; } for (int reg = 61; reg <= 73; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); kavēšanās (10); } for (int reg = 111; reg <= 112; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); kavēšanās (10); } for (int reg = 189; reg <= 201; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); kavēšanās (10); } for (int reg = 239; reg <= 240; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); kavēšanās (10); } atgriezties 0; }

Tātad, ko mēs līdz šim esam iemācījušies? Tabulas attēls ar krāsainiem izceltiem apgabaliem norāda, ka izlaide, šķiet, atbilst pirmajiem reģistru komplektiem.

Līdzšinējie rezultāti var radīt jaunus jautājumus.

Jautājums: kāpēc "ārējai" grupai ir tikai viens reģistra rezultāts?

Jautājums: kas ir visi šie nezināmie reģistri "??????"

Jautājums: tā kā programma netiek pārtraukta, vai tā pieprasīja datus pārāk lēni? pārāk ātri?

Jautājums: vai mēs varam ietekmēt rezultātus, izmēģinot lietas ar pašu sensoru, kad tas darbojas?

6. solis: izpētīsim vairāk lasījumos / datos

Es domāju, ka nākamais solis pirms visa cita ir uzlabot programmu, lai:

• būt elastīgam cikla aizkaves laikā (ms)
• jābūt elastīgam attiecībā uz rādījumu skaitu, lai sniegtu vidējo rādītāju vienam reģistram

(Man bija jāpievieno programma kā fails. Šķita, ka problēma, ievietojot to šeit. "4th.test.mpu9265.c")

Lūk, skrējiens, izmantojot 10 pēdējos rādījumus vidēji 10 ms cilpā:

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

Pirmā, kreisākā sleja ir reģistra numurs. Tad nāk pēdējie 10 šī reģistra rādījumi. Visbeidzot, pēdējā sleja ir katras rindas vidējais rādītājs.

Izskatās, ka 61., 69., 71., 189., 197. un 199. reģistrs ir vai nu tikai binārs, vai gatavs / nav gatavs, vai arī tie ir 16 bitu lielie baiti (negatīvi?).

Citi interesanti novērojumi:

• reģistri 65, 193 - ļoti stabila un tāda pati vērtība
• reģistrs 63, 191 - ļoti stabila un tāda pati vērtība
• reģistri 73, 112, 195, 201, 240 - visi uz nulles

Saistīsim šos novērojumus ar daudzkrāsainu, izceltu galda attēlu no iepriekšējā.

Reģistrs 65 - temperatūra

Reģistrēties 193 - ??????

Reģistrs 63 - akselerometrs

Reģistrēties 191 - ??????

Reģistrs 73 - ārējs

Reģistrējieties 112 un tālāk - ??????

Nu, mums joprojām ir nezināmie, tomēr esam iemācījušies kaut ko noderīgu.

65. reģistrs (temperatūra) un 63. reģistrs (akselerometrs) bija ļoti stabili. Tas ir kaut kas, ko mēs varētu sagaidīt. Es neesmu pieskāries sensoram; tas nekustas, izņemot nejaušas vibrācijas, jo robots atrodas uz viena galda ar manu datoru.

Katram no šiem temperatūras/akselerometra reģistriem ir viens interesants tests. Šim testam mums ir nepieciešama vēl viena programmas versija.

7. solis: mēs varam ietekmēt temperatūru un paātrinājumu

Iepriekšējos soļos mēs sašaurinājām vismaz vienu temperatūras reģistru un vienu paātrinājumu.

Izmantojot šo nākamo programmas versiju ("4th.test.mpu9265.c"), mēs faktiski varam redzēt izmaiņas abos reģistros. Lūdzu, skatieties videoklipus.

Vairāk rakšanas

Ja mēs atgriezīsimies un apskatīsim reģistra informāciju, mēs redzēsim, ka ir:

• trīs 16 bitu izejas žiroskopam
• trīs 16 bitu izejas akselerometram
• trīs 16 bitu izejas magnetometram
• viena 16 bitu izeja temperatūrai

Tomēr mūsu vienkāršajās testēšanas programmās iegūtie rezultāti bija tikai 8 bitu izejas. (atsevišķi reģistri).

Tāpēc mēģināsim vairāk izmantot to pašu pieeju, taču šoreiz lasām 16 bitus, nevis 8.

Mums, iespējams, būs jādara kaut kas līdzīgs zemāk redzamajam. Kā piemēru izmantosim temperatūru, jo tā ir tikai viena 16 bitu izeja.

// iegūt faila aprakstu fd …

int tempRegHi = 65; int tempRegLo = 66; int hiByte = wiringPiI2CReadReg8 (fd, tempRegHi); int loByte = wiringPiI2CReadReg8 (fd, tempRegLo); int rezultāts = hiByte << 8; // ievietojiet hi bitt 8 bitus 16 bitu vērtības augšējā daļā | = loByte; // tagad pievienojiet secībā 8 bitus, iegūstot pilnu 16 bitu skaitli // izdrukājiet šo numuru vai izmantojiet displeja horizontālās grafikas funkciju no iepriekšējās

No iepriekšējiem soļiem mēs redzējām, ka reģistrs 65 ir diezgan stabils, bet 66 reģistrs ir ļoti trokšņains. Tā kā 65 ir augstākās kārtas baiti un 66 zemās kārtas baiti, tam ir jēga.

Lasīšanai mēs varam pieņemt reģistra 65 datus tādus, kādi tie ir, bet mēs varētu vidēji reģistrēt 66 reģistra vērtības.

Vai arī mēs varam vienkārši novērtēt visu rezultātu.

Apskatiet šīs daļas pēdējo videoklipu; tas parāda visas 16 bitu temperatūras vērtības nolasīšanu. Kods ir "sixth.test.mpu9265.c"

8. solis: akselerometrs un žiroskops

Šīs sadaļas videoklipos ir redzama izeja no akselerometra un žiroskopa, izmantojot testa programmu "sevenh.test.mpu9265.c". Šis kods var nolasīt 1, 2 vai 3 secīgus baitu pārus (hi un lo baiti) un pārveido vērtības par vienu 16 bitu vērtību. Tādējādi mēs varam nolasīt jebkuru atsevišķu asi vai divas no tām kopā (un tas apkopo izmaiņas), vai arī varam nolasīt visas trīs (un tas apkopo izmaiņas).

Atkārtojot, šajā posmā, šajā instrukcijā es tikai meklēju atbildi uz vienkāršu jautājumu: "vai robots pagriezās/pagriezās?". Es nemeklēju precīzu vērtību, piemēram, vai tas pagriezās par 90 grādiem. Tas notiks vēlāk, kad mēs sāksim nodarboties ar SLAM, taču tas nav nepieciešams, lai vienkārši izvairītos no šķēršļiem un nejauši kustētos.

9. darbība. (Notiek darbs) Magnetometrs

lietojot rīku i2cdetect, tabulā MPU9265 tiek parādīts kā 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: -- -- -- -- -- -- -- --

Ir jāveic papildu darbības, lai lasītu no IMU magnetometra daļas.

No Invesense reģistru PDF dokumenta:

REĢISTRI 37. līdz 39. - I2C SLAVE 0 CONTROL

• 37. REĢISTRS - I2C_SLV0_ADDR
• 38. REĢISTRĀCIJA - I2C_SLV0_REG
• 39. REĢISTRĀCIJA - I2C_SLV0_CTRL