CAPITOLO V
RACCOLTA E ANALISI
DEI DATI
Nel lavoro di tesi si sono affrontati problemi relativi a tutte le fasi caratteristiche di una procedura completa di riconoscimento di attività (Capitolo II): registrazione segnali e pre-processamento dati, segmentazione segnali, estrazione caratteristiche, classificazione.
Come parametro per la scelta dei sensori si è inizialmente pensato di utilizzare dispositivi che dispongano di accelerometri e con capacità di comunicare tra loro senza fili. In una procedura di riconoscimento attività infatti le comunicazioni mote-mote possono essere sfruttate per misurare il cosiddetto RSSI (Received signal stregth indication) [1], vale a dire una misura della potenza di segnale ricevuta.
La RSSI può essere sfruttata per ricavare la posizione spaziale del mote di interesse. Comunque, dopo un’ attenta analisi e considerato il caso d’esame, è stata scartata l’idea. Ciò perché lo scenario futuro del presente lavoro di tesi è rappresentato da un campo di gioco nel quale sono presenti più atleti e, dato che questi segnali
radio risentono molto degli ostacoli fisici che devono attraversare, si registrerebbero forti attenuazioni che non garantirebbero la bontà della misura.
Scelta dunque la misura di accelerazione come unica quantità da analizzare, il mote più idoneo al lavoro di tesi è risultato l’Iris (Capitolo III – Paragrafo 2), mentre il mote Telosb è stato scartato a causa di problemi di calibrazione degli accelerometri a disposizione.
Successivamente si è scelto il numero di sensori da utilizzare ed il loro posizionamento per soddisfare l’efficacia funzionale dei dati (Fig.5.1). Sia per la scelta del numero sia per il posizionamento, riferendosi ad un’applicazione reale futura, si è tenuto conto di fattori quali:
Praticità. Il numero di sensori non deve essere troppo elevato e il loro posizionamento non deve infastidire chi effettua il movimento
Efficacia. Il numero di sensori così come il loro posizionamento deve poter garantire perlomeno le misure minime indispensabili per permettere il riconoscimento di un’attività
Considerati quindi questi fattori e la vasta gamma di movimenti che può eseguire l’atleta durante un’attività calcistica, si è deciso di posizionare almeno un sensore per ogni arto ed uno sul torace
della persona, in modo da cercare di captare ogni variazione di attività e cambiamento posturale.
Fig.5.1 Posizionamento mote ed orientamento assi
Come raffigurato in Figura 5.1 la disposizione e l’orientamento spaziale dei mote è la seguente:
Mote id 2: arto gamba dx
Asse X trasversale all’arto Asse Y longitudinale all’arto
Mote id 3: arto gamba sx
Asse X trasversale all’arto Asse Y longitudinale all’arto
Mote id 4: arto braccio dx
Asse X trasversale all’arto Asse Y longitudinale all’arto
Mote id 5: arto braccio sx
Asse X trasversale all’arto Asse Y longitudinale all’arto
Mote id 6: corpo parte alta torace Asse X trasversale al corpo Asse Y longitudinale al corpo Una volta stabilito il numero di sensori da utilizzare ed il loro posizionamento, la fase successiva è rappresentata dalla registrazione effettiva dei dati.
V 1. REGISTRAZIONE E
SCARICAMENTO DATI
Per poter sfruttare la rete di nodi sensori (mote), è necessario programmarli per gestire alcune funzionalità:
Effettuare misure degli accelerometri. Effettuare comunicazioni nodo-nodo Effettuare comunicazioni nodo-sink Effettuare comunicazioni sink-PC.
A tal fine si è utilizzato un programma chiamato LOGGER, costituito da una parte di componenti NesC, necessari a gestire le varie operazioni dei
mote precedentemente elencate, ed una parte di codice Java necessaria per gestire l’interfaccia di controllo.
I suddetti componenti necessari alla programmazione dei mote sono così organizzati:
sinkAVG: parte di codice necessaria al mote id 1 collegato al PC, con funzione di sink. Vengono gestite quindi le comunicazioni PC-sink tramite seriale e le comunicazioni PC- sink-nodo tramite comunicazione radio.
loggerAVG: parte di codice necessaria ai mote id 2,3,4,5,6 posizionati sul corpo dell’atleta. Vengono gestite quindi le comunicazioni nodo-nodo ed i vari sensori presenti nella sensorboard tra cui l’accelerometro biassiale (Capitolo III – Paragrafo 2).
La loggerGUI riguarda la parte sviluppata in linguaggio Java nella quale, come già accennato, viene strutturata un’interfaccia per gestire l’intera fase di registrazione e memorizzazione dei dati in un Database PostgresSQL [2], un database relazionale ad oggetti rilasciato con licenza libera. Una volta programmati i mote viene eseguita l’interfaccia Logger GUI (Fig.5.2) attraverso la quale si imposta:
Il numero dell’esperimento. Numero progressivo per identificare una registrazione.
Tempo di campionamento (Sampling period). Tempo misurato in milli secondi al quale si considerano i dati istantanei inerenti ai sensori selezionati (accelerometro in questo caso).
La modalità di esecuzione dell’esperimento. Online data: stabilisce se mantenereattiva la connessione tra sink e mote.
Store Data: memorizzazione dei dati in memoria flash.
Broadcast: un messaggio inviato a tutti i mote collegati alla rete.
I trasduttori attivi e le misure rilevate. Trasduttore di luce
Trasduttore ad infrarossi passivo (PIR) Accelerometro
Potenza di segnale ricevuta (RSSI)
L’identificatore del mote obiettivo (Target Mote). Rappresenta il numero identificativo (Id), assegnato durante la programmazione ai mote, su cui effettuare le operazioni richieste.
I comandi per i mote. Start: inizio registrazione Stop: fine registrazione
Download: scaricamento dati dal mote obiettivo
Download All: scaricamento dati da tutti i mote
Reset Flash: pulizia della memoria flash Start Beacon: inizio trasmissione beacon Stop Beacon: fine trasmissione beacon
Fig.5.2 Interfaccia Logger GUI
Per ogni azione registrata quindi le fasi da seguire sono:
1. Posizionamento corretto e attivazione di tutti i nodi della rete
2. Connessione del nodo sink al pc
3. Apertura dell’interfaccia Logger GUI ed impostazione i parametri di interesse
4. Comando Start. Inizio registrazione 5. Comando Stop. Fine registrazione
6. Comando Download. Scaricamento dei dati dalla memoria Flash del mote indicato in Target Mote e conseguente memorizzazione nel database
7. Comando Reset Flash. Cancellazione dei dati registrati in Flash
8. Comando di Report. Comando per stampare in un file di testo (Fig.5.3) le misure effettuate ai vari tempi di campionamento. È implementato sempre da una classe Java del loggerGUI ma eseguibile non direttamente dall’interfaccia.
Fig.3 Esempio di dati scaricati dal database su un file di testo
Come si osserva nella fase 6, con il comando Download si dà l’ordine di scaricare i dati dalla memoria Flash dei mote per memorizzarli nel database. Questo processo ha il vantaggio di rendere i dati della registrazione reperibili in ogni momento, ma allo stesso tempo impedisce un’analisi real-time delle misure. Infatti per avere i dati pronti ad essere elaborati si deve effettuare un’ulteriore operazione al di fuori dell’interfaccia Logger GUI come descritto nella fase 8.
Date quindi le precedenti otto fasi per registrare e scaricare ogni movimento, le modalità e le impostazioni dei parametri per ogni registrazione sono stati implementati in questo modo:
Tempo di campionamento di 50 msec, ovvero 20 campioni al secondo.
Fase di calibrazione di 5 sec. Per ogni movimento è stato necessario infatti partire da una posizione di riferimento (posizione eretta come in Figura 5.1) nella quale restare fermi per almeno 5 sec, in modo da rendere possibili le operazioni di pre-processamento necessarie alle successive analisi.
Cronometraggio azione effettuata. Per isolare i dati caratteristici di un movimento, si è stabilito di cronometrare l’azione effettuata. Il cronometraggio inizia dal momento in cui la persona comincia la coordinazione
(effettuata con un singolo passo) e finisce una volta compiuto il gesto calcistico. In questo modo si elimina la fase di calibrazione e la fase in cui il corpo della persona ritorna nella posizione di riferimento.
Tutti i movimenti vengono effettuati in un arco di tempo compreso tra gli 0,80 sec e i 3 sec.
Completate le registrazioni di tutti i movimenti necessari secondo le modalità appena elencate, si passa al pre-processamento dei dati.
V 2. ELABORAZIONE DATI IN
AMBIENTE MATLAB
La fase di pre-processamento dati (Capitolo II – Paragrafo 2.1) serve a predisporre la forma degli stessi per le fasi successive del riconoscimento di attività.
Come ambiente di programmazione per questa fase è stato scelto MATLAB [3], nella sua versione 7.10 (R2010a), per via della sua potenza di calcolo numerico, le numerose funzioni presenti in letteratura e la possibilità di produrre grafici dei dati e risultati con comandi semplici.
Ognuna delle serie di dati che registriamo, riferita ad un asse di un mote, in assenza di movimento restituisce un valor medio differente rispetto alle altre. Inoltre ogni registrazione presenta dei tempi
di latenza rispetto ai comandi di Start e Stop impartiti dall’interfaccia Logger GUI. Per risolvere tale situazione, dopo aver caricato tutti i dati dai file di testo, si sfrutta il tempo di calibrazione, svolgendo le seguenti operazioni:
Si calcola la media su venti campioni nella fase di calibrazione e il valore trovato si sottrae a tutto il segnale per centrare le varie registrazioni sullo zero
Successivamente si elimina dai dati considerati i primi quaranta campioni (primi due sec di registrazione). Inutili ai fini di classificazione, perché privi di contenuto informativo.
Dopodichè, per migliorare la qualità dei dati, eliminando rumori ed artefatti eventuali, è stato fatto scorrere su tutti i segnali un filtro a media mobile (Fig.5.4) [4] implementato con una finestra di tre campioni.
Fig.5.4 Plot Matlab. Filtraggio con media mobile. Segnale verde -> no filtrato;
Segnale blu -> filtrato;
Infine, per restringere ancora meglio la parte di segnale utile ad ogni movimento è stato implementato un algoritmo di rivelazione segnale, giocando sulle oscillazioni intorno a delle soglie empiriche decise dopo un’accurata osservazione dei segnali. In pratica si scorre il segnale e ad ogni istante i:
Si calcola la media (med) tra il campione i-esimo, il precedente (i-1) ed il successivo (i+1)
Primo controllo (If): se i valori del campione i o del campione i-1 non superano in valore assoluto la soglia stabilita a 5, i campioni
Secondo controllo (elseif): se i valori dei campioni i, i-1 e i+1 non superano in valore assoluto la soglia stabilita a med+4 non
vengono considerati
Terza opzione (else): se si superano i due controlli precedenti si inizia a considerare
i campioni come utili
Stop campioni: si finisce di considerare i dati come utili contando i campioni in base al Tempo cronometrato in fase di registrazione (es. 2,45 sec * 20 campioni = 49 campioni)
Codice implementato su MATLAB con evidenziate le soglie ed i controlli prima definiti:
function [ar1,IND,camp]=riv_temp(a1,s) % soglia rivelazione SOGLIA=5; S_MED=4; IND=0; camp=1; %% ar1=zeros(1,1); start=0; j=1; for i=1:length(a1)
if i==1 || i==length(a1) || i==length(a1)-1 else if start==0 med=(a1(i)+a1(i+1)+a1(i-1))/3; if abs(a1(i))<=SOGLIA || abs(a1(i-1))<=SOGLIA %niente
elseif (abs(a1(i))<=med+S_MED) && (abs(a1(i+1))<=med+S_MED) &&
%niente else j=j+1; ar1(j,1)=a1(i); start=1; camp=floor(s*20); cont=1; IND=i; end elseif start==1 if cont <= camp j=j+1; ar1(j,1)=a1(i); cont=cont+1; end end end end
Questa ultima funzione riv_temp descritta dal codice MATLAB, sostanzialmente, va a svolgere il compito della fase di Segmentazione (Capitolo II – Paragrafo 2.2), sostituendosi ad algoritmi più complessi ma garantendo comunque l’isolamento dei dati di interesse nell’attività considerata.
Il fatto di aver usato questo metodo è giustificato dalla necessità di:
evitare la fase iniziale relativa alla calibrazione, molto variabile a causa della latenza di registrazione dei mote e non significativa nel contenuto informativo. evitare la fase finale di registrazione
riferita al ritorno della coordinazione corporea nella posizione di riferimento. In questa fase infatti il movimento sarebbe
stato forzato in modo anomalo rispetto alla realtà del movimento stesso, visto che durante un’attività calcistica più completa, come una partita o un allenamento, le diverse azioni sono svolte in rapida successione senza interruzioni o riposizionamenti in una posizione base.
Dopo aver definito quindi tutti i segmenti dei segnali di interesse è possibile passare alla classificazione dei dati.
V 3. CLASSIFICAZIONE DATI
In questa fase sono stati sfruttati diversi algoritmi per cercare di comprendere quale tipologia di classificazione sia più adatta per gli scopi proposti nella tesi.
Le attività scelte per essere classificate variano dalle più semplici come camminata, corsa, salto ad alcune più complesse come calcio di collo destro, calcio di collo sinistro, calcio di piatto destro, calcio di piatto sinistro, cercando di variare le velocità di esecuzione.
Per quanto riguarda gli algoritmi usati, come Template Matching sono stati utilizzati la Correlazione Incrociata o XCorr (Capitolo IV – Paragrafo 2) e la forma ottimizzata Weigth Derivate Dynamic Time Warping o WDDTW (Capitolo IV – Paragrafo 3), nella quale la funzione peso utilizzata è rappresentata dalla Modified
logistic weigth function (MLWF) con g= 0.05 in modo da pesare le distanze in maniera lineare (entrambi i metodi sono stati sviluppati in ambiente MATLAB).
Come metodo di Mahine Learning sono state usate delle reti neurali ESN (Echo State network), implementate in codice Java.
V 3.1 TEMPLATE MATCHING
Per entrambi i metodi di Template Matching le fasi che contraddistinguono la struttura logica dell’algoritmo effettuato sono equivalenti. Quello che cambia sostanzialmente, è il modo di calcolare (intrinseco del metodo scelto) la similarità tra template e segnali di test e di conseguenza anche le soglie empiriche scelte per accettare i risultati. Questi infatti sono considerati come massima
correlazione nel caso della XCorr o minima distanza nel caso del WDDTW, con delle soglie
rispettivamente da superare o non superare per poter valutare come “match” positivo il risultato. In sostanza un risultato migliore sarà indicato:
nel XCorr da un valore più alto nel WDDTW da un valore più basso
V 3.1.1 SCELTA TEMPLATE
Per ogni attività considerata sono state effettuate dieci registrazioni da parte della stessa persona, delle quali cinque sono state usate come
template (segnale di riferimento), mentre le altre cinque sono state usate per verificare i risultati. Considerando il numero elevato di attività da analizzare ed il numero di segnali per ogni registrazione, si è scelto di diminuire il numero di segnali di riferimento. Si è quindi considerato un’unica registrazione di riferimento, scelta tra le cinque di ogni movimento caratteristico come il segnale più simile rispetto agli altri. Il concetto di
simile viene riferito al migliore punteggio (score)
ottenuto con gli algoritmi di Template Matching. In realtà quindi, il template non è propriamente uno, perché una registrazione si riferisce ai segnali di un accelerometro biassiale di cinque mote diversi. Quindi si parte da una situazione in cui ho 5 registrazioni X 5 mote X 2 assi: 50 segnali. Di questi 50, solo i 10 della migliore prova costituiscono i template dell’attività di interesse.
Considerando N uguali all’id del mote (2,3,4,5,6), M ed m il numero della registrazione (1,2,3,4,5), i passi da seguire sono quindi:
1. Calcolo degli score_Nx_Mm. Da considerare tra coppie di segnali riferite allo stesso mote in registrazioni diverse. Ad esempio mote 2/registrazione 1:
score_2x_12, score_2x_13, score_2x_14, score_2x_15.
score_2x_21, score_2x_23, score_2x_24, score_2x_25.
………
2. Calcolo degli score_Ny_Mm. Da considerare tra coppie di segnali riferite allo stesso mote in registrazioni diverse. Ad esempio mote 4/registrazione 1
score_4y_12, score_4y_13, score_4y_14, score_4y_15
mote 4/registrazione 2:
score_4x_21, score_4x_23, score_4x_24, score_4x_25.
………..
3. Calcolo somma_Nx_M. Ad esempio mote 2/registrazione 1:
somma_2x_1= . score_2x_12 + score_2x_13 + score_2x_14 + score_2x_15. Mote 2/registrazione 2:
somma_2x_2= . score_2x_21 + score_2x_23 + score_2x_24 + score_2x_25. ……….
4. Calcolo somma_Ny_M. Ad esempio mote 2/registrazione 1:
somma_2y_1= . score_2y_12 + score_2y_13 + score_2y_14 + score_2y_15. Mote 2/registrazione 2:
somma_1y_2= . score_2y_21 + score_2y_23 + score_2y_24 + score_2y_25. ……….
5. Calcolo somma_N_M -> somma_Nx_M + somma_Ny_M 6. Calcolo S_M -> somma_2_M +
somma_3_M + somma_4_M + somma_5_M + somma_6_M Per ogni registrazione (M= 1,2,3,4,5)
7. Si considera la migliore S_M
8. Si prendono come template i 10 segnali riferiti alla migliore S_M
V 3.1.2 TEST CLASSIFICAZIONE
Una volta estratti i template dalle cinque prove scelte per ogni attività, ne rimangono altre cinque per testare la classificazione.
Per ogni sequenza di test dunque, vengono calcolati gli score del corrispettivo metodo di Template Matching con i template riferiti alle diverse attività. Naturalmente gli score vengono calcolati fra tracciati di segnale appartenenti allo stesso asse dello stesso mote.
Inoltre per cercare di capire quali assi di quali mote riescono a dare un “match” positivo, sono stati estratti risultati considerando separatamente gli assi di un numero variabile di mote.
Si è cercato di ottenere quindi delle classificazioni utilizzando:
1 solo mote sulla gamba (destra e o sinistra) 1 solo mote sul torace
2 mote sulle gambe + 1 sul torace
4 mote (2 sulle gambe + 2 sulle braccia) 5 mote (4 + 1 sul torace)
Per tutti questi casi si sono considerati i risultati dei match di un asse singolo o di entrambi gli assi insieme.
Caso di 1 solo mote e 1 solo asse:
Confronto tra score e la SOGLIA per ciascuna attività
L’attività con lo score migliore che rientra nella SOGLIA è scelta dalla classificazione Caso di 1 solo mote e 2 assi:
Confronto tra score dei 2 assi e la SOGLIA per ciascuna attività
Se entrambi gli score rientrano nella SOGLIA viene considerata la somma di essi (score_x + score_y)
L’attività che risulta avere gli score opportuni a rientrare nella la SOGLIA e con la somma migliore è scelta dalla classificazione
Caso di 2 mote e 1 asse:
Confronto tra score dei due mote e la SOGLIA per ciascuna attività
Se entrambi gli score rientrano nella SOGLIA viene considerata la somma di essi (score_1 + score_2)
L’attività che risulta avere gli score opportuni che rientrano nella SOGLIA e con
la somma migliore è scelta dalla classificazione
Caso 2 mote e 2 assi:
Confronto tra score dei due mote e la SOGLIA per ciascuna attività
Se tutti gli score rientrano nella SOGLIA viene considerata la SOMMA di essi ( somma_x= score_1x + score_2x
somma_y= score_1y + score_2y SOMMA= somma_x + somma_y ) L’attività che risulta avere gli score
opportuni che rientrano nella SOGLIA e con la SOMMA migliore è scelta dalla classificazione
Caso di 3 mote e 1 asse:
Confronto tra score dei tre mote e la SOGLIA per ciascuna attività
Se tutti gli score rientrano nella SOGLIA viene considerata la somma di essi (score_1 + score_2 + score_3)
L’attività che risulta avere gli score opportuni che rientrano nella SOGLIA e con la somma migliore è scelta dalla classificazione
Caso 3 mote e 2 assi:
Confronto tra score dei tre mote e la SOGLIA per ciascuna attività
Se tutti gli score rientrano nella SOGLIA viene considerata la SOMMA di essi (
somma_x= score_1x + score_2x + score_3x somma_y= score_1y + score_2y +
score_3y SOMMA= somma_x + somma_y ) L’attività che risulta avere gli score
opportuni rientrano nella SOGLIA e con la SOMMA migliore è scelta dalla classificazione
Caso di 4 mote e 1 asse:
Confronto tra score dei quattro mote e la SOGLIA per ciascuna attività
Se tutti gli score rientrano nella SOGLIA viene considerata la somma di essi (score_1 + score_2 + score_3 + score_4)
L’attività che risulta avere gli score opportuni che rientrano nella SOGLIA e con la somma migliore è scelta dalla classificazione
Caso 4 mote e 2 assi:
Confronto tra score dei quattro mote e la SOGLIA per ciascuna attività
Se tutti gli score rientrano nella SOGLIA viene considerata la SOMMA di essi ( somma_x= score_1x + score_2x + score_3x + score_4x somma_y= score_1y + score_2y +
score_3y + score_4y SOMMA= somma_x + somma_y )
L’attività che risulta avere gli score opportuni rientrano nella SOGLIA e con la SOMMA migliore è scelta dalla classificazione
Caso di 5 mote e 1 asse:
Confronto tra score dei cinque mote e la SOGLIA per ciascuna attività
Se tutti gli score rientrano nella SOGLIA viene considerata la somma di essi (score_1 + score_2 + score_3 + score_4 + score_5) L’attività che risulta avere gli score
opportuni che rientrano nella SOGLIA e con la somma migliore è scelta dalla classificazione
Caso 5 mote e 2 assi:
Confronto tra score dei cinque mote e la SOGLIA per ciascuna attività
Se tutti gli score rientrano nella SOGLIA viene considerata la SOMMA di essi ( somma_x= score_1x + score_2x + score_3x + score_4x + score_5x somma_y= score_1y + score_2y + score_3y + score_4y + score_5y SOMMA= somma_x + somma_y ) L’attività che risulta avere gli score
opportuni rientrano nella SOGLIA e con la SOMMA migliore è scelta dalla classificazione
V 3.2 MAHINE LEARNING
Come metodo di Mahine Learning si è deciso di usare delle Reti Neurali artificiali del tipo ESN (Capitolo IV – Paragrafo 4.1), per via della loro struttura adatta ad analizzare serie di dati temporali [5] [6].
L’applicazione che è stata usata è implementata in codice Java ed ha lo scopo di addestrare delle reti ESN in modo indipendente rispetto al progetto RUBICON [7], nel quale quest'applicazione è stata utilizzata anche per la fase sperimentale dell'apprendimento.
Il codice è preimpostato per eseguire una serie di dataset conosciuti, ma è anche possibile eseguire il codice con nuovi dataset modificando lo script completeScriptedComputation nella classe ESNmain, in modo da configurare un’esecuzione adatta allo specifico caso.
L'eseguibile (oggetto della compilazione) accetta in ingresso quattro diverse configurazioni:
Senza parametri Con 1 parametro Con 2 parametri Con 8 parametri
In queste possiamo specificare alcuni parametri per definire caratteristiche come il path contenente i dati in ingresso (dataset), il path che contiene i dati di uscita, il dataset predefinito da analizzare e il metodo di addestramento da
eseguire. Nelle prime due configurazioni però si ha la possibilità di eseguire lo script completeScriptedComputation in modo da impostare manualmente l’addestramento delle reti neurali su un nuovo dataset non predefinito nel codice.
V 3.2.1 SCRIPT PER ESECUZIONE MANUALE
Lo script da eseguire per l’esecuzione
manuale si è detto essere il
completeScriptedComputation, il quale può ricevere due parametri:
il primo, supervisor, è il riferimento alla classe che contiene il metodo che presi i parametri di ingresso esegue i metodi per la creazione dell'ambiente di apprendimento, e quindi lo avvia.
Il secondo, whichConfigDataSet, serve a specificare per quale dataset si esegue l’apprendimento. Può anche essere nullo, nel qual caso il valore viene specificato a mano nello script. La terza opzione è che whichConfigDataSet abbia il valore manual nel qual caso si specificano tutti i parametri per la configurazione dell'applicazione su un determinato dataset non noto.
Nel caso di questo lavoro di tesi interessa proprio
whichConfigDataSet, in modo da settare tutti i parametri specifici di interesse, quali:
TypeOfExecution exect = TypeOfExecution.s; Con questo parametro si indica secondo quale tecnica probabilistica strutturiamo l’addestramento. Passando s come in questo caso, si effettua una semplice Cross-Fold-Validation [8]. Questo metodo divide il dataset in diversi gruppi, e attraverso un ciclo iterativo ne considera uno come test set ed i restanti come training set. La stessa logica è usata su due livelli: infatti dopo aver scelto i gruppi facenti parte del training set, tra questi ne vengono scelti alcuni che costituiscono il validation set.
int numberOfSamples=20; Parametro che indica quanti file di dataset abbiamo. Considerato il seguente caso, nel quale si ha un file per ogni registrazione, e la possibilità di classificare in due classi l’attività analizzata , si avrà un valore di 20= 10 * ogni attività (2).
int numberOfData=10; Indica quanti segnali si ha all’interno di un file. Dati caratteristici quindi di una registrazione
int numberOfSource=1; Indicherebbe quanti mote si utilizza ma in realtà il formato per il quale è impostato l’algoritmo legge un unico file che quindi conterrà i segnali di tutti i
mote (Input = numberOfData * numberOfSource ).
boolean staticIndexOfTest = false; Restituendo un valore true si può definire l’indice dal quale considerare le sequenze di test. Restituendo false la scelta è lasciata al programma secondo il tipo di addestramento passato.
int howManySampleForTest=6; Viene deciso il numero di file rispetto al totale (numberOfsample) da considerare di test String taskType = "classification"; Si può
impostare classificazione (“classification”) o regressione (“regression”)
String taskGranularity = "sequence-to-sequence"; viene indicato quando il programma deve restituire un’uscita, se in corrispondenza di una sequenza (sequence-to-sequence) o in corrispondenza di un singolo elemento (sequence-to-element). String typeOfLossFunction = "mae"; Viene
decisa la metrica. Passando ed sfruttiamo la distanza Euclidea, oppure si può sfruttare il valore assoluto con il parametro impostato a mae.
Con i suddetti parametri passati allo script per l’esecuzione manuale, l’algoritmo considera:
Un Dataset composto da venti file (due attività a confronto: dieci file per
ogni attività), ognuno contenente i segnali di una registrazione. Per ogni time-step è indicato il target di classificazione (1 o -1)
Metodo di scelta dei file di addestramento e validazione: viene utilizzato un algoritmo di Cross-Fold-Validation con 4 fold. Ogni fold indica un ciclo iterativo svolto dall’algoritmo Cross-Fold-Validation. Naturalmente più cicli si effettuano e più si aumenta il tempo di calcolo, ma anche l’efficienza dell’algoritmo.
Numero di file di test da considerare uguale a 6 sui 20 complessivi che formano il dataset. Vengono scelti dall’algoritmo Cross-Fold-Validation. Parametri responsabili della
configurazione della rete: questi parametri hanno degli insiemi di valori stabiliti che possono essere combinati tra loro, in modo da costituire la forma ottima della rete neurale. I suddetti parametri sono:
- dimensione del reservoir - parametro di regolarizzazione - parametro di leaky
- parametro rho
Un esempio di addestramento e validazione si può osservare in
Tabella 5.1. In questa tabella si possono osservare alcune delle 143 possibili configurazioni strutturate con diversi valori dei parametri suddetti, l’errore di addestramento e l’errore di validazione commessi. Di tutte le configurazioni, quella con
errore di validazione minore è utilizzata per le registrazioni di test
Id ResDim Reg Leaky rho TrainingErr ValidErr 0 25 0,001 0,05 0,8 0,050959222 0,10520625 1 25 0,001 0,05 0,9 0,06703558 0,08096894 2 25 0,001 0,05 0,99 0,08354427 0,20428064 3 25 0,001 0,1 0,8 0,056018095 0,08517296 4 25 0,001 0,1 0,9 0,06565814 0,07072379 5 25 0,001 0,1 0,99 0,059654772 0,1036239 6 25 0,001 0,2 0,8 0,05301185 0,054335214 7 25 0,001 0,2 0,9 0,06007371 0,088283665 8 25 0,001 0,2 0,99 0,06285975 0,0739384 9 25 0,001 0,5 0,8 0,03433161 0,05460954 …… ……….. ……….. ……… …….. ...……… ………..… …… ……….. ……….. ……… …….. ……… ………..… …… ……….. ……….. ……… …….. ……… ………..… 48 50 0,001 0,05 0,8 0.042852324 0.08751724 49 50 0,001 0,05 0,9 0.05964472 0.10177109 50 50 0,001 0,05 0,99 0.053489536 0.20945443 …… ……….. ……….. ……… …….. ……… ……….. …… ……….. ……….. ……… …….. ……… ………..… …… ……….. ……….. ……… …….. ……… ………..… 135 100 1 0,1 0,8 0.050985705 0.07174527 136 100 1 0,1 0,9 0.05703951 0.08774747 137 100 1 0,1 0,99 0.054971434 0.07934448 138 100 1 0,2 0,8 0.048692673 0.07791811 139 100 1 0,2 0,9 0.050668374 0.085798 140 100 1 0,2 0,99 0.04472685 0.06956581 141 100 1 0,5 0,8 0.04405564 0.06770253 142 100 1 0,5 0,9 0.034967337 0.07247004 143 100 1 0,5 0,99 0.039311778 0.08666931
Tabella 5.1 Esempio di addestramento (training) e Validazione (validation) con reti ESN.
Gli errori di classificazione sono calcolati osservando la risposta dell’algoritmo ad ogni step di uscita della rete. Nell’esempio mostrato in Tabella 5.2 si può notare l’uscita, restituita dalla rete neurale, rispetto al target corretto. Tale uscita sarà 1 in caso di riconoscimento target 1, o 0 in caso di riconoscimento target -1. L’errore invece indica la differenza tra target ed uscita.
STEP OUTPUT TARGET ERROR
0 0 0 0 1 0 0 0 2 0 0 0 3 0 0 0 4 0 0 0 5 0 0 0 6 0 0 0 7 0 0 0 8 0 0 0 9 0 0 0 10 0 0 0 11 0 0 0 12 0 0 0 13 0 0 0 14 0 0 0 15 1 0 1 16 1 0 1 17 1 0 1 18 1 0 1 19 1 0 1 20 0 0 0
Tabella 5.2 Esempio di uscita nella distinzione tra Calcio di collo destro e Calcio di piatto destro in fase di test.