Pid Di Velocità Con Encoder Incrementale - Un problema diffuso e importante

[gianni.tenca]

Ciao a tutti.

Per la mia tesi sto implementando un controllo in retroazione di velocità su un motore azionato da un inverter vettoriale.

Uso un PC in real-time (ma il mio problema si può applicare anche ai PLC) per fare una retroazione di velocità molto precisa sfruttando il segnale di posizione dell'encoder (che incrementa il contatore di una scheda di acquisizione PCI montata nel PC).

Il mio problema, sicuramente molto comune, è che calcolando la velocità del motore a partire dalla posizione, ottengo delle oscillazioni "fittizie" di velocità dovute alla natura discreta del segnale di posizione.

Un esempio per capirci: motore a velocità costante, leggo dopo 2ms la posizione, il contatore si è incrementato rispetto alla lettura precedente di 20 (i fronti di salita dell'encoder incrementale), ma il motore è avanzato di 20.2 punti in realtà. Così dopo 5 periodi troverò un avanzamento di 21 punti dato dalla somma delle parti frazionarie che vanno accumulandosi anche se in verità la velocità è sempre rimasta costante. Basta mettersi giù con carta e matita e si capisce che è davvero così!

Ciò genera oscillazioni periodiche di velocità non reali. Il tutto si complica a velocità non costante.

Immagino che in tanti si siano trovati di fronte a quest problema e vorrei sapere qual'è la soluzione più comunemente adottata:

- Filtraggio digitale con le Z-trasformate delle oscillazioni? (Non molto efficace)

- Metodi di derivazione numerica più raffinati?

- Ricostruzione del segnale prima di derivare? (Ma ha senso ricostruire un segnale già di per sè falsato?)

Ricordatevi che io lavoro con LinuxRT quindi non posso usare linguaggi di programmazione di alto livello che abbiano già routine preposte alla elaborazione dei segnali.

Qualunque aiuto o indicazione di materiale da leggere è ben accetto!

[Livio Orsini]

Primo: ho spostato la discussione nel forum specifico. Se posti nel forum specifico è più facile ottenere risposte adeguate.

Poi il problema specifico.

Non ho capito se il problema che segnali è un problema di sola misura o investe anche la regolazione.

Che ci sia un errore di misura dovuto alla quantizzazione ed al troncamento è inevitabile. Importante è minimizzarlo in modo che sia ininfluente.

Ho almeno tre decdi di esperienza in merito, ho realizzato regolatori solo HW e regolatori HW+FW. Il problema che denunci esiste ma è ininfluente ai fini pratici.

I problemi maggiori s'incontrano alle basse velocità di rotazione dove è più conveniente misurare il periodo tra due impulsi consecutivi di encoder. Poi salendo di velocità la misura del periodo si fa più imprecisa e conviene misurare la frequenza. L'algoritmo ottimale tiene conto di tutte e due le misurazioni e scarta la meno precisa.

Per chiudere l'anello partendo dalla posizione, che credo sia il tuo caso, io ho sempre usato im approccio diverso. Genero la posizione ideeale (teorica) e la confronto con la posizione reale. Se ben progettato e realizzato questo tipo di algoritmo annulla quasi totalmente l'effetto di quantizzazione che denunci. E' simile all'amplificazione differenziale: non elimina il rumore ma ne minimizza gli effetti.

Se invece devi solo misurare la velocità il problema si risolve filtrando adeguatamente. Si va da semplici passa basso a medie su finestre scorrevoli (slide windows come vengono di solito chiamate nella letteratura specifica),

Tieni conto che più complichi l'algoritmo per eliminare l'influenza degli errori di campionamento più rafforzi la componente degli errori di troncamento.

Modificato: 26 ottobre 2004 da Livio Orsini

[Dario Valeri]

ciao

non puo' essere che il motore abbia incrementato di 20.2 ....

o 20 oppure 21 (se conti l'encoder incrementale) se invece calcoli i gradi è un altra cosa.

il motore si trova , PERO' , in una posizione intermedia (non ancora conteggiata) tra il

20esimo impulso e il 20unesimo impulso

questo non e' un errore perche' non si somma al totale.!!!(in sintesi e' come dici tu)

puoi risolvere questo, se ti da' fastidi, aumentando il numero di impulsi del encoder..

cioè aumentando la precisione del conteggio hardware.

temo, pero' di non essermi spiegato bene!

ciao

dario

[Livio Orsini]

non puo' essere che il motore abbia incrementato di 20.2 ....

o 20 oppure 21 (se conti l'encoder incrementale) se invece calcoli i gradi è un altra cosa.

Dario, forse non hai ben presente il problema di "gianni.tenca".

Effettua un campionamento a periodo fisso. Nell'esempio riportato per 4 compionamenti si leggono 20 impulsi di differenza, al quinto campionamento se ne leggono 21. Apparentemente la velocità ha subito una variazione del 5%, effettivamente la velocità è costante e la differenza è dovuta all'erore di quantizzazione che si integra e si recupera istantaneamente.

E' un tipoco problema dei regolatori numerici, come lo è l'errore di troncamento.

Si possono progettare algoritmi che ne minimizzino l'effetto. Per esempio nei regolatori di velocità uno dei metodi è effettuare la regolazione come se si trattasse di un PLL (Phase Locked Loop).

[Dario Valeri]

ciao

si , avevo capito questo , infatti temevo di non esser riuscito a spiegarmi.

ciao

dario

[gianni.tenca]

Grazie mille, Dario e Livio, per la vostra tempestività e pertinenza! Se tutti i forum fossero così...

La tua risposta, Livio, è molto precisa; forse, però, è necessario aggiungere qualche informazione per spiegare perchè per me questo problema non è trascurabile.

1) Il mio obiettivo è studiare leggi di moto che, inserendo una componente armonica di oscillazione nella velocità, permetta di minimizzare l'usura nelle bronzine di un meccanismo azionato dal motore. Quindi devo ottenere un controllo molto preciso con alcune variazioni di velocità al giro.

2) Il motore è collegato senza un riduttore al meccanismo quindi sono obbligato a lavorare a velocità basse.

3) Quell' incremento di 1 punto ogni tot periodi, per il mio encoder (max 2048 p.ti a giro) e il mio periodo di controllo, significa avere un +14 rpm che potrebbe essere fastidioso per le mie leggi.

4) La frequenza caratteristica di questa oscillazione può essere qualsiasi (dipende dalla parte frazionaria), al variare della velocità. L'aliasing quindi renderà questo "disturbo" sovrapposto alla mia legge di moto almeno a certe velocità.

Devo ammettere di non aver capito bene la risposta di Livio sul controllo misurando il periodo tra segnali di encoder. Dovrei aver la possibilità di installare un interrupt per misurare il tempo di sistema tutte le volte che il contatore si incrementa per poter calcolare il periodo tra due incrementi consecutivi? Se è così, allora penso di non poterlo fare perchè non posso raggiungere tempi di risposta così rapidi.

(In effetti la scheda di acquisizione Sensoray 626 non ha ancora driver per linux RT quindi in attesa di trovarlo da qualche parte lavoro in soft real-time: so che non è molto adatto all'applicazione ma funziona molto meglio del previsto: in università ci si arrangia sempre con quello che si ha)

A parte questo apprezzo molto il consiglio di fare il controllo direttamente sulla posizione. In effetti ci avevo pensato anche io ma senza molta convinzione perchè mi interessavano leggi di velocità (anche se basta integrare la legge di moto di velocità per averla di posizione), perchè pensavo di poter risolvere il probelma con algoritmi solo un pò più complessi.

Hai ragione, Livio, posso raggiungere l'obiettivo con il controllo di posizione: l'unico dubbio resta nella stabilizzazione un pò complicata perchè con l'anello di posizione di fatto il modello del sistema presenta un polo doppio nell'origine.

Ciao.

Gianni.

[Livio Orsini]

....un pò complicata perchè con l'anello di posizione di fatto il modello del sistema presenta un polo doppio nell'origine..

Mhh, di pende da come realizzi il controllo. Tieni presente che il controllo è...stupido. Lui regola in velocità ma non lo sa. E' un po' come i vecchi modulatori di frequenza: si midulava la fase per ottenere la modulazione di frequenza.

...Dovrei aver la possibilità di installare un interrupt per misurare il tempo di sistema ...

In effetti è necessario che scatti un interrupt sul fronte dell'impulso in modo da far partire un contatore, che conta un clock preciso e di frequenza la più elevata possibile. Il contatore verrà letto sul fronte del prossimo impulso.