Difference between revisions of "Talk:Online P300 and ErrP recognition with BCI2000"

Revision as of 10:11, 17 August 2008

Plugin Galileo/Modulo sorgente BCI2000

• Riferimento su Airbat del sorgente modulo Plugin: sgarlata/Plugin

• Riferimento su Airbat del sorgente modulo sorgente BCI2000: sgarlata/GalileoSource

Il sistema attualmente è composto da un plugin che si occupa di inviare i dati tramite pipe ad un altro modulo che fa parte dell'intero sistema di BCI2000.

Per ottenere una corretta temporizzazione del sistema di BCI2000 abbiamo sfruttato il fatto che il plugin è più lento nell'invio dei dati rispetto all'intero sistema BCI2000. Infatti si è deciso di inviare tramite plugin una quantità di dati costante pari a 1/16 di secondo, tenendo conto del fatto che durante l'esecuzione di una registrazione online la quantità di dati ricevuti dal plugin risulta molto regolare e costante. In questo modo ogni invio di dati tramite pipe rappresenta il trascorrere di un tempo prefissato che risulta pari a 1/16 di secondo.

Sono stati effettuati diversi test (aggiunta di un buffer di accumulo, invio di blocchi di dimensione maggiore 0.1 secondi) per cercare di mantenere il più possibile costante l'intervallo che trascorre tra l'invio di un blocco dati e quello successivo, nonostante questi tentativi abbiamo riscontrato il fatto che l'intervallo tra due blocchi risulta in media molto regolare, questa regolarità viene persa però nei momenti in cui il sistema viene perturbato da fattori esterni dovuti all'intervento dell'utente, quali ad esempio: apertura nuova finestra, spostamento finestre, apertura cartelle ecc... Tutti questi fattori possono essere trascurati, in quanto durante l'esecuzione dell'intero sistema l'utente non deve interagire direttamente con il sistema, ma deve solamente essere sottoposto a delle stimolazioni, e se l'utente decide di interagire è perché sta effettuando modifiche ed in quel momento non necessita di un sistema sincrono e regolare.

Noi speriamo che non capiti durante il funzionamento normale o sia molto raro (BernardoDalSeno 20:21, 24 May 2008 (CEST))

Per tutte queste motivazioni si è deciso che il plugin non appena accumulato un blocco dati pari a 1/16 di secondo deve subito inviarlo tramite pipe, in modo da mantenere una regolarità tra l'invio consecutivo di due blocchi.

Nel sever Airbat sono presenti i sorgenti dei differenti plugin implementati con le differenti stategie di funzionamento:

• Cartella sgarlata/old/PluginPipe: il plugin implementato consente un invio di dati in blocchi di 0.1secondi, consentendo al modulo sorgente di BCI2000 di occuparsi dell'invio di blocchi dati di dimensioni inferiori all'interno del sistema di BCI2000. Questa strategia è stata abbandonata perchè abbiamo notato che a 512Hz il plugin riceveva blocchi di 32 campioni per ogni chiamata, e doveva inviare blocchi di 51 campioni, questa differenza faceva si che l'invio di blocchi non era regolare in quanto ad esempio dopo due chiamate inviavo un blocco da 51 campioni e poi dovevo aspettare 3 chiamate per inviare un nuovo blocco dati.

• Cartella sgarlata/old/PluginBuffer: il plugin implementato mantiene un buffer di N blocchi dati pari a 1/16 di secondo, ed inizia l'invio di un blocco dati nel momento in cui mezzo buffer è stato riempito, utilizzando come clock di invio l'orologio di invocazione del plugin, dato che in maniera molto regolare vi era un invocazione ogni 1/16 di secondo a 512Hz. La strategia dell'utilizzo del buffer è stata abbandonata in quanto, si introduceva ritardo con il buffer ed in oltre i problemi di perdita di regolarità si verificavano comunque perchè non erano dovuti a dei mancati invii di dati da parte del plugin,ma erano dovuti al fatto che il sistema veniva perturbato da un utente esterno ed il modulo sorgente di BCI2000 attendeva nella lettura di un nuovo blocco.

• Cartella sgarlata/old/PluginTemporizzato: questo plugin utilizza un blocco dati pari a 1/16 di secondo, ma diversamente dal plugin finale manca della stampa di diversi valori di debug e della possibilità di connessione con il sistema di BCI2000 non sincrona.

Le diverse strategie di sviluppo del plugin sono state studiate ed implementate per poter utilizzare un applicativo di stimolazione che rimanesse sincrono con l'intero sistema e quindi che avesse la possibilità di essere implementato da un modulo applicativo di BCI2000. Uno stimolatore sincrono è un vantaggio in quanto consente di farlo evolvere durante l'acquisizione dei segnali e di effettuare diverse scelte sulla base di questi e dei risultati fin ora ottenuti.

Per quanto riguarda il modulo sorgente di BCI2000 questo si occupa di leggere dalla pipe: il numero di canali, il numero di campioni per canale e la frequenza di campionamento. Una volta letti questi valori controlla che l'utente abbia inserito tra i parametri gli stessi valori letti tramite pipe, se questo non avviene blocca l'intero sistema e comunica l'errore all'utente con i valori esatti da inserire. Questa procedura viene ripetuta finché l'utente non inserisce gli stessi parametri letti dal modulo source. Si è visto che invece non si riesce a passare i parametri dal modulo sorgente agli altri moduli di BCI2000 durante la fase di inizializzazione.

A run time il modulo source si occupa di leggere dalla pipe una blocco di dati e di inviarlo al modulo successivo (modulo filtro); ogni blocco viene inoltrato non appena è disponibile.

Da fare

• Script per il confronto tra dati registrati da BCI2000 e da Galileo.
• Misurare il numero di campioni per chiamata a varie frequenze.
• Eliminare la finestra del plugin, e salvare eventuali tempi (istanti) di perdite di dati (pipe piena) su file e alla fine della registrazione avvisare l'utente se ci sono state perdite. Il file verrà cancellato se non contiene errori. Nessun file di log va sovrascritto.

Per come è fatto il sistema, è inevitabile che la pipe si riempia prima dell'inizio della registrazione vera e propria. Questo periodo non va segnalato né salvato su file (andrà ideato un opportuno sistema per identificarlo).

CATENA DI FILTRI DI BCI2000

Attualmente la catena di filtri del modulo di BCI2000 è suddivisa nel seguente modo:

1)un filtro spaziale

2)un filtro di Trigger che si occupa di rilevare gli inizi delle stimolazioni tramite l'analisi del segnale proveniente dal fototransistor

3)un filtro che si occupa di accumulare più forme d'onda p300 relative alla stessa stimolazione e tra queste farne la media

4)un filtro di classificazione

5)un filtro di normalizzazione

Si vuole modificare sia la sequenza di filtri che il funzionamento di alcuni di questi nel seguente modo:

1)filtro spaziale

2)filtro di Trigger che determina in maniera automatica, tramite una fase iniziale dettata dal modulo applicativo, il valore di soglia per distinguere gli istanti di tempo in cui il riquadro è nero oppure bianco. PARAMETRI DEFINITI:

• WindowSize = definisce la dimensione della finestra mobile utilizzata per filtrare il segnale
• TriggerChannel = definisce il numero del segnale sul quale identificare i trigger

STATI DEFINITI:

• TriggerFound = posto a 1 se il filtro identifica nel blocco analizzato l'inizio di una stimolazione
• TriggerIndex = se TriggerFound è posto a 1, questo stato contiene indice del campione nel blocco analizzato che ha determinato l'inizio dello stimolo.
• Riferimento su Airbat del sorgente filtro Trigger: sgarlata/P3ErrPSignalProcessingGalileo/TriggerFilterAutoThreshold

3)filtro butterworth passa banda con banda passante definibile tramite l'impostazione di appositi parametri (default banda passante 5Hz-10Hz, dato che i potenziali evocati hanno un andamento lento nel tempo). L'output di questo filtro è utilizzato in fase di riconoscimento dell'ErrP. PARAMETRI DEFINITI:

• ButterworthBPLowCorner = definisce il valore di banda passante minimo
• ButterworthBPHighCorner = definisce il valore di banda passante massimo
• Riferimento su Airbat del sorgente filtro ButterworthBP: sgarlata/P3ErrPSignalProcessingGalileo/ButterworthBP

4)un filtro che si occupa solamente di accumulare le forme d'onda con un ring buffer che memorizza una porzione di segnale precedente. PARAMETRI DEFINITI:

• EpochLength = lunghezza in secondi dell'epoca da accumulare
• LengthBeforeStimulus = lunghezza in secondi della porzione di segnale da accumulare prima dell'inizio di una stimolazione
• VisualizeCollectorFiltering = se settato questo parametro consente di visualizzare l'intera epoca accumulata

STATI DEFINITI:

• StimulusCodeDone = il codice dello stimolo la cui relativa epoca è stata interamente accumulata
• StimulusTypeDone = il tipo relativo all'epoca appena accumulata
• Riferimento su Airbat del sorgente filtro Collector: sgarlata/P3ErrPSignalProcessingGalileo/CollectorFilterGALILEO

5)filtro di classificazione per P300 ed ErrP. Per la classificazione P300 attualmente è implementato il classificatore lineare "Logistic", mentre per la classificazione ErrP è implementato un classificatore LDA. PARAMETRI DEFINITI:

• ClassifierFunction = identifica la funzione di classificazione P300 da utilizzare (attualmente è solamente implementato il classificatore Logistic)
• P3WeightMatrix = matrice in cui ogni colonna indica un canale e il numero di righe è pari al numero di campioni dell'epoca in ingresso aumentato di 1 . La prima riga di ogni colonna indica il canale sul quale applicare i pesi definiti nelle righe successive.
• P3Constant = costante utilizzata dal classificatore P300 Logistic
• ErrPSamplesIndex = matrice in cui per ogni riga è indicato nella prima colonna il canale segiuto dall'indice dei campioni da prelevare dal segnale d'ingresso
• S, Mm, MsT, C = matrici utilizzate dal classificatore ErrP

STATI DEFINITI:

• ErrPFound = questo stato è posto a 0 durante il calcolo dell'ErrP, terminato il calcolo se viene identificato un ErrP questo stato è posto a 1 altrimenti è posto a 2.
• Riferimento su Airbat del sorgente filtro Collector: sgarlata/P3ErrPSignalProcessingGalileo/P3ErrPClassifier

6)filtro che effettua la media dei valori in uscita dal filtro di classificazione PARAMETRI DEFINITI:

• EpochsToAverage = il numero di classificazioni da mediare

STATI DEFINITI:

• StimulusCodeRes = il codice dello stimolo del quale è stata calcolata la media di "EpochsToAverage" stimolazioni
• StimulusTypeRes = il tipo relativo allo StimulusCodeRes appena determinato
• Riferimento su Airbat del sorgente filtro Media: sgarlata/P3ErrPSignalProcessingGalileo/MeanFilter

7)un filtro di normalizzazione

Fatto

Filtro che rileva i trigger

Adattamento automatico della soglia per i trigger (Analisi switch riquadro: Bianco->Nero->Bianco per un tempo definito dall'utente)

Accumulare forme d'onda con parti che precedono il trigger

Script Matlab per verificare l'accuratezza della rilevazione dei fronti d'onda.

Da fare

Elencare stati e parametri usati dai filtri, e documentare quelli nuovi.

Il classificatore per P300 usi questa formula:

 <math>L_{\rm P300} = \frac{1}{1 + exp( c + \sum_i w_i x_i )}</math>

dove <math>x_i</math> sono i campioni EEG di tutti i canali, mentre c e <math>w_i</math> sono dei pesi oppurtuni. I <math>w_i</math> saranno organizzati in una matrice bidimensionale, in cui ogni riga contiene: il numero del canale, seguito da tutti i pesi per quel canale. Poi con un ulteriore parametro si potrà selezionare una funzione alternativa alla logistica.

Modulo applicativo speller P300

• Riferimento su Airbat del sorgente modulo Applicativo: sgarlata/P3Speller

Il modulo applicativo deve essere adattato al sistema di trigger.

Per quanto riguarda il modulo applicativo bisogna introdurre un riquadro posto nell'angolo superiore destro dello schermo e farlo variare (bianco/nero) ogni qual volta viene effettuata una stimolazione e, prima dell'inizio della sequenza di stimolazioni, introdurre una fase preliminare in cui si fa variare (bianco/nero) il riquadro per un tempo totale preimpostato in modo da poter far determinare in maniera automatica dal filtro di Trigger il valore di soglia che permette di distinguere se siamo in fase di stimolazione (riquadro nero) o in fase di non stimolazione (riquadro bianco). Terminata la fase di taratura del valore di soglia, lo speller può effettuare la sua sequenza di stimolazioni. Alla fine di ogni treno di stimolazioni lo speller P300 determina, in base alle classificazioni ricevute, qual'è la stimolazione con classificazione maggiore mostrandola a video. A questo punto inizia una nuova fase in cui viene controllata la presenza dell'ErrP, se è stato identificato una forma d'onda ErrP lo speller non effettua alcuna selezione (modalità "free mode") altrimenti seleziona la stimolazione mostrata a video precedentemente, riprendendo con una nuova sequenza di stimolazioni.

Per le modifiche da effettuare al modulo applicativo di BCI2000 quando questo deve comunicare tramite protocollo UDP con un altro applicativo che effettua le stimolazioni su una differente macchina Linux si è invitati a visionare la relativa discussione di Roberto Massimini.

Fatto

• Modificare lo stato StimulusBegin anche per lo stimulo ErrP

Da fare

• Misurare lo sfasamento tra sync e stimolo
• Verifica del sistema per associare la stimolazione ai trigger rilevati dall'apposito filtro
• Scrivere specifiche per comunicazione tra BCI2000 e un modulo applicativo P300 esterno che gira su una macchina Linux separata

Integrazione con ErrP

Il sistema basato su BCI2000 che usa P300 va espanso per poter usar anche i potenziali d'errore

Ciò che si vuole sviluppare è un sistema che si basi su una procedura di verifica automatica tramite l'integrazione del controllo anche sui potenziali d'errore. La verifica dell'Errp non è effettuato tramite media di più forme d'onda così come avviene con le rilevazioni della P300, ma sulla singola prova. Infatti, dopo l'analisi delle forme d'onda P300 e la determinazione del target voluto dall'utente, si introduce una ulteriore fase in cui si mostra all'utente la probabile selezione voluta e si valuta la presenza del potenziale d'errore. Se non viene riscontrata questa forma d'onda si seleziona il target precedentemente identificato, altrimenti si ripete una nuova sequenza di stimolazioni per identificare nuovamente il target voluto.

Schema del comportamento del classificatore LDA di Gianmaria:

c - ((x - media_tr) * scala_tr * medie_tr)

cioè

y = c1 + x * matrice

e la classe è l'indice del valore minimo del vettore y (che è lungo 2)

Fatto

Introdurre una nova fase di controllo Errp nel modulo applicativo dello speller

Introdurre un nuovo filtro nella catena dei filtri che si occupa del'accumulo dei potenziali d'errore

Modificare opportunamente i filtri di: classificazione, media e normalizzazione per supportare il controllo dell'Errp

Da fare

Far funzionare lo speller in modalità "copy": il testo viene specificato all'utente e la lettera giusta viene scelta dall'applicazione con una probabilità dell'80% (parametro), in modo da avere dati per l'addestramento sia della P300 che dell'ErrP. Negli stati va salvata l'informazione su qual è la stimolazione che contiene una P300 (questo dovrebbe esserci già per la P300) e quale contiene un ErrP.

Fare uno script Matlab nuovo, derivato da quelli di Gianmaria, che faccia l'addestramento su dati salvati dallo speller BCI2000 in modalità "copy" e restituisca (su file) le tabelle per il classificatore pronte per essere caricate nel modulo di BCI2000.

Questo viene meglio diviso in diversi script: 1. Uno script che carica un file BCI2000 in una struttura eeg_p300_data; meglio se accetta gli stessi parametri di load_eeg_data_dei.m 2. Uno script che prende una struttura eeg_p300_data, calcola l'intervallo ottimo, addestra il classificatore e salva le matrici per l'uso online. 3. Uno script che usa i 2 precedenti: carica i dati da un po' di file, li concatena, e addestra il classificatore (BernardoDalSeno 17:39, 9 July 2008 (CEST))

Assicurarsi che l'attuale classificatore ErrP faccia esattamente le stesse cose di quello usato da Gianmaria (LDA sui dati grezzi).

Nel filtro P3ErrPClassifier: ogni riga specifica un solo intervallo; più righe possono riferirsi allo stesso canale.

Varie

Rinominare tutte le directory dei sorgenti in conformità allo stile di BCI2000 e senza usare spazi. Allineare i nomi dei moduli e quelli delle directory che li contengono.