3. Collaudo e Software
Una volta realizzata l’unità elettronica, mediante i tradizionali strumenti da banco, si è provveduto al suo collaudo. Quindi si è passati alla messa a punto del firmware utilizzato dal microcontrollore per la lettura dei sensori. Per permettere all’utente di interfacciarsi con il sistema tramite PC è stata realizzata una piattaforma software in ambiente LabView, con i vantaggi di una potenza calcolo illimitata ed una e un’analisi semplificata dei dati, nella ricerca della configurazione finale dell’algoritmo di controllo, prima del trasferimento su veicolo. Le parti di codice relative al firmware del microcontrollore e descritte in questo capitolo sono riportate nell’appendice D.
3.1 Il Banco Prova
Per le prove in laboratorio è stato utilizzato un banco di lavoro per la sospensione che permette di studiarne le caratteristiche, caricandola con opportuni pesi. Il banco è costituito da tre piatti orizzontali: quello superiore funziona da piano di carico ed è libero di scorrere lungo quattro guide verticali.
L’impiego del banco prova ha permesso un comodo utilizzo dei classici strumenti di misura da laboratorio per il collaudo della scheda di controllo e la valutazione si alcune grandezze caratteristiche del sistema.
Si è proceduti anche con una seconda realizzazione della scheda hardware che, una volta collaudata, è stata montata su veicolo e resa operativa.
Figura 3.2 Istallazione dell'unità controllo nel sottosella.
3.2 Acquisizione dei dati
Durante le prove sperimentali i segnali vengono inviati e acquisiti su PC tramite tecnologia bluetooth.
I messaggi inviati dal microcontrollore sono relativi allo stato del driver di potenza, ai sensori e agli interruttori .
I segnali analogici provenienti dal sensore potenziometrico, dalla batteria, dalla resistenza di sense per la lettura della corrente assorbita dall’attuatore e dal TD340 per il monitoraggio della temperatura del driver arrivano al microcontrollore che ne effettua una conversione in digitale tramite il suo convertitore A/D con frequenza di campionamento pari a 1 Khz.
Figura 3.3 Temporizzazione del convertitore A\D SAR a 8 bit.
Il segnale di clock utilizzato dall’ADC è stato settato a 666,7 khz. Trattandosi di un SAR a 8 bit, il convertitore impiegherà 12 µs per la conversione di ogni dato a cui va aggiunto Tsample(= TADCclock). Considerando infine un Tsetup pari a 4 µs, per
un ciclo completo della nostra funzione, che abbiamo visto prevedere 4 conversioni, saranno necessari 70 µs.
I dati riguardanti la velocità e i giri del motore dell’attuatore, provenienti da sensori di hall, vengono invece ricavati dalla frequenza degli impulsi andando a utilizzare i moduli PCA del microcontrollore in modalità capture.
Per quanto riguarda i giri del motore, poiché il sensore di hall è relativo, gli impulsi vanno contati tenendo presente l’informazione legata alla direzione di rotazione del motore settata dal microcontrollore (dir_m ).
La velocità viene invece misurata andando a calcolare il tempo intercorso tra l’arrivo di due impulsi del sensore di hall situato sul cerchione. A tal proposito bisogna precisare che la base dei tempi utilizzata dal modulo PCA si basa sul segnale proveniente dall’overflow del timer0. In questo caso il timer0 è usato come contatore a 8 bit (TL0) che viene caricato ad un certo valore iniziale (contenuto nel registro TH0). Allora, ricordando il periodo necessario ad ciclo macchina in caso si lavori in modalità X2, il segnale di clock del PCA avrà periodo:
/6) (F TH0) -(256 = T0 * TH0) -(256 = TPCA osc clock clock
Figura 3.4 Schema del contatore in mode 2
La scheda comunica con l’esterno tramite una porta seriale UART con baud rate pari a 38400. Su questa sono disponibili tutte le informazioni già descritte ordinate in un unico pacchetto che viene inviato su PC tramite trasmettitore wireless Bluetooth (Tabella 3-1). Il pacchetto dati viene aggiornato ogni 20 ms.
# bytes Dato
1 Byte di start
2 Stato L (indica stato del microcontrollore)
2 Corsa
4 Giri precarico
2 Corrente
2 Batteria
4 Delta_tempo (per calcolo velocità)
2 numero cicli contati (per calcolo velocità)
2 Temperatura TD340
1 Stato H (indica stato del microcontrollore)
1 Stato algoritmo
2 ---
2 Livello precarico
2 Nuovo livello precarico
1 Byte di stop
3.3 Controllo remoto
Per una lettura più immediata dei dati è stato sviluppato in ambiente LabView un pannello che permette all’utente il check-up del veicolo e il controllo della ECU.
Figura 3.5 Pannello LabView realizzzato per il test del sistema.
Al centro, nella parte stato veicolo, si possono leggere :
− la velocità (in km/h),
− la tensione di batteria (in volt),
− lo stato del cavalletto laterale,
− la corsa della sospensione (in cm).
Mentre nella parte dedicata all’attuatore vengono monitorate:
− la temperatura del driver TD340,
− i giri fatti dal motore dell’attuatore,
Il controllo del sistema può essere a sua volta locale o remoto.
Se si é in modalità remoto il microcontrollore riceve i comandi da LabView; tale situazione è utile in primo momento, durante la ricerca della strategia di controllo poiché ci permette in modo agevole di cambiare algoritmi e parametri alla ricerca del settaggio migliore.
Figura 3.7 Particolare del pannello: sezione per il controllo remoto.
I principali comandi che possono essere inviati al microcontrollore sono:
− O: apre il logging;
− C: chiude il logging;
− R: abilita il controllo remoto;
− I: chiude il controllo remoto e abilita il controllo automatico; e se siamo in remoto operazioni che possono essere fatte sono:
− A: azzera precarico;
− M: accende il motore (deve essere seguito da “+” o ” –“ per la direzione);
− S: setta il precarico (deve essere seguito da un numero compreso tra 0 e 7, che sta ad indicare il livello di precarico).
Per il controllo del motore è stata implementata sul microcontrollore una macchina a 3 stati:
−IDLE_CTRL: controlla i comandi ricevuti (azzera precarico, attiva motore, setta precarico);
−RESET_CTRL: resetta le variabili di controllo;
Una volta definito l’algoritmo di settaggio del precarico, per la sua validazione, viene trasferito su microcontrollore.
In questa fase viene monitorato lo stato in cui si trova il microcontrollore.
Per fare ciò vengono visualizzate sul pannello le informazioni relative allo stato dell’algoritmo interno e alcuni flags inviati nel pacchetto e divisi in 2 bytes, stato_L e Stato_H (Tabella 3-2).
Bit Stato_H Stato_L
0 stato_algoritmo_0
(non significativo) cmd_m
1 Stato_algoritmo_1
(non significativo) stato_m
2 Stato_algoritmo_2
(non significativo) dir_m
3 Stato_algoritmo_3
(non significativo)
cav: stato del cavalletto laterale 4 Setting fine_corsa: ‘1’ in caso di precarico minimo o massimo 5 Set Leggi 6 vel_inrange: ‘1’ se la velocità e nell’intervallo impostato Setta: ‘1’ durante il settaggio 7 Done errore
Tabella 3-2 Flags per il controllo dell’algoritmo.
3.4 Esecuzione di processo
Il corpo principale del programma si divide nell’esecuzione di 6 tasks da parte del microcontrollore: una volta lette le informazioni ricevute sulle porte d’ingresso, il microcontrollore calcola il nuovo stato del nodo ed esegue il controllo del sistema.
1. lettura ingressi locali: legge le informazioni ricevute sulle porte d’ingresso; 2. calcolo nuovo stato nodo;
3. controllo: esegue il controllo del sistema (vedi anche Capitolo 4);
4. scrittura uscite locali: scrive i comandi da inviare al driver TD340 per la gestione dell’attutore;
5. invio pacchetto: esegue la funzione logging vista in precedenza; 6. idle : attende un tick di sistema;
La gestione dei tasks avviene per mezzo di uno scheduling ciclico,che si ripete ogni 10 ms, compatibile con l’esecuzione dei tasks.
LETTURA INGRESSI LOCALI
CALCOLO NUOVO STATO NODO CONTROLLO SCRITTURA USCITE LOCALI INVIO PACCHETTO IDLE
