Wallace - Robot autònom de bricolatge - Part 5 - Afegir IMU: 9 passos

2024 Autora: John Day | [email protected]. Última modificació: 2024-01-30 08:15

Seguim amb Wallace. El nom de Wallace provenia d'una barreja de "Wall-E" i d'un projecte anterior (reconeixement de veu) i, en utilitzar la utilitat "espeak", semblava una mica britànic. I com un valet o majordom. I aquest és l'objectiu final: que aquest projecte es converteixi en quelcom útil. Així, "Wallace".

Wallace es pot moure, pot evitar obstacles fent servir sensors de distància IR (recentment, d’alguna manera es van fregir (?) (Han de mirar-ho quan tinc oportunitat), també té alguns sensors de distància acústics (tres d’aquests van anar malament al mateix temps) temps, juntament amb un expansor MCP23017) i, finalment, poden detectar canvis en el corrent del motor per saber quan es troba amb alguna cosa.

A més dels sensors, Wallace "recorda" els 100 moviments i té algunes anàlisis rudimentàries mitjançant la història del moviment.

L’objectiu fins ara de Wallace és simplement intentar seguir avançant i saber quan s’enganxa en algun patró que es repeteix (com en un racó) i no avançar realment.

He passat diverses iteracions pel moviment i la navegació, i el mal de cap constant ha estat durant la rotació.

Com que Wallace és un robot rastrejat, i volia mantenir les coses més senzilles al programari (per a més endavant), per girar-lo, només el tinc girat / girat al seu lloc. Per tant, apliqueu un cicle de potència / servei igual però oposat als motors.

El problema trobat es deu al disseny de la plataforma robot Agent 390. Les corretges de les vies tendeixen a fregar-se contra els laterals. I el que és pitjor, un bàndol ho fa més que l’altre.

A terra i anar recte, no ha estat un problema. Apareix a la catifa. Vaig triar mantenir Wallace fora de les catifes després que les seves pistes quedessin malhumorades (agafen la brutícia extremadament fàcil).

El problema real és quan es gira sobre el terra.

Si el programari aplica un cicle de treball d’alt nivell, aleshores gira més o menys constantment. No obstant això, durant un cicle de treball baix, pot girar o no. O pot girar una mica i després disminuir la velocitat. L'acció pivotant sembla incontrolable a través del programari o, en el millor dels casos, molt difícil.

El problema apareix durant la navegació i desplaçant-se o allunyant-se dels obstacles. Es pot moure de manera massa salvatge o es pot quedar atrapat en intentar fer canvis molt mínims, sense ni tan sols moure’s.

Per tant, l'explicació anterior va motivar aquest instructiu.

Inicialment, havia volgut prescindir o retardar la introducció d’una unitat de detecció de moviment (IMU), perquè són A) complicats, B) sorollosos, C) es poden introduir errors amb el pas del temps, etc., etc. En aquest sentit, podríem fer-ho molt bé saltant cap als làsers IR de temps de vol. I podríem, mitjançant làsers, saber si el robot girava o no, seguint els canvis de distància.

De fet, també ho podríem fer (una mena de) ara, amb els sensors acústics.

Tot i això, tot això és una manera molt indirecta i complicada de respondre a una pregunta senzilla: "hem rotat o no?"

Em va semblar que saltar per utilitzar els sensors làser ToF em portaria al següent nivell de programari; és a dir, SLAM (Localització i mapatge simultanis). Encara no estava preparat per anar-hi.

És bo fer un projecte de robot per capes, amb les primeres capes (inferiors) més senzilles i les darreres capes (superiors) més abstractes i abordant qüestions més difícils.

Es poden pensar capes en alguna cosa així:

1. marc físic del robot / base estructural mecànica
2. sistema d’accionament rudimentari (Raspberry, Roboclaw, motors, cablejat, etc., programari bàsic, basat en teclat)
3. circuits imprescindibles per suportar sensors (commutador de tensió bidireccional, expansor de ports, E-Stop, distribució d'energia, etc.)
4. sensors d'evitació d'obstacles (acústics, IR)
5. posicionament bàsic i detecció de moviments bàsics (acceleròmetre, giroscopi, magnetòmetre, codificadors de motors, codificadors de rodes)

Podeu elaborar la vostra pròpia llista. Els punts d’aquesta llista són que probablement els haureu de fer més o menys en aquest ordre i, també, que si passeu un temps a cada capa per aconseguir que cadascun tingui un bon estat de treball, això us ajudarà més endavant a mesura que les coses es compliquin.

La llista anterior es podria assignar més o menys a aquestes capes conceptuals del programari.

• SLAM (Localització i mapatge simultanis)
• Control i consciència del moviment, rotació
• Evitació d'obstacles bàsics
• Control i detecció de dades del sensor
• Moviment essencial cap endavant, cap enrere, cap a l'esquerra i cap a la dreta, accelerar, reduir la velocitat, aturar-se

Com podeu veure, per a aquesta llista, els primers ítems serien les capes superiors i més complicades que aborden qüestions i qüestions més abstractes, com ara "on estic" i "cap a on vaig", mentre que els últims ítems serien el capes de programari inferiors que gestionen el "com parlar / escoltar el sensor A" o "com moure aquesta roda".

Ara, no estic dient que quan comenceu per una capa, l’haureu completat i després estigui a la capa següent, per no tornar mai a l’anterior. Un projecte de robot pot semblar-se a mètodes moderns i iteratius de desenvolupament de programari (àgil, SCRUM, etc.).

Només dic que prengueu temps a cadascun. Haureu d’equilibrar el que heu de fer a cadascun i decidir el que intenteu amb una capa determinada que val la pena.

Hi ha un cert "conflicte" o "tensió" entre dues idees o direccions en competència.

Un és el que anomenaria "plug-n-play" per resoldre el problema A.

L’altre és el bricolatge (fes-ho tu mateix). I pot ser que ni tan sols sigui la millor etiqueta per a aquesta altra idea.

Aquí teniu un exemple de cadascun d’ells, amb sort, veureu la tensió o el conflicte entre les dues opcions.

Per a aquest exemple, agafem SLAM, evitació d'obstacles i moviments bàsics essencials, tot com un sol problema a resoldre al mateix temps.

1. Si decidim seguir la ruta plug-n-play, saltem immediatament (depenent del pressupost) a coses com els làsers rotatius muntats a la part superior, o la càmera de profunditat de camp o els làsers ToF, i l’IMU (tema d’aquest Instructible).
2. Si, en canvi, volem seguir la segona ruta, podem intentar extreure tota la informació possible d’alguns sensors acústics o sensors d’IR, o sense cap sensor, només fem servir la supervisió del corrent del motor (bump)

Què es pot dir sobre el número 1 contra el número 2? Una cosa seria que haurem après molt més fent el # 2. Les limitacions de tenir només sensors acústics per treballar, ens obliguen a pensar en molts més problemes.

D’altra banda, si estem massa centrats en fer les coses mitjançant el número 2, potser estem perdent el temps, perquè demanem més del que hauríem als sensors acústics.

Un concepte o idea més a pensar: quina mescla de maquinari i programari respon millor a les preguntes de "com" i quina mescla de programari (i maquinari?) Respon a la pregunta de "què", "quan", "on". Perquè "com" sol ser una pregunta de nivell inferior de quina "quina", "quan" i "on" depenen per obtenir una resposta.

De totes maneres, tot l’anterior era només una cosa a pensar.

En el meu cas, després de molts esforços i de tenir el problema molest i consistent de la fricció de la pista i de no aconseguir un control i un moviment consistents, és hora de fer una altra cosa.

Per tant, aquest instructiu - una IMU.

L’objectiu és que si l’IMU diu que el robot NO pivota, augmentem el cicle de treball. Si pivotem massa ràpidament, disminuirem el cicle de treball.

Pas 1: el sensor IMU

I, per tant, el nostre proper sensor a afegir a Wallace és l’IMU. Després d'algunes investigacions, em vaig decidir per un MPU6050. Però llavors, en aquest moment, el MPU9050 (i encara més recentment, el MPU9250) semblava una idea encara millor.

La meva font d’accés ha estat Amazon (als Estats Units). Així que en vaig demanar dos.

El que vaig obtenir de fet (sembla que no hi ha control sobre això; això és el que no m’agrada d’Amazon) eren dos MPU92 / 65. Em pregunto una mica sobre la designació. Mireu les imatges; sembla que és una designació "familiar". En qualsevol cas, amb això em quedo.

Afegir-lo és molt senzill: obtenir una placa proto amb pistes de connexió, soldar el sensor a la placa, afegir un bloc de terminals de cargol de 10 pins (tinc el meu de Pololu).

Per tal de minimitzar qualsevol interferència, vaig intentar situar aquests sensors lluny de qualsevol altra cosa.

Això també significava utilitzar alguns perns / femelles de niló.

Utilitzaré el protocol I2C. Esperem que la longitud total del cable no sigui massa dolenta.

Hi ha molta informació en altres llocs sobre les connexions bàsiques i els nivells de tensió, etc., així que no ho repetiré aquí.

Pas 2: les coses no sempre són netes, fàcils

En aquest escrit, no sembla que hi hagi molt en línia per a aquest MPU-92/65. El que hi ha disponible, igual que amb la majoria de sensors, sembla que són exemples amb Arduino.

Intento fer que aquests Instructables siguin una mica diferents presentant un procés no tan net, perquè les coses no sempre funcionen de seguida.

Suposo que aquests Instructables són més similars a un bloc que els rectes A-B-C, 1-2-3 "així ho fas".

Pas 3: prova inicial

A partir de les imatges del pas anterior, els cables vermells i negres que van als sensors són, per descomptat, VCC (5V) i GND. Els cables verds i grocs són les connexions I2C.

Si heu fet altres projectes I2C o heu seguit aquestes sèries, ja coneixeu "i2cdetect" i aquest és el primer pas per saber si el gerd pot veure el nou sensor.

Com podeu veure a les imatges d’aquest pas, el nostre primer intent no va tenir èxit. La IMU no apareix (ha de ser l'identificador del dispositiu 0x68).

Tot i això, la bona notícia és que el bus I2C funciona. Veiem un dispositiu 0x20 i és l’expansor de ports MCP23017 (actualment responsable dels sensors acústics HCSR04).

No és fàcil de veure a la imatge, però sí que he connectat els cables de color verd i groc del mateix color de l’IMU al MCP23017 (vegeu la part inferior esquerra de la imatge)

Haurem de solucionar problemes.

Pas 4: resolució de problemes

Utilitzant la configuració de continuïtat d’un voltímetre (el que té el to agut), he provat les connexions VCC (5V), GND, SDA i SCL. Eren bons.

El següent intent va ser desconnectar l'MCP23017 del bus I2C, deixant només el MPU-92/65 al bus. Això va resultar infructuós: "i2cdetect" no mostrava cap dispositiu.

Aleshores, vaig desmuntar el sensor del tòtem i el vaig tornar a connectar directament al bus bidireccional de 5V a 3V; és a dir, directament al gerd. (cables més curts?).

I voilà. Aquesta vegada hi ha èxit. Veiem que apareix 0x68 amb "i2cdetect".

Però encara no sabem per què va funcionar aquesta vegada. Podria ser la longitud dels cables? La ubicació anterior?

Nota: No va fer cap diferència si ADO estava connectat a terra o no. Podria ser que hi hagi resistències pull-down i pull-down incorporades. El mateix podria passar per FSYNC.

A continuació, he tornat a connectar l'MCP23017. Ara tenim dos dispositius al bus I2C. (veure imatge). Amb èxit, ara veiem 0x20 i 0x68 amb i2cdetect.

Els vídeos expliquen una mica més el que va passar durant la resolució de problemes.

Pas 5: llegir les dades del sensor

Diverses aproximacions

Vaig decidir adoptar diverses aproximacions per obtenir informació útil del sensor. Aquí els teniu, no en cap ordre:

1. proveu una programació bàsica
2. consulteu documentació en línia sobre registres
3. mireu els exemples i / o el codi d'altres persones

Per què aquests plantejaments? Per què no només cal buscar alguna biblioteca o codi existent?

Experimentant i provant algunes idees, podem absorbir millor alguns coneixements sobre aquest sensor en particular, sinó també obtenir una mica de tècnica, habilitat i maneres de pensar sobre com afrontar alguna cosa nova i alguna cosa que potser no té molta documentació; cosa que pot tenir moltes incògnites.

A més, un cop hem jugat i provat algunes de les nostres pròpies idees i hem obtingut alguns coneixements, estem en millor posició per avaluar el codi o la biblioteca d'una altra persona.

Per exemple, després de mirar algun codi C ++ del MPU9250 a github, em vaig adonar que m’obligava a utilitzar interrupcions, cosa que encara no vull fer.

A més, inclou coses addicionals com el calibratge; de nou, una cosa que encara no m'interessa.

Pot ser que el que hagi de fer per respondre a la simple pregunta "és que el robot gira sí o no" es pugui respondre molt simplement amb la lectura d'alguns registres.

Registres

En aquest moment, sembla que no hi ha molt disponible en aquest sensor. De fet, si mireu les imatges que s’inclouen amb aquest instructable i mireu de prop les inscripcions dels xips reals, em faig preguntar-me si això no és un knock-off. No relaciono el que veig amb res d’Invense. Independentment, vaig optar per mirar la informació del registre dels models que vaig trobar: la MPU-6050 i la MPU-9250.

En ambdós casos, el següent és el mateix per a tots dos. I, per començar, suposem que també serà el mateix per a aquest MPU-92/65.

59 a 64: mesures de l’acceleròmetre

65, 66 - mesures de temperatura 67 a 72 - mesures de giroscopi 73 a 96 - dades de sensor extern

Un element a destacar: el MPU-6050 sembla que NO té magnetòmetre, mentre que el MPU-9250 (i suposem que aquest també) en té.

Alguna informació més interessant, que espero que sigui útil, extreta del registre-document:

Informació del magnetòmetre:

identificador de magnetòmetre: 0x48 registra de 00 a 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 HYZ HZZ HZZ HZZ HZZ HZZ HZZ HZZ HZZ HZZ HZZ HZZ HZZZ ST2 0 0 0 BITM HOFL 0 0 0 un desglossament del que significa cada registre: HXL [7: 0]: dades de mesura de l'eix X inferior 8 bits HXH [15: 8]: dades de mesura de l'eix X majors 8 bits HYL [7: 0]: Dades de mesura de l'eix Y inferior 8bit HYH [15: 8]: dades de mesura de l'eix Y superior 8bit HZL [7: 0]: dades de mesura de l'eix Z inferior 8bit HZH [15: 8]: dades de mesura de l'eix Z més altes 8 bits

Programació

Una altra informació de la documentació del registre és que semblava que només hi havia aproximadament uns 100 registres. Per tant, una tàctica podria ser escriure un programa senzill que accedeixi al dispositiu (0x68) i intenti llegir una sèrie de registres de manera seqüencial, sense tenir en compte el seu significat, només per veure quines dades es poden veure.

I, a continuació, feu passades successives, utilitzant el mateix codi, i compareu les dades d'una passada contra la següent.

La idea és que probablement podríem eliminar els registres que semblen no tenir dades (zeros o FF?) O que mai canvien mai, i també ens podríem centrar en els que sí que canvien.

A continuació, un que estem examinant només els que canvien, afegiu una funció de mitjana que fa la mitjana de les últimes N lectures d’aquest registre, per veure si hi ha de fet un cert valor constant per a aquest registre. Això suposaria que mantenim el sensor molt quiet i en la mateixa ubicació.

Finalment, podríem provar suaument coses amb el sensor, com ara empènyer-lo (acceleròmetre, giroscopi) o bufar-hi (temperatura) o girar-lo (els dos anteriors més el magnetòmetre) i veure quin efecte té sobre els valors.

M'agrada fer servir la biblioteca wiringPi tant com sigui possible. Té suport per a I2C.

Primera tirada:

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

* per construir: gcc first.test.mpu9265.c -o first.test.mpu9265 -lwiringPi * * per executar: sudo./first.test.mpu9265 * * aquest programa acaba de generar un interval de registres (possibles) des de l'MCP23017, * i després de la MPU9265 (o qualsevol altra MPU en aquesta adreça 0x68) * * La vaig fer servir per validar si fins i tot podia llegir des del sensor, ja que * ja tenia confiança en el MCP23017. * ************************************************** **************************** / #include #include #include #include #include int main (int argc, char ** argv) {put ("Vegem què ha de dir MCP23017 @ 0x20:"); errno = 0; int deviceId1 = 0x20; int fd1 = wiringPiI2CSetup (deviceId1); if (-1 == fd1) {fprintf (stderr, "No es pot obrir el dispositiu WiringPi I2C:% s / n", strerror (errno)); retorn 1; } per a (int reg = 0; reg <300; reg ++) {fprintf (stderr, "% d", wiringPiI2CReadReg8 (fd1, reg)); fflush (stderr); retard (10); } posa (""); put ("Vegem què ha de dir MPU9265 @ 0x20:"); errno = 0; int deviceId2 = 0x68; int fd2 = wiringPiI2CSetup (deviceId2); if (-1 == fd2) {fprintf (stderr, "No es pot obrir el dispositiu WiringPi I2C:% s / n", strerror (errno)); retorn 1; } per a (int reg = 0; reg <300; reg ++) {fprintf (stderr, "% d", wiringPiI2CReadReg8 (fd2, reg)); fflush (stderr); retard (10); } posa (""); retorn 0; }

La segona tirada:

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

* per construir: gcc second.test.mpu9265.c -o second.test.mpu9265 -lwiringPi * * per executar: sudo./second.test.mpu9265 * * Aquest programa emet el número de registre al costat del valor llegit. * * Això fa que sigui útil dirigir (redirigir) la sortida a un fitxer i, a continuació, * es poden fer diverses proves per comparar-les. Podria donar una idea de * quin registre és important i com es poden comportar les dades. * ************************************************** **************************** / #include #include #include #include #include #include int main (int argc, char ** argv) {int deviceId = -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; } put ("Vegem què ha de dir MPU9265 @ 0x20:"); errno = 0; int fd = wiringPiI2CSetup (deviceId); if (-1 == fd) {fprintf (stderr, "No es pot obrir el dispositiu WiringPi I2C:% s / n", strerror (errno)); retorn 1; } per a (int reg = 0; reg <300; reg ++) {fprintf (stderr, "% d:% d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); retard (10); } retorn 0; }

La tercera tirada:

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

* construir: gcc third.test.mpu9265.c -o third.test.mpu9265 -lwiringPi * * per executar: sudo./third.test.mpu9265 * * Aquest programa és el resultat del segon. Només es llegeix dels registres * que indicaven una diferència entre una execució i la següent.* ************************************************** **************************** / #include #include #include #include #include #include int main (int argc, char ** argv) {int deviceId = -1; if (0) {} else if (! strncmp (argv [1], "0x68", strlen ("0x68"))) {deviceId = 0x68; } else if (! strncmp (argv [1], "0x69", strlen ("0x69"))) {deviceId = 0x69; } put ("Vegem què ha de dir MPU9265 @ 0x20:"); errno = 0; int fd = wiringPiI2CSetup (deviceId); if (-1 == fd) {fprintf (stderr, "No es pot obrir el dispositiu WiringPi I2C:% s / n", strerror (errno)); retorn 1; } per a (int reg = 61; reg <= 73; reg ++) {fprintf (stderr, "% d:% d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); retard (10); } per a (int reg = 111; reg <= 112; reg ++) {fprintf (stderr, "% d:% d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); retard (10); } per a (int reg = 189; reg <= 201; reg ++) {fprintf (stderr, "% d:% d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); retard (10); } for (int reg = 239; reg <= 240; reg ++) {fprintf (stderr, "% d:% d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); retard (10); } retorn 0; }

Què hem après fins ara? La imatge de la taula amb zones ressaltades de colors indica que la sortida sembla coincidir amb els primers conjunts de registres.

Els resultats fins ara poden generar noves preguntes.

Pregunta: per què només hi ha un resultat de registre per al grup "extern"?

Pregunta: quins són tots aquests registres desconeguts "??????"

Pregunta: com que el programa no està basat en interrupcions, ha sol·licitat dades massa lentament? massa ràpid?

Pregunta: podem afectar els resultats provant coses amb el mateix sensor mentre s’executa?

Pas 6: aprofundim més en les dades / lectures

Crec que el següent pas abans de qualsevol altra cosa és millorar el programa per:

• ser flexible quant a la demora del bucle (ms)
• sigueu flexibles quant a quantes lectures per obtenir una mitjana corrent per registre

(Vaig haver d'adjuntar el programa com a fitxer. Sembla ser un problema en inserir-lo aquí. "Quarter.test.mpu9265.c")

Aquí teniu una prova que utilitza les 10 darreres lectures per a una mitjana, en un bucle de 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

La primera columna més a l'esquerra és el número de registre. Després vindran les darreres 10 lectures d’aquest registre. Finalment, l’última columna és la mitjana de cada fila.

Sembla que els registres 61, 69, 71, 189, 197 i 199 només són binaris o estan preparats / no estan preparats, o bé són el byte alt d’un valor de 16 bits (negatiu?).

Altres observacions interessants:

• registres 65, 193: molt constant i amb el mateix valor
• registre 63, 191: molt constant i amb el mateix valor
• registres 73, 112, 195, 201, 240, tot a zero

Relacionem aquestes observacions amb la imatge de taula ressaltada i multicolor de l’anterior.

Registre de 65 - temperatura

Registre 193 - ??????

Registre 63 - acceleròmetre

Registre 191 - ??????

Registre 73 - extern

Registre 112 i posteriors - ??????

Bé, encara tenim incògnites, però hem après alguna cosa útil.

El registre 65 (temperatura) i el registre 63 (acceleròmetre) van ser molt estables. Això és una cosa que esperaríem. No he tocat el sensor; no es mou, a part de qualsevol vibració incidental, ja que el robot descansa sobre la mateixa taula que el meu ordinador.

Hi ha una prova interessant que podem fer per a cadascun d’aquests registres de temperatura / acceleròmetre. Per a aquesta prova, necessitem una altra versió del programa.

Pas 7: Som capaços d’afectar la temperatura i l’acceleració

En els passos anteriors vam reduir almenys un registre de temperatura i un d’acceleració.

Amb aquesta propera versió del programa ("5th.test.mpu9265.c"), podem veure que es produeix un canvi en ambdós registres. Mireu els vídeos.

Més excavació

Si tornem enrere i fem una ullada a la informació del registre, veurem que hi ha:

• tres sortides de 16 bits per giroscopi
• tres sortides de 16 bits per a l’acceleròmetre
• tres sortides de 16 bits per magnetòmetre
• una sortida de 16 bits per a la temperatura

Tanmateix, els resultats obtinguts pels nostres programes de prova senzills van ser totes sortides de 8 bits. (registres individuals).

Proveu, doncs, més del mateix enfocament, però aquesta vegada llegint 16 bits en lloc de 8.

Probablement haurem de fer alguna cosa com a continuació. Utilitzem la temperatura com a exemple, ja que només té una sortida de 16 bits.

// obtenir el descriptor de fitxer fd …

int tempRegHi = 65; int tempRegLo = 66; int hiByte = wiringPiI2CReadReg8 (fd, tempRegHi); int loByte = wiringPiI2CReadReg8 (fd, tempRegLo); int result = hiByte << 8; // posa l'ordre de 8 bits a la part superior d'un resultat de 16 bits | = loByte; // ara afegiu en l'ordre següent 8 bits, obtenint un número complet de 16 bits // imprimiu aquest número o utilitzeu la funció de gràfic horitzontal de visualització d'abans

Dels nostres passos anteriors hem vist que el registre 65 és força constant, mentre que el registre 66 és molt sorollós. Com que el 65 és el byte d’ordre alt i el 66 el byte d’ordre baix, això té sentit.

Per a la lectura, podem prendre les dades del registre dels 65 tal qual, però podríem promediar els valors del registre dels 66.

O simplement podem fer una mitjana del resultat sencer.

Mireu l’últim vídeo d’aquesta part; demostra llegir tot el valor de temperatura de 16 bits. El codi és "sisè.test.mpu9265.c"

Pas 8: l’acceleròmetre i el giroscopi

Els vídeos d’aquesta secció mostren la sortida de l’acceleròmetre i el giroscopi, mitjançant un programa de prova "seven.test.mpu9265.c". Aquest codi pot llegir 1, 2 o 3 parells de bytes consecutius (hi i lo bytes) i converteix els valors en un únic valor de 16 bits. Així, podem llegir qualsevol eix, o bé podem llegir-ne dos junts (i resumeix els canvis), o bé podem llegir els tres (i resumeix els canvis).

Per reiterar, per a aquesta fase, per a aquesta instrucció, només estic mirant de respondre a una pregunta senzilla: "el robot va girar / pivotar?". No busco cap valor precís, com ara, si va girar 90 graus. Això arribarà més tard quan comencem a fer SLAM, però no és necessari per a la simple evitació d'obstacles i el moviment aleatori.

Pas 9: (treball en curs) el magnetòmetre

en utilitzar l'eina i2cdetect, el MPU9265 apareix com a 0x68 a la taula:

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

Cal llegir passos addicionals des de la part del magnetòmetre de l’IMU.

Des del document PDF dels registres d'Invesense:

REGISTRES 37 A 39 - CONTROL ESCLAU I2C 0

• REGISTRE 37 - I2C_SLV0_ADDR
• REGISTREU 38 - I2C_SLV0_REG
• REGISTREU 39 - I2C_SLV0_CTRL