Ricostruzione in tempo reale delle forze di contatto strada-pneumatico

Author(s):
R. Zavaglio - TESI

Industry:
Automotive, ATE/Instrumentation

Products:
Real-Time Module, LabVIEW, FPGA Module, CompactRIO

The Challenge:
Realizzare un sistema funzionante in tempo reale in grado di acquisire i segnali provenienti dalle quattro ruote di un veicolo ed elaborarli utilizzando pre-esistenti algoritmi di proprietà Pirelli in modo da ricostruire le forze di contatto pneumatico-strada.

The Solution:
L’utilizzo del prodotto NI CompactRIO (cRIO) ci ha permesso di suddividere l’esistente algoritmo di ricostruzione in due parti in modo da sfruttare tutta la potenza dell’FPGA nel campionamento sincrono delle quattro ruote e nella preparazione dei segnali in una forma adatta ad una ricostruzione efficiente. Con i dati così preparati si è potuto implementare sul controllore real time un algoritmo di ricostruzione robusto e veloce.

Introduzione
Nel punto di contatto tra la ruota di un veicolo in movimento e la strada nascono forze che sono di fondamentale importanza per determinare la sicurezza delle condizioni di marcia. Sfortunatamente, ad oggi, non esistono metodi applicabili su larga scala (cioè non solo su costosi prototipi) per una misura diretta di queste forze; ci si deve quindi accontentare di stime ricavate dal modello dinamico complessivo del veicolo.
Pirelli Pneumatici, in collaborazione con il dipartimento di meccanica del Politecnico di Milano, ha studiato un metodo innovativo, denominato “Cyber Wheel”, per la ricostruzione delle forze di contatto ruota-strada. Il progetto si è proposto di stimare le forze in questione utilizzando i segnali provenienti da una serie di estensimetri applicati direttamente sui cerchi. Dopo una fase di studio teorico e di test in laboratorio, è stato messo a punto, da Pirelli Pneumatici, un modello adatto alla ricostruzione delle forze ed è stata definita una procedura di calcolo in grado di stimare “off line” tali forze. Si è poi trattato di rendere il modello funzionante in tempo reale sul veicolo attraverso l’implementazione dell’algoritmo di calcolo su un sistema hardware in grado di soddisfare le richieste di velocità e recisione necessarie al buon funzionamento dell’algoritmo. L’autore di questo articolo ha partecipato all’implementazione dell’algoritmo sull’hardware prescelto (cRIO) occupandosi della ricollocazione dell’algoritmo di ricostruzione delle forze di cui verrano discussi gli aspetti implementativi più interessanti.

La scelta dell’apparecchiatura
L’algoritmo doveva soddisfare alcuni semplici requisiti di velocità, che sarebbero stati impossibili da raggiungere se si fosse mantenuta la formulazione del modello utilizzata per lo sviluppo teorico, adatta per una analisi a lotti da eseguire fuori linea.
Si è dovuto quindi ingegnerizzare la parte di acquisizione e di preparazione dei valori acquisiti in modo da renderla efficiente e applicabile a una versione ricorsiva dell’algoritmo.
In questa fase di ingegnerizzazione del modello ci si è resi conto che l’algoritmo poteva essere spezzato in due parti praticamente indipendenti, di cui la prima aveva tutte le caratteristiche per essere implementata in maniera efficiente su un target di tipo FPGA, mentre la seconda, contenendo la maggior parte delle operazioni matematiche in virgola mobile, doveva essere implementata su un processore più versatile.
A questo punto la scelta dell’apparecchiatura è ricaduta su CompactRIO che, per la presenza sia dell’FPGA che del controllore Real-Time, si adatta perfettamente alle caratteristiche di questa nuova versione dell’algoritmo.
Per consentire l’acquisizione dei segnali provenienti dai sensori, cRIO è stato corredato di quattro moduli di acquisizione analogica a quattro canali con campionamento simultaneo. Ognuno dei moduli gestisce una ruota acquisendo i tre segnali provenienti dai sensori e il segnale di sincronizzazione.

L’algoritmo di campionamento
Il modello di ricostruzione delle forze necessita di un numero costante di campioni per ogni giro della ruota, che durante la marcia del veicolo varia continuamente la propria velocità di rotazione. Campionare a frequenza costante per poi interpolare i dati comporterebbe un eccessivo appesantimento dei calcoli e la necessità di disporre di una notevole quantità di memoria da utilizzare per le velocità più basse. Si è quindi pensato di realizzare un campionamento a frequenza variabile con inseguimento della velocità di rotazione. Questo metodo ci permette di compensare le variazioni di velocità in maniera efficiente mantenendo costante il tempo di calcolo e l’occupazione di memoria per un ampio spettro di velocità del veicolo (da 10 a 250 Km/h).
Il principale vantaggio del campionamento a frequenza variabile è quello di eliminare l’effetto della velocità sulla risposta in frequenza del sistema: questo ci permette tra l’altro di realizzare un filtro anti-aliasing efficiente senza l’utilizzo di particolari accorgimenti.
L’algoritmo di campionamento comprende una parte per il riconoscimento di un punto che caratterizzi l’inizio del giro ruota in base al quale, utilizzando le velocità e le accelerazioni dei giri precedenti, viene calcolata la sequenza temporale dei successivi campioni da acquisire.
Allo scadere di ognuno dei tempi calcolati, viene eseguita l’acquisizione dei segnali, il prefiltro anti-aliasing e il salvataggio dei valori su due banchi di memoria utilizzati alternativamente per consentire un’acquisizione continua anche durante il trasferimento dei dati al controllore real time.
Va notato che le ruote non girano tutte alla stessa velocità, quindi l’algoritmo deve essere suddiviso anch’esso in quattro parti indipendenti ognuna delle quali gestisce l’acquisizione da una singola ruota.
Il parallelismo viene realizzato in maniera efficiente dall’FPGA, che ci consente di eseguire il codice relativo ai cicli di acquisizione in maniera indipendente e deterministica. Poiché ogni ciclo di acquisizione utilizza un diverso modulo analogico e salva i dati su una propria area di memoria, si ottengono quattro processi completamente indipendenti.

Il trasferimento dei dati al controllore real-time
I buffer che contengono i valori acquisiti dai sensori sono fisicamente allocati sulla memoria disponibile all’FPGA; vanno quindi trasferiti al controllore real time prima che possano essere sovrascritti da nuovi valori. Per fare ciò utilizziamo un ulteriore processo residente sull’FPGA che viene avvertito della disponibilità di un banco di memoria da trasferire mediante una coda FIFO, dove i vari processi di acquisizione vanno ad accodare un messaggio ogni volta che viene completato un giro ruota. A questo punto il processo di trasferimento legge dalla FIFO i messaggi servendo in sequenza i vari processi.
I dati sono trasferiti allertando mediante interrupt un processo in attesa sul controllore real time e sincronizzandosi con il medesimo nella lettura e scrittura dei dati sui registri di interfaccia. Questo metodo, che comporta un solo interrupt per ogni blocco di dati, è stato il più veloce ed affidabile, in quanto riduce al minimo i tempi di latenza richiesti dalla gestione degli interrupt.

La ricostruzione delle forze
Il controllore real time, sollevato dalla necessità di gestire l’acquisizione e la preelaborazione dei dati, potrà essere programmato in modo da ottimizzare i calcoli necessari alla realizzazione del modello di ricostruzione delle forze. Poiché le ruote sono indipendenti, è necessario decidere come elaborare i dati di ogni singola ruota in modo da minimizzare il ritardo complessivo introdotto dai calcoli.
Il processo di trasferimento dei dati fornisce una sequenza di vettori ognuno dei quali contiene i dati acquisiti in un giro ruota. Gli istanti in cui sono disponibili i vettori di dati dipende dalla velocità e dalla posizione iniziale di ogni ruota: ne risulta quindi una sequenza temporale in continua variazione dove la probabilità di interazione degli eventi è proporzionale al tempo di calcolo.
Cosa fare se mentre si stanno elaborando i dati relativi ad una ruota anche un’altra ruota finisce il proprio giro ?
In un primo tempo avevamo preso in considerazione la possibilità di generare un processo indipendente per ogni ruota nell’intento di minimizzare il ritardo globale di ricostruzione. Ci siamo però resi subito conto che il fatto di lasciare gestire al sistema operativo la concorrenza di quattro processi tutti alla stessa priorità, che sono attivati in istanti temporali continuamente variabili, comporta non solo un aumento dei tempi complessivi di calcolo, ma anche un aumento dei tempi di trasferimento dei dati tra l’FPGA e il controllore real time. La somma di questi due effetti crea una notevole irregolarità dei tempi di ritardo complessivi (jitter) senza portare alcun vantaggio.
La gestione sequenziale con un singolo processo ad alta priorità si è invece dimostrata più efficiente. Il trasferimento dei dati di un giro e i relativi calcoli di ricostruzione vengono eseguiti senza interruzioni e solo alla fine viene controllato se un nuovo vettore di dati è disponibile per iniziare il nuovo ciclo. In questo modo si riducono i tempi necessari al sistema operativo per passare da un processo all’altro e si evita che l’allungamento dei tempi di calcolo di ogni singolo processo concorrente aumenti la probabilità che se ne inserisca un altro in parallelo incrementando ulteriormente i ritardi.
Il processo di ricostruzione delle forze si trova quindi a dover realizzare il modello in sequenza sulle quattro ruote con tempi di trasferimento e ricostruzione di 1,6 millisecondi per ruota. Ovviamente il ritardo di ricostruzione per ogni singola ruota varia in funzione dell’istante in cui quest’ultima termina il giro rispetto alle altre. Si va da un massimo di 7,5 millisecondi, nel caso di perfetto sincronismo delle quattro ruote, ad un minimo di 1,6 millisecondi, nel caso di indipendenza completa. Durante la marcia normale si è potuto valutare un ritardo medio che si aggira intorno ai 3,5 millisecondi.
Per dare un’idea delle massime tempistiche richieste, basta considerare che un giro ruota a 250 Km/h è completato in circa 29 millisecondi, il che comporta per il nostro algoritmo un ritardo medio di ricostruzione inferiore ad un ottavo di giro.
Oltre al rispetto delle tempistiche, dobbiamo valutare l’errore che introduciamo nei calcoli utilizzando l’algoritmo in tempo reale al posto dell’algoritmo a lotti che abbiamo preso come riferimento. Per poterli confrontare abbiamo applicato i due algoritmi alla medesima sequenza di dati acquisendo in parallelo sia i dati grezzi provenienti dai sensori che i valori di forza calcolati dall’algoritmo ricorsivo. Il risultato è stato decisamente positivo mostrando una sequenza di errore non correlata a media nulla e deviazione standard inferiore allo 0,05% su tutte e tre le forze.
Naturalmente questo non rappresenta l’errore di ricostruzione delle forze rispetto al valore “vero”, ma ci garantisce l’equivalenza dei due algoritmi.

Conclusioni
Implementare un algoritmo di calcolo in tempo reale differisce notevolmente dalla semplice trasposizione dei calcoli necessari alla sua versione “fuori linea” e spesso richiede una rivisitazione dello stesso in base all’hardware prescelto. Anche la scelta dell’hardware su cui l’algoritmo deve essere implementato è infatti intimamente legata all’ingegnerizzazione dell’algoritmo stesso e deve essere presa in considerazione in fase di implementazione.
Soprattutto nel caso di progetti dove le modifiche sono all’ordine del giorno, avere un sistema versatile e potente può fare la differenza nel raggiungimento del risultato finale; nel nostro caso ha sicuramente contribuito a ridurre i tempi di realizzazione consentendoci di sperimentare percorsi differenti al fine di raggiungere il risultato ottimale.

Browse All Case Studies »