[Multicotteri] Elettronica : IMU, MCU, Sensori ed algoritmi di controllo

wow non sapevo che un elicottero modificasse il passo dell'elica per aumentare o diminuire le forze, grazie della lezioncina :smiley: ho visto un po di video, e in effetti di manutenzione se ne deve fare molta essendoci tutta quella meccanica.
Adesso che mi avete spiegato tutte queste cose però mi sorge un dubbio: perchè non si può utilizzare la stessa elettronica che si usa nei quadri per il controllo dell'assetto?? cioè un elicottero non riuscirebbe a stabilizzarsi da solo avendo a disposizione un accelerometro?

cavde:
wow non sapevo che un elicottero modificasse il passo dell'elica per aumentare o diminuire le forze

Escludendo dal discorso i giocattoli con il doppio rotore coassiale, che utilizzano un diverso sistema per volare e governare, tutti gli elicotteri monorotore come minimo hanno il passo ciclico, un sistema che tramite un piatto oscillante permette di cambiare il passo delle pale in modo simmetrico con verso opposto, una aumenta il passo mentre l'altra lo perde, in modo graduale durante una intera rotazione, questo permette all'elicottero di spostare il vettore della spinta all'interno di un cono e di dividerlo tra sostentamento e spinta in una direzione.
Una volta i modelli più semplici di elicotteri usavano la variazione del numero di giri del rotore, combinata al passo ciclico, per variare l'intensità della spinta e di conseguenza la forza che sostiene e spinge l'elicottero permettendo di farlo salire/scendere in verticale e gestire la velocità di spostamento, ora tutti i modelli di elicotteri RC, sempre esclusi i giocattoli, usano il passo collettivo che è la variazione del passo di ambedue le pale di una stessa quantità e con lo stesso verso, questo può avvenire tramite un apposito asse di comando coassiale all'albero del rotore, sistema ormai quasi in disuso, oppure sempre tramite il piatto oscillante che viene alzato e abbassato per variare il collettivo.
Sebbene può sembrare strano utilizzare il piatto oscillante per comandare sia il ciclico che il collettivo permette di semplificare la meccanica e consente comandi più precisi perché il piatto viene azionato direttamente, senza rinvii, tramite tre servo disposti a 120°, si chiama azionamento trilink e richiede uno speciale sistema di miscelazione dei comandi che deve essere presente sul radiocomando, quelli recenti per hely lo hanno tutti.

Adesso che mi avete spiegato tutte queste cose però mi sorge un dubbio: perchè non si può utilizzare la stessa elettronica che si usa nei quadri per il controllo dell'assetto?? cioè un elicottero non riuscirebbe a stabilizzarsi da solo avendo a disposizione un accelerometro?

Perché l'elicottero è un mezzo molto più instabile del quadricottero e la fisica del suo volo è molto diversa, comunque volendo è possibile stabilizzarlo elettronicamente, esistono appositi sistemi elettronici denominati flybar less, il nome deriva dal fatto che viene eliminato un componente del rotore che si chiama fly bar (è quella specie di piccolo rotore con le due palette che vedi montato a 90° rispetto al rotore), però costano diverse centinaia di Euro nelle versioni base, e non garantiscono la stessa stabilità di un quadri, fino ad arrivare anche a oltre 1000 Euro per quelli veramente efficaci.
Non ultimo tieni presente che se ad un pilota di hely che si diverte a fare volo acrobatico ad alto livello, come me per esempio, viene a proporre un sistema per rendere l'elicottero docile come minimo ti prendi un vaffa, noi l'hely lo vogliamo inc....to nero :grin:

Per capire cosa intendo volo acrobatico ad alto livello guarda questo video (un quadri non può volare in questo modo).

esaustivo come sempre e complimenti a quel ragazzino del video!
però non mi attira per niente fare volo acrobatico, mi piace la tranquillità e pacatezza del mio quadricottero, siamo in sintonia :wink:

Ciao ragazzi, io sono in procinto di costruire un quadricottero, ho acquistato il necessario e ora sto provando a creare l'algoritmo per bilanciare due motori posti su un'asse (è la base di partenza) con scarsi risultati però.

Lavoro con un Arduino Mega2560 e un sensore giroscopio accelerometro GY-521, riesco a leggere i dati raw (che forse sono un po' ballerini) ma non ci sono dati aberranti. Volevo capire se avete consigli su un filtro semplice da utilizzare sui dati e la logica con la quale essi modificano l'output suoi motori. Se avete esempi consigli vi ringrazio molto anticipatamente.

Guarda sulla mia firma il progetto quadrilatero completo, ma occhio che non credo sia veramente completo, non ricordo se ho aggiornato il codice. Però è una base di partenza. In pratica ora fai così: invia i dati letti al pc e crea una guida che visualizzi un oggetto 3d che farai muovere con il sensore. Quando questo è ok puoi passare alla fase braccio, poi alla fase quad, ed ifine volo

Ho fatto qualche passo avanti, vi posto il video del risultato (ancora in beta) che ho ottenuto applicando un PID per cercare di bilanciare un asse: Self Balancing - 1 asse - YouTube

Ho notato però che l'input del sensore è poco uniforme, quindi per procedere devo assolutamente implementare un filtro di kalman come questo Gioblu.com is for sale | HugeDomains ma ho una domanda da niubbo, l'algoritmo nel link mi permette di filtrare solo un asse giusto?! Nel programma finale, avrò bisogno di controllare 2 assi quindi devo implementare 2 kalman e due PID?!

Grazie anticipate!

samu_87:
Ho fatto qualche passo avanti, vi posto il video del risultato (ancora in beta) che ho ottenuto applicando un PID per cercare di bilanciare un asse: Self Balancing - 1 asse - YouTube

Direi che sei sulla buona strada :slight_smile:

Ho notato però che l'input del sensore è poco uniforme, quindi per procedere devo assolutamente implementare un filtro di kalman come questo Gioblu.com is for sale | HugeDomains ma ho una domanda da niubbo,

Si ti serve un Kalman, ma non quella cosa che trovi sul tutorial che hai linkato, è tutto meno che un vero Kalman :slight_smile:
Il Kalman lo applichi a tutto il sistema, ovvero a tutti i d.o.f., e questo richiede un grosso lavoro di analisi matematica e devi anche conoscere in modo abbastanza preciso le funzioni di trasferimento del sistema altrimenti te lo scordi di implementare un Kalman che sia realmente preciso.
Potresti optare per la soluzione di Lesto che utilizza solo la DCM, molto più semplice da implementare e offre lo stesso buoni risultati.
Ovviamente c'è sempre la questione pid, che è tutt'altro che secondaria, e da quello che hai scritto qui direi che non hai le idee molto chiare su cosa sia e come funziona il pid :slight_smile:
Ti consiglio di cercare il corso pid di Livio Orsini, lo trovi in formato pdf liberamente scaricabile, è la miglior introduzione possibile al mondo del pid che, dietro l'apparente semplicità della formulazione canonica, nasconde molte insidie e alberga il maligno (come direbbe Bonolis :grin: ).

lesto:
Guarda sulla mia firma il progetto quadrilatero completo,

Ma vola ?

ottimo lavoro, è un buon inizio.
Come ti sei accorto i sensori vanno "puliti", in oltre i sensori hanno un "output rate" (vedi datasheet per i valori) che in pratica è quante volte al secondo si aggiornano. Leggere i sensori più in fretta senza apposita pulizia dei valori crea risultati sballati. Poi applichi il kallmann, che pulisce i segnali ulteriormente, e poi fai una "sensor fusion", ovvero applichi un algoritmo che "mischia" i dati dei sensori.
Lavora tranquillamente su un singolo asse, tanto tranne la rotazione su se stesso (yaw), che puoi implementare più avanti,
Io uso la DCM che fa sia da filtro che da sensor fusion (arduinoSketch/Stabilizzazione.cpp at master · lestofante/arduinoSketch · GitHub), ed è lo stesso algoritmo usato nella libreria freeIMU, anzi, mi pare che lui usi la versione "base" di Mayhony mentre io uso quella modificata da Madgwick che incorpora la compensazione per la distorsione magnetica del magnetometro

astrobeed:

lesto:
Guarda sulla mia firma il progetto quadrilatero completo,

Ma vola ?

no, è un codice vecchissimo (5 mesi fa), ora sono allo stesso punto di samu_87 ma con migliore stabilità e su tutti gli assi (yaw compreso) ma comnadabile solo come potenza motore(throttle) via Seriale (debug del quaternione graficamente a 30Hz se non ricordo male).
Ovviamente ora è tutto fermo perchè sto portando il codice sull STM32, se ne avessi il tempo. Forse sono riuscito a comunicarci via seriale attraverso un traslatore di livelli e un chip FTDI, l'USB per ora l'ho abbandonata che mi ha portato via un sacco di tempo senza risultati.

lesto:
Ovviamente ora è tutto fermo perchè sto portando il codice sull STM32, se ne avessi il tempo.

Io ho già fatto il porting del mio codice per dsPIC33 sulla STM32F3, funziona abbastanza bene devo solo finire di ottimizzare ed eliminare qualche bug minore.
Come prima impressione, corroborata da verifiche pratiche e strumentali, posso confermarti che i sensori della STM32F3 sono realmente superiori a quelli che utilizzavo sulla precedente versione della IMU, ovvero l'ITG3200 e l'ADXL345 con il magnetometro HMC5883L.
Inutile dire che avanza tempo cpu in abbondanza per gestire il quadri e il GPS con tanto di funzionalità per il volo autonomo, questo anche grazie alla presenza della fpu e del core dsp, impossibile chiedere di più per solo 14 Euro :grin:

si, ma io voglio i dati via USB!!!!! a parte che in realtà se la seriale mi funziona bene, è giusto a 3,3v come gli xbee di cui ne ho una coppia a casa...
il problema è il tempo da dedicarci, speravo nelle vacanze di natale ma una capellona mi ha agguantato, e addio al già poco tempo libero :slight_smile:

astrobeed:

samu_87:
Ho fatto qualche passo avanti, vi posto il video del risultato (ancora in beta) che ho ottenuto applicando un PID per cercare di bilanciare un asse: Self Balancing - 1 asse - YouTube

Direi che sei sulla buona strada :slight_smile:

Ho notato però che l'input del sensore è poco uniforme, quindi per procedere devo assolutamente implementare un filtro di kalman come questo Gioblu.com is for sale | HugeDomains ma ho una domanda da niubbo,

Si ti serve un Kalman, ma non quella cosa che trovi sul tutorial che hai linkato, è tutto meno che un vero Kalman :slight_smile:
Il Kalman lo applichi a tutto il sistema, ovvero a tutti i d.o.f., e questo richiede un grosso lavoro di analisi matematica e devi anche conoscere in modo abbastanza preciso le funzioni di trasferimento del sistema altrimenti te lo scordi di implementare un Kalman che sia realmente preciso.
Potresti optare per la soluzione di Lesto che utilizza solo la DCM, molto più semplice da implementare e offre lo stesso buoni risultati.
Ovviamente c'è sempre la questione pid, che è tutt'altro che secondaria, e da quello che hai scritto qui direi che non hai le idee molto chiare su cosa sia e come funziona il pid :slight_smile:
Ti consiglio di cercare il corso pid di Livio Orsini, lo trovi in formato pdf liberamente scaricabile, è la miglior introduzione possibile al mondo del pid che, dietro l'apparente semplicità della formulazione canonica, nasconde molte insidie e alberga il maligno (come direbbe Bonolis :grin: ).

Intanto ti ringrazio, mi sa che inizierò la DCM.

Per quanto riguarda il PID ho trovato questi materiali, inserisco i link così che possano essere utili ad altri:

http://www.fabbrimarco.com/droboitalia/Le%20guide%20di%20Roboitalia%20-%20il%20PID%20facile1.pdf

http://www.plcforum.info/didattica/conreg/conreg.htm

Poi devo assolutamente visualizzare l'andamento dei valori con grafici tramite Processing.

Ringrazio molto anche lesto!

P = errore / kP;
I = I + roll * kI;
D = ((errore - erroreOld) / interval) * kD;

float PID = P + I + D;

Ora le formule di PID dovrebbero essere corrette giusto?! considerando che interval è la durata dell loop.

Da qui capisco che con queste tre regole posso controllare una sola variabile di output, nel senso, il PID mi permette di correggere un errore, l'errore è dato da un valore aspettato e un valore letto, il PID minimizza questo errore. Se fin qui ci sono ora dico che il mio errore è lo scostamento dallo zero di un asse X del quale possiedo il valore, come attuatori ho due motori che compiono lo stesso numero di giri, il PID mi fornirà (se settato a dovere) un valore da sottrarre a un motore e sommare all'altro che mi garantisce la stabilità di tale asse.

Dovendo stabilizzare due assi X e Y dovrò gestire due PID distinti per ogni asse??
O mi sfugge il funzionamento della DCM che fonde gli input?!

Grazie!

lesto:
si, ma io voglio i dati via USB!!!!! a parte che in realtà se la seriale mi funziona bene, è giusto a 3,3v come gli xbee di cui ne ho una coppia a casa...

La parte USB non l'ho ancora guardata, però è sicuramente possibile come testimonia il video linkato.

ma una capellona mi ha agguantato, e addio al già poco tempo libero :slight_smile:

Questa si che è una cosa positiva :grin:

samu_87:
Per quanto riguarda il PID ho trovato questi materiali, inserisco i link così che possano essere utili ad altri:
http://www.fabbrimarco.com/droboitalia/Le%20guide%20di%20Roboitalia%20-%20il%20PID%20facile1.pdf
http://www.plcforum.info/didattica/conreg/conreg.htm

Il primo link è solo una introduzione molto all'acqua di rose al pid, l'autore è un amico.
Il secondo link è il corso pid di Livio Orsini che ti avevo indicato, studialo con molta attenzione perché è ottimo.

Poi devo assolutamente visualizzare l'andamento dei valori con grafici tramite Processing.

Fattibile, però ti consiglio di dare un'occhiata a questo sito, trovi una soluzione pronta all'uso e totalmente free.

samu_87:
Ora le formule di PID dovrebbero essere corrette giusto?! considerando che interval è la durata dell loop.

No, quello non è un pid, gli assomiglia ma non lo è

Da qui capisco che con queste tre regole posso controllare una sola variabile di output, nel senso, il PID mi permette di correggere un errore

Non è corretto, un pid può avere più input di feedback e multipli output di correzione, ovviamente le cose si complicano non poco, solitamente si preferisce utilizzare singoli pid tra loro concatenati che vengono indicati come pid a doppio, triplo, etc, anello a seconda del numero di feedback in ingresso.

, l'errore è dato da un valore aspettato e un valore letto, il PID minimizza questo errore.

Lo scopo del pid non è minimizzare, è mantenere l'errore a zero, ovviamente in pratica è impossibile e in realtà il sistema oscilla in modo periodico attorno allo zero, più è efficace il pid e minore è l'intensità delle oscillazioni e maggiore il periodo, il pid quasi ideale ha una caratteristica smorzata sull'errore che rimane a valori talmente bassi che si possono considerare nulli perché non hanno alcun effetto sul sistema.

Se fin qui ci sono ora dico che il mio errore è lo scostamento dallo zero di un asse X del quale possiedo il valore, come attuatori ho due motori che compiono lo stesso numero di giri, il PID mi fornirà (se settato a dovere) un valore da sottrarre a un motore e sommare all'altro che mi garantisce la stabilità di tale asse.

Stai commettendo un grosso errore di valutazione, il controllo primario non è la posizione, è la velocità di rotazione dell'asse, solo quando l'hai azzerata, o mantenuta costante ad un valore desiderato, puoi prendere in considerazione di portare l'asse ad un certo valore di inclinazione desiderato, e non è detto che sia per forza zero.
Detto in altri termini ti serve un pid a doppio anello, input velocità angolare (giroscopio, parametro primario) e posizione angolare (input accelerometro/magnetometro, parametro secondario).

O mi sfugge il funzionamento della DCM che fonde gli input?!

La DCM ti fornisce l'assetto, non esegue la correzione, quello è compito del pid.

astrobeed:
Stai commettendo un grosso errore di valutazione, il controllo primario non è la posizione, è la velocità di rotazione dell'asse, solo quando l'hai azzerata, o mantenuta costante ad un valore desiderato, puoi prendere in considerazione di portare l'asse ad un certo valore di inclinazione desiderato, e non è detto che sia per forza zero.
Detto in altri termini ti serve un pid a doppio anello, input velocità angolare (giroscopio, parametro primario) e posizione angolare (input accelerometro/magnetometro, parametro secondario).

Quindi io ho il mio sensore GY-521 che mi fornisce dati di giroscopio e accelerometro, ora utilizzo i dati provenienti dal giroscopio che mi danno la distanza (in radianti? valori compresi fra -16000 e 16000) dallo zero che rappresenta l'asse perfettamente parallelo al suolo.
Dovrei quindi usare il valore dell'accelerometro?
Quindi in futuro PID a doppio anello che tramite l'accelerometro tiene l'asse "in bolla" e tramite il radiocomando varia un parametro inclinazione che viene mantenuto dal secondo anello del PID?

Grazie e scusa l'ignoranza ma iniziare non è facile :slight_smile:

samu_87:
Quindi io ho il mio sensore GY-521 che mi fornisce dati di giroscopio e accelerometro, ora utilizzo i dati provenienti dal giroscopio che mi danno la distanza (in radianti? valori compresi fra -16000 e 16000) dallo zero che rappresenta l'asse perfettamente parallelo al suolo.

Attenzione, il giroscopio fornisce la velocità angolare, non la posizione, questa semmai potresti ricavarla tramite integrazione, però è un metodo che in pochissimo tempo ti porta ad errori enormi.
Per ottenere in modo preciso la posizione si usa la sensor fusion tra giroscopio e accelerometro, e questa te la fa la DCM, però intanto puoi tranquillamente lavorare con solo i dati giroscopici per mettere a punto l'anello controllo velocità facendo in modo che l'asse rimane stabile dove lo metti e se gli dai un colpo deve fermarsi da solo nel modo più rapido possibile.

astrobeed:

samu_87:
Quindi io ho il mio sensore GY-521 che mi fornisce dati di giroscopio e accelerometro, ora utilizzo i dati provenienti dal giroscopio che mi danno la distanza (in radianti? valori compresi fra -16000 e 16000) dallo zero che rappresenta l'asse perfettamente parallelo al suolo.

Attenzione, il giroscopio fornisce la velocità angolare, non la posizione, questa semmai potresti ricavarla tramite integrazione, però è un metodo che in pochissimo tempo ti porta ad errori enormi.
Per ottenere in modo preciso la posizione si usa la sensor fusion tra giroscopio e accelerometro, e questa te la fa la DCM, però intanto puoi tranquillamente lavorare con solo i dati giroscopici per mettere a punto l'anello controllo velocità facendo in modo che l'asse rimane stabile dove lo metti e se gli dai un colpo deve fermarsi da solo nel modo più rapido possibile.

Ok perfetto! quindi per ora mi concentro solamente sul valore del giroscopio relativo all'asse che misuro giusto?! O mi serve anche l'asse Y?

Mi potresti dire per che motivo si scostano le mie equazioni del PID?!