Difference between revisions of "Talk:Graphical user interface for an autonomous wheelchair"

From AIRWiki
Jump to: navigation, search
m (Communication Protocol Requirements)
Line 52: Line 52:
  
 
If the syncrony will be lost there's a Reset Message that restarts from the calibration. It will be activated when the number of the classifications is different from the number of the stimulations on the screen
 
If the syncrony will be lost there's a Reset Message that restarts from the calibration. It will be activated when the number of the classifications is different from the number of the stimulations on the screen
 +
 +
== Implementation of GUI ==
 +
=== Primo incontro (04/03/2009) ===
 +
 +
* Attualmente sulla carrozzella è installata una GUI molto semplice, che lavora all'interno del sistema BCI2000. L'idea è quella di creare una interfaccia asincrona che dovrà interagire con il sistema BCI2000 già realizzato mediante un socket TCP.
 +
 +
* Ci sono diverse possibilità per implementare la GUI:
 +
 +
0) Stimoliamo le singole location presenti all'interno della mappa: il problema è che può diventare pesante, e che può essere difficile dal punto di vista cognitivo per l'utente.
 +
 +
1) Per prima cosa stimoliamo i diversi locali, e poi stimoliamo le location appartenenti al singolo locale selezionato (in realtà dovremo continuare a stimolare anche gli altri locali, nel caso in cui l'utente volesse uscire dalla stanza!)
 +
Le singole location possono essere stimolate in diversi modi: per gruppi, singolarmente, tramite una griglia.
 +
 +
2) Dividiamo la piantina in celle e poi le stimoliamo singolarmente. Questo approccio può essere problematico dal punto di vista della pianificazione del percorso: come fare se la location non è direttamente raggiungibile dall'interno della singola cella, per esempio a causa della presenza di un muro?
 +
 +
L'approccio 1) è decisamente il più naturale. Si può comunque pensare di sviluppare tutti i metodi e poi confrontarli.
 +
 +
* Le caratteristiche della GUI devono essere:
 +
- menu gerarchico per la navigazione
 +
 +
- file di configurazione (direttamente lo stesso file del pianificatore) deve definire la piantina, le stanze, le location, (gruppi di location?).
 +
 +
* Il linguaggio in cui sviluppare la GUI può essere
 +
- MAIA forte rischio di avere problemi di sincronizzazione!
 +
 +
- SDL su C++. Optiamo per questa scelta, che presenta meno rischi.

Revision as of 18:10, 7 March 2009

General

The interface is used mainly to drive the Lurch wheelchair. It has different screens, corresponding to the different rooms or different environments where the wheelchair can move. The screens are organized hierarchically: a main screen permits to choose whether to drive the wheelchair or perform other tasks. The screens used for driving the wheelchair show a map of the environment, with different levels of details; e.g., a map might show just the rooms of a house, and then another map might show the living room with the furniture and ‘interesting’ positions (like near the table, in front of the TV, beside the window...).

The interface should be as accessible as possible. It can be driven by a BCI, used with the touch screen or with the keyboard. The BCI is based on the P300 and ErrP potentials; so the interface should highlight the possible choices on at a time (in orthogonal groups if the choices are numerous), and show the choice detected by the BCI for ErrP-based confirmation.

Maybe the screen should be updated while the wheelchair navigates; e.g., when the wheelchair enter into the kitchen, the GUI shows the map of the kitchen.

To Do

  • Feasibility check: wxWidgets and OpenMaia. Check if using OpenMaia with wxWidgets is okay for the stimulation synchronization. The timing difference between the highlighting of a choice and the switching of the synchronization square should be no more than the duration of a screen frame (about 16 ms for a 60 Hz screen).
  • Development of a storage system to store information about the layout and the action of the interfaces; an extension of the XML format used by OpenMaia to describe keyboards should be possible.

Communication Protocol Requirements

  • Cross-platform (at least Linux and Windows)
  • Based on the IP protocol
  • Asynchronous (as much as possible), so as not to block remote processes
  • Preferably, the protocol should be in ASCII, with fixed-width fields (the number of fields is variable, by necessity).

To Do

  • List of the pieces of information to be transferred between the application and the GUI

Communication Protocol

UML Sequence Diagram

Diagram

ComunicationProtocol.jpg

Comments about the diagram

Structure of MessageA:

  • Number of repetitions: number of flashings
  • Number of stimulations: number of flashings in one repetition
  • List of the stimulations: list of the possible stimulations with its type
  • Number of types
  • Stimulations sequence: it includes all the repetitions

Each stimulation must hav associated a type (e.g Icon, Row-Column)

Structure of SelectionA:

  • For each number of stimulation types you have a equal number of ids (e.g for Icon it will be used 1 id, for Row-Column 2 ids)

Graphic example of id:

IdExample.jpg

It will be also an end asynchronous message, that brings the BCI in pause, and it closes the graphic interface.

If the syncrony will be lost there's a Reset Message that restarts from the calibration. It will be activated when the number of the classifications is different from the number of the stimulations on the screen

Implementation of GUI

Primo incontro (04/03/2009)

  • Attualmente sulla carrozzella è installata una GUI molto semplice, che lavora all'interno del sistema BCI2000. L'idea è quella di creare una interfaccia asincrona che dovrà interagire con il sistema BCI2000 già realizzato mediante un socket TCP.
  • Ci sono diverse possibilità per implementare la GUI:

0) Stimoliamo le singole location presenti all'interno della mappa: il problema è che può diventare pesante, e che può essere difficile dal punto di vista cognitivo per l'utente.

1) Per prima cosa stimoliamo i diversi locali, e poi stimoliamo le location appartenenti al singolo locale selezionato (in realtà dovremo continuare a stimolare anche gli altri locali, nel caso in cui l'utente volesse uscire dalla stanza!) Le singole location possono essere stimolate in diversi modi: per gruppi, singolarmente, tramite una griglia.

2) Dividiamo la piantina in celle e poi le stimoliamo singolarmente. Questo approccio può essere problematico dal punto di vista della pianificazione del percorso: come fare se la location non è direttamente raggiungibile dall'interno della singola cella, per esempio a causa della presenza di un muro?

L'approccio 1) è decisamente il più naturale. Si può comunque pensare di sviluppare tutti i metodi e poi confrontarli.

  • Le caratteristiche della GUI devono essere:

- menu gerarchico per la navigazione

- file di configurazione (direttamente lo stesso file del pianificatore) deve definire la piantina, le stanze, le location, (gruppi di location?).

  • Il linguaggio in cui sviluppare la GUI può essere

- MAIA forte rischio di avere problemi di sincronizzazione!

- SDL su C++. Optiamo per questa scelta, che presenta meno rischi.