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

Revision as of 10:28, 24 May 2008

Plugin Galileo/Modulo sorgente BCI2000

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

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

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.1secondi) 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 nuva 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.

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.

Per quanto rigurada 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. A run time il modulo source si occupa di leggere dalla pipe una blocco di dati e di inviarlo al modulo successivo (modulo filtro).

Da fare

Misurare il numero di campioni per chiamata a varie frequenze.

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

• Riferimento su Airbat del sorgente filtro Trigger: sgarlata/P3SignalProcessingGalileo/TriggerFilterAutoThreshold

3)un filtro che si occupa solamente di accumulare le forme d'onda p300 con un ring buffer che memorizza una porzione di segnale precedente, dato che noi rileviamo l'inizio di una stimolazione con un ritardo che è pari alla dimensione della finestra mobile fatta scorrere lungo il segnale di trigger

• Riferimento su Airbat del sorgente filtro P300: sgarlata/P3SignalProcessingGalileo/P3CollectorFilterGALILEO

4)filtro di classificazione

5)filtro che effettua la media dei valori in uscita dal filtro di classificazione

• Riferimento su Airbat del sorgente filtro Media: sgarlata/P3SignalProcessingGalileo/MeanFilter

6)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

Da fare

Verificare l'accuratezza della rilevazione dei fronti d'onda

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.

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

Aggiungere quadrato di sync nell'applicazione speller

Da fare

Misurare lo sfasamento tra sync e stimolo

Sviluppare 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.

Fatto

Da fare

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

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.