Arduino e sensori accelerometri

[ElNonino]

Originalmente inviato da Minestrone

A proposito di giroscopi:
Mi sarebbe servito un giroscopio preciso che rilevasse l'angolo con l'orizzontale di una barra che sale e scende sorretta da due cilindri pneumatici all'estremità. Mi son trovato che il MPU6050 non è affatto abbastanza veloce e preciso per il lavoro che serviva a me. Probabilmente ho sbagliato qualcosa ma ho provato anche a variare i fondoscala dei sensori senza trarne beneficio.

Avete da consigliarmi qualche giroscopio che possa fare al caso mio e che possa correggere la deriva con l'accelerometro che sia facile da gestire (magari analogico) ?
Grazie

A mio avviso per realizzare una livella elettronica non serve un giroscopio ma un accelerometro a 3 assi, forse l'ho già scritto ma io per rilevare l'inclinazione dei pannelli FV del mio impianto uso da 10 anni un accelerometro analogico della Freescale MMA7760 (ora sostituito da un'altro pin to pin compatibile) i cui valori vengono letti ed elaborati da un PIC18F...

Usando anche solo due assi e giocando con la trigonometria leggo l'assetto con la precisione di 1/20° anche con escursioni termiche da -30°C a +40°C, se è richiesta velocità per i calcoli un Arduino Nano forse è un poco limitato, anche perchè per ottenere la stessa precisione su 180° è necessario implementare una tabella per la linearizzazione, se la ritrovo ti giro una application note che spiega bene gli algoritmi necessari, se ti servisse posso mandarti il pezzo di programma in C che realizzai.

[Minestrone]

Il programma lo leggo volentieri. In ogni modo temo che il problema sia proprio l'accelerometro, a mio avviso, che legge anche le vibrazioni e le scambia per variazioni angolari. Devo provare a fare fare i calcoli all'Arduino e non al dmp interno filtrando i valori dell'accelerometro.

Inviato dal mio Mi A1 utilizzando Tapatalk

[ElNonino]

Questa è la parte del programma che legge tramite AD i canali X e Z dell'accelerometro, effettua alcuni calcoli preliminari, linearizza e poi rende il risultato finale in 1/10°, cioè 90,0° = 900; trasmettere numeri interi richiede meno tempo e memoria che inviare dei float.

naturalmente è scritto in C puro e per un PIC18Fxxx quindi non è direttamente usabile con Arduino, se hai dubbi chiedi pure.

[Minestrone]

Quando termino le ferie me lo leggo con calma. Intanto grazie.

Inviato dal mio Mi A1 utilizzando Tapatalk

[ElNonino]

Hai provato e risolto ?

[Minestrone]

Ho letto il tuo codice, tu usi il processore in maniera molto più efficiente di come lo uso io ed ho preso spunto per migliorare il mio codice, di fatto però la sostanza non cambia molto, solo l'esecuzione è più veloce (forse). Tu hai fatto una livella con solo accelerometri, nel mio caso non va bene perché l'accelerometro fornisce un output sporco e non può essere letto velocemente e senza filtri, ecco perché della necessità di usare anche il giroscopio.

Per quanto riguarda l'incidenziometro ho risolto cambiando l'approccio ed usando due arduino che comunicano in seriale e non in I2c eliminando anche il display che comunicava anche esso in I2c. A tempo debito però svilupperò anche la prima versione del progetto perchè PENSO finalmente di aver capito che il problema sia la comunicazione I2C che veniva interrotta dagli interrupt dei sensori e bloccava il codice. Rinunciando ad utilizzare il processore interno dei sensori e facendo fare tutti i calcoli all' Arduino non avrei più necessità di usare l'interrupt e potrei aver risolto il problema. Questa cosa mi era stata consigliata all'inizio della discussione ma non ho dato il giusto peso al consiglio.
Probabilmente un programmatore capace avrebbe intuito il problema alla svelta, io ci ho messo un po' di più (sempre che il problema fosse quello).


Per quanto riguarda l'altra applicazione ho deciso che l'utilizzo di un sensore come questo rende l'applicazione troppo complessa ed ho optato per l'utilizzo di sensori lineari che forniscono informazione precisa e diretta della posizione delle due estremità della barra, una semplice sottrazione mi dà poi l'informazione del dislivello, che è quello che mi interessa. La seconda soluzione è più costosa ma più semplice, più diretta e sicura.

[ElNonino]

Originalmente inviato da Minestrone

Ho letto il tuo codice, tu usi il processore in maniera molto più efficiente di come lo uso io ed ho preso spunto per migliorare il mio codice, di fatto però la sostanza non cambia molto, solo l'esecuzione è più veloce (forse). Tu hai fatto una livella con solo accelerometri, nel mio caso non va bene perché l'accelerometro fornisce un output sporco e non può essere letto velocemente e senza filtri, ecco perché della necessità di usare anche il giroscopio.

Per quanto riguarda l'incidenziometro ho risolto cambiando l'approccio ed usando due arduino che comunicano in seriale e non in I2c eliminando anche il display che comunicava anche esso in I2c. A tempo debito però svilupperò anche la prima versione del progetto perchè PENSO finalmente di aver capito che il problema sia la comunicazione I2C che veniva interrotta dagli interrupt dei sensori e bloccava il codice. Rinunciando ad utilizzare il processore interno dei sensori e facendo fare tutti i calcoli all' Arduino non avrei più necessità di usare l'interrupt e potrei aver risolto il problema. Questa cosa mi era stata consigliata all'inizio della discussione ma non ho dato il giusto peso al consiglio.
Probabilmente un programmatore capace avrebbe intuito il problema alla svelta, io ci ho messo un po' di più (sempre che il problema fosse quello).


Per quanto riguarda l'altra applicazione ho deciso che l'utilizzo di un sensore come questo rende l'applicazione troppo complessa ed ho optato per l'utilizzo di sensori lineari che forniscono informazione precisa e diretta della posizione delle due estremità della barra, una semplice sottrazione mi dà poi l'informazione del dislivello, che è quello che mi interessa. La seconda soluzione è più costosa ma più semplice, più diretta e sicura.

Bene, il sistema per leggere le due estremità di una barra e porla orizzontale può essere creato senza usare alcun microcontrollore basta usare, giustamente, sensori analogici ed un paio di comparatori analogici e poco più.

Per il resto se hai problemi di velocità di acquisizione e necessiti di filtraggio è meglio che abbandoni Arduino Uno (ma anche MEGA) e passi ad altri processori, molto indicati allo scopo sono i dsPIC della Microchip, capisco che Arduino sia come il prezzemolo perchè apparentemente semplice da programmare ma quando il gioco si fa duro mostra tutti i suoi limiti specialmente se si utilizza il suo IDE e le librerie preconfezionate; programmandolo direttamente le prestazioni migliorerebbero non poco.

Comunque se hai risolto facendo comunicare due Arduino con la seriale non dovresti avere grandi problemi di velocità d'acquisizione e per me basterebbe usare solamente un accelerometro, la fusione di dati da acc+gyro comporta calcoli complessi e molto lenti su un UNO.

IMHO

[Minestrone]

Originalmente inviato da ElNonino

Bene, il sistema per leggere le due estremità di una barra e porla orizzontale può essere creato senza usare alcun microcontrollore basta usare, giustamente, sensori analogici ed un paio di comparatori analogici e poco più.

Per il resto se hai problemi di velocità di acquisizione e necessiti di filtraggio è meglio che abbandoni Arduino Uno (ma anche MEGA) e passi ad altri processori, molto indicati allo scopo sono i dsPIC della Microchip, capisco che Arduino sia come il prezzemolo perchè apparentemente semplice da programmare ma quando il gioco si fa duro mostra tutti i suoi limiti specialmente se si utilizza il suo IDE e le librerie preconfezionate; programmandolo direttamente le prestazioni migliorerebbero non poco.

Comunque se hai risolto facendo comunicare due Arduino con la seriale non dovresti avere grandi problemi di velocità d'acquisizione e per me basterebbe usare solamente un accelerometro, la fusione di dati da acc+gyro comporta calcoli complessi e molto lenti su un UNO.

IMHO

Rispondo per gradi partendo dalla fine:
Per quanto riguarda l'inclinometro problemi di velocità non ce ne sono perchè tanto è uno strumento che deve misurare l'inclinazione dell'ala e può essere lento quanto vuole. Mi ero impuntato ad usare il processore interno dei sensori proprio perchè volevo sgravare l'arduino dai calcoli di sensor fusion.
Di fatto, se si usa un filtro complementare e non si ha bisogno di grande velocità di esecuzione un atmel 328 può anche andare. La sensor fusion a questo punto serve più che altro per pulire e filtrare il dato degli accelerometri che è molto sporco di suo e sente tutte le vibrazioni, fa le veci della media in virgola mobile.

Per quanto riguarda il problema della barra invece l'esperimento che ho fatto con Arduino mi serviva solo per capire se fosse una strada applicabile senza comprare sensori commerciali e tutta l'attrezzeria che necessitano per funzionare. Sono sicuro che con dei sensori commerciali confezionati ad hoc il sistema potrebbe anche funzionare ma l'esperimento mi è bastato per scartare questa possibilità in quanto troppo complessa. Preferisco sempre soluzioni semplici, anche se sono più costose. Alla fine ci sarà un plc che si occuperà della lettura dei sensori oltre alle altre cose.

[ElNonino]

In ambito industriale concordo con la scelta di un PLC + sensori dedicati specialmente se esistono soluzioni già testate e chiavi in mano.

Per il filtraggio io ho usato una doppia media mobile perchè il movimento dell'asse verticale dei pannelliFV è estremamente lento e pressochè privo di vibrazioni o giochi meccanici, in altri casi ho implementato filtri FIR ed IIR progettati in funzione del tipo di disturbo e/o tempi di risposta richiesti, misurare l'nclinazione con un giroscopio comporto o un tempo di campionamento fisso e preciso (come normalmente avviene con il mio micro S.O.) oppure un calcolo aggiuntivo per il deltaT dello stesso.

Se non è richiesta velocità anche Arduino ce la può fare, quello che trovo strano è che in un sistema quasi statico, come quello dell'incidenziometro, l'uscita dell'accelerometro fosse molto "sporca", dovresti provare a misurarla e visualizzarla con un accelerometro analogico ed un oscilloscopio.