Unità di misura spostamento accelerometro MPU-6040

[Samuele Zanin]

Sto provando l'accelerometro in oggetto.
E' la prima volta che metto le mani su un accelerometro.

Ho provato con vari sketc, l'ultimo è questo:
http://www.giuseppecaccavale.it/arduino/mpu-6050-gy-521-arduino-tutorial/

Noto però una cosa. Anche lasciando l'accelerometro fermo, dopo un po' di secondi, continuo a vedere variazioni nei valori:

A me non interessa avere l'inclinazione del giroscopio, ma solo misurare l'intensita della vibrazione.
Non sono esperto in fisica (fatta solo i primi due anni delle superiori).
Muovendolo, a volte ho variazioni consistenti dei valori, altre volte queste si confondono nel "rumore di fondo".
I numeri qui sontto, sono espressi in una qualche unità di misura? Mi aspettavo qualche valore tipo "millimetri/secondo/secondo".

Accelerometer: X = 2292 | Y = 4240 | Z = 17556
Accelerometer: X = 2380 | Y = 3904 | Z = 17532
Accelerometer: X = 2356 | Y = 4236 | Z = 17324
Accelerometer: X = 2528 | Y = 4336 | Z = 17296
Accelerometer: X = 2220 | Y = 3808 | Z = 17500
Accelerometer: X = 2604 | Y = 4428 | Z = 17508
Accelerometer: X = 2400 | Y = 4252 | Z = 17540
Accelerometer: X = 2460 | Y = 3820 | Z = 17516
Accelerometer: X = 2520 | Y = 4384 | Z = 17332
Accelerometer: X = 2280 | Y = 4072 | Z = 17504
Accelerometer: X = 2388 | Y = 3892 | Z = 17484
Accelerometer: X = 2364 | Y = 4252 | Z = 17320
Accelerometer: X = 2244 | Y = 3924 | Z = 17464
Accelerometer: X = 2404 | Y = 4152 | Z = 17420
Accelerometer: X = 2384 | Y = 4412 | Z = 17320
Accelerometer: X = 2612 | Y = 4148 | Z = 17700
Accelerometer: X = 2296 | Y = 3856 | Z = 17524
Accelerometer: X = 2152 | Y = 4312 | Z = 17408
Accelerometer: X = 2700 | Y = 3976 | Z = 17496
Accelerometer: X = 2196 | Y = 4016 | Z = 17516
Accelerometer: X = 2176 | Y = 4272 | Z = 17180
Accelerometer: X = 2492 | Y = 4004 | Z = 17380
Accelerometer: X = 2392 | Y = 4020 | Z = 17568
Accelerometer: X = 2252 | Y = 4304 | Z = 17192
Accelerometer: X = 2500 | Y = 4012 | Z = 17512
Accelerometer: X = 2260 | Y = 3908 | Z = 17584

[Mirco Piccin]

Ciao Samuele,

[cut]

> Ho provato con vari sketc, l'ultimo è questo:
> http://www.giuseppecaccavale.it/arduino/mpu-6050-gy-521-arduino-tutorial/
>
> Noto però una cosa. Anche lasciando l'accelerometro fermo, dopo un po' di
> secondi, continuo a vedere variazioni nei valori:
>
> A me non interessa avere l'inclinazione del giroscopio, ma solo misurare
> l'intensita della vibrazione.
> Non sono esperto in fisica (fatta solo i primi due anni delle superiori).
> Muovendolo, a volte ho variazioni consistenti dei valori, altre volte queste
> si confondono nel "rumore di fondo".

[cut]


a me è capitato di usare l'MPU6050.
Per avere valori assoluti devi mergiare i dati di accellerometro e di
giroscopio -> DMP.

Ti consiglio innanzitutto di usare la libreria i2cdev in particolare la MPU6050:
https://github.com/jrowberg/i2cdevlib
https://github.com/jrowberg/i2cdevlib/tree/master/Arduino/MPU6050
dove trovi anche degli esempi pratici.

M

[Marco Clocchiatti]

provo a darti una mia risposta anche io, dato che lo scorso anno ho giocato con un accelerometro simile al tuo.

prima di tutto, non mi sembra, a colpo d'occhio, che la sequenza di dati che hai postato faccia pensare a una misurazione instabile.
L'asse Z, infatti, riporta i valori più elevati, che corrispondono, grosso modo, al valore di g, nelle unità di misura del tuo accelerometro.
Le prime due cifre sono rigorosamente costanti, mentre la terza varia tra 1 e 7.

Gli assi X e Y sono diversi da zero, che fa pensare a una orientazione non perfettamente verticale dell'oggetto o del sensore al suo interno (per gestire corettamente l'orientazione verticale, bisognerebbe eseguire una taratura).

Le unità di misura di misura con sono riportati i dati può variare, a seconda della sensibilità di lettura selezionata.
Per controllare queste cose, bisognerebbe riferirsi al datasheet del produttore.
credo che, nel tuo caso, possa andare bene questo:
https://www.olimex.com/Products/Modules/Sensors/MOD-MPU6050/resources/RM-MPU-60xxA_rev_4.pdf

se ho ragione (fai i tuoi controlli), la sensibilità è dichiarata alla pagina 30.
in linea di principio, il valore teorico di g, alla massima sensibilità, dovrebbe corrispondere a 16384.

guggolando un po', ho trovato questa pagina:
http://playground.arduino.cc/Main/MPU-6050
dove sono riportate alcune formule di conversione che l'autore dichiara conformi alle specifiche ufficiali e uno sketch minimale che puoi confrontare con il tuo.

[Samuele Zanin]

On Monday, May 18, 2015 at 10:16:13 PM UTC+2, Marco Clocchiatti wrote:

prima di tutto, non mi sembra, a colpo d'occhio, che la sequenza di dati che hai postato faccia pensare a una misurazione instabile.
L'asse Z, infatti, riporta i valori più elevati, che corrispondono, grosso modo, al valore di g, nelle unità di misura del tuo accelerometro.
Le prime due cifre sono rigorosamente costanti, mentre la terza varia tra 1 e 7.

Ok, stando al pdf che hai linkato sotto, i numeri sono scritti in complemento a due.
Quindi il fatto che la misura di Z sia prossima a 16384 vuol dire che l'accelerazione è bassa.
Invece per gli assi X e Y sono ben distanti da 4096 o 2048.

Gli assi X e Y sono diversi da zero, che fa pensare a una orientazione non perfettamente verticale dell'oggetto o del sensore al suo interno (per gestire corettamente l'orientazione verticale, bisognerebbe eseguire una taratura).

Se fossero le misure del giroscopio, il fatto che X e Y siano diversi da zero, mi può star bene in quanto indicano che il sensore non è perfettamente piano, ma indicando l'accelerazione, non vul dire che il sensore è in movimento? O mi sto perdendo da qualche parte?

Le unità di misura di misura con sono riportati i dati può variare, a seconda della sensibilità di lettura selezionata.

Adesso, non so su quale sensibilità sia tarato il sensore. Ipotizzando di usare la sensibilità più alta (quindi la variazione di una unità nel numero indica un'accelerazione minore), il datasheet riporta +- 2g 16384 LSB/g.
Possiamo scrivere la proporzione 16384:1=17556:x ==> 1,07g ==> 1,07 x 9,81 m/s/s ==> 10,4967
La variazione di 1 bit, indica la variazione di: 16384:1=1:x ==> 0,5987 mm/s/s.

Prendendo i primi 5 valori che ho postato:
17556, 17532, 17324, 17296, 17500
abbiamo tra uno e l'altro queste variazioni:
24, 208, 28, -204
che corrispondono rispettivamente a:
14,36
124,52
16,76
-122,13 mm/s/s.

Che a me paiono tantini.

guggolando un po', ho trovato questa pagina:
http://playground.arduino.cc/Main/MPU-6050
dove sono riportate alcune formule di conversione che l'autore dichiara conformi alle specifiche ufficiali e uno sketch minimale che puoi confrontare con il tuo.

Si, ci ero arrivato anche a questo link, ma come ho scritto sopra, i conti non mi tornano.
Probabilmente parto da presupposti errati.

[Marco Clocchiatti]

Il giorno mercoledì 20 maggio 2015 23:02:12 UTC+2, Samuele Zanin ha scritto:

On Monday, May 18, 2015 at 10:16:13 PM UTC+2, Marco Clocchiatti wrote:

prima di tutto, non mi sembra, a colpo d'occhio, che la sequenza di dati che hai postato faccia pensare a una misurazione instabile.
L'asse Z, infatti, riporta i valori più elevati, che corrispondono, grosso modo, al valore di g, nelle unità di misura del tuo accelerometro.
Le prime due cifre sono rigorosamente costanti, mentre la terza varia tra 1 e 7.

Ok, stando al pdf che hai linkato sotto, i numeri sono scritti in complemento a due.
Quindi il fatto che la misura di Z sia prossima a 16384 vuol dire che l'accelerazione è bassa.

provo a spiegare quello che mi sembra di capire, così ci confrontiamo.
complemento a due significa che il primo bit serve a definire il segno.

i dati sono rappresentati con 16 bit. cioè 65536 numeri interi.
la metà sono numeri positivi. cioè 32768.
a mio parere, il valore 32768 dovrebbe corrispondere a 2g, cioè all'overflow.

1g, di conseguenza, è rappresentato, teoricamente, dal valore 16384, in linea con le specifiche, che dichiarano un LSB=g/16384 .

i tuoi valori sull'asse Z sono superiori a 17000, quindi sembrerebbe che tu stia misurando qualcosa di superiore a g.
non so spiegare questo particolare. forse la sensibilità reale del tuo strumento è ancora superiore a quanto dichiarato dalle specifiche stesse.
bisogna tener conto che la produzione industriale di questi oggetti non è finalizzata a distribuire sul mercato prodotti tarati pronti ad eseguire misure di precisione, ma sensori atti all'uso immediato per scopi ludici. in genere, i programmi di utilizzano dipendono dalle variazioni e non dai valori assoluti.

chi è realmente interessato ai valori assoluti deve eseguire una taratura ad ok, che può dare esiti diversi per ogni singolo sensore.

[Mirco Piccin]

dmp

--
--
----
Per mandare un messaggio al gruppo "Treviso Arduino User Group", invialo a:
treviso_ardui...@googlegroups.com
Per annullare l'iscrizione a questo gruppo, invia un'email a:
treviso_arduino_use...@googlegroups.com
Per altre informazioni, visita la url:
http://groups.google.com/group/treviso_arduino_user_group

---
You received this message because you are subscribed to the Google Groups "Treviso Arduino User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to treviso_arduino_use...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Marco Clocchiatti]

Il giorno mercoledì 20 maggio 2015 23:02:12 UTC+2, Samuele Zanin ha scritto:

On Monday, May 18, 2015 at 10:16:13 PM UTC+2, Marco Clocchiatti wrote:

Gli assi X e Y sono diversi da zero, che fa pensare a una orientazione non perfettamente verticale dell'oggetto o del sensore al suo interno (per gestire corettamente l'orientazione verticale, bisognerebbe eseguire una taratura).

Se fossero le misure del giroscopio, il fatto che X e Y siano diversi da zero, mi può star bene in quanto indicano che il sensore non è perfettamente piano, ma indicando l'accelerazione, non vul dire che il sensore è in movimento? O mi sto perdendo da qualche parte?

secondo me, non c'è nulla di strano, nel fatto che X e Y siano diversi da zero.
L'accelerazione è un vettore. le componenti X e Y risultano diverse da zero perché l'asse Z del sensore non è perfettamente parallelo all'accelerazione di gravità, come idealmente si vorrebbe.

[Marco Clocchiatti]

Il giorno giovedì 21 maggio 2015 16:18:32 UTC+2, pictux ha scritto:

dmp

:)
scusa. è la prima volta che trovo questa sigla.
cosa vuol dire dmp?

[Mirco Piccin]

DMP = Digital Motion Processor

"The MPU-6050 is a serious little piece of motion processing tech! By combining a MEMS 3-axis gyroscope and a 3-axis accelerometer on the same silicon die together with an onboard Digital Motion Processor™ (DMP™) capable of processing complex 9-axis MotionFusion algorithms, the MPU-6050 does away with the cross-axis alignment problems that can creep up on discrete parts."

--

[Marco Clocchiatti]

Il giorno mercoledì 20 maggio 2015 23:02:12 UTC+2, Samuele Zanin ha scritto:

Prendendo i primi 5 valori che ho postato:

17556, 17532, 17324, 17296, 17500
abbiamo tra uno e l'altro queste variazioni:
24, 208, 28, -204
che corrispondono rispettivamente a:
14,36
124,52
16,76
-122,13 mm/s/s.

Che a me paiono tantini.

sono daccordo con la tua analisi.
anche io avevo osservato che i tuoi dati variano sulla terza cifra, anche se la sensibilità nominale dello strumento varia su 5.
questo però è un comportamento comune di tutti gli strumenti di precisione. soprattutto quelli digitali.

è un po' come leggere il millesimo di secondo sul display del proprio orologio e pretendere di fare misure con la stessa precisione.
la distinzione tra sensibilità e precisione è il segreto di ogni buona misura.

[Marco Clocchiatti]

Il giorno giovedì 21 maggio 2015 16:24:10 UTC+2, pictux ha scritto:

DMP = Digital Motion Processor

capisco.
se il problema di Samuele è legato all'interferenza di un processore interno, credo di non avere esperienza in merito.
infatti, lo scorso anno ho giocato con un accelerometro puro (adxl345).

però vorrei fare una domanda, su un aspetto che mi sfugge.
per quale meccanismo la presenza di un processore interno può interferire aumentando la dispersione delle misure rilevate su un singolo canale di acquisizione?

[Mirco Piccin]

..questo processore interno non genera interferenze (credo), ma
piuttosto ha funzione opposta.
Permette di ottenere informazioni pulite e pronte all'uso senza impazzire.

[bissaorboea]

Ho pasticciato anch'io con il 6050, da quanto ho capito i dati RAW sono difficilmente utilizzabili, occore usare i dati processati dal DMP.

Per farlo ho usato la libreria: https://github.com/jrowberg/i2cdevlib
Inoltre dallo stesso repository si può scaricare un test su processing (teapot) che dimostra una certa stabilità.
Non ho approfondito i dettagli, ma facendo un po' di reverse engineering magari si può capire qualcosa di più.

Bye,
Bissa.

[Mirco Piccin]

Ciao Bissa,

> Ho pasticciato anch'io con il 6050, da quanto ho capito i dati RAW sono
> difficilmente utilizzabili, occore usare i dati processati dal DMP.
> Per farlo ho usato la libreria: https://github.com/jrowberg/i2cdevlib

appunto, come cerco di dire fin dall'inizio :)

M

[Samuele Zanin]

On Thursday, May 21, 2015 at 4:20:21 PM UTC+2, Marco Clocchiatti wrote:

secondo me, non c'è nulla di strano, nel fatto che X e Y siano diversi da zero.

L'accelerazione è un vettore. le componenti X e Y risultano diverse da zero perché l'asse Z del sensore non è perfettamente parallelo all'accelerazione di gravità, come idealmente si vorrebbe.

Qui mi perdo.
Se il sensore è fermo e l'ho bloccato con le pinze della terza mano che ha la base in ferro avvitata ad una tavoletta in legno, io dovrei misurare zero accelerazione in tutte le direzioni.
Da quel che ricordo di fisica (sono passati 20 anni), se anche mi muovessi, ma a velocità costante l'accelerazione sarebbe zero.
Se anche il sensore fosse inclinato ma fermo, non dovrei avere accelerazione. A meno che per accelerazione non intendano la forza che viene esercitata sul sensore. In questo caso la gravità applica costantemente una forza che però non provoca accelerazione in quanto il sensore è sopra al tavolo.

[Samuele Zanin]

On Thursday, May 21, 2015 at 4:29:12 PM UTC+2, Marco Clocchiatti wrote:

Il giorno mercoledì 20 maggio 2015 23:02:12 UTC+2, Samuele Zanin ha scritto:

Prendendo i primi 5 valori che ho postato:

17556, 17532, 17324, 17296, 17500
abbiamo tra uno e l'altro queste variazioni:
24, 208, 28, -204
che corrispondono rispettivamente a:
14,36
124,52
16,76
-122,13 mm/s/s.

Che a me paiono tantini.

sono daccordo con la tua analisi.
anche io avevo osservato che i tuoi dati variano sulla terza cifra, anche se la sensibilità nominale dello strumento varia su 5.
questo però è un comportamento comune di tutti gli strumenti di precisione. soprattutto quelli digitali.

Mi sono perso di nuovo.
.

è un po' come leggere il millesimo di secondo sul display del proprio orologio e pretendere di fare misure con la stessa precisione.
la distinzione tra sensibilità e precisione è il segreto di ogni buona misura.

Se ho un orologio capace di contare il millesimo di secondo, mi aspetto di avere misure precise al millesimo (o al più con un errore di 2 millesimi).

[Samuele Zanin]

Quello è stato il primo esempio da cui sono partito.
Vedevo misure instabili, ho provato a guardare il codice, vedevo che richiamava un sacco di metodi.
Avevo fatto altre ricerche ed ero approdato ad un codice più semplice che speravo funzionasse meglio.
Ho comunque ricaricato lo sketch MPU6050_DMP6 e attivato sia OUTPUT_READABLE_REALACCEL che
OUTPUT_READABLE_WORLDACCEL ottenendo misure più stabili, però comunque quando sono fermo leggo valori diversi da zero (come scrivevo sopra).

Domani sera porto la bestia.

[Pierluigi Luisi]

In realtà esiste una accelerazione sempre presente sulla terra: l'accelerazione di gravità.

Saluti
Pierluigi

--

[Samuele Zanin]

On Sunday, May 24, 2015 at 3:08:01 PM UTC+2, Pierluigi Luisi wrote:

In realtà esiste una accelerazione sempre presente sulla terra: l'accelerazione di gravità.

Ok, che è la forza di gravità.
In ogni caso, sembra che sia inevitabile che venga misurata per come è costruito l'accelerometro, anche se in realtà l'accelerazione è zero.

http://forum.arduino.cc/index.php?topic=112892.15
http://www.settorezero.com/wordpress/cosa-sono-come-funzionano-e-a-cosa-servono-gli-accelerometri/

[Pierluigi Luisi]

però quella è proprio una accelerazione, e appunto è inevitabile che venga misurata, per qualunque accelerometro.

E' anche utile che sia così, anche per capire come sia orientato questo accelerometro, no?

Pierluigi

--

[Marco Clocchiatti]

Il giorno domenica 24 maggio 2015 15:02:32 UTC+2, Samuele Zanin ha scritto:

 

Se ho un orologio capace di contare il millesimo di secondo, mi aspetto di avere misure precise al millesimo (o al più con un errore di 2 millesimi).

davvero tu credi al tempo misurato dal tuo cronometro da polso fino all'ultima cifra?
bada che hai premuto lo start e lo stop con il ditone grosso.

come ho detto sopra, non posso aiutarti nella scelta del software.
se però l'instabilità che hai descritto sopra non dovesse ridursi aggiustando gli script, sei costretto ad assumerla come una caratteristica del tuo strumento di misura.
e trattarla eseguendo una taratura.

in linea di principio, avere qualche cifra ballerina nella misura di un fenomeno statico non è necessariamente una cosa negativa.
supponi ad esempio di riconoscere, nella distribuzione delle cifre variabili, una distribuzione gaussiana.
e supponi di avere necessità, per i tuoi scopi, di una frequenza di campionamento non troppo elevata.
in queste condizioni, acquisendo dati a una frequenza maggiore di quella necessaria e facendo la media, puoi migliorare la qualità delle misure.

[Silvio Ross]

Essendoci sempre presente la forza di gravità, e se non ho capito male il valore Z non sembra perfettamente tarato; allora anche quando il sensore è perfettamente fermo, ci sarà un volte diverso da "zero" in X e Y.
Se questo varia allora c'è accelerazione, altrimenti si può leggere "fermo" anche se legge un'accelerazione costante non essendo correttamente tarata la Z.

[Mirco Piccin]

..anche qui qualche cosiderazione:
http://forum.arduino.cc/index.php?topic=327185.0

2015-05-25 14:07 GMT+02:00 Silvio Ross <rroo...@gmail.com>:
> Essendoci sempre presente la forza di gravità, e se non ho capito male il valore Z non sembra perfettamente tarato; allora anche quando il sensore è perfettamente fermo, ci sarà un volte diverso da "zero" in X e Y.
> Se questo varia allora c'è accelerazione, altrimenti si può leggere "fermo" anche se legge un'accelerazione costante non essendo correttamente tarata la Z.
>

[Samuele Zanin]

On Wednesday, June 3, 2015 at 12:58:15 PM UTC+2, pictux wrote:

..anche qui qualche cosiderazione:
http://forum.arduino.cc/index.php?topic=327185.0

Per il momento ho risolto confrontando i valori tra due letture consecutive e loggandoli solo se la differenza tra le due letture è maggiore di 50.
Ho invece dovuto porconare in tutte le lingue note ed ignote per riuscire a fare un cavo da attaccarci.
Altra magagana è che libreria accelerometro + libreira sd arrivo a 30K su 32 di spazio disponibile.
La libreria per la scrittura su sd è solo temporanea, finché non mi faccio un'idea di che dati avrò a disposizione.