Ciao a tutti,
sto realizzando un sistema costituito da due sensori MPU-6050 (acc & gyro) in modo la rilevare gli spostamenti di due segmenti articolari.
Utilizzo il protocollo I2C e riesco a leggere un singolo sensore senza problemi. Nel momento in cui collego 2 sensori su di un BUS (SCL e SDA) comincio ad avere errori di FIFO-overflow e tutto ad un tratto (a random) la comunicazione si interrompe (il led TX si spegne).
I sensori hanno indirizzi diversi (uno 0x68 e l'altro 0x69).
Sto dietro a questo problema da un sacco di tempo e non riesco a trovarne una soluzione. Qualunque vostro consigli è ben accetto!
NOTE -- > In allegato: schema, script, MPU6050 datasheet e lo schematico del sensore
Su breadboard hai delle capacità parassite dovute alla vicinanza delle piste.. con I2C hai dei segnali a 100KHz e questo effetto inizia a sentirsi.. hai provato ad usare una breadboard più piccola?
Prova ad abbassare la resistenza di pull-up (prova ad es. 1 o 2k invece delle resistenze da 4.4k)
Ti lascio un buon link (purtroppo in inglese) I2C Primer – I2C Bus
Ciao
PS: Hai un oscilloscopio?
@Tonid: ho provato a cambiare le R con 2K2 e ho ottenuto un miglioramento, ovvero che adesso la trasmissione rimane attiva per 1-2min e poi si spegne. Prima durava molto meno. I FIFO-Overflow sembrano spariti.
@Flz47655: Grazie del link! purtroppo non ho una breadboard più piccola, però vorrei provare in questi giorni a saldare il tutto, perché mi sono accorto che comunque basta muovere un filo che la trasmissione si interrompe. Ma, al di là di questo fatto, la TX si ferma comunque anche quando il sistema rimane immobile sul tavolo senza nessun spostamento.
Dite che devo provare con delle R ancora più piccole di 2K2?... tra l'altro sullo schematic del sensore sono presenti 2 R pari a 10K in uscita da SCL e SDA.
Qualcuno a mai provato ad usare 2 sensori su di un unico bus I2C?
@cyclone: sul datasheet del sensore ho letto questo "400KHz Fast Mode I2C for communicating with all registers"... se fosse questo il problema, come faccio a variare questo valore? e a quanto dovrei portarlo indicativamente?
woodstock: @leo72: purtroppo sono obbligato ad usare una tensione da 3.3V... quindi secondo te dovrei usare una R = 1K1?
Con 3.3V usa una R da 1.2K, devi disattivare le pull up interne di Arduino.
Quanto sono lunghi i collegamenti tra i sensori ed Arduino ?
Che tipo di cavi hai usato ?
La I2C ha come unico limite la capacità complessiva della linea, 400 pf, che è data da quella dei sensori, nel tuo caso molto piccola, e quella dei cavi che può essere molto alta compromettendo l'integrità dei segnali SDA e SCL.
Come porti l'alimentazione ai due sensori ?
Potrebbe essere indispensabile utilizzare un traslatore di livelli (LLS) per la I2C, è vero che l'ATmega 328 riesce a lavorare sulla I2C con solo 3.3 V, però è al limite delle specifiche e questo riduce sensibilmente i limiti operativi.
Beh ragazzi... posso finalmente dire che dopo 15min di attività... la trasmissione non si è ancora interrotta!... i dati sono stabili tranne ogni tanto che uno dei sensori "sfarfalla" per poi ritornare stabile... questo è un punto che devo ancora risolvere!
Le modifiche effettuate sono state:
R di pullup = 1K (una per SCL e una per SDA)
Modifica dei file twi.h e twi.c seguendo le istruzioni di @Lesto
Poi penso che il tutto sarà ancora più stabile quando i componenti verranno saldati l'uno con l'altro e non più posizionati su basetta.
Ringrazio infinitamente tutti quanti!! Spero che tutto questo possa essere utile anche per altri.
ti posso confermare che la disattivazione delle pull-up interne che ti ho suggerito è la stessa che intende astro. Se non erro il limite di cavi per la i2c e circa 1 o 2 metri, poi in realtà il limite è la capacità parassita dei cavi, quindi tanto dipende dalla loro qualità.
Ora un pò di domande sul tuo progettino, visto che non sei l'unico che lavora sulle IMU
Che cosa intendi fare con la IMU? che algoritmi hai intenzione di usare per "miscelare" le letture? hai già esperienza con questo genere di aslgoritmi?
Praticamente vorrei fare motion tracking di un arto (es braccio+avanbraccio) e ricreare una simulazione in 3D.
Confesso che non ho esperienza con algoritmi di questo tipo. Ci sto lavorando da un mese e mezzo e sono praticamente partito da zero per quanto riguarda la progettazione di questo tipo di sistemi.
Al momento sono soddisfatto di essere stato in grado di ottenere il quaternione in modo tale da poterlo utilizzare per ricreare i movimenti a pc. Il vantaggio del MPU6050 è che possiede al suo interno un DMP in grado di ricavare il quaternione, coordinate di Eulero, rollio-beccheggio-imbardata e la possibilità di collaudare il sensore muovendo una teapot a monitor.
Si il sensore ha un DMP interno. Gestito tutto quando dalla libreria dedicata. Appena ne ho la possibilità posterò il video della teapot in movimento con un sensore.
