Newsgroup: it.hobby.elettronica.digitale
Titolo: Filtro miscelazione dati

Ciao,
ho due dati che mi danno l'informazione di heading.
Uno proviene da una bussola Honeywell, l'altro dall'integrazione di un 
rate-gyro. Entrambi sono compresi nel range 0,0 - 360,0 gradi.
In realtï¿œ, il secondo sensore mi fornisce la prua rispetto a un valore 
di riferimento.
Vorrei "miscelare" questi due dati per ottenerne uno dalle migliori 
qualitï¿œ, tenendo presente che:
* la bussola ï¿œ accurata a lungo termine (t > 3-4 sec) ma nel breve 
periodo (t < 500 ms) presenta dei ritardi e degli spike dovuti ai motori 
nelle vicinanze
* il rate-gyro ï¿œ accurato nel breve periodo e per movimenti non troppo 
lenti ma a lungo andare puï¿œ perdere di accuratezza a causa della soglia 
di rumore
Il filtro dovrebbe risolvere (o almeno attenuare) queste pecche 
prendendo quindi le caratteristiche migliori di ciascun sensore.
Mi piacerebbe inoltre non dover impostare il riferimento al rate-gyro ma 
che si allineasse autonomamente alla bussola a lungo termine.
Un filtro passa basso + passa alto non mi sembra una buona idea perchï¿œ 
aggiungerei alla bussola ulteriori ritardi che renderebbero piï¿œ 
instabile in sistema...
Avete qualche suggerimento?
Grazie
Marco

 instabile in sistema...
Non hai detto qual ï¿œ la frequenza di campionamento e qual ï¿œ il ritardo 
"ammissibile". Sinceramente non vedo alternativa al filtraggio 
passabasso/alto. Ovvio che vanno pensati bene.
Tieni presente che se usi due filtri complementari, questi hanno lo 
stesso ritardo di gruppo (costante se ï¿œ un FIR "finestrato"). Perï¿œ se 
dici che la bussola ha dei ritardi (evidentemente ï¿œ giï¿œ filtrata di suo) 
puï¿œ valer la pena avere due filtri non complementari per compensare i 
ritardi, al limite tenendo solo un passa alto sul giroscopio (che 
ritarda ed elimina le derive). Hai sottomano le risposte in frequenza?
Ciao
Pasu

 Hai sottomano le risposte in frequenza?
Il datasheet dell'ADXRS150 da una banda passante a -3db intorno ai 40 
Hz. Per bussola, una HMR3200, non ho molti dettagli ma se ben ricordo il 
campionamento interno ï¿œ intorno ai 15 Hz, poi filtrato a circa 5 Hz.
Ma che la bussola sia lenta mi fa solo piacere perchï¿œ mi serve 
unicamente per tenere la rotta quando vado dritto. Viceversa le piccole 
variazioni le vorrei leggere (e ci riesco) con il giroscopio.
Mi rimane solo di "sommare" i due valori cosï¿œ che il risultato finale 
sia migliore. Da quello che ho letto la strada sono proprio i Kalman 
filter, ma non ho trovato un esempio adatto al mio caso nï¿œ software di 
progettazione.
Penso infatti che se riuscissi ad avere un dato di heading accurato e 
veloce, poi si tratta "solo" di tarare bene il PID. Adesso come adesso 
invece anche con una guida manuale ï¿œ difficile tenere la rotta a causa 
delle continue oscillazioni della bussola.
Marco

 delle continue oscillazioni della bussola.
Ehm... Mi sa che stai dando un po' troppe informazioni per scontate... O 
erano in un tuo post precedente?
Ciao
Pasu

 erano in un tuo post precedente?
Scusa, probabilmente pensavo di aver fornito informazioni sufficienti. O 
meglio, come al solito ho chiesto aiuto su una soluzione specifica non 
descrivendo l'intero contesto.
Comunque ï¿œ presto fatto: ho un veicolo subacqeuo quasi stabile sugli 
assi di rollio e beccheggio dotato quindi di un unico rate-gyro 
sull'asse di imbardata. In aggiunta c'ï¿œ appunto la nostra bussola.
La propulsione ï¿œ gestita da alcuni motori in DC. Il controllo puï¿œ essere 
manuale o semi-automatico (mantenimento prua e/o profonditï¿œ).
Al momento l'unica cosa che ancora andrebbe migliorata ï¿œ proprio il 
controllo automatico della prua a causa dei problemi descritti sopra: il 
segnale di feedback (ora dato dalla bussola) ï¿œ troppo lento/rumoroso 
perchï¿œ il PID lavori decentemente (*).
Forse ingenuamente pensavo che se questo valore venisse migliorato 
(maggiore stabilitï¿œ, maggiore banda passante grazie all'aiuto del gyro) 
avrei un anello di regolazione piï¿œ efficace.
Marco
(*) c'ï¿œ anche da dire che potrei essere io a non saper tarare il PID, ma 
dato che quello per il mantenimento della profonditï¿œ va che ï¿œ una 
meraviglia penso che qualche problema sul segnale di heading ce l'ho!

 avrei un anello di regolazione piï¿œ efficace.
Non mi sembra un'idea tanto ingenua...
Ciao!
P.

 Non mi sembra un'idea tanto ingenua...
Il buon Tim Wescott che giï¿œ mi ha aiutato in passato mi ha suggerito 
proprio quello che pensavo di evitare: un semplice passa basso + passa 
alto del primo ordine.
Lui dice:
"considera che hai due misure dello stesso segnale:
ra = x + na
rb = x + nb
filtrandole opportunamente si avrebbe:
x_est = H * ra + (1 - H) * rb
ma noi abbiamo
ra = x + na     (compass)
rb = dx/dt + nb (gyro)
quindi facciamo un terzo segnale:
rc = rb / s
rc = x + nb / s
da cui:
x_est = H * ra + (1 - H) * rc"
In pratica se ho ben interpretato utilizzando appunto un passa basso per 
la bussola (che ha rumore sulle alte frequenze ma ottime qualitï¿œ a lungo 
termine) e un passa alto sul gyro integrato (che fa viceversa) tale per 
cui dato H il passa basso abbiamo 1-H come passa alto. Cosï¿œ dovremmo 
ricostruire decentemente il segnale x.
Da un punto di vista intuitivo penso possiamo dire che il rate-gyro va a 
modificare il segnale della bussola solo durante le rotazioni cosï¿œ da 
"aiutarla" a essere piï¿œ precisa.
Marco

 "aiutarla" a essere piï¿œ precisa.
O piï¿œ rapida, se non piï¿œ precisa...
Ciao!
Pasu

 Un filtro passa basso + passa alto non mi sembra una buona idea 
 > perchï¿œ aggiungerei alla bussola ulteriori ritardi che renderebbero
 > piï¿œ instabile in sistema.
Perï¿œ non avevo considerato di eliminare il filtro interno alla bussola e 
di utilizzare i due complementari.
Marco

 di utilizzare i due complementari.
Insomma tra tutti e tre (mi ci metto anch'io, via) un po' per uno 
qualcosa di giusto l'abbiamo detto :-)
Buon divertimento (e buona fortuna) con tutti i tentativi!
Pasu

 Marco
argomento interessante, piu' tardi leggo i datasheet.
premesso che la teoria dei filtri non e' il mio forte, non credo che
possano essere usati semplici passa_alto e passa_basso , perche' dopo la
somma (non algebrica) il guadagno non sarebbe unitario su tutta la
banda; piuttosto userei qualcosa tipo 2 segnali variabili complementari
0_100% di gain applicati ai due segnali prima della somma; credo che in
digitale si possa fare con due linee di ritardo di enne campioni ed enne
parametri impostabili che stabiliscono il peso dei campioni.
per il pid vado meglio: il segnale setpoint e' perfettamente pulito ?
se non lo e' , e puo' disturbare il pid, deve essere filtrato; in questa
applicazione in cui non e' necessaria una risposta velocissima alla
variazione di setpoint, una cosa che puo' aiutare e' portare fuori il
setpoint dalla derivativa, ovvero eseguirla solo sul segnale posizione.
hai scelto una adeguata base dei tempi ?  a spanne dovrebbe essere una
frazione del periodo di oscillazione del sistema; se la imposti troppo
veloce, il segnale derivativa diventa piccolo e viene sommerso dal
rumore; se la imposti troppo lenta, non riesci a fermare la
pendolazione.
hai preso provvedimenti per evitare la saturazione dell' integrale ?
e per garantire che il segnale out arriva al 100% nonostante il rumore ?
e per eliminare la eventuale isteresi dell' attuatore ?
l' attuatore ha risposta lineare oppure deve essere corretto in senso
esponenziale oppure logaritmico ?
per la bussola: se lavori sugli ultimi 3 campioni scartando il valore
piu' sballato e mediando gli altri 2, lo spike sparisce (ma solo se e'
davvero uno spike).
saluti
-- 
  lowcost

 davvero uno spike).
Io li chiamo spike, ma sono piuttosto dei disturbi che come dicevo 
durano fino a un paio di secondi in presenza di variazioni consistenti 
del regime dei motori.
Buona domenica!
Marco

 del regime dei motori.
allora quanto ho detto non funziona.
saluti
-- 
  lowcost

 si linearizza la risposta.
Giusto. Ma si guadagna davvero molto in termini di prestazioni 
sull'anello di controllo? Inoltre, secondo te ci vuole proprio un 
esponenziale o posso pensare di cavarmela con una polinomiale, magari 
con una semplice quadratica?
Marco

 con una semplice quadratica?
ho sempre usato roba semplice, quadrati + complementi + medie.
guardando le curve controlvoltage/thrust si vede la nonlinearita', che
in questo caso e' troppo sensibile in alto.
saluti
-- 
  lowcost

 passato ed il "futuro", quindi l'uscita viene ritardata di un campione.
Domanda attinente al thread anche se non sapevo bene dove agganciarmi.
Quando devo filtrare la bussola devo stare attento che la sua uscita ï¿œ 
compresa tra 0 e 360 e il rollover porterebbe a un salto fittizio di 360 
ovviamente non gradito dal filtro.
Quale trucco semplice si puï¿œ usare per ovviare a questo senza scomodare 
FSM o altre diavolerie? :)
Grazie come sempre dei suggerimenti!
Marco

 FSM o altre diavolerie? :)
Mi ï¿œ venuta fuori una cosa cosï¿œ:
if (HMR3300.hdg > 270 && ROVDATA.hdg < 90)
    ROVDATA.hdg = (int) iir_update(&iir_low_pass, HMR3300.hdg + 360)
else if (HMR3300.hdg < 90 && ROVDATA.hdg > 270)
    ROVDATA.hdg = (int) iir_update(&iir_low_pass, HMR3300.hdg - 360)
if (ROVDATA.hdg >= 360) ROVDATA.hdg -= 360;
if (ROVDATA.hdg < 0   ) ROVDATA.hgd += 360;
Dove HMR3300.hdg ï¿œ il segnale di ingresso e ROVDATA.hdg ï¿œ il valore 
corrente del filtro.
A occhiometro dovrebbe fare il suo mestiere.
Marco

 A occhiometro dovrebbe fare il suo mestiere.
Troppo facile :(
E i campioni memorizzati nella linea di ritardo dove li lasciamo?
Snort.
Marco

 ovviamente non gradito dal filtro.
Secondo me il miglior modo di risolvere un problema ï¿œ non porselo :-)
Non puoi rappresentare il tuo angolo su tutta la risoluzione disponibile?
Esempio se usi un int (con segno) fai in modo che questo rappresenti
180ï¿œ-eps=0x7FFF (32767)
-180=0x8000 (-32768)
dove eps ï¿œ la risoluzione (eps=0x10000/360)
In questo modo sfrutti l'overflow per fare il tuo rollover (ma come parlo?)
Altrimenti penso che l'unica via di scampo sia fare il controllo del 
range ogni volta che memorizzi un angolo.
Ma il filtro iir del tuo post piï¿œ sotto serve (anche) per questo?
Ciao
Pasu

 Ma il filtro iir del tuo post piï¿œ sotto serve (anche) per questo?
Si, esatto. Anche :)
Nel senso che vorrei provare a pasticciare un po' e provare varie 
soluzioni. Quindi da un lato cerco un'implementazione "generica" di 
filtri FIR/IIR, dall'altro vorrei capire come filtrare dati del genere...
Ciao!
Marco

 Per tutti i campioni memorizzati nella linea di ritardo del filtro!?
Sï¿œ, non mi sembra un compito cosï¿œ oneroso...ï¿œ solo un controllo per 
campione.
Per il filtro IIR magari piï¿œ tardi intervengo anch'io nell'altro post :-)
Da profano comunque ci andrei cauto ad  usare un IIR in un sistema di 
controllo, ma capisco che l'efficienza e il basso ritardo di gruppo 
(anche se per niente costante in frequenza e se scegli bene il filtro) 
sono caratteristiche allettanti.
Ciao
Pasu

 sono caratteristiche allettanti.
Spesso ho utilizzato un IIR a singolo polo per filtrare dati in ingresso 
e ha sempre lavorato ottimamente. In realtï¿œ io vedo (forse sbagliando) i 
FIR come un caso particolare di IIR in cui non ci sono poli... Quindi la 
mia funzione "universale" dovrebbe funzionare anche per i FIR se i 
coefficienti del denominatore sono tutti 0...
Marco

 Non vedo come il filtro possa filtrarli correttamente...
Hai ragione, non funziona. :-(
Mi sembrava un po' troppo bello per essere vero
P.

 Mi sembrava un po' troppo bello per essere vero
Tim Wescott mi ha proposto un sistema intrigante, ma devo vedere se puï¿œ 
funzionare.
Lui dice di spalmare la rappresentazione dell'angolo su tutto ad INT_MIN 
a INT_MAX cosï¿œ da fare in modo che l'overflow porti automaticamente al 
rollover del dato.
Perï¿œ ritengo piï¿œ facile seguire la strada di prima: controllare ogni 
campione memorizzato fino a che rientrano tutti tra 0 e 360 ed 
eventualmente sommare o sottrarre 360.
M

 rollover del dato.
Mi prendi in giro? Non ï¿œ esattamente quello che intendevo io? L'unica 
differenza ï¿œ che io (non so perchï¿œ) ho voluto usare interi con segno.
P.

 differenza ï¿œ che io (non so perchï¿œ) ho voluto usare interi con segno.
Ops...
No scusa, non ti prendo in giro :)
E' che mi ero perso con tutte le varie proposte... ho riletto il thread 
e mi sono accorto che allora non avevo (ho) capito un tubo.
Sorry :(
Marco

 Sorry :(
No probs, anche perchï¿œ come abbiamo visto l'idea ï¿œ bella ma non funziona :)
P.

 rollover del dato.
esatto!   peccato, arrivo tardi.
ehm, inoltre la stessa variabile signed che contiene -180_+180
(no, quasi +180) puo' essere vista anche come unsigned 0_360
(no, quasi 360) senza nessuna conversione.
se penso a qualcosa di matematico come una derivata o una media,
mi viene da ridere.
saluti
-- 
  lowcost

 mi viene da ridere.
In che senso? Mi sento ottuso... :(
Marco

> mi viene da ridere.
 > In che senso? Mi sento ottuso... :(
nel senso che
media: (360+0)/2 = 180      (dovrebbe essere ~zero)
derivata: (360-0)/T = 180/T  (dovrebbe essere ~zero)
Ciao
Pasu

 possano essere (a parte ovviamente se scegli factor=1)...
Spe' un momento, Tim diceva anche lui tra -180 e +179.9 (fammelo 
scrivere cosï¿œ il limite superiore)
Quindi se y_t=0x7FFF (+179.9) e x_t=0x8000 (-180)
y_t=0x7FFF + (0x8000-0x7FFF)/2
    =0x7FFF + (0x8000+0x8001)/2 = 0x8000
funziona!
P.

 funziona!
Oggi sono in azienda.. se mi lasciano lavorare su questo ROV ci provo :)
Grazie a tutti!
Marco

 funziona!
Confermo funziona :)
Ora devo cercare di realizzare il complementare passa-alto e poi provare 
tutto l'ambaradan!
Marco

 In che senso?
nel senso che in questa algebra polare che impone il modulo sempre
uguale a 1, anche una semplice somma rischia di prendere una grossa
cantonata, se gli addendi hanno valori particolari.
pero' questa matematica complessa mi trova refrattario.
applicando il buon senso dell' artigianello brianzolo, per evitare le
complicazioni, userei il segnale gyro solo per la derivativa del pid (se
davvero necessario) ed il segnale bussola per tutto il resto.
saluti
-- 
  lowcost

 davvero necessario) ed il segnale bussola per tutto il resto.
Anche questo l'aveva giï¿œ proposto Pasu. Appena avrï¿œ possibilitï¿œ di 
lavorarci sopra nuovamente tenterï¿œ anche questa strada.
Il problema ï¿œ che la bussola risente troppo dei disturbi dei motori 
quindi avrei comunque un segnale sbagliato in ingresso al regolatore.
Proverï¿œ anche a usare il gyro come azione derivativa ma, forse 
sbagliando, mi da l'idea di essere troppo limitato come contributo.
Cioï¿œ, il derivatore sarebbe ottimo ma il proporzionale e l'integratore 
lavorerebbero su segnali "sballati". E in un PID mi hanno insegnato che 
le componenti dominanti sono proprio la P e la I (o mi hanno raccontato 
frottole?).
Per farti un esempio oggi ho provato a usare il solo gyro (integrato) ed 
era uno spettacolo, stabile e preciso. La bussola invece ï¿œ lenta e 
disturbata.
Comunque ho realizzato (spero correttamente) i due filtri passa-basso e 
passa-alto e ho sommato le uscite. La situazione un po' ï¿œ migliorata 
anche se non ï¿œ come la vorrei.
A questo aggiungi pure che sono incompetente nella taratura del PID (che 
sto cercando di fare alla Ziegler-Nichols). Insomma, da imparare ho tanto :(
Marco