Wiki de Projets IMA - Contributions de l’utilisateur [fr]

BCI : Interface Cerveau Ordinateur

2014-02-23T15:52:53Z

Tchampag : /* Objectifs Futurs */

= Présentation =

== Contexte : ==

Le but général est de faciliter la vie des personnes paralysées avec un système interprétant directement leurs signaux cérébraux pour communiquer ou agir avec leur environnement. Les patients susceptibles d'utiliser cette technologie sont ceux atteint de paralysie musculaire complète (LIS : Locked In Syndrom) ou de SLA (Sclérose Latérale Amyotrophique). Ces maladies affectant très peu les fonctions cérébrales, cette technologie semble pouvoir devenir LA solution pour pallier au handicap. Ce projet est réalisé en collaboration avec l'équipe BCI du LAGIS.

Voilà ce que fait l'interface cerveau ordinateur (BCI : Brain Computer Interface ou BMI : Brain Machine Interface) de façon détaillée : les signaux électroencéphalographiques (EEG) sont acquis, numérisés et traités pour pouvoir ensuite être transformés en commandes. Une partie de ces informations est aussi affichée de manière simple pour l'utilisateur pour lui permettre un apprentissage plus rapide grâce à ce retour visuel.

Comment ?

[[Fichier:Schema-bci.png|600px|center]]

=== Acquisition ===

L'information cérébrale peut-être acquise de différentes manières :

- La première est non invasive, c'est à dire qu'elle ne nécessite pas d'intervention chirurgical visant à implanter un quelconque dispositif dans le corps du patient. A l'aide d'un casque muni d'électrodes placés sur le crane, on peut acquérir les signaux cérébraux passant à travers la boite crânienne (appelés signaux EEG). L'ordre de grandeur de ces signaux électriques ne dépasse pas le microvolt et les signaux acquis sont très fortement bruités. Mais ce dispositif est simple à mettre en œuvre et peut être utilisé aussi bien par les patients que par les chercheurs lors d'une phase expérimentale qu'est la nôtre.

- La seconde est semi-invasive, l’électrode servant à l'acquisition des signaux est implanté sous la surface de la boîte crânienne (ECoG : électrocorticogramme). Cette méthode permet d'augmenter considérablement la qualité des signaux qui sont beaucoup moins bruités que les signaux EEG. De plus, elle présente peu de risque puisque l’électrode est situé à l’extérieur de la dure-mère.

- La dernière est dite invasive, dans le sens où on vient placer des électrodes directement dans la masse cérébrale. Cette méthode a deja fait ses preuves : en 2005 un patient tétraplégique était capable de contrôler une prothèse robotique grâce à ce dispositif. Néanmoins, les électrodes ont une durée de vie limitée et les lésions cérébrales, dues à l’implantation des électrodes, sont irréversibles.

Une autre méthode consiste à détecter des signaux résultant de stimuli extérieurs connus (ERP : Event Related Potentials). Dans le cadre de notre projet, nous allons développer une interface graphique qui va être intégrer dans une interface BCI de type asynchrone basée sur l'analyse des signaux EEG acquis dans le cas de mouvements imaginés des pieds et des mains gauche ou droite. Les EEG considérés sont issus des activités ipsilatérales et contralatérales du cortex pré-moteur.

=== Traitement des signaux EEG ===

L'objectif du traitement des signaux EEG est de discriminer le mouvement imaginé par le patient (main droite, main gauche, pied). Pour cela, il est nécessaire d'extraire des signaux EEG un certains nombre d'attributs qui vont permettre de prendre une décision sur la commande à effectuer au sein de l'interface BCI en cours de developpement au LAGIS. Il est effectué par un logiciel d'analyse numérique comme MatLab, OpenVibe.

Les attributs extraits sont les amplitudes des signaux cérébraux dans certaines bandes de fréquence. Exemple, l'amplitude du rythme µ (entre 8Hz et 15Hz) disparait environ une seconde avant et pendant un mouvement des pieds ou des mains, mais aussi avant et pendant l'imagination de ce mouvement. Dans le même contexte on peut observer de grandes modifications d'amplitude du signal EEG dans la bande ß (entre 15Hz et 35Hz) occurrentes avant, pendant et juste après un mouvement. Ces signaux sont toujours très brefs mais la manière dont ils sont acquis (niveau d'invasivité) change complètement la manière dont ils seront traités. Les signaux mesurés à la surface du cerveau sont les plus problématiques car ils résultent de l'activité de millions de neurones.

Le pré-traitement a pour fonction l’élimination des artefacts (signaux induits par une autre activité corporelle que celle observée comme le clignement des yeux, la déglutition...) ainsi que l'amélioration du rapport signal sur bruit, bruit venant de tous les signaux à proximité, autant dire de tous les neurones à proximité donc quelques millions par point de mesure. Pour ce faire, différentes techniques sont mises en œuvre :

-Filtrage spatial : Combinaison linéaire des signaux des électrodes voisines. Par exemple le filtrage Laplacien, consistant à soustraire à un signal, la moyenne de ces voisins : très répandu car aussi simple qu’efficace pour éliminer le bruit.

-Filtrage fréquentiel : Sachant que nous cherchons à mesure l'amplitude des signaux dans les bandes de fréquence 8-35Hz il convient d'effectuer un filtrage fréquentiel éliminant toutes les fréquences hors de cette plage.

-Interface Synchrone : Une interface est dite Synchrone lorsque ce n'est pas l'activité spontanée du cerveau qui est analysée mais la réponse attendu à des stimulus générés par l'interface. Des signaux réflexifs sont générés de manière mécanique et inconsciente ce qui rend la phase d'apprentissage beaucoup plus simple.

-Interface Asynchrone : Une interface asynchrone à contrario analyse les signaux à tous moments. Et même si l'on peut sélectionner les zones du cerveaux à observer en choisissant l'emplacement des électrodes il n’empêche que les signaux observés sont le résultat de la somme de toutes les activités cérébrales avoisinante. Dans le cas de la réalisation ou de l'imagination de mouvements des mains (droite ou gauche) par exemple, il s'agit de reconnaitre dans les signaux cérébraux, le moment où un événement se produit et le type d'événement généré (droite ou gauche). Dans le cas de l'interface développée par le LAGIS les signaux EEG sont analysés en s'appuyant sur l'expertise des neurophysiologistes qui ont mis en évidence des modifications des signaux EEG dans certaines bandes de fréquence dans la zone moteur du cortex avant, pendant et après l'imagination ou la réalisation du mouvement.

=== Méthode d'exploitation des signaux cérébraux acquis (ou paradigme) ===
Afin de transformer les signaux acquis en commande d'un vas, d'un fauteuil roulant, ou autre, il est nécessaire de définir un paradigme expérimental. En d'autre termes : la manière dont les signaux cérébraux vont être exploités au sein de l'interface. Il est possible de distinguer deux grandes catégories d'interfaces BCI dans ce cas : les interfaces synchrones et les interfaces asynchrones.

=== Classification ===

A l'issue de la phase de traitement précédemment décrite, nous disposons d'un ensemble d'attributs mesurés sur les signaux à intervalles réguliers (tous les dixièmes de seconde).
A partir de ces vecteurs d'attributs, il s'agit d'identifier le type de mouvement réalisé ou imaginé(dans le cas d'une interface asynchrone) ou de décider si le sujet a répondu positivement au stimulus ou non (dans le cas d'une interface synchrone).

Il s'agit donc de décider si le vecteur d'attributs considéré est caractéristique d'un mouvement ou d'une réponse positive au stimulus. Ceci est le propre de ce que l'on appelle la classification.

Il existe deux grandes familles de techniques de classification : la classification supervisée et la classification non supervisée. La classification non supervisée consiste à prendre une décision d'identification sans aucune connaissance à priori sur les vecteurs d'attributs (ou éléments) à classer.

La classification supervisée part de la connaissance à priori des éléments que l'on vise à identifier et se décline en deux phases successives :

'''Offline'''
Une phase d'apprentissage basée sur l'analyse d'éléments connus et parfaitement identifiés. Il s'agit alors d'ajuster les paramètres du classifieur en fonction des éléments à priori identifiés

'''Online'''
Une phase de classement des éléments inconnus en utilisant le classifieur paramétré dans la phase précédente.

Dans le domaine des interfaces BCI, les techniques de classification les plus utilisées sont de type supervisées. Les plus courantes :

-LDA

-Les réseaux de neurones

-La classification floue

Cette étape a pour but d'exploiter les éléments caractéristiques extraits précédemment. Les méthodes choisies dépendent du type d'interface, on distinguera deux types d'interfaces: synchrones ou asynchrones. Le logiciel remplissant cette fonction a été développé par l'INRIA, il s'agit d'OpenVibe.

=== Commande ===

Le résultat de la classification des attributs extraits des signaux cérébraux st généralement mise sous forme de décision binaire. Par exemple : "Y a t il imagination de mouvement de la main droite?" Résultat : "Oui ou Non". Nous pouvons alors relier ce résultat à la partie opérative de l'interface et piloter ainsi un actionneur. Le nombre d'actionneur devant bien sur être adapté à l'interface qui les exploitera.

=== Interfaces BCI Existantes ===

'''Interface Synchrone'''

[[Fichier:Doc BoxAlgorithm P300SpellerVisualisation Snapshot.png|400px|right]]
Des applications ont déjà été créées pour permettre à une personne complètement immobile de communiquer ou de se déplacer. En terme d'interface de communication, le P300 Speller qui est basé sur la détection de potentiels endogènes évoqués, signaux correspondant à une activité cognitive. Cette interface permet à un sujet entraîné d’écrire plusieurs caractères par minute. Le principe est simple: le sujet regarde une matrice de caractères dont les colonnes et les lignes sont mises en surbrillance de manière aléatoire, il doit alors se concentrer sur le caractère qu'il veut écrire et compter son nombre d'illuminations. A chaque fois que la lettre est comptée une modifications des signaux se produit 300ms plus tard. Il est ainsi possible de détecter la colonne et la ligne sur lesquelles se situe le caractère intéressant. Après plusieurs scintillement on peut donc connaître la lettre choisi par le patient.

[[Fichier:Online-shooter.png|445px|left]]Il existe également tout un ensemble d'interface développées à partir de l'analyse et l'interprétation des signaux SSVEP (Steady-State Visual Evoked Potential). Ceux-ci ne sont pas générés par une action cognitive mais inconsciemment par notre cerveau. Lorsque nous regardons un objet clignotant sur l’écran, on retrouve la fréquence de ce clignotement sur notre lobe occipital. Ainsi, en créant une interface graphique constituée de plusieurs objets clignotants à différentes fréquences (de l'ordre de quelques dizaines de hertz), et en analysant les signaux évoqués, on peut reconnaitre l'objet observé par le sujet. Cette technique basée sur l'analyse de signaux reflexes s'avère très efficace et ne nécessite aucune phase d'apprentissage. L'exemple ci dessous pourrait représenter l'écran de saisie des commandes de pilotage d'un fauteuil roulant. Les deux carrés pourraient représenter une demande de rotation gauche ou droite tandis que le triangle représenterait une demande de marche avant.

[[Fichier:MuseumImmersive1.jpg|right|400px]]

'''Interface Asynchrone'''

La dernière technique est la plus complexe mais aussi celle avec le plus grand potentiel. Elle consiste à analyser les signaux cérébraux en vue de détecter la réalisation ou l'imagination de mouvements de différentes parties du corps. Dans notre cas, ce sont les mouvements des deux mains et des pieds qui sont exploités car plus présents au niveau du cortex moteur et donc plus faciles à détecter. L'identification de ces mouvements fournit donc un total de 3 commandes complètement indépendantes de toute stimulation extérieure. On ne peut prévoir à l'avance quand le sujet décidera d'imaginer un mouvement d'une des parties de son corps. Ce paradigme a déjà été exploité par l'INRIA de Rennes pour diriger un avatar dans un espace 3D virtuel matérialisant une visite virtuelle d'un musée. Les signaux correspondant aux mouvements de la main droite sont utilisés pour tourner à droite, ceux de la main gauche pour tourner à gauche et les mouvements des pieds pour avancer.

Des applications interfaces BCI ont aussi été développées pour commander des prothèses ou des fauteuils roulants. En effet, des expériences ont été menées avec succès sur un patient équipé d'une interface non invasive. Il a réussi à contrôler une main robotique grâce à l'analyse de ses rythmes sensorimoteurs, exploités pour détecter l'imagination de mouvement de la main. Ces essais ont été fais sur des personnes valides mais on peut imaginer les possibilités qui s'offrent à des personnes paralysées ou amputées.

== Objectif : ==

=== Formulation des besoins ===

[[Fichier:main3d.jpg|right|200px]]
Notre projet consiste au développement de l'interface graphique 3D d'une BCI, de type asynchrone basée su l'analyse de mouvements, réels ou imaginés, fournissant à l'utilisateur un feedback visuel ds commandes qu'il effectue. L'interface doit être composée de 2 couches graphiques dissociables :

- Une couche que nous appelons "la couche Feedback" : c'est la couche est au premier-plan. Elle affichera un avatar virtuel qui va exécuter le mouvement réel ou imaginé par le sujet. Par exemple, dans le cas d'un mouvement imaginé de la main, nous devons représenter graphiquement une main exécutant le mouvement imaginé par le sujet. Il peut s'agir d'une rotation du poignet, d'un mouvement de préhension, de mouvements des doigts etc. La visualisation du mouvement que le sujet imagine (le feedback) permettra peut-être un apprentissage de l'interface dit plus aisé pour le sujet mais on doit essayer de s'assurer qu'il ne soit pas un élément perturbateur. Nos inquiétudes sont fondées sur le même principe que l'instabilité des systèmes bouclés en général. On ne peut pas être certain qu'en observant son avatar à l'écran, le cerveau du sujet ne génère pas les sinusaux électriques correspondant au mouvement qu'il observe.

[[Fichier:piano 3d.jpg|300px|left]]
- Une couche ludique : celle-ci se situe au second-plan. Elle présente un objectif à réaliser par l'utilisateur en cohérence avec l'action imaginée et représentée par l'avatar. On peut par exemple imaginer un clavier de piano dans le cas d'un mouvement des doigts, d'un ballon qui se gonfle dans le cas de mouvements de préhension répétés.L'objectif permet de créer une forte motivation de l'utilisateur qui facilitera inconsciemment sa concentration. Par exemple : Si le mouvement imaginé par le sujet est de fermer et d'ouvrir la main, on sélectionnera une interface montrant par exemple une main actionnant une pompe et un arrière plan, des ballons à gonfler. Ou encore, avec un mouvement de doigt tapoter sur une table, on choisira d'avantage un piano en arrière plan joué par cette/ces main(s), ou même, avec un mouvement de serrage de vis avec la main, un meuble à monter le plus rapidement possible.

Ces couches doivent être affichables une par une ou en même temps. Le but est de pouvoir analyser l'impact du feedback sur les performances du sujet lors l'utilisation de l'interface BCI. Ainsi que de fournir au sujet un feedback "réaliste" des mouvements qu'il réalise ou imagine plutôt qu'un curseur sur un graphique.
[[Fichier:Piano main 3d.jpg|430px|center]]

=== Spécifications ===

Au sein de l'équipe BCI du LAGIS, les outils de développement les plus utilisés sont :

-MatLab : Pour le traitement des signaux.

-OpenVibe : Logiciel dédié BCI développé par l'INRIA de Rennes, pour la partie acquisition, traitement et feedback visuel.

-C++ : Pour le développement des blocs OpenVibe additionnels

Les contraintes à respecter dans le cadre de notre projet sont les suivantes :

-Respect et/ou compatibilité avec les technologies utilisées : Compatibilité de l'interface graphique avec OpenVibe. Compatibilité entre l'application et le nombre de signaux de commandes en sortie d'OpenVibe (main gauche, main droite, pieds, repos).

-Grande configurabilité : Ne connaissant pas l'utilisateur qui va utiliser le système, il doit être le plus personnalisable possible. Le but est que chacun puisse s'identifier à notre application pour obtenir les meilleurs résultats possibles. Cela implique donc d'assurer une grande configurabilité des objectifs pour l'utilisateur mais aussi de la manière d'afficher la complétion de ces objectifs et ses performances. Enfin il est important d'assurer une grande configurabilité du mouvement du feedback pour le rendre plus cohérent possible avec celui du sujet.

-Facilité de configuration : l'utilisateur doit pouvoir changer les options facilement et rapidement.

-Modulation du programme : le code source doit être le plus générique possible, documenté, commenté et le plus facilement modifiable possible.

= Étude des différents moteurs graphiques 3D =

== Spécifications ==

Les contraintes de choix du moteur 3D sont les suivantes par ordre de priorités décroissantes :

-Compatibilité avec le VRPN de Openvibe

-Permettre le développement multiplateforme (Linux, Windows, MacOS)

-Simplicité de développement

-Ressources nécessaires pour le mettre en œuvre minimisées

-Rendu visuel de qualité

== Choix d'un moteur ==

=== Moteur Jeux Vidéos Grand Public ===

Les moteurs suivants sont utilisés par les développeurs de jeux vidéos actuels. Leurs rendus graphiques sont les meilleurs, donc nous n'avons analysé en premier lieu que leurs autres caractéristiques :

-Anvil (Assassin's Creed) : License propriétaire privée d'Ubisoft, impossible d'acheter le DK

-CryEngine (Crysis) : Gratuit pour une utilisation non commerciale

-Dunia Engine (Farcry) : Non distribué

-Frostbite (Battlefield) : Non distribué

-Havok (Halo) :

-Hero Engine (Star Wars : Old Republic)

-Quest3D (Audiosurf)

-Source (Portal) : Non distribué

-Unreal Engine (Borderlands)

La plupart de ces moteurs sont très performants, ce qui implique l'utilisation de machines suffisamment puissantes pour les mettre en œuvre. De plus, certains sont conçus exclusivement pour du développement de jeu pour console de salon. Même si leur complexité de programmation est tout aussi abordable que les autres, nous ne pouvons pas choisir ces derniers.

=== Etude Comparative des Moteurs Graphiques ===

-Outerra : Ce moteur permet surtout la génération d'immenses espaces 3D jusqu'à des planètes entières. Le rendu global est effectivement très joli mais les détails de petits éléments sont assez simplistes. Ce moteur n'est donc pas du tout adapté à notre projet.

[[Fichier:Engines.png]]

=== Choix final ===

[[Fichier:Blender_logo.jpg]]

Après cette étude nous avons retenus '''Blender''' car il permet un développement très performant et rapide de model 3D réalistes. Nous comptons utiliser son moteur de jeu BlenderGame qui permet des interactions avec les models pour faire fonctionner nos interfaces. La difficulté que cela soulève est l'absence de VRPN dans ce moteur. Outil qui permet la communication entre un système tier et une interface de réalité virtuel. La suite va donc consister à interfacer Blender et Openvibe

= Développement d'une interface logicielle OpenVibe <-> Blender =

Notre objectif est de permettre une communication entre le logiciel OpenVibe, et le moteur graphique de Blender. Plusieurs protocoles de communication sont alors exploitables.

[[Fichier:Blender-Openvibe.png]]

== Reflexion ==

=== TCP/IP ===

Nos recherches nous ont amené à entrer en relation avec Romain Grandchamp, un doctorant ayant déjà travaillé sur ce sujet : c'est lui qui a réalisé une interface BCI implémentant une liaison TCP/IP entre Blender et BCI2000, un logiciel similaire à OpenVibe pour l'utilisation en recherche en BCI. C'est lui qui nous a proposée cette éventualité. Voici l'un de ses projets en cours : https://sites.google.com/site/romaingrandchamp/cerveaurium

Blender permet ce type de communication grace à un script python, mais ce n'est pas le cas d'OpenVibe.

Notre objectif ici est donc de créer un bloc OpenVibe qui implémentera une fonction de communication via ce protocole.

Ce bloc prendra en entrée un vecteur de donnée issu du classifieur. Le programmeur de scénario OpenVibe pourra paramétrer le message envoyé et pour quel donné du vecteur.
L'idée est donc d'importer des bibliothèques de communication tcp/ip dans openvibe pour développer un bloc pouvant communiquer aussi bien avec Blender qu'avec un autre programme voire un autre système en réseau. Au niveau du choix de protocole TCP ou UDP, c'est le protocole TCP qui satisfera le mieux notre besoin car il garantit l'intégrité des paquets transmis. Sachant que les messages seront transmis à chaque changement d'état d'un des paramètre d'entrée de la boite, il faut absolument que l'ordre soit correctement transmis à Blender. Le protocole UDP permettrai une meilleure réactivité, car plus rapide, mais il ne garantis pas le bon fonctionnement à chaque transmission, on pourrait envisager ce protocole dans le cas d'échanges de messages cadencé à une certaine fréquence, où la quantité rattrape la qualité de la communication.

La difficulté rencontrée ici est l'implémentation d'un bloc nouveau dans OpenVibe. Nous nous somme inscrits sur le forum d'OpenVibe pour nous faire aider de la communauté associée.

=== VRPN ===

Un autre moyen de communication est l'utilisation d'un VRPN, un ensemble de librairies permettant la liaison entre un moteur graphique et une interface de réalité virtuelle.
La bibliothèque VRPN est implémentée nativement dans OpenVibe ce qui nous amène à envisager d'implémenter cette même bibliothèque coté Blender. Le problème étant que nous n'avons pas de garantis que ceci soit possible. Il est possible d'étendre Blender grâce à des scripts python donc nous pensons que c'est effectivement faisable mais ne comprenons pas pourquoi est ce que cette fonction n'a pas déjà été implémenté étant donné la manière dont Blender est répandu et son aspet opensource. Cela dit, la communication VRPN utilise en réalité la communication réseau TCP classique comme base (port par défaut 3883), il s'agit donc en fait d'un protocole spécifique ajouté sur la base dont nous avons pas forcément utilité.

Après des recherches approfondies nous avons découvert qu'il existe un patch permettant de transformer Blender en BlenderCave. http://blendercave.limsi.fr/doku.php
Celui ci intègre de nouvelles fonctions notamment la possibilité de faire de la 3D stéréoscopique mais qui intègrerai également un VRPN.
L'inconvénient principal de cette configuration est que ce patch ne peut être utilisé que sur une révision précise de Blender.

L'objectif serait de vérifier sa compatibilité entre OpenVibe et ce dernier. Si c'est le cas, essayer de porter la fonctionnalité VRPN vers une version quelconque de Blender.

== Développement ==

Nous choisissons donc de développer un système de communication TCP car les briques de bases sont disponibles de chaque coté. En effet la bibliothèque VRPN utilise en fait une communication TCP, donc OpenVibe devrait pouvoir communiquer par TCP.

=== Objectif ===

Réaliser un nouveau bloc OpenVibe permettant de transmettre des données via TCP ou UDP. Nous sommes inscrits sur le Forum OpenVibe : http://openvibe.inria.fr/forum/
Et partons suivre les tutos OpenVibe sur la créations de nouveaux blocs : http://openvibe.inria.fr/introduction-algo-boxes/

=== Réalisation ===

'''Bloc OpenVibe'''

[[Fichier:BCI TCP Writer Champeirock.png|left]][[Fichier:Wireshark Icon BCI Champeiro.png|right|50px]]
Après avoir commencé à développer notre propre Bloc nous avons été informé par la communauté qu'un bloc TCP Writer venait d'être développé (decembre 2013) mais était en version Non Stable. Nous sommes donc repartis de cette base-ci. Doc TCP Writer : http://openvibe.inria.fr/documentation/unstable/Doc_BoxAlgorithm_TCPWriter.html
Nous avons donc analysé la structure de la transmission avec un outils type WireShark
La boite fait office de Server TCP qui transmet son vecteur d'information d'entrée sur une Socket TCP. On peut choisir 3 types de données de sorties : Raw, Hexa ou String.
Mais en pratique, on ne peut utiliser les formats Hex ou String que pour transmettre des données de stimulation, ce qui n'est pas notre cas ici vu que nous voulons transmettre un vecteur d'information. Nous allons donc nous intéresser au format du message transmis au format Raw.
- La boîte envoie d'abord à chaque client qui se connecte huit variables uint32 :
numéro de version
endianness : 0 == inconnue , 1 == little , 2 == big, 3 == PDP
la fréquence d'échantillonnage du signal
le nombre de canaux (nb de lignes de la matrice d'info transmise)
le nombre d'échantillons par bloc (colonnes de la matrice)
Trois variables de rembourrage

8 * 4 = 32 octets au total. Les 6 dernières variables sont dans l'ordre des octets du flux.

Plusieurs clients peuvent se connecter à la socket. La boîte continue à envoyer des données à chaque client jusqu'à ce que le scénario OpenVibe se termine ou que le client se déconnecte.

Analyse détaillée d'une trame pour la transmission d'une Matrice (1,1) :
Server : OpenVibe : TCP Writer

Client : NetCat : nc localhost 5678

Sniffeur de Tram : WireShark

Dans un premier temps le client reçoit 8 paquets dont 4 octets de données. Ce qui correspondrait donc aux 8 variables annoncées. Nous avons fais une étude détaillé pour nous en assurer.

Format et découpage des octets :
14 Octets Ethernets (Addresses, Type)
20 Octets d'en-tête IPv4
32 Octets TCP
4 Octets de Données

1er Envoi
00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 38 5b 08 40 00 40 06 e1 b5 7f 00 00 01 7f 00
00 01 16 2e b7 35 2e ae fd c1 61 71 6f 2c 80 18
08 00 fe 2c 00 00 01 01 08 0a 09 34 a6 e9 09 34
a6 c9 00 00 00 01
Numéro de version : 1, semble correspondre au numéro de version du bloc TCP Writer plus qu'à la version d'OpenVibe

2em Envoi
00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 38 5b 09 40 00 40 06 e1 b4 7f 00 00 01 7f 00
00 01 16 2e b7 35 2e ae fd c5 61 71 6f 2c 80 18
08 00 fe 2c 00 00 01 01 08 0a 09 34 a6 ea 09 34
a6 e9 00 00 00 01
Endianness : Little Endian

3em Envoi
00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 38 5b 0a 40 00 40 06 e1 b3 7f 00 00 01 7f 00
00 01 16 2e b7 35 2e ae fd c9 61 71 6f 2c 80 18
08 00 fe 2c 00 00 01 01 08 0a 09 34 a6 ea 09 34
a6 ea 00 00 00 00
Fréquence d'échantillonnage : 0 Cette valeur n'est valide que dans le cas de la transmission d'un signal ce qui n'est pas le cas ici

4em Envoi
00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 38 5b 0b 40 00 40 06 e1 b2 7f 00 00 01 7f 00
00 01 16 2e b7 35 2e ae fd cd 61 71 6f 2c 80 18
08 00 fe 2c 00 00 01 01 08 0a 09 34 a6 ea 09 34
a6 ea 01 00 00 00
Nombre de Lignes. En considérant seulement le premier octet on obtient effectivement la valeur attendue 1 mais nous ne comprenons pas pourquoi elle serait à cet endroit.

5em Envoi
00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 38 5b 0c 40 00 40 06 e1 b1 7f 00 00 01 7f 00
00 01 16 2e b7 35 2e ae fd d1 61 71 6f 2c 80 18
08 00 fe 2c 00 00 01 01 08 0a 09 34 a6 ea 09 34
a6 ea 00 00 00 01
Nombre de Colonnes = 1

6em Envoi
00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 38 5b 0d 40 00 40 06 e1 b0 7f 00 00 01 7f 00
00 01 16 2e b7 35 2e ae fd d5 61 71 6f 2c 80 18
08 00 fe 2c 00 00 01 01 08 0a 09 34 a6 ea 09 34
a6 ea 00 00 00 00
Variable de rembourrage 1

7em Envoi
00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 38 5b 0e 40 00 40 06 e1 af 7f 00 00 01 7f 00
00 01 16 2e b7 35 2e ae fd d9 61 71 6f 2c 80 18
08 00 fe 2c 00 00 01 01 08 0a 09 34 a6 ea 09 34
a6 ea 00 00 00 00
Variable de rembourrage 2

8em Envoi
00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 38 5b 0f 40 00 40 06 e1 ae 7f 00 00 01 7f 00
00 01 16 2e b7 35 2e ae fd dd 61 71 6f 2c 80 18
08 00 fe 2c 00 00 01 01 08 0a 09 34 a6 ea 09 34
a6 ea 00 00 00 00
Variable de rembourrage 3

Ensuite La trame est composé d'un total de 74 Octets :
14 Octets Ethernets (Addresses, Type)
20 Octets d'en-tête IPv4
32 Octets TCP
8 Octets de Données

00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 3c 7a 2f 40 00 40 06 c2 8a 7f 00 00 01 7f 00
00 01 16 2e 94 10 05 7b a6 c7 6f c2 f5 62 80 18
08 00 fe 30 00 00 01 01 08 0a 08 09 f7 58 08 09
f7 43 75 df 7a cb fa e0 d9 3f

Interprétation
Adresses : Les deux programmes étant en local ses octets sont laissés à 0 Type : 0x0800 ==> IP)
IPv4 : 4 pour IPv4 par defaut
Header Length : 5 : 5 x 32 bits
Length : 00 3c = 60 Correspondant bien aux 74 octets totaux moins les paquets Ethernet
Identification : 7a 2f valeur dépendante du message et incrémentée chaque fois
Flags : 04 00 pour ne pas fragmenter
Time To Live : 40 = 64 Ce qui est largement suffisant étant donné que tnous travaillons en local
Protocol : 06 TCP
CheckSum : c2 8a Correct
Adresse Source : 7f 00 00 01 Correspond à l'adresse localhost
Adresse Destination : 7f 00 00 01 Idem
Port Source : 16 2e = 5678 Est le port configuré dans le bloc TCP Writer d'OpenVibe
Port Destination : 94 10 = 37904
Sequence Number : 05 7b a6 c7
Acknowledgment : 6f c2 f5 62
Longueur de l'en-tete : 80 = 32 Octets que nous sommes en train de détailler
Flags : 18 = Acknowledgment et Push activés
Window Size Value 08 00 = 2048 Octets seront envoyés sans attendre de confirmation d'un éventuel client
CheckSum : fe 30 : La validation étant désactivé d'après WireShark
00 00
Options 01 01 : Ne fait Rien
Kind : 08 TimeStamp(8)
Length : 0a = 10 Octets concernant les variables de temps
Heure d'envoie celon l'émeteur : 08 09 f7 58
Timestamp Echo Replay :08 09 f7 43 
8 Octets de Données : 75 df 7a cb fa e0 d9 3f

L'heure d'envoie de l'émeteur : 08 09 f7 58 que nous avons observer conrespondrait à la date du 11/4/1974 à 1:07:52. Nous avons donc déduis que le server n'enverrait donc pas les données de la manière dont WireShark les interprète... Mais nous n'avons pas plus d'information sur les envois de données que celle rappelées plus haut.

'''Script Blender'''

Nous avons essayé d'écrire un script implémentant soit une communication TCP ou UDP dans le cas d'une future amélioration, tout en restant simple. La communication TCP étant celle que nous visons à utiliser actuellement, et la communication UDP étant celle des VRPN :

<code>
# Projet BCI Lagis Lille
# 
# TCP client

import socket
import sys
#Here enter mode TCP or VRPN 
#depending on how you send data from OpenVibe
MODE = "TCP"
HOST = "localhost"
BUFFER_SIZE = 1024
#Port are here defined as defaults openvibe values
if(MODE == "TCP"):
# Create a socket TCP (SOCK_STREAM for TCP socket)
PORT = 5678
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
else:
# Create a socket UDP (SOCK_DGRAM for UDP socket)
print("VRPN")
PORT = 3883
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
try:
if(MODE == "TCP"):
# Connect to server
sock.connect((HOST, PORT))
else:
sock.bind((HOST, PORT))
# Receive data from the server and shut down
ov_msg = sock.recv(BUFFER_SIZE)
finally:
sock.close()
print("Data :", ov_msg)
</code>

La communication TCP étant fonctionnelle, nous avons analysé les échanges OpenVibe<->Blender avec WireShark. Le script client étant exécuté periodiquement dans blender (au rythme des image de l'animation) on observe un taux de réussite d’échange de donnée supérieur à 85%. Les échecs étant probablement dus aux accès concurrents entre le serveur et le client. Ces erreurs n'engendrerai donc pas de défaut de fonctionnement du système global. Tout au plus, on observerai un retard d'une ou deux images entre le moment où la donnée est recue et le moment ou l'animation est modifié. Mais étant donnée la conception du serveur (TCP Writer), l'en-tête est renvoyé à chaque fois qu'un échange a échoué. Autrement dit, il est nécessaire d'échangé au moins 9 paquets consécutivement sans erreurs pour pouvoir avoir enfin une donnée exploitable.

[[Fichier:BCI WireShark TCP OVtoB.png]]

'''Conversion de donnée OpenVibe'''

Les données d'OpenVibe sont formatés en EBML (Extensible Binary Meta Language) historiquement un formatage pour fichiers multimédia propriétaire de Matroska. Pour les rendre exploitable dans blender nous avons trouver un parser EBML to Python.

Sources : http://sjohannes.wordpress.com/2010/04/28/matroska-tagging-support/

Code Python : http://bazaar.launchpad.net/~exaile-devel/exaile/exaile-0.3.x/view/head:/xl/metadata/_matroska.py

Cette bibliothèque a été développé dans un besoin de convertir des fichiers multimédia en python. Comme notre projet est très différent nous avons étudié ce code pour voir si effectivement il pourrait répondre à nos besoins.
Nous avons donc utilisé le Bloc EBML Spy d'OpenVibe pour observer les données, connues, provenant du classifier du scenario "Handball-replay". La donnée utile pour nous étant un nombre réel compris entre -10 et +10 et indiquant si le sujet présentait des mouvement de la main droite ou de la main gauche.

[[Fichier:BCI EBML Stream Champeiro.png|1000px]]

Dans le code source du parser, on trouve des lignes 292 à 376 les tags qui sont actuellement convertis. Malheureusement, aucun des tags openvibe n'est pris en compte par ce parser. Nous avons donc envisagé d'adapter ce parser à nos besoin quitte à le reconstruire presque entièrement.

'''Client VRPN'''

La communication TCP s'avérant infructueuse nous avons envisagé de développé plutot un client VRPN en python pour Blender. Pour se faire nous avons utilisé la bibliothèque VRPN version 7.30 ainsi qu'un parser de langages objet : SWIG version 2.0.12

= Développement du retour graphique sous blender =

== Objectif ==

Le développement sous Blender consiste à créer un feedback visuel pour l’utilisateur. Il faut donc modéliser une main qui bouge selon la volonté de mouvement de l’utilisateur. Dans un premier temps, il faut créer une main, et lui associer une animation pour qu’elle pianote, superposée à un piano dont les touches bougent en même temps que les doigts ; l’objectif est que lorsque l’utilisateur veut pianoter, il voit la main pianoter à sa place et appuyer sur les touches du piano. Le logiciel de création de Blender permet d’associer un signal d’entrée, par exemple l’appui sur une touche du clavier (d’ordinateur), à l’animation de la main et du piano. L’intérêt serait alors que le signal d’entrée soit provoqué par le logiciel OpenVibe lors de l’imagination de mouvement de l’utilisateur.

== Réalisation ==

Une main déjà modélisée et articulée, ainsi qu’un décor d’opéra contenant un piano, ont été trouvés sur des sites communautaires de Blender.
Pour le piano, il a été nécessaire de recréer le clavier (l’ensemble des touches) car dans le modèle utilisé, elles étaient toutes solidaires. Le clavier à touches indépendantes a donc été placé à la place du clavier original. Maintenant, il est donc possible de faire bouger chaque touche indépendamment, et donc de créer l’animation des touches qui s’enfoncent.

[[Fichier:BCI_piano_Champeiro.png]]

Pour la main, une animation était déjà pré-programmée, qui montrait la main d’abord fermée, puis qui s’ouvrait le plus possible, sans que le rendu paraisse irréaliste. La construction de l’animation est basée sur une série de marqueurs qui indiquent la position que doivent avoir chaque membres à certaines images de l’animation. En réutilisant ces marqueurs, il est donc possible de créer le mouvement de pianotement voulu.

[[Fichier:BCI_roll1_Champeiro.png]] [[Fichier:BCI_roll2_Champeiro.png]]

''Vue du modèle de la main au repos et pendant le pianotement''

Une étape intéressante serait de pouvoir agir sur la vitesse de l’animation de la main, en fonction de l’intensité de l’imagination du mouvement par l’utilisateur.

== Objectifs Futurs ==

Nous avons créé une ébauche de deuxième scène, avec un mouvement de main différent (fermeture et ouverture de la main), où le but est de fermer la main sur une pompe pour gonfler un ballon qui y est connecté. A l'heure actuelle, cette scène n'est esthétiquement pas terminée, mais est utilisable.

Avec une expérience plus avancée de Blender, il serait aussi possible d'utiliser la gestion des collisions pour que le mouvement de la main agisse visuellement directement sur les objets, comme les touches du piano ou la pompe. Cela augmenterait le réalisme du feedback. Nous ne sommes toutefois pas encore en mesure de réaliser cela.

Le but final serait de pouvoir créer une scène par mouvement possible de main ; il y a déjà une scène pour le pianotement, la fermeture de la main, et on pourrait imaginer une scène pour un mouvement de grattement, ou un mouvement de balancier de la main.

= Gestion de Projet et Sources =

== Planning ==

[[Fichier:Gant PFE BCI.png|650px]]

'''Présentation Mi-PFE'''

10/12/2013

'''Présentation BCI

21/02/2014

'''Présentation Polytech'Lille'''

27/02/2014

== Bibliographie ==

=== OpenVibe ===

http://openvibe.inria.fr/

http://openvibe.inria.fr/tag/vrpn/

http://openvibe.inria.fr/documentation-index/#User+Documentation

=== Moteur 3D ===

https://fr.wikipedia.org/wiki/Moteur_3D

http://www.desura.com/search?q=engine+3d&sa.x=0&sa.y=0

http://www.ogre3d.fr/

http://www.outerra.com/forum/index.php?topic=637.0

http://jeux.developpez.com/tutoriels/?page=prog-3d#ogre-3d

http://mycryengine.com/index.php?conid=70

http://www.havok.com/try-havok

http://www.desura.com/engines/unreal-development-kit/downloads/udk

http://www.truevision3d.com/downloads.php

http://hub.jmonkeyengine.org/

http://www.neoaxis.com/neoaxis/licensing

http://www.shivaengine.com/download.html

http://unity3d.com/unity/download

https://store.unity3d.com/

http://www.twinmotion.com/acheter.html

http://www.worldofleveldesign.com/categories/level_design_tutorials/recommended-game-engines.php

=== Blender ===

http://www.blender.org/education-help/tutorials/game-engine/

http://blendercave.limsi.fr/doku.php

http://www.blendswap.com/

=== EEG ===

http://openeeg.sourceforge.net/doc/sw/

http://www.emotiv.com/store/app.php

=== Autres Projets BCI ===

http://air.imag.fr/index.php/Armind

https://sites.google.com/site/romaingrandchamp/cerveaurium

= Annexe =

== Journal ==

'''Entrée 1'''

Installation de OpenVibe (en deux fois pour le rendre fonctionnel)

'''Entrée 2'''

Réalisation de l'ensemble des tutoriels disponibles sur le site de l'INRIA mais malheureusement, cela ne nous a pas amené jusqu'à l'utilisation du VRPN. Nous Projetons maintenant d'étudier les moteurs graphiques 3D existant pour en choisir un pour notre développement.

'''Entrée 3'''

Installation de Ogre. Nécessite un IDE ainsi qu'un compilateur (Comblock + MinGW pour Windows)

Configuration : Installation de MinGW à la racine de C:/ Installation de Ogre Installation de Comblock
Problème pour compiller

BCI : Interface Cerveau Ordinateur

2014-02-23T14:35:58Z

Tchampag : /* Réalisation */

= Présentation =

== Contexte : ==

Le but général est de faciliter la vie des personnes paralysées avec un système interprétant directement leurs signaux cérébraux pour communiquer ou agir avec leur environnement. Les patients susceptibles d'utiliser cette technologie sont ceux atteint de paralysie musculaire complète (LIS : Locked In Syndrom) ou de SLA (Sclérose Latérale Amyotrophique). Ces maladies affectant très peu les fonctions cérébrales, cette technologie semble pouvoir devenir LA solution pour pallier au handicap. Ce projet est réalisé en collaboration avec l'équipe BCI du LAGIS.

Voilà ce que fait l'interface cerveau ordinateur (BCI : Brain Computer Interface ou BMI : Brain Machine Interface) de façon détaillée : les signaux électroencéphalographiques (EEG) sont acquis, numérisés et traités pour pouvoir ensuite être transformés en commandes. Une partie de ces informations est aussi affichée de manière simple pour l'utilisateur pour lui permettre un apprentissage plus rapide grâce à ce retour visuel.

Comment ?

[[Fichier:Schema-bci.png|600px|center]]

=== Acquisition ===

L'information cérébrale peut-être acquise de différentes manières :

- La première est non invasive, c'est à dire qu'elle ne nécessite pas d'intervention chirurgical visant à implanter un quelconque dispositif dans le corps du patient. A l'aide d'un casque muni d'électrodes placés sur le crane, on peut acquérir les signaux cérébraux passant à travers la boite crânienne (appelés signaux EEG). L'ordre de grandeur de ces signaux électriques ne dépasse pas le microvolt et les signaux acquis sont très fortement bruités. Mais ce dispositif est simple à mettre en œuvre et peut être utilisé aussi bien par les patients que par les chercheurs lors d'une phase expérimentale qu'est la nôtre.

- La seconde est semi-invasive, l’électrode servant à l'acquisition des signaux est implanté sous la surface de la boîte crânienne (ECoG : électrocorticogramme). Cette méthode permet d'augmenter considérablement la qualité des signaux qui sont beaucoup moins bruités que les signaux EEG. De plus, elle présente peu de risque puisque l’électrode est situé à l’extérieur de la dure-mère.

- La dernière est dite invasive, dans le sens où on vient placer des électrodes directement dans la masse cérébrale. Cette méthode a deja fait ses preuves : en 2005 un patient tétraplégique était capable de contrôler une prothèse robotique grâce à ce dispositif. Néanmoins, les électrodes ont une durée de vie limitée et les lésions cérébrales, dues à l’implantation des électrodes, sont irréversibles.

Une autre méthode consiste à détecter des signaux résultant de stimuli extérieurs connus (ERP : Event Related Potentials). Dans le cadre de notre projet, nous allons développer une interface graphique qui va être intégrer dans une interface BCI de type asynchrone basée sur l'analyse des signaux EEG acquis dans le cas de mouvements imaginés des pieds et des mains gauche ou droite. Les EEG considérés sont issus des activités ipsilatérales et contralatérales du cortex pré-moteur.

=== Traitement des signaux EEG ===

L'objectif du traitement des signaux EEG est de discriminer le mouvement imaginé par le patient (main droite, main gauche, pied). Pour cela, il est nécessaire d'extraire des signaux EEG un certains nombre d'attributs qui vont permettre de prendre une décision sur la commande à effectuer au sein de l'interface BCI en cours de developpement au LAGIS. Il est effectué par un logiciel d'analyse numérique comme MatLab, OpenVibe.

Les attributs extraits sont les amplitudes des signaux cérébraux dans certaines bandes de fréquence. Exemple, l'amplitude du rythme µ (entre 8Hz et 15Hz) disparait environ une seconde avant et pendant un mouvement des pieds ou des mains, mais aussi avant et pendant l'imagination de ce mouvement. Dans le même contexte on peut observer de grandes modifications d'amplitude du signal EEG dans la bande ß (entre 15Hz et 35Hz) occurrentes avant, pendant et juste après un mouvement. Ces signaux sont toujours très brefs mais la manière dont ils sont acquis (niveau d'invasivité) change complètement la manière dont ils seront traités. Les signaux mesurés à la surface du cerveau sont les plus problématiques car ils résultent de l'activité de millions de neurones.

Le pré-traitement a pour fonction l’élimination des artefacts (signaux induits par une autre activité corporelle que celle observée comme le clignement des yeux, la déglutition...) ainsi que l'amélioration du rapport signal sur bruit, bruit venant de tous les signaux à proximité, autant dire de tous les neurones à proximité donc quelques millions par point de mesure. Pour ce faire, différentes techniques sont mises en œuvre :

-Filtrage spatial : Combinaison linéaire des signaux des électrodes voisines. Par exemple le filtrage Laplacien, consistant à soustraire à un signal, la moyenne de ces voisins : très répandu car aussi simple qu’efficace pour éliminer le bruit.

-Filtrage fréquentiel : Sachant que nous cherchons à mesure l'amplitude des signaux dans les bandes de fréquence 8-35Hz il convient d'effectuer un filtrage fréquentiel éliminant toutes les fréquences hors de cette plage.

-Interface Synchrone : Une interface est dite Synchrone lorsque ce n'est pas l'activité spontanée du cerveau qui est analysée mais la réponse attendu à des stimulus générés par l'interface. Des signaux réflexifs sont générés de manière mécanique et inconsciente ce qui rend la phase d'apprentissage beaucoup plus simple.

-Interface Asynchrone : Une interface asynchrone à contrario analyse les signaux à tous moments. Et même si l'on peut sélectionner les zones du cerveaux à observer en choisissant l'emplacement des électrodes il n’empêche que les signaux observés sont le résultat de la somme de toutes les activités cérébrales avoisinante. Dans le cas de la réalisation ou de l'imagination de mouvements des mains (droite ou gauche) par exemple, il s'agit de reconnaitre dans les signaux cérébraux, le moment où un événement se produit et le type d'événement généré (droite ou gauche). Dans le cas de l'interface développée par le LAGIS les signaux EEG sont analysés en s'appuyant sur l'expertise des neurophysiologistes qui ont mis en évidence des modifications des signaux EEG dans certaines bandes de fréquence dans la zone moteur du cortex avant, pendant et après l'imagination ou la réalisation du mouvement.

=== Méthode d'exploitation des signaux cérébraux acquis (ou paradigme) ===
Afin de transformer les signaux acquis en commande d'un vas, d'un fauteuil roulant, ou autre, il est nécessaire de définir un paradigme expérimental. En d'autre termes : la manière dont les signaux cérébraux vont être exploités au sein de l'interface. Il est possible de distinguer deux grandes catégories d'interfaces BCI dans ce cas : les interfaces synchrones et les interfaces asynchrones.

=== Classification ===

A l'issue de la phase de traitement précédemment décrite, nous disposons d'un ensemble d'attributs mesurés sur les signaux à intervalles réguliers (tous les dixièmes de seconde).
A partir de ces vecteurs d'attributs, il s'agit d'identifier le type de mouvement réalisé ou imaginé(dans le cas d'une interface asynchrone) ou de décider si le sujet a répondu positivement au stimulus ou non (dans le cas d'une interface synchrone).

Il s'agit donc de décider si le vecteur d'attributs considéré est caractéristique d'un mouvement ou d'une réponse positive au stimulus. Ceci est le propre de ce que l'on appelle la classification.

Il existe deux grandes familles de techniques de classification : la classification supervisée et la classification non supervisée. La classification non supervisée consiste à prendre une décision d'identification sans aucune connaissance à priori sur les vecteurs d'attributs (ou éléments) à classer.

La classification supervisée part de la connaissance à priori des éléments que l'on vise à identifier et se décline en deux phases successives :

'''Offline'''
Une phase d'apprentissage basée sur l'analyse d'éléments connus et parfaitement identifiés. Il s'agit alors d'ajuster les paramètres du classifieur en fonction des éléments à priori identifiés

'''Online'''
Une phase de classement des éléments inconnus en utilisant le classifieur paramétré dans la phase précédente.

Dans le domaine des interfaces BCI, les techniques de classification les plus utilisées sont de type supervisées. Les plus courantes :

-LDA

-Les réseaux de neurones

-La classification floue

Cette étape a pour but d'exploiter les éléments caractéristiques extraits précédemment. Les méthodes choisies dépendent du type d'interface, on distinguera deux types d'interfaces: synchrones ou asynchrones. Le logiciel remplissant cette fonction a été développé par l'INRIA, il s'agit d'OpenVibe.

=== Commande ===

Le résultat de la classification des attributs extraits des signaux cérébraux st généralement mise sous forme de décision binaire. Par exemple : "Y a t il imagination de mouvement de la main droite?" Résultat : "Oui ou Non". Nous pouvons alors relier ce résultat à la partie opérative de l'interface et piloter ainsi un actionneur. Le nombre d'actionneur devant bien sur être adapté à l'interface qui les exploitera.

=== Interfaces BCI Existantes ===

'''Interface Synchrone'''

[[Fichier:Doc BoxAlgorithm P300SpellerVisualisation Snapshot.png|400px|right]]
Des applications ont déjà été créées pour permettre à une personne complètement immobile de communiquer ou de se déplacer. En terme d'interface de communication, le P300 Speller qui est basé sur la détection de potentiels endogènes évoqués, signaux correspondant à une activité cognitive. Cette interface permet à un sujet entraîné d’écrire plusieurs caractères par minute. Le principe est simple: le sujet regarde une matrice de caractères dont les colonnes et les lignes sont mises en surbrillance de manière aléatoire, il doit alors se concentrer sur le caractère qu'il veut écrire et compter son nombre d'illuminations. A chaque fois que la lettre est comptée une modifications des signaux se produit 300ms plus tard. Il est ainsi possible de détecter la colonne et la ligne sur lesquelles se situe le caractère intéressant. Après plusieurs scintillement on peut donc connaître la lettre choisi par le patient.

[[Fichier:Online-shooter.png|445px|left]]Il existe également tout un ensemble d'interface développées à partir de l'analyse et l'interprétation des signaux SSVEP (Steady-State Visual Evoked Potential). Ceux-ci ne sont pas générés par une action cognitive mais inconsciemment par notre cerveau. Lorsque nous regardons un objet clignotant sur l’écran, on retrouve la fréquence de ce clignotement sur notre lobe occipital. Ainsi, en créant une interface graphique constituée de plusieurs objets clignotants à différentes fréquences (de l'ordre de quelques dizaines de hertz), et en analysant les signaux évoqués, on peut reconnaitre l'objet observé par le sujet. Cette technique basée sur l'analyse de signaux reflexes s'avère très efficace et ne nécessite aucune phase d'apprentissage. L'exemple ci dessous pourrait représenter l'écran de saisie des commandes de pilotage d'un fauteuil roulant. Les deux carrés pourraient représenter une demande de rotation gauche ou droite tandis que le triangle représenterait une demande de marche avant.

[[Fichier:MuseumImmersive1.jpg|right|400px]]

'''Interface Asynchrone'''

La dernière technique est la plus complexe mais aussi celle avec le plus grand potentiel. Elle consiste à analyser les signaux cérébraux en vue de détecter la réalisation ou l'imagination de mouvements de différentes parties du corps. Dans notre cas, ce sont les mouvements des deux mains et des pieds qui sont exploités car plus présents au niveau du cortex moteur et donc plus faciles à détecter. L'identification de ces mouvements fournit donc un total de 3 commandes complètement indépendantes de toute stimulation extérieure. On ne peut prévoir à l'avance quand le sujet décidera d'imaginer un mouvement d'une des parties de son corps. Ce paradigme a déjà été exploité par l'INRIA de Rennes pour diriger un avatar dans un espace 3D virtuel matérialisant une visite virtuelle d'un musée. Les signaux correspondant aux mouvements de la main droite sont utilisés pour tourner à droite, ceux de la main gauche pour tourner à gauche et les mouvements des pieds pour avancer.

Des applications interfaces BCI ont aussi été développées pour commander des prothèses ou des fauteuils roulants. En effet, des expériences ont été menées avec succès sur un patient équipé d'une interface non invasive. Il a réussi à contrôler une main robotique grâce à l'analyse de ses rythmes sensorimoteurs, exploités pour détecter l'imagination de mouvement de la main. Ces essais ont été fais sur des personnes valides mais on peut imaginer les possibilités qui s'offrent à des personnes paralysées ou amputées.

== Objectif : ==

=== Formulation des besoins ===

[[Fichier:main3d.jpg|right|200px]]
Notre projet consiste au développement de l'interface graphique 3D d'une BCI, de type asynchrone basée su l'analyse de mouvements, réels ou imaginés, fournissant à l'utilisateur un feedback visuel ds commandes qu'il effectue. L'interface doit être composée de 2 couches graphiques dissociables :

- Une couche que nous appelons "la couche Feedback" : c'est la couche est au premier-plan. Elle affichera un avatar virtuel qui va exécuter le mouvement réel ou imaginé par le sujet. Par exemple, dans le cas d'un mouvement imaginé de la main, nous devons représenter graphiquement une main exécutant le mouvement imaginé par le sujet. Il peut s'agir d'une rotation du poignet, d'un mouvement de préhension, de mouvements des doigts etc. La visualisation du mouvement que le sujet imagine (le feedback) permettra peut-être un apprentissage de l'interface dit plus aisé pour le sujet mais on doit essayer de s'assurer qu'il ne soit pas un élément perturbateur. Nos inquiétudes sont fondées sur le même principe que l'instabilité des systèmes bouclés en général. On ne peut pas être certain qu'en observant son avatar à l'écran, le cerveau du sujet ne génère pas les sinusaux électriques correspondant au mouvement qu'il observe.

[[Fichier:piano 3d.jpg|300px|left]]
- Une couche ludique : celle-ci se situe au second-plan. Elle présente un objectif à réaliser par l'utilisateur en cohérence avec l'action imaginée et représentée par l'avatar. On peut par exemple imaginer un clavier de piano dans le cas d'un mouvement des doigts, d'un ballon qui se gonfle dans le cas de mouvements de préhension répétés.L'objectif permet de créer une forte motivation de l'utilisateur qui facilitera inconsciemment sa concentration. Par exemple : Si le mouvement imaginé par le sujet est de fermer et d'ouvrir la main, on sélectionnera une interface montrant par exemple une main actionnant une pompe et un arrière plan, des ballons à gonfler. Ou encore, avec un mouvement de doigt tapoter sur une table, on choisira d'avantage un piano en arrière plan joué par cette/ces main(s), ou même, avec un mouvement de serrage de vis avec la main, un meuble à monter le plus rapidement possible.

Ces couches doivent être affichables une par une ou en même temps. Le but est de pouvoir analyser l'impact du feedback sur les performances du sujet lors l'utilisation de l'interface BCI. Ainsi que de fournir au sujet un feedback "réaliste" des mouvements qu'il réalise ou imagine plutôt qu'un curseur sur un graphique.
[[Fichier:Piano main 3d.jpg|430px|center]]

=== Spécifications ===

Au sein de l'équipe BCI du LAGIS, les outils de développement les plus utilisés sont :

-MatLab : Pour le traitement des signaux.

-OpenVibe : Logiciel dédié BCI développé par l'INRIA de Rennes, pour la partie acquisition, traitement et feedback visuel.

-C++ : Pour le développement des blocs OpenVibe additionnels

Les contraintes à respecter dans le cadre de notre projet sont les suivantes :

-Respect et/ou compatibilité avec les technologies utilisées : Compatibilité de l'interface graphique avec OpenVibe. Compatibilité entre l'application et le nombre de signaux de commandes en sortie d'OpenVibe (main gauche, main droite, pieds, repos).

-Grande configurabilité : Ne connaissant pas l'utilisateur qui va utiliser le système, il doit être le plus personnalisable possible. Le but est que chacun puisse s'identifier à notre application pour obtenir les meilleurs résultats possibles. Cela implique donc d'assurer une grande configurabilité des objectifs pour l'utilisateur mais aussi de la manière d'afficher la complétion de ces objectifs et ses performances. Enfin il est important d'assurer une grande configurabilité du mouvement du feedback pour le rendre plus cohérent possible avec celui du sujet.

-Facilité de configuration : l'utilisateur doit pouvoir changer les options facilement et rapidement.

-Modulation du programme : le code source doit être le plus générique possible, documenté, commenté et le plus facilement modifiable possible.

= Étude des différents moteurs graphiques 3D =

== Spécifications ==

Les contraintes de choix du moteur 3D sont les suivantes par ordre de priorités décroissantes :

-Compatibilité avec le VRPN de Openvibe

-Permettre le développement multiplateforme (Linux, Windows, MacOS)

-Simplicité de développement

-Ressources nécessaires pour le mettre en œuvre minimisées

-Rendu visuel de qualité

== Choix d'un moteur ==

=== Moteur Jeux Vidéos Grand Public ===

Les moteurs suivants sont utilisés par les développeurs de jeux vidéos actuels. Leurs rendus graphiques sont les meilleurs, donc nous n'avons analysé en premier lieu que leurs autres caractéristiques :

-Anvil (Assassin's Creed) : License propriétaire privée d'Ubisoft, impossible d'acheter le DK

-CryEngine (Crysis) : Gratuit pour une utilisation non commerciale

-Dunia Engine (Farcry) : Non distribué

-Frostbite (Battlefield) : Non distribué

-Havok (Halo) :

-Hero Engine (Star Wars : Old Republic)

-Quest3D (Audiosurf)

-Source (Portal) : Non distribué

-Unreal Engine (Borderlands)

La plupart de ces moteurs sont très performants, ce qui implique l'utilisation de machines suffisamment puissantes pour les mettre en œuvre. De plus, certains sont conçus exclusivement pour du développement de jeu pour console de salon. Même si leur complexité de programmation est tout aussi abordable que les autres, nous ne pouvons pas choisir ces derniers.

=== Etude Comparative des Moteurs Graphiques ===

-Outerra : Ce moteur permet surtout la génération d'immenses espaces 3D jusqu'à des planètes entières. Le rendu global est effectivement très joli mais les détails de petits éléments sont assez simplistes. Ce moteur n'est donc pas du tout adapté à notre projet.

[[Fichier:Engines.png]]

=== Choix final ===

[[Fichier:Blender_logo.jpg]]

Après cette étude nous avons retenus '''Blender''' car il permet un développement très performant et rapide de model 3D réalistes. Nous comptons utiliser son moteur de jeu BlenderGame qui permet des interactions avec les models pour faire fonctionner nos interfaces. La difficulté que cela soulève est l'absence de VRPN dans ce moteur. Outil qui permet la communication entre un système tier et une interface de réalité virtuel. La suite va donc consister à interfacer Blender et Openvibe

= Développement d'une interface logicielle OpenVibe <-> Blender =

Notre objectif est de permettre une communication entre le logiciel OpenVibe, et le moteur graphique de Blender. Plusieurs protocoles de communication sont alors exploitables.

[[Fichier:Blender-Openvibe.png]]

== Reflexion ==

=== TCP/IP ===

Nos recherches nous ont amené à entrer en relation avec Romain Grandchamp, un doctorant ayant déjà travaillé sur ce sujet : c'est lui qui a réalisé une interface BCI implémentant une liaison TCP/IP entre Blender et BCI2000, un logiciel similaire à OpenVibe pour l'utilisation en recherche en BCI. C'est lui qui nous a proposée cette éventualité. Voici l'un de ses projets en cours : https://sites.google.com/site/romaingrandchamp/cerveaurium

Blender permet ce type de communication grace à un script python, mais ce n'est pas le cas d'OpenVibe.

Notre objectif ici est donc de créer un bloc OpenVibe qui implémentera une fonction de communication via ce protocole.

Ce bloc prendra en entrée un vecteur de donnée issu du classifieur. Le programmeur de scénario OpenVibe pourra paramétrer le message envoyé et pour quel donné du vecteur.
L'idée est donc d'importer des bibliothèques de communication tcp/ip dans openvibe pour développer un bloc pouvant communiquer aussi bien avec Blender qu'avec un autre programme voire un autre système en réseau. Au niveau du choix de protocole TCP ou UDP, c'est le protocole TCP qui satisfera le mieux notre besoin car il garantit l'intégrité des paquets transmis. Sachant que les messages seront transmis à chaque changement d'état d'un des paramètre d'entrée de la boite, il faut absolument que l'ordre soit correctement transmis à Blender. Le protocole UDP permettrai une meilleure réactivité, car plus rapide, mais il ne garantis pas le bon fonctionnement à chaque transmission, on pourrait envisager ce protocole dans le cas d'échanges de messages cadencé à une certaine fréquence, où la quantité rattrape la qualité de la communication.

La difficulté rencontrée ici est l'implémentation d'un bloc nouveau dans OpenVibe. Nous nous somme inscrits sur le forum d'OpenVibe pour nous faire aider de la communauté associée.

=== VRPN ===

Un autre moyen de communication est l'utilisation d'un VRPN, un ensemble de librairies permettant la liaison entre un moteur graphique et une interface de réalité virtuelle.
La bibliothèque VRPN est implémentée nativement dans OpenVibe ce qui nous amène à envisager d'implémenter cette même bibliothèque coté Blender. Le problème étant que nous n'avons pas de garantis que ceci soit possible. Il est possible d'étendre Blender grâce à des scripts python donc nous pensons que c'est effectivement faisable mais ne comprenons pas pourquoi est ce que cette fonction n'a pas déjà été implémenté étant donné la manière dont Blender est répandu et son aspet opensource. Cela dit, la communication VRPN utilise en réalité la communication réseau TCP classique comme base (port par défaut 3883), il s'agit donc en fait d'un protocole spécifique ajouté sur la base dont nous avons pas forcément utilité.

Après des recherches approfondies nous avons découvert qu'il existe un patch permettant de transformer Blender en BlenderCave. http://blendercave.limsi.fr/doku.php
Celui ci intègre de nouvelles fonctions notamment la possibilité de faire de la 3D stéréoscopique mais qui intègrerai également un VRPN.
L'inconvénient principal de cette configuration est que ce patch ne peut être utilisé que sur une révision précise de Blender.

L'objectif serait de vérifier sa compatibilité entre OpenVibe et ce dernier. Si c'est le cas, essayer de porter la fonctionnalité VRPN vers une version quelconque de Blender.

== Développement ==

Nous choisissons donc de développer un système de communication TCP car les briques de bases sont disponibles de chaque coté. En effet la bibliothèque VRPN utilise en fait une communication TCP, donc OpenVibe devrait pouvoir communiquer par TCP.

=== Objectif ===

Réaliser un nouveau bloc OpenVibe permettant de transmettre des données via TCP ou UDP. Nous sommes inscrits sur le Forum OpenVibe : http://openvibe.inria.fr/forum/
Et partons suivre les tutos OpenVibe sur la créations de nouveaux blocs : http://openvibe.inria.fr/introduction-algo-boxes/

=== Réalisation ===

'''Bloc OpenVibe'''

[[Fichier:BCI TCP Writer Champeirock.png|left]][[Fichier:Wireshark Icon BCI Champeiro.png|right|50px]]
Après avoir commencé à développer notre propre Bloc nous avons été informé par la communauté qu'un bloc TCP Writer venait d'être développé (decembre 2013) mais était en version Non Stable. Nous sommes donc repartis de cette base-ci. Doc TCP Writer : http://openvibe.inria.fr/documentation/unstable/Doc_BoxAlgorithm_TCPWriter.html
Nous avons donc analysé la structure de la transmission avec un outils type WireShark
La boite fait office de Server TCP qui transmet son vecteur d'information d'entrée sur une Socket TCP. On peut choisir 3 types de données de sorties : Raw, Hexa ou String.
Mais en pratique, on ne peut utiliser les formats Hex ou String que pour transmettre des données de stimulation, ce qui n'est pas notre cas ici vu que nous voulons transmettre un vecteur d'information. Nous allons donc nous intéresser au format du message transmis au format Raw.
- La boîte envoie d'abord à chaque client qui se connecte huit variables uint32 :
numéro de version
endianness : 0 == inconnue , 1 == little , 2 == big, 3 == PDP
la fréquence d'échantillonnage du signal
le nombre de canaux (nb de lignes de la matrice d'info transmise)
le nombre d'échantillons par bloc (colonnes de la matrice)
Trois variables de rembourrage

8 * 4 = 32 octets au total. Les 6 dernières variables sont dans l'ordre des octets du flux.

Plusieurs clients peuvent se connecter à la socket. La boîte continue à envoyer des données à chaque client jusqu'à ce que le scénario OpenVibe se termine ou que le client se déconnecte.

Analyse détaillée d'une trame pour la transmission d'une Matrice (1,1) :
Server : OpenVibe : TCP Writer

Client : NetCat : nc localhost 5678

Sniffeur de Tram : WireShark

Dans un premier temps le client reçoit 8 paquets dont 4 octets de données. Ce qui correspondrait donc aux 8 variables annoncées. Nous avons fais une étude détaillé pour nous en assurer.

Format et découpage des octets :
14 Octets Ethernets (Addresses, Type)
20 Octets d'en-tête IPv4
32 Octets TCP
4 Octets de Données

1er Envoi
00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 38 5b 08 40 00 40 06 e1 b5 7f 00 00 01 7f 00
00 01 16 2e b7 35 2e ae fd c1 61 71 6f 2c 80 18
08 00 fe 2c 00 00 01 01 08 0a 09 34 a6 e9 09 34
a6 c9 00 00 00 01
Numéro de version : 1, semble correspondre au numéro de version du bloc TCP Writer plus qu'à la version d'OpenVibe

2em Envoi
00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 38 5b 09 40 00 40 06 e1 b4 7f 00 00 01 7f 00
00 01 16 2e b7 35 2e ae fd c5 61 71 6f 2c 80 18
08 00 fe 2c 00 00 01 01 08 0a 09 34 a6 ea 09 34
a6 e9 00 00 00 01
Endianness : Little Endian

3em Envoi
00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 38 5b 0a 40 00 40 06 e1 b3 7f 00 00 01 7f 00
00 01 16 2e b7 35 2e ae fd c9 61 71 6f 2c 80 18
08 00 fe 2c 00 00 01 01 08 0a 09 34 a6 ea 09 34
a6 ea 00 00 00 00
Fréquence d'échantillonnage : 0 Cette valeur n'est valide que dans le cas de la transmission d'un signal ce qui n'est pas le cas ici

4em Envoi
00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 38 5b 0b 40 00 40 06 e1 b2 7f 00 00 01 7f 00
00 01 16 2e b7 35 2e ae fd cd 61 71 6f 2c 80 18
08 00 fe 2c 00 00 01 01 08 0a 09 34 a6 ea 09 34
a6 ea 01 00 00 00
Nombre de Lignes. En considérant seulement le premier octet on obtient effectivement la valeur attendue 1 mais nous ne comprenons pas pourquoi elle serait à cet endroit.

5em Envoi
00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 38 5b 0c 40 00 40 06 e1 b1 7f 00 00 01 7f 00
00 01 16 2e b7 35 2e ae fd d1 61 71 6f 2c 80 18
08 00 fe 2c 00 00 01 01 08 0a 09 34 a6 ea 09 34
a6 ea 00 00 00 01
Nombre de Colonnes = 1

6em Envoi
00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 38 5b 0d 40 00 40 06 e1 b0 7f 00 00 01 7f 00
00 01 16 2e b7 35 2e ae fd d5 61 71 6f 2c 80 18
08 00 fe 2c 00 00 01 01 08 0a 09 34 a6 ea 09 34
a6 ea 00 00 00 00
Variable de rembourrage 1

7em Envoi
00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 38 5b 0e 40 00 40 06 e1 af 7f 00 00 01 7f 00
00 01 16 2e b7 35 2e ae fd d9 61 71 6f 2c 80 18
08 00 fe 2c 00 00 01 01 08 0a 09 34 a6 ea 09 34
a6 ea 00 00 00 00
Variable de rembourrage 2

8em Envoi
00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 38 5b 0f 40 00 40 06 e1 ae 7f 00 00 01 7f 00
00 01 16 2e b7 35 2e ae fd dd 61 71 6f 2c 80 18
08 00 fe 2c 00 00 01 01 08 0a 09 34 a6 ea 09 34
a6 ea 00 00 00 00
Variable de rembourrage 3

Ensuite La trame est composé d'un total de 74 Octets :
14 Octets Ethernets (Addresses, Type)
20 Octets d'en-tête IPv4
32 Octets TCP
8 Octets de Données

00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 3c 7a 2f 40 00 40 06 c2 8a 7f 00 00 01 7f 00
00 01 16 2e 94 10 05 7b a6 c7 6f c2 f5 62 80 18
08 00 fe 30 00 00 01 01 08 0a 08 09 f7 58 08 09
f7 43 75 df 7a cb fa e0 d9 3f

Interprétation
Adresses : Les deux programmes étant en local ses octets sont laissés à 0 Type : 0x0800 ==> IP)
IPv4 : 4 pour IPv4 par defaut
Header Length : 5 : 5 x 32 bits
Length : 00 3c = 60 Correspondant bien aux 74 octets totaux moins les paquets Ethernet
Identification : 7a 2f valeur dépendante du message et incrémentée chaque fois
Flags : 04 00 pour ne pas fragmenter
Time To Live : 40 = 64 Ce qui est largement suffisant étant donné que tnous travaillons en local
Protocol : 06 TCP
CheckSum : c2 8a Correct
Adresse Source : 7f 00 00 01 Correspond à l'adresse localhost
Adresse Destination : 7f 00 00 01 Idem
Port Source : 16 2e = 5678 Est le port configuré dans le bloc TCP Writer d'OpenVibe
Port Destination : 94 10 = 37904
Sequence Number : 05 7b a6 c7
Acknowledgment : 6f c2 f5 62
Longueur de l'en-tete : 80 = 32 Octets que nous sommes en train de détailler
Flags : 18 = Acknowledgment et Push activés
Window Size Value 08 00 = 2048 Octets seront envoyés sans attendre de confirmation d'un éventuel client
CheckSum : fe 30 : La validation étant désactivé d'après WireShark
00 00
Options 01 01 : Ne fait Rien
Kind : 08 TimeStamp(8)
Length : 0a = 10 Octets concernant les variables de temps
Heure d'envoie celon l'émeteur : 08 09 f7 58
Timestamp Echo Replay :08 09 f7 43 
8 Octets de Données : 75 df 7a cb fa e0 d9 3f

L'heure d'envoie de l'émeteur : 08 09 f7 58 que nous avons observer conrespondrait à la date du 11/4/1974 à 1:07:52. Nous avons donc déduis que le server n'enverrait donc pas les données de la manière dont WireShark les interprète... Mais nous n'avons pas plus d'information sur les envois de données que celle rappelées plus haut.

'''Script Blender'''

Nous avons essayé d'écrire un script implémentant soit une communication TCP ou UDP dans le cas d'une future amélioration, tout en restant simple. La communication TCP étant celle que nous visons à utiliser actuellement, et la communication UDP étant celle des VRPN :

<code>
# Projet BCI Lagis Lille
# 
# TCP client

import socket
import sys
#Here enter mode TCP or VRPN 
#depending on how you send data from OpenVibe
MODE = "TCP"
HOST = "localhost"
BUFFER_SIZE = 1024
#Port are here defined as defaults openvibe values
if(MODE == "TCP"):
# Create a socket TCP (SOCK_STREAM for TCP socket)
PORT = 5678
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
else:
# Create a socket UDP (SOCK_DGRAM for UDP socket)
print("VRPN")
PORT = 3883
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
try:
if(MODE == "TCP"):
# Connect to server
sock.connect((HOST, PORT))
else:
sock.bind((HOST, PORT))
# Receive data from the server and shut down
ov_msg = sock.recv(BUFFER_SIZE)
finally:
sock.close()
print("Data :", ov_msg)
</code>

La communication TCP étant fonctionnelle, nous avons analysé les échanges OpenVibe<->Blender avec WireShark. Le script client étant exécuté periodiquement dans blender (au rythme des image de l'animation) on observe un taux de réussite d’échange de donnée supérieur à 85%. Les échecs étant probablement dus aux accès concurrents entre le serveur et le client. Ces erreurs n'engendrerai donc pas de défaut de fonctionnement du système global. Tout au plus, on observerai un retard d'une ou deux images entre le moment où la donnée est recue et le moment ou l'animation est modifié. Mais étant donnée la conception du serveur (TCP Writer), l'en-tête est renvoyé à chaque fois qu'un échange a échoué. Autrement dit, il est nécessaire d'échangé au moins 9 paquets consécutivement sans erreurs pour pouvoir avoir enfin une donnée exploitable.

[[Fichier:BCI WireShark TCP OVtoB.png]]

'''Conversion de donnée OpenVibe'''

Les données d'OpenVibe sont formatés en EBML (Extensible Binary Meta Language) historiquement un formatage pour fichiers multimédia propriétaire de Matroska. Pour les rendre exploitable dans blender nous avons trouver un parser EBML to Python.

Sources : http://sjohannes.wordpress.com/2010/04/28/matroska-tagging-support/

Code Python : http://bazaar.launchpad.net/~exaile-devel/exaile/exaile-0.3.x/view/head:/xl/metadata/_matroska.py

Cette bibliothèque a été développé dans un besoin de convertir des fichiers multimédia en python. Comme notre projet est très différent nous avons étudié ce code pour voir si effectivement il pourrait répondre à nos besoins.
Nous avons donc utilisé le Bloc EBML Spy d'OpenVibe pour observer les données, connues, provenant du classifier du scenario "Handball-replay". La donnée utile pour nous étant un nombre réel compris entre -10 et +10 et indiquant si le sujet présentait des mouvement de la main droite ou de la main gauche.

[[Fichier:BCI EBML Stream Champeiro.png|1000px]]

Dans le code source du parser, on trouve des lignes 292 à 376 les tags qui sont actuellement convertis. Malheureusement, aucun des tags openvibe n'est pris en compte par ce parser. Nous avons donc envisagé d'adapter ce parser à nos besoin quitte à le reconstruire presque entièrement.

'''Client VRPN'''

La communication TCP s'avérant infructueuse nous avons envisagé de développé plutot un client VRPN en python pour Blender. Pour se faire nous avons utilisé la bibliothèque VRPN version 7.30 ainsi qu'un parser de langages objet : SWIG version 2.0.12

= Développement du retour graphique sous blender =

== Objectif ==

Le développement sous Blender consiste à créer un feedback visuel pour l’utilisateur. Il faut donc modéliser une main qui bouge selon la volonté de mouvement de l’utilisateur. Dans un premier temps, il faut créer une main, et lui associer une animation pour qu’elle pianote, superposée à un piano dont les touches bougent en même temps que les doigts ; l’objectif est que lorsque l’utilisateur veut pianoter, il voit la main pianoter à sa place et appuyer sur les touches du piano. Le logiciel de création de Blender permet d’associer un signal d’entrée, par exemple l’appui sur une touche du clavier (d’ordinateur), à l’animation de la main et du piano. L’intérêt serait alors que le signal d’entrée soit provoqué par le logiciel OpenVibe lors de l’imagination de mouvement de l’utilisateur.

== Réalisation ==

Une main déjà modélisée et articulée, ainsi qu’un décor d’opéra contenant un piano, ont été trouvés sur des sites communautaires de Blender.
Pour le piano, il a été nécessaire de recréer le clavier (l’ensemble des touches) car dans le modèle utilisé, elles étaient toutes solidaires. Le clavier à touches indépendantes a donc été placé à la place du clavier original. Maintenant, il est donc possible de faire bouger chaque touche indépendamment, et donc de créer l’animation des touches qui s’enfoncent.

[[Fichier:BCI_piano_Champeiro.png]]

Pour la main, une animation était déjà pré-programmée, qui montrait la main d’abord fermée, puis qui s’ouvrait le plus possible, sans que le rendu paraisse irréaliste. La construction de l’animation est basée sur une série de marqueurs qui indiquent la position que doivent avoir chaque membres à certaines images de l’animation. En réutilisant ces marqueurs, il est donc possible de créer le mouvement de pianotement voulu.

[[Fichier:BCI_roll1_Champeiro.png]] [[Fichier:BCI_roll2_Champeiro.png]]

''Vue du modèle de la main au repos et pendant le pianotement''

Une étape intéressante serait de pouvoir agir sur la vitesse de l’animation de la main, en fonction de l’intensité de l’imagination du mouvement par l’utilisateur.

== Objectifs Futurs ==

= Gestion de Projet et Sources =

== Planning ==

[[Fichier:Gant PFE BCI.png|650px]]

'''Présentation Mi-PFE'''

10/12/2013

'''Présentation BCI

21/02/2014

'''Présentation Polytech'Lille'''

27/02/2014

== Bibliographie ==

=== OpenVibe ===

http://openvibe.inria.fr/

http://openvibe.inria.fr/tag/vrpn/

http://openvibe.inria.fr/documentation-index/#User+Documentation

=== Moteur 3D ===

https://fr.wikipedia.org/wiki/Moteur_3D

http://www.desura.com/search?q=engine+3d&sa.x=0&sa.y=0

http://www.ogre3d.fr/

http://www.outerra.com/forum/index.php?topic=637.0

http://jeux.developpez.com/tutoriels/?page=prog-3d#ogre-3d

http://mycryengine.com/index.php?conid=70

http://www.havok.com/try-havok

http://www.desura.com/engines/unreal-development-kit/downloads/udk

http://www.truevision3d.com/downloads.php

http://hub.jmonkeyengine.org/

http://www.neoaxis.com/neoaxis/licensing

http://www.shivaengine.com/download.html

http://unity3d.com/unity/download

https://store.unity3d.com/

http://www.twinmotion.com/acheter.html

http://www.worldofleveldesign.com/categories/level_design_tutorials/recommended-game-engines.php

=== Blender ===

http://www.blender.org/education-help/tutorials/game-engine/

http://blendercave.limsi.fr/doku.php

http://www.blendswap.com/

=== EEG ===

http://openeeg.sourceforge.net/doc/sw/

http://www.emotiv.com/store/app.php

=== Autres Projets BCI ===

http://air.imag.fr/index.php/Armind

https://sites.google.com/site/romaingrandchamp/cerveaurium

= Annexe =

== Journal ==

'''Entrée 1'''

Installation de OpenVibe (en deux fois pour le rendre fonctionnel)

'''Entrée 2'''

Réalisation de l'ensemble des tutoriels disponibles sur le site de l'INRIA mais malheureusement, cela ne nous a pas amené jusqu'à l'utilisation du VRPN. Nous Projetons maintenant d'étudier les moteurs graphiques 3D existant pour en choisir un pour notre développement.

'''Entrée 3'''

Installation de Ogre. Nécessite un IDE ainsi qu'un compilateur (Comblock + MinGW pour Windows)

Configuration : Installation de MinGW à la racine de C:/ Installation de Ogre Installation de Comblock
Problème pour compiller

Fichier:BCI roll2 Champeiro.png

2014-02-17T16:02:23Z

Tchampag :

Fichier:BCI roll1 Champeiro.png

2014-02-17T16:01:56Z

Tchampag :

Fichier:BCI piano Champeiro.png

2014-02-17T16:01:26Z

Tchampag :

BCI : Interface Cerveau Ordinateur

2014-02-17T16:00:57Z

Tchampag : /* Réalisation */

= Présentation =

== Contexte : ==

Le but général est de faciliter la vie des personnes paralysées avec un système interprétant directement leurs signaux cérébraux pour communiquer ou agir avec leur environnement. Les patients susceptibles d'utiliser cette technologie sont ceux atteint de paralysie musculaire complète (LIS : Locked In Syndrom) ou de SLA (Sclérose Latérale Amyotrophique). Ces maladies affectant très peu les fonctions cérébrales, cette technologie semble pouvoir devenir LA solution pour pallier au handicap. Ce projet est réalisé en collaboration avec l'équipe BCI du LAGIS.

Voilà ce que fait l'interface cerveau ordinateur (BCI : Brain Computer Interface ou BMI : Brain Machine Interface) de façon détaillée : les signaux électroencéphalographiques (EEG) sont acquis, numérisés et traités pour pouvoir ensuite être transformés en commandes. Une partie de ces informations est aussi affichée de manière simple pour l'utilisateur pour lui permettre un apprentissage plus rapide grâce à ce retour visuel.

Comment ?

[[Fichier:Schema-bci.png|600px|center]]

=== Acquisition ===

L'information cérébrale peut-être acquise de différentes manières :

- La première est non invasive, c'est à dire qu'elle ne nécessite pas d'intervention chirurgical visant à implanter un quelconque dispositif dans le corps du patient. A l'aide d'un casque muni d'électrodes placés sur le crane, on peut acquérir les signaux cérébraux passant à travers la boite crânienne (appelés signaux EEG). L'ordre de grandeur de ces signaux électriques ne dépasse pas le microvolt et les signaux acquis sont très fortement bruités. Mais ce dispositif est simple à mettre en œuvre et peut être utilisé aussi bien par les patients que par les chercheurs lors d'une phase expérimentale qu'est la nôtre.

- La seconde est semi-invasive, l’électrode servant à l'acquisition des signaux est implanté sous la surface de la boîte crânienne (ECoG : électrocorticogramme). Cette méthode permet d'augmenter considérablement la qualité des signaux qui sont beaucoup moins bruités que les signaux EEG. De plus, elle présente peu de risque puisque l’électrode est situé à l’extérieur de la dure-mère.

- La dernière est dite invasive, dans le sens où on vient placer des électrodes directement dans la masse cérébrale. Cette méthode a deja fait ses preuves : en 2005 un patient tétraplégique était capable de contrôler une prothèse robotique grâce à ce dispositif. Néanmoins, les électrodes ont une durée de vie limitée et les lésions cérébrales, dues à l’implantation des électrodes, sont irréversibles.

Une autre méthode consiste à détecter des signaux résultant de stimuli extérieurs connus (ERP : Event Related Potentials). Dans le cadre de notre projet, nous allons développer une interface graphique qui va être intégrer dans une interface BCI de type asynchrone basée sur l'analyse des signaux EEG acquis dans le cas de mouvements imaginés des pieds et des mains gauche ou droite. Les EEG considérés sont issus des activités ipsilatérales et contralatérales du cortex pré-moteur.

=== Traitement des signaux EEG ===

L'objectif du traitement des signaux EEG est de discriminer le mouvement imaginé par le patient (main droite, main gauche, pied). Pour cela, il est nécessaire d'extraire des signaux EEG un certains nombre d'attributs qui vont permettre de prendre une décision sur la commande à effectuer au sein de l'interface BCI en cours de developpement au LAGIS. Il est effectué par un logiciel d'analyse numérique comme MatLab, OpenVibe.

Les attributs extraits sont les amplitudes des signaux cérébraux dans certaines bandes de fréquence. Exemple, l'amplitude du rythme µ (entre 8Hz et 15Hz) disparait environ une seconde avant et pendant un mouvement des pieds ou des mains, mais aussi avant et pendant l'imagination de ce mouvement. Dans le même contexte on peut observer de grandes modifications d'amplitude du signal EEG dans la bande ß (entre 15Hz et 35Hz) occurrentes avant, pendant et juste après un mouvement. Ces signaux sont toujours très brefs mais la manière dont ils sont acquis (niveau d'invasivité) change complètement la manière dont ils seront traités. Les signaux mesurés à la surface du cerveau sont les plus problématiques car ils résultent de l'activité de millions de neurones.

Le pré-traitement a pour fonction l’élimination des artefacts (signaux induits par une autre activité corporelle que celle observée comme le clignement des yeux, la déglutition...) ainsi que l'amélioration du rapport signal sur bruit, bruit venant de tous les signaux à proximité, autant dire de tous les neurones à proximité donc quelques millions par point de mesure. Pour ce faire, différentes techniques sont mises en œuvre :

-Filtrage spatial : Combinaison linéaire des signaux des électrodes voisines. Par exemple le filtrage Laplacien, consistant à soustraire à un signal, la moyenne de ces voisins : très répandu car aussi simple qu’efficace pour éliminer le bruit.

-Filtrage fréquentiel : Sachant que nous cherchons à mesure l'amplitude des signaux dans les bandes de fréquence 8-35Hz il convient d'effectuer un filtrage fréquentiel éliminant toutes les fréquences hors de cette plage.

-Interface Synchrone : Une interface est dite Synchrone lorsque ce n'est pas l'activité spontanée du cerveau qui est analysée mais la réponse attendu à des stimulus générés par l'interface. Des signaux réflexifs sont générés de manière mécanique et inconsciente ce qui rend la phase d'apprentissage beaucoup plus simple.

-Interface Asynchrone : Une interface asynchrone à contrario analyse les signaux à tous moments. Et même si l'on peut sélectionner les zones du cerveaux à observer en choisissant l'emplacement des électrodes il n’empêche que les signaux observés sont le résultat de la somme de toutes les activités cérébrales avoisinante. Dans le cas de la réalisation ou de l'imagination de mouvements des mains (droite ou gauche) par exemple, il s'agit de reconnaitre dans les signaux cérébraux, le moment où un événement se produit et le type d'événement généré (droite ou gauche). Dans le cas de l'interface développée par le LAGIS les signaux EEG sont analysés en s'appuyant sur l'expertise des neurophysiologistes qui ont mis en évidence des modifications des signaux EEG dans certaines bandes de fréquence dans la zone moteur du cortex avant, pendant et après l'imagination ou la réalisation du mouvement.

=== Méthode d'exploitation des signaux cérébraux acquis (ou paradigme) ===
Afin de transformer les signaux acquis en commande d'un vas, d'un fauteuil roulant, ou autre, il est nécessaire de définir un paradigme expérimental. En d'autre termes : la manière dont les signaux cérébraux vont être exploités au sein de l'interface. Il est possible de distinguer deux grandes catégories d'interfaces BCI dans ce cas : les interfaces synchrones et les interfaces asynchrones.

=== Classification ===

A l'issue de la phase de traitement précédemment décrite, nous disposons d'un ensemble d'attributs mesurés sur les signaux à intervalles réguliers (tous les dixièmes de seconde).
A partir de ces vecteurs d'attributs, il s'agit d'identifier le type de mouvement réalisé ou imaginé(dans le cas d'une interface asynchrone) ou de décider si le sujet a répondu positivement au stimulus ou non (dans le cas d'une interface synchrone).

Il s'agit donc de décider si le vecteur d'attributs considéré est caractéristique d'un mouvement ou d'une réponse positive au stimulus. Ceci est le propre de ce que l'on appelle la classification.

Il existe deux grandes familles de techniques de classification : la classification supervisée et la classification non supervisée. La classification non supervisée consiste à prendre une décision d'identification sans aucune connaissance à priori sur les vecteurs d'attributs (ou éléments) à classer.

La classification supervisée part de la connaissance à priori des éléments que l'on vise à identifier et se décline en deux phases successives :

'''Offline'''
Une phase d'apprentissage basée sur l'analyse d'éléments connus et parfaitement identifiés. Il s'agit alors d'ajuster les paramètres du classifieur en fonction des éléments à priori identifiés

'''Online'''
Une phase de classement des éléments inconnus en utilisant le classifieur paramétré dans la phase précédente.

Dans le domaine des interfaces BCI, les techniques de classification les plus utilisées sont de type supervisées. Les plus courantes :

-LDA

-Les réseaux de neurones

-La classification floue

Cette étape a pour but d'exploiter les éléments caractéristiques extraits précédemment. Les méthodes choisies dépendent du type d'interface, on distinguera deux types d'interfaces: synchrones ou asynchrones. Le logiciel remplissant cette fonction a été développé par l'INRIA, il s'agit d'OpenVibe.

=== Commande ===

Le résultat de la classification des attributs extraits des signaux cérébraux st généralement mise sous forme de décision binaire. Par exemple : "Y a t il imagination de mouvement de la main droite?" Résultat : "Oui ou Non". Nous pouvons alors relier ce résultat à la partie opérative de l'interface et piloter ainsi un actionneur. Le nombre d'actionneur devant bien sur être adapté à l'interface qui les exploitera.

=== Interfaces BCI Existantes ===

'''Interface Synchrone'''

[[Fichier:Doc BoxAlgorithm P300SpellerVisualisation Snapshot.png|400px|right]]
Des applications ont déjà été créées pour permettre à une personne complètement immobile de communiquer ou de se déplacer. En terme d'interface de communication, le P300 Speller qui est basé sur la détection de potentiels endogènes évoqués, signaux correspondant à une activité cognitive. Cette interface permet à un sujet entraîné d’écrire plusieurs caractères par minute. Le principe est simple: le sujet regarde une matrice de caractères dont les colonnes et les lignes sont mises en surbrillance de manière aléatoire, il doit alors se concentrer sur le caractère qu'il veut écrire et compter son nombre d'illuminations. A chaque fois que la lettre est comptée une modifications des signaux se produit 300ms plus tard. Il est ainsi possible de détecter la colonne et la ligne sur lesquelles se situe le caractère intéressant. Après plusieurs scintillement on peut donc connaître la lettre choisi par le patient.

[[Fichier:Online-shooter.png|445px|left]]Il existe également tout un ensemble d'interface développées à partir de l'analyse et l'interprétation des signaux SSVEP (Steady-State Visual Evoked Potential). Ceux-ci ne sont pas générés par une action cognitive mais inconsciemment par notre cerveau. Lorsque nous regardons un objet clignotant sur l’écran, on retrouve la fréquence de ce clignotement sur notre lobe occipital. Ainsi, en créant une interface graphique constituée de plusieurs objets clignotants à différentes fréquences (de l'ordre de quelques dizaines de hertz), et en analysant les signaux évoqués, on peut reconnaitre l'objet observé par le sujet. Cette technique basée sur l'analyse de signaux reflexes s'avère très efficace et ne nécessite aucune phase d'apprentissage. L'exemple ci dessous pourrait représenter l'écran de saisie des commandes de pilotage d'un fauteuil roulant. Les deux carrés pourraient représenter une demande de rotation gauche ou droite tandis que le triangle représenterait une demande de marche avant.

[[Fichier:MuseumImmersive1.jpg|right|400px]]

'''Interface Asynchrone'''

La dernière technique est la plus complexe mais aussi celle avec le plus grand potentiel. Elle consiste à analyser les signaux cérébraux en vue de détecter la réalisation ou l'imagination de mouvements de différentes parties du corps. Dans notre cas, ce sont les mouvements des deux mains et des pieds qui sont exploités car plus présents au niveau du cortex moteur et donc plus faciles à détecter. L'identification de ces mouvements fournit donc un total de 3 commandes complètement indépendantes de toute stimulation extérieure. On ne peut prévoir à l'avance quand le sujet décidera d'imaginer un mouvement d'une des parties de son corps. Ce paradigme a déjà été exploité par l'INRIA de Rennes pour diriger un avatar dans un espace 3D virtuel matérialisant une visite virtuelle d'un musée. Les signaux correspondant aux mouvements de la main droite sont utilisés pour tourner à droite, ceux de la main gauche pour tourner à gauche et les mouvements des pieds pour avancer.

Des applications interfaces BCI ont aussi été développées pour commander des prothèses ou des fauteuils roulants. En effet, des expériences ont été menées avec succès sur un patient équipé d'une interface non invasive. Il a réussi à contrôler une main robotique grâce à l'analyse de ses rythmes sensorimoteurs, exploités pour détecter l'imagination de mouvement de la main. Ces essais ont été fais sur des personnes valides mais on peut imaginer les possibilités qui s'offrent à des personnes paralysées ou amputées.

== Objectif : ==

=== Formulation des besoins ===

[[Fichier:main3d.jpg|right|200px]]
Notre projet consiste au développement de l'interface graphique 3D d'une BCI, de type asynchrone basée su l'analyse de mouvements, réels ou imaginés, fournissant à l'utilisateur un feedback visuel ds commandes qu'il effectue. L'interface doit être composée de 2 couches graphiques dissociables :

- Une couche que nous appelons "la couche Feedback" : c'est la couche est au premier-plan. Elle affichera un avatar virtuel qui va exécuter le mouvement réel ou imaginé par le sujet. Par exemple, dans le cas d'un mouvement imaginé de la main, nous devons représenter graphiquement une main exécutant le mouvement imaginé par le sujet. Il peut s'agir d'une rotation du poignet, d'un mouvement de préhension, de mouvements des doigts etc. La visualisation du mouvement que le sujet imagine (le feedback) permettra peut-être un apprentissage de l'interface dit plus aisé pour le sujet mais on doit essayer de s'assurer qu'il ne soit pas un élément perturbateur. Nos inquiétudes sont fondées sur le même principe que l'instabilité des systèmes bouclés en général. On ne peut pas être certain qu'en observant son avatar à l'écran, le cerveau du sujet ne génère pas les sinusaux électriques correspondant au mouvement qu'il observe.

[[Fichier:piano 3d.jpg|300px|left]]
- Une couche ludique : celle-ci se situe au second-plan. Elle présente un objectif à réaliser par l'utilisateur en cohérence avec l'action imaginée et représentée par l'avatar. On peut par exemple imaginer un clavier de piano dans le cas d'un mouvement des doigts, d'un ballon qui se gonfle dans le cas de mouvements de préhension répétés.L'objectif permet de créer une forte motivation de l'utilisateur qui facilitera inconsciemment sa concentration. Par exemple : Si le mouvement imaginé par le sujet est de fermer et d'ouvrir la main, on sélectionnera une interface montrant par exemple une main actionnant une pompe et un arrière plan, des ballons à gonfler. Ou encore, avec un mouvement de doigt tapoter sur une table, on choisira d'avantage un piano en arrière plan joué par cette/ces main(s), ou même, avec un mouvement de serrage de vis avec la main, un meuble à monter le plus rapidement possible.

Ces couches doivent être affichables une par une ou en même temps. Le but est de pouvoir analyser l'impact du feedback sur les performances du sujet lors l'utilisation de l'interface BCI. Ainsi que de fournir au sujet un feedback "réaliste" des mouvements qu'il réalise ou imagine plutôt qu'un curseur sur un graphique.
[[Fichier:Piano main 3d.jpg|430px|center]]

=== Spécifications ===

Au sein de l'équipe BCI du LAGIS, les outils de développement les plus utilisés sont :

-MatLab : Pour le traitement des signaux.

-OpenVibe : Logiciel dédié BCI développé par l'INRIA de Rennes, pour la partie acquisition, traitement et feedback visuel.

-C++ : Pour le développement des blocs OpenVibe additionnels

Les contraintes à respecter dans le cadre de notre projet sont les suivantes :

-Respect et/ou compatibilité avec les technologies utilisées : Compatibilité de l'interface graphique avec OpenVibe. Compatibilité entre l'application et le nombre de signaux de commandes en sortie d'OpenVibe (main gauche, main droite, pieds, repos).

-Grande configurabilité : Ne connaissant pas l'utilisateur qui va utiliser le système, il doit être le plus personnalisable possible. Le but est que chacun puisse s'identifier à notre application pour obtenir les meilleurs résultats possibles. Cela implique donc d'assurer une grande configurabilité des objectifs pour l'utilisateur mais aussi de la manière d'afficher la complétion de ces objectifs et ses performances. Enfin il est important d'assurer une grande configurabilité du mouvement du feedback pour le rendre plus cohérent possible avec celui du sujet.

-Facilité de configuration : l'utilisateur doit pouvoir changer les options facilement et rapidement.

-Modulation du programme : le code source doit être le plus générique possible, documenté, commenté et le plus facilement modifiable possible.

= Étude des différents moteurs graphiques 3D =

== Spécifications ==

Les contraintes de choix du moteur 3D sont les suivantes par ordre de priorités décroissantes :

-Compatibilité avec le VRPN de Openvibe

-Permettre le développement multiplateforme (Linux, Windows, MacOS)

-Simplicité de développement

-Ressources nécessaires pour le mettre en œuvre minimisées

-Rendu visuel de qualité

== Choix d'un moteur ==

=== Moteur Jeux Vidéos Grand Public ===

Les moteurs suivants sont utilisés par les développeurs de jeux vidéos actuels. Leurs rendus graphiques sont les meilleurs, donc nous n'avons analysé en premier lieu que leurs autres caractéristiques :

-Anvil (Assassin's Creed) : License propriétaire privée d'Ubisoft, impossible d'acheter le DK

-CryEngine (Crysis) : Gratuit pour une utilisation non commerciale

-Dunia Engine (Farcry) : Non distribué

-Frostbite (Battlefield) : Non distribué

-Havok (Halo) :

-Hero Engine (Star Wars : Old Republic)

-Quest3D (Audiosurf)

-Source (Portal) : Non distribué

-Unreal Engine (Borderlands)

La plupart de ces moteurs sont très performants, ce qui implique l'utilisation de machines suffisamment puissantes pour les mettre en œuvre. De plus, certains sont conçus exclusivement pour du développement de jeu pour console de salon. Même si leur complexité de programmation est tout aussi abordable que les autres, nous ne pouvons pas choisir ces derniers.

=== Etude Comparative des Moteurs Graphiques ===

-Outerra : Ce moteur permet surtout la génération d'immenses espaces 3D jusqu'à des planètes entières. Le rendu global est effectivement très joli mais les détails de petits éléments sont assez simplistes. Ce moteur n'est donc pas du tout adapté à notre projet.

[[Fichier:Engines.png]]

=== Choix final ===

[[Fichier:Blender_logo.jpg]]

Après cette étude nous avons retenus '''Blender''' car il permet un développement très performant et rapide de model 3D réalistes. Nous comptons utiliser son moteur de jeu BlenderGame qui permet des interactions avec les models pour faire fonctionner nos interfaces. La difficulté que cela soulève est l'absence de VRPN dans ce moteur. Outil qui permet la communication entre un système tier et une interface de réalité virtuel. La suite va donc consister à interfacer Blender et Openvibe

= Développement d'une interface logicielle OpenVibe <-> Blender =

Notre objectif est de permettre une communication entre le logiciel OpenVibe, et le moteur graphique de Blender. Plusieurs protocoles de communication sont alors exploitables.

[[Fichier:Blender-Openvibe.png]]

== Reflexion ==

=== TCP/IP ===

Nos recherches nous ont amené à entrer en relation avec Romain Grandchamp, un doctorant ayant déjà travaillé sur ce sujet : c'est lui qui a réalisé une interface BCI implémentant une liaison TCP/IP entre Blender et BCI2000, un logiciel similaire à OpenVibe pour l'utilisation en recherche en BCI. C'est lui qui nous a proposée cette éventualité. Voici l'un de ses projets en cours : https://sites.google.com/site/romaingrandchamp/cerveaurium

Blender permet ce type de communication grace à un script python, mais ce n'est pas le cas d'OpenVibe.

Notre objectif ici est donc de créer un bloc OpenVibe qui implémentera une fonction de communication via ce protocole.

Ce bloc prendra en entrée un vecteur de donnée issu du classifieur. Le programmeur de scénario OpenVibe pourra paramétrer le message envoyé et pour quel donné du vecteur.
L'idée est donc d'importer des bibliothèques de communication tcp/ip dans openvibe pour développer un bloc pouvant communiquer aussi bien avec Blender qu'avec un autre programme voire un autre système en réseau. Au niveau du choix de protocole TCP ou UDP, c'est le protocole TCP qui satisfera le mieux notre besoin car il garantit l'intégrité des paquets transmis. Sachant que les messages seront transmis à chaque changement d'état d'un des paramètre d'entrée de la boite, il faut absolument que l'ordre soit correctement transmis à Blender. Le protocole UDP permettrai une meilleure réactivité, car plus rapide, mais il ne garantis pas le bon fonctionnement à chaque transmission, on pourrait envisager ce protocole dans le cas d'échanges de messages cadencé à une certaine fréquence, où la quantité rattrape la qualité de la communication.

La difficulté rencontrée ici est l'implémentation d'un bloc nouveau dans OpenVibe. Nous nous somme inscrits sur le forum d'OpenVibe pour nous faire aider de la communauté associée.

=== VRPN ===

Un autre moyen de communication est l'utilisation d'un VRPN, un ensemble de librairies permettant la liaison entre un moteur graphique et une interface de réalité virtuelle.
La bibliothèque VRPN est implémentée nativement dans OpenVibe ce qui nous amène à envisager d'implémenter cette même bibliothèque coté Blender. Le problème étant que nous n'avons pas de garantis que ceci soit possible. Il est possible d'étendre Blender grâce à des scripts python donc nous pensons que c'est effectivement faisable mais ne comprenons pas pourquoi est ce que cette fonction n'a pas déjà été implémenté étant donné la manière dont Blender est répandu et son aspet opensource. Cela dit, la communication VRPN utilise en réalité la communication réseau TCP classique comme base (port par défaut 3883), il s'agit donc en fait d'un protocole spécifique ajouté sur la base dont nous avons pas forcément utilité.

Après des recherches approfondies nous avons découvert qu'il existe un patch permettant de transformer Blender en BlenderCave. http://blendercave.limsi.fr/doku.php
Celui ci intègre de nouvelles fonctions notamment la possibilité de faire de la 3D stéréoscopique mais qui intègrerai également un VRPN.
L'inconvénient principal de cette configuration est que ce patch ne peut être utilisé que sur une révision précise de Blender.

L'objectif serait de vérifier sa compatibilité entre OpenVibe et ce dernier. Si c'est le cas, essayer de porter la fonctionnalité VRPN vers une version quelconque de Blender.

== Développement ==

Nous choisissons donc de développer un système de communication TCP car les briques de bases sont disponibles de chaque coté. En effet la bibliothèque VRPN utilise en fait une communication TCP, donc OpenVibe devrait pouvoir communiquer par TCP.

=== Objectif ===

Réaliser un nouveau bloc OpenVibe permettant de transmettre des données via TCP ou UDP. Nous sommes inscrits sur le Forum OpenVibe : http://openvibe.inria.fr/forum/
Et partons suivre les tutos OpenVibe sur la créations de nouveaux blocs : http://openvibe.inria.fr/introduction-algo-boxes/

=== Réalisation ===

'''Bloc OpenVibe'''

[[Fichier:BCI TCP Writer Champeirock.png|left]][[Fichier:Wireshark Icon BCI Champeiro.png|right|50px]]
Après avoir commencé à développer notre propre Bloc nous avons été informé par la communauté qu'un bloc TCP Writer venait d'être développé (decembre 2013) mais était en version Non Stable. Nous sommes donc repartis de cette base-ci. Doc TCP Writer : http://openvibe.inria.fr/documentation/unstable/Doc_BoxAlgorithm_TCPWriter.html
Nous avons donc analysé la structure de la transmission avec un outils type WireShark
La boite fait office de Server TCP qui transmet son vecteur d'information d'entrée sur une Socket TCP. On peut choisir 3 types de données de sorties : Raw, Hexa ou String.
Mais en pratique, on ne peut utiliser les formats Hex ou String que pour transmettre des données de stimulation, ce qui n'est pas notre cas ici vu que nous voulons transmettre un vecteur d'information. Nous allons donc nous intéresser au format du message transmis au format Raw.
- La boîte envoie d'abord à chaque client qui se connecte huit variables uint32 :
numéro de version
endianness : 0 == inconnue , 1 == little , 2 == big, 3 == PDP
la fréquence d'échantillonnage du signal
le nombre de canaux (nb de lignes de la matrice d'info transmise)
le nombre d'échantillons par bloc (colonnes de la matrice)
Trois variables de rembourrage

8 * 4 = 32 octets au total. Les 6 dernières variables sont dans l'ordre des octets du flux.

Plusieurs clients peuvent se connecter à la socket. La boîte continue à envoyer des données à chaque client jusqu'à ce que le scénario OpenVibe se termine ou que le client se déconnecte.

Analyse détaillée d'une trame pour la transmission d'une Matrice (1,1) :
Server : OpenVibe : TCP Writer

Client : NetCat : nc localhost 5678

Sniffeur de Tram : WireShark

Dans un premier temps le client reçoit 8 paquets dont 4 octets de données. Ce qui correspondrait donc aux 8 variables annoncées. Nous avons fais une étude détaillé pour nous en assurer.

Format et découpage des octets :
14 Octets Ethernets (Addresses, Type)
20 Octets d'en-tête IPv4
32 Octets TCP
4 Octets de Données

1er Envoi
00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 38 5b 08 40 00 40 06 e1 b5 7f 00 00 01 7f 00
00 01 16 2e b7 35 2e ae fd c1 61 71 6f 2c 80 18
08 00 fe 2c 00 00 01 01 08 0a 09 34 a6 e9 09 34
a6 c9 00 00 00 01
Numéro de version : 1, semble correspondre au numéro de version du bloc TCP Writer plus qu'à la version d'OpenVibe

2em Envoi
00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 38 5b 09 40 00 40 06 e1 b4 7f 00 00 01 7f 00
00 01 16 2e b7 35 2e ae fd c5 61 71 6f 2c 80 18
08 00 fe 2c 00 00 01 01 08 0a 09 34 a6 ea 09 34
a6 e9 00 00 00 01
Endianness : Little Endian

3em Envoi
00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 38 5b 0a 40 00 40 06 e1 b3 7f 00 00 01 7f 00
00 01 16 2e b7 35 2e ae fd c9 61 71 6f 2c 80 18
08 00 fe 2c 00 00 01 01 08 0a 09 34 a6 ea 09 34
a6 ea 00 00 00 00
Fréquence d'échantillonnage : 0 Cette valeur n'est valide que dans le cas de la transmission d'un signal ce qui n'est pas le cas ici

4em Envoi
00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 38 5b 0b 40 00 40 06 e1 b2 7f 00 00 01 7f 00
00 01 16 2e b7 35 2e ae fd cd 61 71 6f 2c 80 18
08 00 fe 2c 00 00 01 01 08 0a 09 34 a6 ea 09 34
a6 ea 01 00 00 00
Nombre de Lignes. En considérant seulement le premier octet on obtient effectivement la valeur attendue 1 mais nous ne comprenons pas pourquoi elle serait à cet endroit.

5em Envoi
00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 38 5b 0c 40 00 40 06 e1 b1 7f 00 00 01 7f 00
00 01 16 2e b7 35 2e ae fd d1 61 71 6f 2c 80 18
08 00 fe 2c 00 00 01 01 08 0a 09 34 a6 ea 09 34
a6 ea 00 00 00 01
Nombre de Colonnes = 1

6em Envoi
00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 38 5b 0d 40 00 40 06 e1 b0 7f 00 00 01 7f 00
00 01 16 2e b7 35 2e ae fd d5 61 71 6f 2c 80 18
08 00 fe 2c 00 00 01 01 08 0a 09 34 a6 ea 09 34
a6 ea 00 00 00 00
Variable de rembourrage 1

7em Envoi
00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 38 5b 0e 40 00 40 06 e1 af 7f 00 00 01 7f 00
00 01 16 2e b7 35 2e ae fd d9 61 71 6f 2c 80 18
08 00 fe 2c 00 00 01 01 08 0a 09 34 a6 ea 09 34
a6 ea 00 00 00 00
Variable de rembourrage 2

8em Envoi
00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 38 5b 0f 40 00 40 06 e1 ae 7f 00 00 01 7f 00
00 01 16 2e b7 35 2e ae fd dd 61 71 6f 2c 80 18
08 00 fe 2c 00 00 01 01 08 0a 09 34 a6 ea 09 34
a6 ea 00 00 00 00
Variable de rembourrage 3

Ensuite La trame est composé d'un total de 74 Octets :
14 Octets Ethernets (Addresses, Type)
20 Octets d'en-tête IPv4
32 Octets TCP
8 Octets de Données

00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00
00 3c 7a 2f 40 00 40 06 c2 8a 7f 00 00 01 7f 00
00 01 16 2e 94 10 05 7b a6 c7 6f c2 f5 62 80 18
08 00 fe 30 00 00 01 01 08 0a 08 09 f7 58 08 09
f7 43 75 df 7a cb fa e0 d9 3f

Interprétation
Adresses : Les deux programmes étant en local ses octets sont laissés à 0 Type : 0x0800 ==> IP)
IPv4 : 4 pour IPv4 par defaut
Header Length : 5 : 5 x 32 bits
Length : 00 3c = 60 Correspondant bien aux 74 octets totaux moins les paquets Ethernet
Identification : 7a 2f valeur dépendante du message et incrémentée chaque fois
Flags : 04 00 pour ne pas fragmenter
Time To Live : 40 = 64 Ce qui est largement suffisant étant donné que tnous travaillons en local
Protocol : 06 TCP
CheckSum : c2 8a Correct
Adresse Source : 7f 00 00 01 Correspond à l'adresse localhost
Adresse Destination : 7f 00 00 01 Idem
Port Source : 16 2e = 5678 Est le port configuré dans le bloc TCP Writer d'OpenVibe
Port Destination : 94 10 = 37904
Sequence Number : 05 7b a6 c7
Acknowledgment : 6f c2 f5 62
Longueur de l'en-tete : 80 = 32 Octets que nous sommes en train de détailler
Flags : 18 = Acknowledgment et Push activés
Window Size Value 08 00 = 2048 Octets seront envoyés sans attendre de confirmation d'un éventuel client
CheckSum : fe 30 : La validation étant désactivé d'après WireShark
00 00
Options 01 01 : Ne fait Rien
Kind : 08 TimeStamp(8)
Length : 0a = 10 Octets concernant les variables de temps
Heure d'envoie celon l'émeteur : 08 09 f7 58
Timestamp Echo Replay :08 09 f7 43 
8 Octets de Données : 75 df 7a cb fa e0 d9 3f

L'heure d'envoie de l'émeteur : 08 09 f7 58 que nous avons observer conrespondrait à la date du 11/4/1974 à 1:07:52. Nous avons donc déduis que le server n'enverrait donc pas les données de la manière dont WireShark les interprète... Mais nous n'avons pas plus d'information sur les envois de données que celle rappelées plus haut.

'''Script Blender'''

Nous avons essayé d'écrire un script implémentant soit une communication TCP ou UDP dans le cas d'une future amélioration, tout en restant simple. La communication TCP étant celle que nous visons à utiliser actuellement, et la communication UDP étant celle des VRPN :

<code>
# Projet BCI Lagis Lille
# 
# TCP client

import socket
import sys
#Here enter mode TCP or VRPN 
#depending on how you send data from OpenVibe
MODE = "TCP"
HOST = "localhost"
BUFFER_SIZE = 1024
#Port are here defined as defaults openvibe values
if(MODE == "TCP"):
# Create a socket TCP (SOCK_STREAM for TCP socket)
PORT = 5678
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
else:
# Create a socket UDP (SOCK_DGRAM for UDP socket)
print("VRPN")
PORT = 3883
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
try:
if(MODE == "TCP"):
# Connect to server
sock.connect((HOST, PORT))
else:
sock.bind((HOST, PORT))
# Receive data from the server and shut down
ov_msg = sock.recv(BUFFER_SIZE)
finally:
sock.close()
print("Data :", ov_msg)
</code>

La communication TCP est fonctionnelle, nous avons analysé les échanges OpenVibe<->Blender avec WireShark et les resultats sont encourageants. Le script client étant exécuté periodiquement dans blender (au rythme des image de l'animation) on observe un taux de réussite d’échange de donnée supérieur à 85%. Ces erreurs n'engendreront donc pas de défaut de fonctionnement du système global. Tout au plus, on observera un retard d'une ou deux images entre le moment où la donnée est recue et le moment ou l'animation est modifié.

[[Fichier:BCI WireShark TCP OVtoB.png]]

'''Conversion de donnée OpenVibe'''

Les données d'OpenVibe sont formatés en EBML (Extensible Binary Meta Language) historiquement un formatage pour fichiers multimédia propriétaire de Matroska. Pour les rendre exploitable dans blender nous avons trouver un parser EBML to Python.

Sources : http://sjohannes.wordpress.com/2010/04/28/matroska-tagging-support/

Code Python : http://bazaar.launchpad.net/~exaile-devel/exaile/exaile-0.3.x/view/head:/xl/metadata/_matroska.py

Cette bibliothèque a été développé dans un besoin de convertir des fichiers multimédia en python. Comme notre projet est très différent nous avons étudié ce code pour voir si effectivement il pourrait répondre à nos besoins.
Nous avons donc utilisé le Bloc EBML Spy d'OpenVibe pour observer les données, connues, provenant du classifier du scenario "Handball-replay". La donnée utile pour nous étant un nombre réel compris entre -10 et +10 et indiquant si le sujet présentait des mouvement de la main droite ou de la main gauche.

[[Fichier:BCI EBML Stream Champeiro.png|1000px]]

Dans le code source du parser, on trouve des lignes 292 à 376 les tags qui sont actuellement convertis. Malheureusement, aucun des tags openvibe n'est pris en compte par ce parser. Nous avons donc envisagé d'adapter ce parser à nos besoin quitte à le reconstruire presque entièrement.

= Développement du retour graphique sous blender =

== Objectif ==

Le développement sous Blender consiste à créer un feedback visuel pour l’utilisateur. Il faut donc modéliser une main qui bouge selon la volonté de mouvement de l’utilisateur. Dans un premier temps, il faut créer une main, et lui associer une animation pour qu’elle pianote, superposée à un piano dont les touches bougent en même temps que les doigts ; l’objectif est que lorsque l’utilisateur veut pianoter, il voit la main pianoter à sa place et appuyer sur les touches du piano. Le logiciel de création de Blender permet d’associer un signal d’entrée, par exemple l’appui sur une touche du clavier (d’ordinateur), à l’animation de la main et du piano. L’intérêt serait alors que le signal d’entrée soit provoqué par le logiciel OpenVibe lors de l’imagination de mouvement de l’utilisateur.

== Réalisation ==

Une main déjà modélisée et articulée, ainsi qu’un décor d’opéra contenant un piano, ont été trouvés sur des sites communautaires de Blender.
Pour le piano, il a été nécessaire de recréer le clavier (l’ensemble des touches) car dans le modèle utilisé, elles étaient toutes solidaires. Le clavier à touches indépendantes a donc été placé à la place du clavier original. Maintenant, il est donc possible de faire bouger chaque touche indépendamment, et donc de créer l’animation des touches qui s’enfoncent.

[[Fichier:BCI_piano_Champeiro.png]]

Pour la main, une animation était déjà pré-programmée, qui montrait la main d’abord fermée, puis qui s’ouvrait le plus possible, sans que le rendu paraisse irréaliste. La construction de l’animation est basée sur une série de marqueurs qui indiquent la position que doivent avoir chaque membres à certaines images de l’animation. En réutilisant ces marqueurs, il est donc possible de créer le mouvement de pianotement voulu.

[[Fichier:BCI_roll1_Champeiro.png]] [[Fichier:BCI_roll2_Champeiro.png]]

''Vue du modèle de la main au repos et pendant le pianotement''

Une étape intéressante serait de pouvoir agir sur la vitesse de l’animation de la main, en fonction de l’intensité de l’imagination du mouvement par l’utilisateur.

= Gestion de Projet et Sources =

== Planning ==

[[Fichier:Gant PFE BCI.png|650px]]

'''Présentation Mi-PFE'''

10/12/2013

'''Présentation BCI

21/02/2014

'''Présentation Polytech'Lille'''

27/02/2014

== Bibliographie ==

=== OpenVibe ===

http://openvibe.inria.fr/

http://openvibe.inria.fr/tag/vrpn/

http://openvibe.inria.fr/documentation-index/#User+Documentation

=== Moteur 3D ===

https://fr.wikipedia.org/wiki/Moteur_3D

http://www.desura.com/search?q=engine+3d&sa.x=0&sa.y=0

http://www.ogre3d.fr/

http://www.outerra.com/forum/index.php?topic=637.0

http://jeux.developpez.com/tutoriels/?page=prog-3d#ogre-3d

http://mycryengine.com/index.php?conid=70

http://www.havok.com/try-havok

http://www.desura.com/engines/unreal-development-kit/downloads/udk

http://www.truevision3d.com/downloads.php

http://hub.jmonkeyengine.org/

http://www.neoaxis.com/neoaxis/licensing

http://www.shivaengine.com/download.html

http://unity3d.com/unity/download

https://store.unity3d.com/

http://www.twinmotion.com/acheter.html

http://www.worldofleveldesign.com/categories/level_design_tutorials/recommended-game-engines.php

=== Blender ===

http://www.blender.org/education-help/tutorials/game-engine/

http://blendercave.limsi.fr/doku.php

http://www.blendswap.com/

=== EEG ===

http://openeeg.sourceforge.net/doc/sw/

http://www.emotiv.com/store/app.php

=== Autres Projets BCI ===

http://air.imag.fr/index.php/Armind

https://sites.google.com/site/romaingrandchamp/cerveaurium

= Annexe =

== Journal ==

'''Entrée 1'''

Installation de OpenVibe (en deux fois pour le rendre fonctionnel)

'''Entrée 2'''

Réalisation de l'ensemble des tutoriels disponibles sur le site de l'INRIA mais malheureusement, cela ne nous a pas amené jusqu'à l'utilisation du VRPN. Nous Projetons maintenant d'étudier les moteurs graphiques 3D existant pour en choisir un pour notre développement.

'''Entrée 3'''

Installation de Ogre. Nécessite un IDE ainsi qu'un compilateur (Comblock + MinGW pour Windows)

Configuration : Installation de MinGW à la racine de C:/ Installation de Ogre Installation de Comblock
Problème pour compiller

Fichier:Piano.png

2014-02-17T15:58:42Z

Tchampag : a téléversé une nouvelle version de « Fichier:Piano.png »

BCI : Interface Cerveau Ordinateur

2014-02-06T22:19:23Z

Tchampag : /* Réalisation */

= Présentation =

== Contexte : ==

Le but général est de faciliter la vie des personnes paralysées avec un système interprétant directement leurs signaux cérébraux pour communiquer ou agir avec leur environnement. Les patients susceptibles d'utiliser cette technologie sont ceux atteint de paralysie musculaire complète (LIS : Locked In Syndrom) ou de SLA (Sclérose Latérale Amyotrophique). Ces maladies affectant très peu les fonctions cérébrales, cette technologie semble pouvoir devenir LA solution pour pallier au handicap. Ce projet est réalisé en collaboration avec l'équipe BCI du LAGIS.

Voilà ce que fait l'interface cerveau ordinateur (BCI : Brain Computer Interface ou BMI : Brain Machine Interface) de façon détaillée : les signaux électroencéphalographiques (EEG) sont acquis, numérisés et traités pour pouvoir ensuite être transformés en commandes. Une partie de ces informations est aussi affichée de manière simple pour l'utilisateur pour lui permettre un apprentissage plus rapide grâce à ce retour visuel.

Comment ?

[[Fichier:Schema-bci.png|600px|center]]

=== Acquisition ===

L'information cérébrale peut-être acquise de différentes manières :

- La première est non invasive, c'est à dire qu'elle ne nécessite pas d'intervention chirurgical visant à implanter un quelconque dispositif dans le corps du patient. A l'aide d'un casque muni d'électrodes placés sur le crane, on peut acquérir les signaux cérébraux passant à travers la boite crânienne (appelés signaux EEG). L'ordre de grandeur de ces signaux électriques ne dépasse pas le microvolt et les signaux acquis sont très fortement bruités. Mais ce dispositif est simple à mettre en œuvre et peut être utilisé aussi bien par les patients que par les chercheurs lors d'une phase expérimentale qu'est la nôtre.

- La seconde est semi-invasive, l’électrode servant à l'acquisition des signaux est implanté sous la surface de la boîte crânienne (ECoG : électrocorticogramme). Cette méthode permet d'augmenter considérablement la qualité des signaux qui sont beaucoup moins bruités que les signaux EEG. De plus, elle présente peu de risque puisque l’électrode est situé à l’extérieur de la dure-mère.

- La dernière est dite invasive, dans le sens où on vient placer des électrodes directement dans la masse cérébrale. Cette méthode a deja fait ses preuves : en 2005 un patient tétraplégique était capable de contrôler une prothèse robotique grâce à ce dispositif. Néanmoins, les électrodes ont une durée de vie limitée et les lésions cérébrales, dues à l’implantation des électrodes, sont irréversibles.

Une autre méthode consiste à détecter des signaux résultant de stimuli extérieurs connus (ERP : Event Related Potentials). Dans le cadre de notre projet, nous allons développer une interface graphique qui va être intégrer dans une interface BCI de type asynchrone basée sur l'analyse des signaux EEG acquis dans le cas de mouvements imaginés des pieds et des mains gauche ou droite. Les EEG considérés sont issus des activités ipsilatérales et contralatérales du cortex pré-moteur.

=== Traitement des signaux EEG ===

L'objectif du traitement des signaux EEG est de discriminer le mouvement imaginé par le patient (main droite, main gauche, pied). Pour cela, il est nécessaire d'extraire des signaux EEG un certains nombre d'attributs qui vont permettre de prendre une décision sur la commande à effectuer au sein de l'interface BCI en cours de developpement au LAGIS. Il est effectué par un logiciel d'analyse numérique comme MatLab, OpenVibe.

Les attributs extraits sont les amplitudes des signaux cérébraux dans certaines bandes de fréquence. Exemple, l'amplitude du rythme µ (entre 8Hz et 15Hz) disparait environ une seconde avant et pendant un mouvement des pieds ou des mains, mais aussi avant et pendant l'imagination de ce mouvement. Dans le même contexte on peut observer de grandes modifications d'amplitude du signal EEG dans la bande ß (entre 15Hz et 35Hz) occurrentes avant, pendant et juste après un mouvement. Ces signaux sont toujours très brefs mais la manière dont ils sont acquis (niveau d'invasivité) change complètement la manière dont ils seront traités. Les signaux mesurés à la surface du cerveau sont les plus problématiques car ils résultent de l'activité de millions de neurones.

Le pré-traitement a pour fonction l’élimination des artefacts (signaux induits par une autre activité corporelle que celle observée comme le clignement des yeux, la déglutition...) ainsi que l'amélioration du rapport signal sur bruit, bruit venant de tous les signaux à proximité, autant dire de tous les neurones à proximité donc quelques millions par point de mesure. Pour ce faire, différentes techniques sont mises en œuvre :

-Filtrage spatial : Combinaison linéaire des signaux des électrodes voisines. Par exemple le filtrage Laplacien, consistant à soustraire à un signal, la moyenne de ces voisins : très répandu car aussi simple qu’efficace pour éliminer le bruit.

-Filtrage fréquentiel : Sachant que nous cherchons à mesure l'amplitude des signaux dans les bandes de fréquence 8-35Hz il convient d'effectuer un filtrage fréquentiel éliminant toutes les fréquences hors de cette plage.

-Interface Synchrone : Une interface est dite Synchrone lorsque ce n'est pas l'activité spontanée du cerveau qui est analysée mais la réponse attendu à des stimulus générés par l'interface. Des signaux réflexifs sont générés de manière mécanique et inconsciente ce qui rend la phase d'apprentissage beaucoup plus simple.

-Interface Asynchrone : Une interface asynchrone à contrario analyse les signaux à tous moments. Et même si l'on peut sélectionner les zones du cerveaux à observer en choisissant l'emplacement des électrodes il n’empêche que les signaux observés sont le résultat de la somme de toutes les activités cérébrales avoisinante. Dans le cas de la réalisation ou de l'imagination de mouvements des mains (droite ou gauche) par exemple, il s'agit de reconnaitre dans les signaux cérébraux, le moment où un événement se produit et le type d'événement généré (droite ou gauche). Dans le cas de l'interface développée par le LAGIS les signaux EEG sont analysés en s'appuyant sur l'expertise des neurophysiologistes qui ont mis en évidence des modifications des signaux EEG dans certaines bandes de fréquence dans la zone moteur du cortex avant, pendant et après l'imagination ou la réalisation du mouvement.

=== Méthode d'exploitation des signaux cérébraux acquis (ou paradigme) ===
Afin de transformer les signaux acquis en commande d'un vas, d'un fauteuil roulant, ou autre, il est nécessaire de définir un paradigme expérimental. En d'autre termes : la manière dont les signaux cérébraux vont être exploités au sein de l'interface. Il est possible de distinguer deux grandes catégories d'interfaces BCI dans ce cas : les interfaces synchrones et les interfaces asynchrones.

=== Classification ===

A l'issue de la phase de traitement précédemment décrite, nous disposons d'un ensemble d'attributs mesurés sur les signaux à intervalles réguliers (tous les dixièmes de seconde).
A partir de ces vecteurs d'attributs, il s'agit d'identifier le type de mouvement réalisé ou imaginé(dans le cas d'une interface asynchrone) ou de décider si le sujet a répondu positivement au stimulus ou non (dans le cas d'une interface synchrone).

Il s'agit donc de décider si le vecteur d'attributs considéré est caractéristique d'un mouvement ou d'une réponse positive au stimulus. Ceci est le propre de ce que l'on appelle la classification.

Il existe deux grandes familles de techniques de classification : la classification supervisée et la classification non supervisée. La classification non supervisée consiste à prendre une décision d'identification sans aucune connaissance à priori sur les vecteurs d'attributs (ou éléments) à classer.

La classification supervisée part de la connaissance à priori des éléments que l'on vise à identifier et se décline en deux phases successives :

'''Offline'''
Une phase d'apprentissage basée sur l'analyse d'éléments connus et parfaitement identifiés. Il s'agit alors d'ajuster les paramètres du classifieur en fonction des éléments à priori identifiés

'''Online'''
Une phase de classement des éléments inconnus en utilisant le classifieur paramétré dans la phase précédente.

Dans le domaine des interfaces BCI, les techniques de classification les plus utilisées sont de type supervisées. Les plus courantes :

-LDA

-Les réseaux de neurones

-La classification floue

Cette étape a pour but d'exploiter les éléments caractéristiques extraits précédemment. Les méthodes choisies dépendent du type d'interface, on distinguera deux types d'interfaces: synchrones ou asynchrones. Le logiciel remplissant cette fonction a été développé par l'INRIA, il s'agit d'OpenVibe.

=== Commande ===

Le résultat de la classification des attributs extraits des signaux cérébraux st généralement mise sous forme de décision binaire. Par exemple : "Y a t il imagination de mouvement de la main droite?" Résultat : "Oui ou Non". Nous pouvons alors relier ce résultat à la partie opérative de l'interface et piloter ainsi un actionneur. Le nombre d'actionneur devant bien sur être adapté à l'interface qui les exploitera.

=== Interfaces BCI Existantes ===

'''Interface Synchrone'''

[[Fichier:Doc BoxAlgorithm P300SpellerVisualisation Snapshot.png|400px|right]]
Des applications ont déjà été créées pour permettre à une personne complètement immobile de communiquer ou de se déplacer. En terme d'interface de communication, le P300 Speller qui est basé sur la détection de potentiels endogènes évoqués, signaux correspondant à une activité cognitive. Cette interface permet à un sujet entraîné d’écrire plusieurs caractères par minute. Le principe est simple: le sujet regarde une matrice de caractères dont les colonnes et les lignes sont mises en surbrillance de manière aléatoire, il doit alors se concentrer sur le caractère qu'il veut écrire et compter son nombre d'illuminations. A chaque fois que la lettre est comptée une modifications des signaux se produit 300ms plus tard. Il est ainsi possible de détecter la colonne et la ligne sur lesquelles se situe le caractère intéressant. Après plusieurs scintillement on peut donc connaître la lettre choisi par le patient.

[[Fichier:Online-shooter.png|445px|left]]Il existe également tout un ensemble d'interface développées à partir de l'analyse et l'interprétation des signaux SSVEP (Steady-State Visual Evoked Potential). Ceux-ci ne sont pas générés par une action cognitive mais inconsciemment par notre cerveau. Lorsque nous regardons un objet clignotant sur l’écran, on retrouve la fréquence de ce clignotement sur notre lobe occipital. Ainsi, en créant une interface graphique constituée de plusieurs objets clignotants à différentes fréquences (de l'ordre de quelques dizaines de hertz), et en analysant les signaux évoqués, on peut reconnaitre l'objet observé par le sujet. Cette technique basée sur l'analyse de signaux reflexes s'avère très efficace et ne nécessite aucune phase d'apprentissage. L'exemple ci dessous pourrait représenter l'écran de saisie des commandes de pilotage d'un fauteuil roulant. Les deux carrés pourraient représenter une demande de rotation gauche ou droite tandis que le triangle représenterait une demande de marche avant.

[[Fichier:MuseumImmersive1.jpg|right|400px]]

'''Interface Asynchrone'''

La dernière technique est la plus complexe mais aussi celle avec le plus grand potentiel. Elle consiste à analyser les signaux cérébraux en vue de détecter la réalisation ou l'imagination de mouvements de différentes parties du corps. Dans notre cas, ce sont les mouvements des deux mains et des pieds qui sont exploités car plus présents au niveau du cortex moteur et donc plus faciles à détecter. L'identification de ces mouvements fournit donc un total de 3 commandes complètement indépendantes de toute stimulation extérieure. On ne peut prévoir à l'avance quand le sujet décidera d'imaginer un mouvement d'une des parties de son corps. Ce paradigme a déjà été exploité par l'INRIA de Rennes pour diriger un avatar dans un espace 3D virtuel matérialisant une visite virtuelle d'un musée. Les signaux correspondant aux mouvements de la main droite sont utilisés pour tourner à droite, ceux de la main gauche pour tourner à gauche et les mouvements des pieds pour avancer.

Des applications interfaces BCI ont aussi été développées pour commander des prothèses ou des fauteuils roulants. En effet, des expériences ont été menées avec succès sur un patient équipé d'une interface non invasive. Il a réussi à contrôler une main robotique grâce à l'analyse de ses rythmes sensorimoteurs, exploités pour détecter l'imagination de mouvement de la main. Ces essais ont été fais sur des personnes valides mais on peut imaginer les possibilités qui s'offrent à des personnes paralysées ou amputées.

== Objectif : ==

=== Formulation des besoins ===

[[Fichier:main3d.jpg|right|200px]]
Notre projet consiste au développement de l'interface graphique 3D d'une BCI, de type asynchrone basée su l'analyse de mouvements, réels ou imaginés, fournissant à l'utilisateur un feedback visuel ds commandes qu'il effectue. L'interface doit être composée de 2 couches graphiques dissociables :

- Une couche que nous appelons "la couche Feedback" : c'est la couche est au premier-plan. Elle affichera un avatar virtuel qui va exécuter le mouvement réel ou imaginé par le sujet. Par exemple, dans le cas d'un mouvement imaginé de la main, nous devons représenter graphiquement une main exécutant le mouvement imaginé par le sujet. Il peut s'agir d'une rotation du poignet, d'un mouvement de préhension, de mouvements des doigts etc. La visualisation du mouvement que le sujet imagine (le feedback) permettra peut-être un apprentissage de l'interface dit plus aisé pour le sujet mais on doit essayer de s'assurer qu'il ne soit pas un élément perturbateur. Nos inquiétudes sont fondées sur le même principe que l'instabilité des systèmes bouclés en général. On ne peut pas être certain qu'en observant son avatar à l'écran, le cerveau du sujet ne génère pas les sinusaux électriques correspondant au mouvement qu'il observe.

[[Fichier:piano 3d.jpg|300px|left]]
- Une couche ludique : celle-ci se situe au second-plan. Elle présente un objectif à réaliser par l'utilisateur en cohérence avec l'action imaginée et représentée par l'avatar. On peut par exemple imaginer un clavier de piano dans le cas d'un mouvement des doigts, d'un ballon qui se gonfle dans le cas de mouvements de préhension répétés.L'objectif permet de créer une forte motivation de l'utilisateur qui facilitera inconsciemment sa concentration. Par exemple : Si le mouvement imaginé par le sujet est de fermer et d'ouvrir la main, on sélectionnera une interface montrant par exemple une main actionnant une pompe et un arrière plan, des ballons à gonfler. Ou encore, avec un mouvement de doigt tapoter sur une table, on choisira d'avantage un piano en arrière plan joué par cette/ces main(s), ou même, avec un mouvement de serrage de vis avec la main, un meuble à monter le plus rapidement possible.

Ces couches doivent être affichables une par une ou en même temps. Le but est de pouvoir analyser l'impact du feedback sur les performances du sujet lors l'utilisation de l'interface BCI. Ainsi que de fournir au sujet un feedback "réaliste" des mouvements qu'il réalise ou imagine plutôt qu'un curseur sur un graphique.
[[Fichier:Piano main 3d.jpg|430px|center]]

=== Spécifications ===

Au sein de l'équipe BCI du LAGIS, les outils de développement les plus utilisés sont :

-MatLab : Pour le traitement des signaux.

-OpenVibe : Logiciel dédié BCI développé par l'INRIA de Rennes, pour la partie acquisition, traitement et feedback visuel.

-C++ : Pour le développement des blocs OpenVibe additionnels

Les contraintes à respecter dans le cadre de notre projet sont les suivantes :

-Respect et/ou compatibilité avec les technologies utilisées : Compatibilité de l'interface graphique avec OpenVibe. Compatibilité entre l'application et le nombre de signaux de commandes en sortie d'OpenVibe (main gauche, main droite, pieds, repos).

-Grande configurabilité : Ne connaissant pas l'utilisateur qui va utiliser le système, il doit être le plus personnalisable possible. Le but est que chacun puisse s'identifier à notre application pour obtenir les meilleurs résultats possibles. Cela implique donc d'assurer une grande configurabilité des objectifs pour l'utilisateur mais aussi de la manière d'afficher la complétion de ces objectifs et ses performances. Enfin il est important d'assurer une grande configurabilité du mouvement du feedback pour le rendre plus cohérent possible avec celui du sujet.

-Facilité de configuration : l'utilisateur doit pouvoir changer les options facilement et rapidement.

-Modulation du programme : le code source doit être le plus générique possible, documenté, commenté et le plus facilement modifiable possible.

= Étude des différents moteurs graphiques 3D =

== Spécifications ==

Les contraintes de choix du moteur 3D sont les suivantes par ordre de priorités décroissantes :

-Compatibilité avec le VRPN de Openvibe

-Permettre le développement multiplateforme (Linux, Windows, MacOS)

-Simplicité de développement

-Ressources nécessaires pour le mettre en œuvre minimisées

-Rendu visuel de qualité

== Choix d'un moteur ==

=== Moteur Jeux Vidéos Grand Public ===

Les moteurs suivants sont utilisés par les développeurs de jeux vidéos actuels. Leurs rendus graphiques sont les meilleurs, donc nous n'avons analysé en premier lieu que leurs autres caractéristiques :

-Anvil (Assassin's Creed) : License propriétaire privée d'Ubisoft, impossible d'acheter le DK

-CryEngine (Crysis) : Gratuit pour une utilisation non commerciale

-Dunia Engine (Farcry) : Non distribué

-Frostbite (Battlefield) : Non distribué

-Havok (Halo) :

-Hero Engine (Star Wars : Old Republic)

-Quest3D (Audiosurf)

-Source (Portal) : Non distribué

-Unreal Engine (Borderlands)

La plupart de ces moteurs sont très performants, ce qui implique l'utilisation de machines suffisamment puissantes pour les mettre en œuvre. De plus, certains sont conçus exclusivement pour du développement de jeu pour console de salon. Même si leur complexité de programmation est tout aussi abordable que les autres, nous ne pouvons pas choisir ces derniers.

=== Etude Comparative des Moteurs Graphiques ===

-Outerra : Ce moteur permet surtout la génération d'immenses espaces 3D jusqu'à des planètes entières. Le rendu global est effectivement très joli mais les détails de petits éléments sont assez simplistes. Ce moteur n'est donc pas du tout adapté à notre projet.

[[Fichier:Engines.png]]

=== Choix final ===

[[Fichier:Blender_logo.jpg]]

Après cette étude nous avons retenus '''Blender''' car il permet un développement très performant et rapide de model 3D réalistes. Nous comptons utiliser son moteur de jeu BlenderGame qui permet des interactions avec les models pour faire fonctionner nos interfaces. La difficulté que cela soulève est l'absence de VRPN dans ce moteur. Outil qui permet la communication entre un système tier et une interface de réalité virtuel. La suite va donc consister à interfacer Blender et Openvibe

= Développement d'une interface logicielle OpenVibe <-> Blender =

Notre objectif est de permettre une communication entre le logiciel OpenVibe, et le moteur graphique de Blender. Plusieurs protocoles de communication sont alors exploitables.

[[Fichier:Blender-Openvibe.png]]

== Reflexion ==

=== TCP/IP ===

Nos recherches nous ont amené à entrer en relation avec Romain Grandchamp, un doctorant ayant déjà travaillé sur ce sujet : c'est lui qui a réalisé une interface BCI implémentant une liaison TCP/IP entre Blender et BCI2000, un logiciel similaire à OpenVibe pour l'utilisation en recherche en BCI. C'est lui qui nous a proposée cette éventualité. Voici l'un de ses projets en cours : https://sites.google.com/site/romaingrandchamp/cerveaurium

Blender permet ce type de communication grace à un script python, mais ce n'est pas le cas d'OpenVibe.

Notre objectif ici est donc de créer un bloc OpenVibe qui implémentera une fonction de communication via ce protocole.

Ce bloc prendra en entrée un vecteur de donnée issu du classifieur. Le programmeur de scénario OpenVibe pourra paramétrer le message envoyé et pour quel donné du vecteur.
L'idée est donc d'importer des bibliothèques de communication tcp/ip dans openvibe pour développer un bloc pouvant communiquer aussi bien avec Blender qu'avec un autre programme voire un autre système en réseau. Au niveau du choix de protocole TCP ou UDP, c'est le protocole TCP qui satisfera le mieux notre besoin car il garantit l'intégrité des paquets transmis. Sachant que les messages seront transmis à chaque changement d'état d'un des paramètre d'entrée de la boite, il faut absolument que l'ordre soit correctement transmis à Blender. Le protocole UDP permettrai une meilleure réactivité, car plus rapide, mais il ne garantis pas le bon fonctionnement à chaque transmission, on pourrait envisager ce protocole dans le cas d'échanges de messages cadencé à une certaine fréquence, où la quantité rattrape la qualité de la communication.

La difficulté rencontrée ici est l'implémentation d'un bloc nouveau dans OpenVibe. Nous nous somme inscrits sur le forum d'OpenVibe pour nous faire aider de la communauté associée.

=== VRPN ===

Un autre moyen de communication est l'utilisation d'un VRPN, un ensemble de librairies permettant la liaison entre un moteur graphique et une interface de réalité virtuelle.
La bibliothèque VRPN est implémentée nativement dans OpenVibe ce qui nous amène à envisager d'implémenter cette même bibliothèque coté Blender. Le problème étant que nous n'avons pas de garantis que ceci soit possible. Il est possible d'étendre Blender grâce à des scripts python donc nous pensons que c'est effectivement faisable mais ne comprenons pas pourquoi est ce que cette fonction n'a pas déjà été implémenté étant donné la manière dont Blender est répandu et son aspet opensource. Cela dit, la communication VRPN utilise en réalité la communication réseau TCP classique comme base (port par défaut 3883), il s'agit donc en fait d'un protocole spécifique ajouté sur la base dont nous avons pas forcément utilité.

Après des recherches approfondies nous avons découvert qu'il existe un patch permettant de transformer Blender en BlenderCave. http://blendercave.limsi.fr/doku.php
Celui ci intègre de nouvelles fonctions notamment la possibilité de faire de la 3D stéréoscopique mais qui intègrerai également un VRPN.
L'inconvénient principal de cette configuration est que ce patch ne peut être utilisé que sur une révision précise de Blender.

L'objectif serait de vérifier sa compatibilité entre OpenVibe et ce dernier. Si c'est le cas, essayer de porter la fonctionnalité VRPN vers une version quelconque de Blender.

== Développement ==

Nous choisissons donc de développer un système de communication TCP car les briques de bases sont disponibles de chaque coté. En effet la bibliothèque VRPN utilise en fait une communication TCP, donc OpenVibe devrait pouvoir communiquer par TCP.

=== Objectif ===

Réaliser un nouveau bloc OpenVibe permettant de transmettre des données via TCP ou UDP. Nous sommes inscrits sur le Forum OpenVibe : http://openvibe.inria.fr/forum/
Et partons suivre les tutos OpenVibe sur la créations de nouveaux blocs : http://openvibe.inria.fr/introduction-algo-boxes/

=== Réalisation ===

'''Bloc OpenVibe'''

[[Fichier:BCI TCP Writer Champeirock.png|left]][[Fichier:Wireshark Icon BCI Champeiro.png|right|50px]]
Après avoir commencé à développer notre Bloc nous avons été informé par la communauté qu'un bloc TCP Writer avait déjà été développé mais était en version Non Stable. Nous sommes donc repartis de cette base-ci. Doc TCP Writer : http://openvibe.inria.fr/documentation/unstable/Doc_BoxAlgorithm_TCPWriter.html
Nous avons donc analysé la structure de la transmission avec un outils type WireShark
La boite fait office de Server TCP qui transmet son vecteur d'information d'entrée sur une Socket TCP. On peut choisir 3 types de données de sorties : Raw, Hexa ou String.
Mais en pratique, on ne peut utiliser les formats Hex ou String que pour transmettre des données de stimulation, ce qui n'est pas notre cas ici vu que nous voulons transmettre un vecteur d'information. Nous allons donc nous intéresser au format du message transmis au format Raw.
- La boîte envoie d'abord à chaque client qui se connecte huit variables uint32 :
numéro de version
endianness : 0 == inconnue , 1 == little , 2 == big, 3 == PDP
la fréquence d'échantillonnage du signal
le nombre de canaux (nb de lignes de la matrice d'info transmise)
le nombre d'échantillons par bloc (colonnes de la matrice)
Trois variables de rembourrage

8 * 4 = 32 octets au total. Les 6 dernières variables sont dans l'ordre des octets du flux.

Plusieurs clients peuvent se connecter à la socket. La boîte continue à envoyer des données à chaque client jusqu'à ce que le scénario OpenVibe se termine ou que le client se déconnecte.

Analyse détaillée d'une trame pour la transmission d'une Matrice (1,1) :
La trame est composé d'un total de 74 Octets :
14 Octets Ethernets (Addresses, Type)
20 Octets d'en-tête IPv4
32 Octets TCP (ceux détaillé au dessus)
8 Octets de Données

'''Script Blender'''

Grâce à la communauté Blender il est aisée de trouver un bout de code python implémentant des fonctionnalités réseaux.
Sources : http://blenderartists.org/forum/showthread.php?280465-setblocking%280%29-PROBLEM!&highlight=setblocking

= Développement du retour graphique sous blender =

== Objectif ==

Le développement sous Blender consiste à créer un feedback visuel pour l’utilisateur. Il faut donc modéliser une main qui bouge selon la volonté de mouvement de l’utilisateur. Dans un premier temps, il faut créer une main, et lui associer une animation pour qu’elle pianote, superposée à un piano dont les touches bougent en même temps que les doigts ; l’objectif est que lorsque l’utilisateur veut pianoter, il voit la main pianoter à sa place et appuyer sur les touches du piano. Le logiciel de création de Blender permet d’associer un signal d’entrée, par exemple l’appui sur une touche du clavier (d’ordinateur), à l’animation de la main et du piano. L’intérêt serait alors que le signal d’entrée soit provoqué par le logiciel OpenVibe lors de l’imagination de mouvement de l’utilisateur.

== Réalisation ==

Une main déjà modélisée et articulée, ainsi qu’un décor d’opéra contenant un piano, ont été trouvés sur des sites communautaires de Blender.
Pour le piano, il a été nécessaire de recréer le clavier (l’ensemble des touches) car dans le modèle utilisé, elles étaient toutes solidaires. Le clavier à touches indépendantes a donc été placé à la place du clavier original. Maintenant, il est donc possible de faire bouger chaque touche indépendamment, et donc de créer l’animation des touches qui s’enfoncent.

[[Fichier:piano.png]]

Pour la main, une animation était déjà pré-programmée, qui montrait la main d’abord fermée, puis qui s’ouvrait le plus possible, sans que le rendu paraisse irréaliste. La construction de l’animation est basée sur une série de marqueurs qui indiquent la position que doivent avoir chaque membres à certaines images de l’animation. En réutilisant ces marqueurs, il est donc possible de créer le mouvement de pianotement voulu.

[[Fichier:roll1.png]] [[Fichier:roll2.png]]

''Vue du modèle de la main au repos et pendant le pianotement''

Une étape intéressante serait de pouvoir agir sur la vitesse de l’animation de la main, en fonction de l’intensité de l’imagination du mouvement par l’utilisateur.

= Gestion de Projet et Sources =

== Planning ==

[[Fichier:Gant PFE BCI.png|650px]]

'''Présentation Mi-PFE'''

10/12/2013

'''Présentation BCI

21/02/2014

'''Présentation Polytech'Lille'''

27/02/2014

== Bibliographie ==

=== OpenVibe ===

http://openvibe.inria.fr/

http://openvibe.inria.fr/tag/vrpn/

http://openvibe.inria.fr/documentation-index/#User+Documentation

=== Moteur 3D ===

https://fr.wikipedia.org/wiki/Moteur_3D

http://www.desura.com/search?q=engine+3d&sa.x=0&sa.y=0

http://www.ogre3d.fr/

http://www.outerra.com/forum/index.php?topic=637.0

http://jeux.developpez.com/tutoriels/?page=prog-3d#ogre-3d

http://mycryengine.com/index.php?conid=70

http://www.havok.com/try-havok

http://www.desura.com/engines/unreal-development-kit/downloads/udk

http://www.truevision3d.com/downloads.php

http://hub.jmonkeyengine.org/

http://www.neoaxis.com/neoaxis/licensing

http://www.shivaengine.com/download.html

http://unity3d.com/unity/download

https://store.unity3d.com/

http://www.twinmotion.com/acheter.html

http://www.worldofleveldesign.com/categories/level_design_tutorials/recommended-game-engines.php

=== Blender ===

http://www.blender.org/education-help/tutorials/game-engine/

http://blendercave.limsi.fr/doku.php

http://www.blendswap.com/

=== EEG ===

http://openeeg.sourceforge.net/doc/sw/

http://www.emotiv.com/store/app.php

=== Autres Projets BCI ===

http://air.imag.fr/index.php/Armind

https://sites.google.com/site/romaingrandchamp/cerveaurium

= Annexe =

== Journal ==

'''Entrée 1'''

Installation de OpenVibe (en deux fois pour le rendre fonctionnel)

'''Entrée 2'''

Réalisation de l'ensemble des tutoriels disponibles sur le site de l'INRIA mais malheureusement, cela ne nous a pas amené jusqu'à l'utilisation du VRPN. Nous Projetons maintenant d'étudier les moteurs graphiques 3D existant pour en choisir un pour notre développement.

'''Entrée 3'''

Installation de Ogre. Nécessite un IDE ainsi qu'un compilateur (Comblock + MinGW pour Windows)

Configuration : Installation de MinGW à la racine de C:/ Installation de Ogre Installation de Comblock
Problème pour compiller

BCI : Interface Cerveau Ordinateur

2014-02-06T22:18:46Z

Tchampag : /* Réalisation */

= Présentation =

== Contexte : ==

Le but général est de faciliter la vie des personnes paralysées avec un système interprétant directement leurs signaux cérébraux pour communiquer ou agir avec leur environnement. Les patients susceptibles d'utiliser cette technologie sont ceux atteint de paralysie musculaire complète (LIS : Locked In Syndrom) ou de SLA (Sclérose Latérale Amyotrophique). Ces maladies affectant très peu les fonctions cérébrales, cette technologie semble pouvoir devenir LA solution pour pallier au handicap. Ce projet est réalisé en collaboration avec l'équipe BCI du LAGIS.

Voilà ce que fait l'interface cerveau ordinateur (BCI : Brain Computer Interface ou BMI : Brain Machine Interface) de façon détaillée : les signaux électroencéphalographiques (EEG) sont acquis, numérisés et traités pour pouvoir ensuite être transformés en commandes. Une partie de ces informations est aussi affichée de manière simple pour l'utilisateur pour lui permettre un apprentissage plus rapide grâce à ce retour visuel.

Comment ?

[[Fichier:Schema-bci.png|600px|center]]

=== Acquisition ===

L'information cérébrale peut-être acquise de différentes manières :

- La première est non invasive, c'est à dire qu'elle ne nécessite pas d'intervention chirurgical visant à implanter un quelconque dispositif dans le corps du patient. A l'aide d'un casque muni d'électrodes placés sur le crane, on peut acquérir les signaux cérébraux passant à travers la boite crânienne (appelés signaux EEG). L'ordre de grandeur de ces signaux électriques ne dépasse pas le microvolt et les signaux acquis sont très fortement bruités. Mais ce dispositif est simple à mettre en œuvre et peut être utilisé aussi bien par les patients que par les chercheurs lors d'une phase expérimentale qu'est la nôtre.

- La seconde est semi-invasive, l’électrode servant à l'acquisition des signaux est implanté sous la surface de la boîte crânienne (ECoG : électrocorticogramme). Cette méthode permet d'augmenter considérablement la qualité des signaux qui sont beaucoup moins bruités que les signaux EEG. De plus, elle présente peu de risque puisque l’électrode est situé à l’extérieur de la dure-mère.

- La dernière est dite invasive, dans le sens où on vient placer des électrodes directement dans la masse cérébrale. Cette méthode a deja fait ses preuves : en 2005 un patient tétraplégique était capable de contrôler une prothèse robotique grâce à ce dispositif. Néanmoins, les électrodes ont une durée de vie limitée et les lésions cérébrales, dues à l’implantation des électrodes, sont irréversibles.

Une autre méthode consiste à détecter des signaux résultant de stimuli extérieurs connus (ERP : Event Related Potentials). Dans le cadre de notre projet, nous allons développer une interface graphique qui va être intégrer dans une interface BCI de type asynchrone basée sur l'analyse des signaux EEG acquis dans le cas de mouvements imaginés des pieds et des mains gauche ou droite. Les EEG considérés sont issus des activités ipsilatérales et contralatérales du cortex pré-moteur.

=== Traitement des signaux EEG ===

L'objectif du traitement des signaux EEG est de discriminer le mouvement imaginé par le patient (main droite, main gauche, pied). Pour cela, il est nécessaire d'extraire des signaux EEG un certains nombre d'attributs qui vont permettre de prendre une décision sur la commande à effectuer au sein de l'interface BCI en cours de developpement au LAGIS. Il est effectué par un logiciel d'analyse numérique comme MatLab, OpenVibe.

Les attributs extraits sont les amplitudes des signaux cérébraux dans certaines bandes de fréquence. Exemple, l'amplitude du rythme µ (entre 8Hz et 15Hz) disparait environ une seconde avant et pendant un mouvement des pieds ou des mains, mais aussi avant et pendant l'imagination de ce mouvement. Dans le même contexte on peut observer de grandes modifications d'amplitude du signal EEG dans la bande ß (entre 15Hz et 35Hz) occurrentes avant, pendant et juste après un mouvement. Ces signaux sont toujours très brefs mais la manière dont ils sont acquis (niveau d'invasivité) change complètement la manière dont ils seront traités. Les signaux mesurés à la surface du cerveau sont les plus problématiques car ils résultent de l'activité de millions de neurones.

Le pré-traitement a pour fonction l’élimination des artefacts (signaux induits par une autre activité corporelle que celle observée comme le clignement des yeux, la déglutition...) ainsi que l'amélioration du rapport signal sur bruit, bruit venant de tous les signaux à proximité, autant dire de tous les neurones à proximité donc quelques millions par point de mesure. Pour ce faire, différentes techniques sont mises en œuvre :

-Filtrage spatial : Combinaison linéaire des signaux des électrodes voisines. Par exemple le filtrage Laplacien, consistant à soustraire à un signal, la moyenne de ces voisins : très répandu car aussi simple qu’efficace pour éliminer le bruit.

-Filtrage fréquentiel : Sachant que nous cherchons à mesure l'amplitude des signaux dans les bandes de fréquence 8-35Hz il convient d'effectuer un filtrage fréquentiel éliminant toutes les fréquences hors de cette plage.

-Interface Synchrone : Une interface est dite Synchrone lorsque ce n'est pas l'activité spontanée du cerveau qui est analysée mais la réponse attendu à des stimulus générés par l'interface. Des signaux réflexifs sont générés de manière mécanique et inconsciente ce qui rend la phase d'apprentissage beaucoup plus simple.

-Interface Asynchrone : Une interface asynchrone à contrario analyse les signaux à tous moments. Et même si l'on peut sélectionner les zones du cerveaux à observer en choisissant l'emplacement des électrodes il n’empêche que les signaux observés sont le résultat de la somme de toutes les activités cérébrales avoisinante. Dans le cas de la réalisation ou de l'imagination de mouvements des mains (droite ou gauche) par exemple, il s'agit de reconnaitre dans les signaux cérébraux, le moment où un événement se produit et le type d'événement généré (droite ou gauche). Dans le cas de l'interface développée par le LAGIS les signaux EEG sont analysés en s'appuyant sur l'expertise des neurophysiologistes qui ont mis en évidence des modifications des signaux EEG dans certaines bandes de fréquence dans la zone moteur du cortex avant, pendant et après l'imagination ou la réalisation du mouvement.

=== Méthode d'exploitation des signaux cérébraux acquis (ou paradigme) ===
Afin de transformer les signaux acquis en commande d'un vas, d'un fauteuil roulant, ou autre, il est nécessaire de définir un paradigme expérimental. En d'autre termes : la manière dont les signaux cérébraux vont être exploités au sein de l'interface. Il est possible de distinguer deux grandes catégories d'interfaces BCI dans ce cas : les interfaces synchrones et les interfaces asynchrones.

=== Classification ===

A l'issue de la phase de traitement précédemment décrite, nous disposons d'un ensemble d'attributs mesurés sur les signaux à intervalles réguliers (tous les dixièmes de seconde).
A partir de ces vecteurs d'attributs, il s'agit d'identifier le type de mouvement réalisé ou imaginé(dans le cas d'une interface asynchrone) ou de décider si le sujet a répondu positivement au stimulus ou non (dans le cas d'une interface synchrone).

Il s'agit donc de décider si le vecteur d'attributs considéré est caractéristique d'un mouvement ou d'une réponse positive au stimulus. Ceci est le propre de ce que l'on appelle la classification.

Il existe deux grandes familles de techniques de classification : la classification supervisée et la classification non supervisée. La classification non supervisée consiste à prendre une décision d'identification sans aucune connaissance à priori sur les vecteurs d'attributs (ou éléments) à classer.

La classification supervisée part de la connaissance à priori des éléments que l'on vise à identifier et se décline en deux phases successives :

'''Offline'''
Une phase d'apprentissage basée sur l'analyse d'éléments connus et parfaitement identifiés. Il s'agit alors d'ajuster les paramètres du classifieur en fonction des éléments à priori identifiés

'''Online'''
Une phase de classement des éléments inconnus en utilisant le classifieur paramétré dans la phase précédente.

Dans le domaine des interfaces BCI, les techniques de classification les plus utilisées sont de type supervisées. Les plus courantes :

-LDA

-Les réseaux de neurones

-La classification floue

Cette étape a pour but d'exploiter les éléments caractéristiques extraits précédemment. Les méthodes choisies dépendent du type d'interface, on distinguera deux types d'interfaces: synchrones ou asynchrones. Le logiciel remplissant cette fonction a été développé par l'INRIA, il s'agit d'OpenVibe.

=== Commande ===

Le résultat de la classification des attributs extraits des signaux cérébraux st généralement mise sous forme de décision binaire. Par exemple : "Y a t il imagination de mouvement de la main droite?" Résultat : "Oui ou Non". Nous pouvons alors relier ce résultat à la partie opérative de l'interface et piloter ainsi un actionneur. Le nombre d'actionneur devant bien sur être adapté à l'interface qui les exploitera.

=== Interfaces BCI Existantes ===

'''Interface Synchrone'''

[[Fichier:Doc BoxAlgorithm P300SpellerVisualisation Snapshot.png|400px|right]]
Des applications ont déjà été créées pour permettre à une personne complètement immobile de communiquer ou de se déplacer. En terme d'interface de communication, le P300 Speller qui est basé sur la détection de potentiels endogènes évoqués, signaux correspondant à une activité cognitive. Cette interface permet à un sujet entraîné d’écrire plusieurs caractères par minute. Le principe est simple: le sujet regarde une matrice de caractères dont les colonnes et les lignes sont mises en surbrillance de manière aléatoire, il doit alors se concentrer sur le caractère qu'il veut écrire et compter son nombre d'illuminations. A chaque fois que la lettre est comptée une modifications des signaux se produit 300ms plus tard. Il est ainsi possible de détecter la colonne et la ligne sur lesquelles se situe le caractère intéressant. Après plusieurs scintillement on peut donc connaître la lettre choisi par le patient.

[[Fichier:Online-shooter.png|445px|left]]Il existe également tout un ensemble d'interface développées à partir de l'analyse et l'interprétation des signaux SSVEP (Steady-State Visual Evoked Potential). Ceux-ci ne sont pas générés par une action cognitive mais inconsciemment par notre cerveau. Lorsque nous regardons un objet clignotant sur l’écran, on retrouve la fréquence de ce clignotement sur notre lobe occipital. Ainsi, en créant une interface graphique constituée de plusieurs objets clignotants à différentes fréquences (de l'ordre de quelques dizaines de hertz), et en analysant les signaux évoqués, on peut reconnaitre l'objet observé par le sujet. Cette technique basée sur l'analyse de signaux reflexes s'avère très efficace et ne nécessite aucune phase d'apprentissage. L'exemple ci dessous pourrait représenter l'écran de saisie des commandes de pilotage d'un fauteuil roulant. Les deux carrés pourraient représenter une demande de rotation gauche ou droite tandis que le triangle représenterait une demande de marche avant.

[[Fichier:MuseumImmersive1.jpg|right|400px]]

'''Interface Asynchrone'''

La dernière technique est la plus complexe mais aussi celle avec le plus grand potentiel. Elle consiste à analyser les signaux cérébraux en vue de détecter la réalisation ou l'imagination de mouvements de différentes parties du corps. Dans notre cas, ce sont les mouvements des deux mains et des pieds qui sont exploités car plus présents au niveau du cortex moteur et donc plus faciles à détecter. L'identification de ces mouvements fournit donc un total de 3 commandes complètement indépendantes de toute stimulation extérieure. On ne peut prévoir à l'avance quand le sujet décidera d'imaginer un mouvement d'une des parties de son corps. Ce paradigme a déjà été exploité par l'INRIA de Rennes pour diriger un avatar dans un espace 3D virtuel matérialisant une visite virtuelle d'un musée. Les signaux correspondant aux mouvements de la main droite sont utilisés pour tourner à droite, ceux de la main gauche pour tourner à gauche et les mouvements des pieds pour avancer.

Des applications interfaces BCI ont aussi été développées pour commander des prothèses ou des fauteuils roulants. En effet, des expériences ont été menées avec succès sur un patient équipé d'une interface non invasive. Il a réussi à contrôler une main robotique grâce à l'analyse de ses rythmes sensorimoteurs, exploités pour détecter l'imagination de mouvement de la main. Ces essais ont été fais sur des personnes valides mais on peut imaginer les possibilités qui s'offrent à des personnes paralysées ou amputées.

== Objectif : ==

=== Formulation des besoins ===

[[Fichier:main3d.jpg|right|200px]]
Notre projet consiste au développement de l'interface graphique 3D d'une BCI, de type asynchrone basée su l'analyse de mouvements, réels ou imaginés, fournissant à l'utilisateur un feedback visuel ds commandes qu'il effectue. L'interface doit être composée de 2 couches graphiques dissociables :

- Une couche que nous appelons "la couche Feedback" : c'est la couche est au premier-plan. Elle affichera un avatar virtuel qui va exécuter le mouvement réel ou imaginé par le sujet. Par exemple, dans le cas d'un mouvement imaginé de la main, nous devons représenter graphiquement une main exécutant le mouvement imaginé par le sujet. Il peut s'agir d'une rotation du poignet, d'un mouvement de préhension, de mouvements des doigts etc. La visualisation du mouvement que le sujet imagine (le feedback) permettra peut-être un apprentissage de l'interface dit plus aisé pour le sujet mais on doit essayer de s'assurer qu'il ne soit pas un élément perturbateur. Nos inquiétudes sont fondées sur le même principe que l'instabilité des systèmes bouclés en général. On ne peut pas être certain qu'en observant son avatar à l'écran, le cerveau du sujet ne génère pas les sinusaux électriques correspondant au mouvement qu'il observe.

[[Fichier:piano 3d.jpg|300px|left]]
- Une couche ludique : celle-ci se situe au second-plan. Elle présente un objectif à réaliser par l'utilisateur en cohérence avec l'action imaginée et représentée par l'avatar. On peut par exemple imaginer un clavier de piano dans le cas d'un mouvement des doigts, d'un ballon qui se gonfle dans le cas de mouvements de préhension répétés.L'objectif permet de créer une forte motivation de l'utilisateur qui facilitera inconsciemment sa concentration. Par exemple : Si le mouvement imaginé par le sujet est de fermer et d'ouvrir la main, on sélectionnera une interface montrant par exemple une main actionnant une pompe et un arrière plan, des ballons à gonfler. Ou encore, avec un mouvement de doigt tapoter sur une table, on choisira d'avantage un piano en arrière plan joué par cette/ces main(s), ou même, avec un mouvement de serrage de vis avec la main, un meuble à monter le plus rapidement possible.

Ces couches doivent être affichables une par une ou en même temps. Le but est de pouvoir analyser l'impact du feedback sur les performances du sujet lors l'utilisation de l'interface BCI. Ainsi que de fournir au sujet un feedback "réaliste" des mouvements qu'il réalise ou imagine plutôt qu'un curseur sur un graphique.
[[Fichier:Piano main 3d.jpg|430px|center]]

=== Spécifications ===

Au sein de l'équipe BCI du LAGIS, les outils de développement les plus utilisés sont :

-MatLab : Pour le traitement des signaux.

-OpenVibe : Logiciel dédié BCI développé par l'INRIA de Rennes, pour la partie acquisition, traitement et feedback visuel.

-C++ : Pour le développement des blocs OpenVibe additionnels

Les contraintes à respecter dans le cadre de notre projet sont les suivantes :

-Respect et/ou compatibilité avec les technologies utilisées : Compatibilité de l'interface graphique avec OpenVibe. Compatibilité entre l'application et le nombre de signaux de commandes en sortie d'OpenVibe (main gauche, main droite, pieds, repos).

-Grande configurabilité : Ne connaissant pas l'utilisateur qui va utiliser le système, il doit être le plus personnalisable possible. Le but est que chacun puisse s'identifier à notre application pour obtenir les meilleurs résultats possibles. Cela implique donc d'assurer une grande configurabilité des objectifs pour l'utilisateur mais aussi de la manière d'afficher la complétion de ces objectifs et ses performances. Enfin il est important d'assurer une grande configurabilité du mouvement du feedback pour le rendre plus cohérent possible avec celui du sujet.

-Facilité de configuration : l'utilisateur doit pouvoir changer les options facilement et rapidement.

-Modulation du programme : le code source doit être le plus générique possible, documenté, commenté et le plus facilement modifiable possible.

= Étude des différents moteurs graphiques 3D =

== Spécifications ==

Les contraintes de choix du moteur 3D sont les suivantes par ordre de priorités décroissantes :

-Compatibilité avec le VRPN de Openvibe

-Permettre le développement multiplateforme (Linux, Windows, MacOS)

-Simplicité de développement

-Ressources nécessaires pour le mettre en œuvre minimisées

-Rendu visuel de qualité

== Choix d'un moteur ==

=== Moteur Jeux Vidéos Grand Public ===

Les moteurs suivants sont utilisés par les développeurs de jeux vidéos actuels. Leurs rendus graphiques sont les meilleurs, donc nous n'avons analysé en premier lieu que leurs autres caractéristiques :

-Anvil (Assassin's Creed) : License propriétaire privée d'Ubisoft, impossible d'acheter le DK

-CryEngine (Crysis) : Gratuit pour une utilisation non commerciale

-Dunia Engine (Farcry) : Non distribué

-Frostbite (Battlefield) : Non distribué

-Havok (Halo) :

-Hero Engine (Star Wars : Old Republic)

-Quest3D (Audiosurf)

-Source (Portal) : Non distribué

-Unreal Engine (Borderlands)

La plupart de ces moteurs sont très performants, ce qui implique l'utilisation de machines suffisamment puissantes pour les mettre en œuvre. De plus, certains sont conçus exclusivement pour du développement de jeu pour console de salon. Même si leur complexité de programmation est tout aussi abordable que les autres, nous ne pouvons pas choisir ces derniers.

=== Etude Comparative des Moteurs Graphiques ===

-Outerra : Ce moteur permet surtout la génération d'immenses espaces 3D jusqu'à des planètes entières. Le rendu global est effectivement très joli mais les détails de petits éléments sont assez simplistes. Ce moteur n'est donc pas du tout adapté à notre projet.

[[Fichier:Engines.png]]

=== Choix final ===

[[Fichier:Blender_logo.jpg]]

Après cette étude nous avons retenus '''Blender''' car il permet un développement très performant et rapide de model 3D réalistes. Nous comptons utiliser son moteur de jeu BlenderGame qui permet des interactions avec les models pour faire fonctionner nos interfaces. La difficulté que cela soulève est l'absence de VRPN dans ce moteur. Outil qui permet la communication entre un système tier et une interface de réalité virtuel. La suite va donc consister à interfacer Blender et Openvibe

= Développement d'une interface logicielle OpenVibe <-> Blender =

Notre objectif est de permettre une communication entre le logiciel OpenVibe, et le moteur graphique de Blender. Plusieurs protocoles de communication sont alors exploitables.

[[Fichier:Blender-Openvibe.png]]

== Reflexion ==

=== TCP/IP ===

Nos recherches nous ont amené à entrer en relation avec Romain Grandchamp, un doctorant ayant déjà travaillé sur ce sujet : c'est lui qui a réalisé une interface BCI implémentant une liaison TCP/IP entre Blender et BCI2000, un logiciel similaire à OpenVibe pour l'utilisation en recherche en BCI. C'est lui qui nous a proposée cette éventualité. Voici l'un de ses projets en cours : https://sites.google.com/site/romaingrandchamp/cerveaurium

Blender permet ce type de communication grace à un script python, mais ce n'est pas le cas d'OpenVibe.

Notre objectif ici est donc de créer un bloc OpenVibe qui implémentera une fonction de communication via ce protocole.

Ce bloc prendra en entrée un vecteur de donnée issu du classifieur. Le programmeur de scénario OpenVibe pourra paramétrer le message envoyé et pour quel donné du vecteur.
L'idée est donc d'importer des bibliothèques de communication tcp/ip dans openvibe pour développer un bloc pouvant communiquer aussi bien avec Blender qu'avec un autre programme voire un autre système en réseau. Au niveau du choix de protocole TCP ou UDP, c'est le protocole TCP qui satisfera le mieux notre besoin car il garantit l'intégrité des paquets transmis. Sachant que les messages seront transmis à chaque changement d'état d'un des paramètre d'entrée de la boite, il faut absolument que l'ordre soit correctement transmis à Blender. Le protocole UDP permettrai une meilleure réactivité, car plus rapide, mais il ne garantis pas le bon fonctionnement à chaque transmission, on pourrait envisager ce protocole dans le cas d'échanges de messages cadencé à une certaine fréquence, où la quantité rattrape la qualité de la communication.

La difficulté rencontrée ici est l'implémentation d'un bloc nouveau dans OpenVibe. Nous nous somme inscrits sur le forum d'OpenVibe pour nous faire aider de la communauté associée.

=== VRPN ===

Un autre moyen de communication est l'utilisation d'un VRPN, un ensemble de librairies permettant la liaison entre un moteur graphique et une interface de réalité virtuelle.
La bibliothèque VRPN est implémentée nativement dans OpenVibe ce qui nous amène à envisager d'implémenter cette même bibliothèque coté Blender. Le problème étant que nous n'avons pas de garantis que ceci soit possible. Il est possible d'étendre Blender grâce à des scripts python donc nous pensons que c'est effectivement faisable mais ne comprenons pas pourquoi est ce que cette fonction n'a pas déjà été implémenté étant donné la manière dont Blender est répandu et son aspet opensource. Cela dit, la communication VRPN utilise en réalité la communication réseau TCP classique comme base (port par défaut 3883), il s'agit donc en fait d'un protocole spécifique ajouté sur la base dont nous avons pas forcément utilité.

Après des recherches approfondies nous avons découvert qu'il existe un patch permettant de transformer Blender en BlenderCave. http://blendercave.limsi.fr/doku.php
Celui ci intègre de nouvelles fonctions notamment la possibilité de faire de la 3D stéréoscopique mais qui intègrerai également un VRPN.
L'inconvénient principal de cette configuration est que ce patch ne peut être utilisé que sur une révision précise de Blender.

L'objectif serait de vérifier sa compatibilité entre OpenVibe et ce dernier. Si c'est le cas, essayer de porter la fonctionnalité VRPN vers une version quelconque de Blender.

== Développement ==

Nous choisissons donc de développer un système de communication TCP car les briques de bases sont disponibles de chaque coté. En effet la bibliothèque VRPN utilise en fait une communication TCP, donc OpenVibe devrait pouvoir communiquer par TCP.

=== Objectif ===

Réaliser un nouveau bloc OpenVibe permettant de transmettre des données via TCP ou UDP. Nous sommes inscrits sur le Forum OpenVibe : http://openvibe.inria.fr/forum/
Et partons suivre les tutos OpenVibe sur la créations de nouveaux blocs : http://openvibe.inria.fr/introduction-algo-boxes/

=== Réalisation ===

'''Bloc OpenVibe'''

[[Fichier:BCI TCP Writer Champeirock.png|left]][[Fichier:Wireshark Icon BCI Champeiro.png|right|50px]]
Après avoir commencé à développer notre Bloc nous avons été informé par la communauté qu'un bloc TCP Writer avait déjà été développé mais était en version Non Stable. Nous sommes donc repartis de cette base-ci. Doc TCP Writer : http://openvibe.inria.fr/documentation/unstable/Doc_BoxAlgorithm_TCPWriter.html
Nous avons donc analysé la structure de la transmission avec un outils type WireShark
La boite fait office de Server TCP qui transmet son vecteur d'information d'entrée sur une Socket TCP. On peut choisir 3 types de données de sorties : Raw, Hexa ou String.
Mais en pratique, on ne peut utiliser les formats Hex ou String que pour transmettre des données de stimulation, ce qui n'est pas notre cas ici vu que nous voulons transmettre un vecteur d'information. Nous allons donc nous intéresser au format du message transmis au format Raw.
- La boîte envoie d'abord à chaque client qui se connecte huit variables uint32 :
numéro de version
endianness : 0 == inconnue , 1 == little , 2 == big, 3 == PDP
la fréquence d'échantillonnage du signal
le nombre de canaux (nb de lignes de la matrice d'info transmise)
le nombre d'échantillons par bloc (colonnes de la matrice)
Trois variables de rembourrage

8 * 4 = 32 octets au total. Les 6 dernières variables sont dans l'ordre des octets du flux.

Plusieurs clients peuvent se connecter à la socket. La boîte continue à envoyer des données à chaque client jusqu'à ce que le scénario OpenVibe se termine ou que le client se déconnecte.

Analyse détaillée d'une trame pour la transmission d'une Matrice (1,1) :
La trame est composé d'un total de 74 Octets :
14 Octets Ethernets (Addresses, Type)
20 Octets d'en-tête IPv4
32 Octets TCP (ceux détaillé au dessus)
8 Octets de Données

'''Script Blender'''

Grâce à la communauté Blender il est aisée de trouver un bout de code python implémentant des fonctionnalités réseaux.
Sources : http://blenderartists.org/forum/showthread.php?280465-setblocking%280%29-PROBLEM!&highlight=setblocking

= Développement du retour graphique sous blender =

== Objectif ==

Le développement sous Blender consiste à créer un feedback visuel pour l’utilisateur. Il faut donc modéliser une main qui bouge selon la volonté de mouvement de l’utilisateur. Dans un premier temps, il faut créer une main, et lui associer une animation pour qu’elle pianote, superposée à un piano dont les touches bougent en même temps que les doigts ; l’objectif est que lorsque l’utilisateur veut pianoter, il voit la main pianoter à sa place et appuyer sur les touches du piano. Le logiciel de création de Blender permet d’associer un signal d’entrée, par exemple l’appui sur une touche du clavier (d’ordinateur), à l’animation de la main et du piano. L’intérêt serait alors que le signal d’entrée soit provoqué par le logiciel OpenVibe lors de l’imagination de mouvement de l’utilisateur.

== Réalisation ==

Une main déjà modélisée et articulée, ainsi qu’un décor d’opéra contenant un piano, ont été trouvés sur des sites communautaires de Blender.
Pour le piano, il a été nécessaire de recréer le clavier (l’ensemble des touches) car dans le modèle utilisé, elles étaient toutes solidaires. Le clavier à touches indépendantes a donc été placé à la place du clavier original. Maintenant, il est donc possible de faire bouger chaque touche indépendamment, et donc de créer l’animation des touches qui s’enfoncent.

[[Fichier:piano.png]]

Pour la main, une animation était déjà pré-programmée, qui montrait la main d’abord fermée, puis qui s’ouvrait le plus possible, sans que le rendu paraisse irréaliste. La construction de l’animation est basée sur une série de marqueurs qui indiquent la position que doivent avoir chaque membres à certaines images de l’animation. En réutilisant ces marqueurs, il est donc possible de créer le mouvement de pianotement voulu.

[[Fichier:roll1.png]] [[Fichier:roll2.png]]

Vue du modèle de la main au repos et pendant le pianotement

Une étape intéressante serait de pouvoir agir sur la vitesse de l’animation de la main, en fonction de l’intensité de l’imagination du mouvement par l’utilisateur.

= Gestion de Projet et Sources =

== Planning ==

[[Fichier:Gant PFE BCI.png|650px]]

'''Présentation Mi-PFE'''

10/12/2013

'''Présentation BCI

21/02/2014

'''Présentation Polytech'Lille'''

27/02/2014

== Bibliographie ==

=== OpenVibe ===

http://openvibe.inria.fr/

http://openvibe.inria.fr/tag/vrpn/

http://openvibe.inria.fr/documentation-index/#User+Documentation

=== Moteur 3D ===

https://fr.wikipedia.org/wiki/Moteur_3D

http://www.desura.com/search?q=engine+3d&sa.x=0&sa.y=0

http://www.ogre3d.fr/

http://www.outerra.com/forum/index.php?topic=637.0

http://jeux.developpez.com/tutoriels/?page=prog-3d#ogre-3d

http://mycryengine.com/index.php?conid=70

http://www.havok.com/try-havok

http://www.desura.com/engines/unreal-development-kit/downloads/udk

http://www.truevision3d.com/downloads.php

http://hub.jmonkeyengine.org/

http://www.neoaxis.com/neoaxis/licensing

http://www.shivaengine.com/download.html

http://unity3d.com/unity/download

https://store.unity3d.com/

http://www.twinmotion.com/acheter.html

http://www.worldofleveldesign.com/categories/level_design_tutorials/recommended-game-engines.php

=== Blender ===

http://www.blender.org/education-help/tutorials/game-engine/

http://blendercave.limsi.fr/doku.php

http://www.blendswap.com/

=== EEG ===

http://openeeg.sourceforge.net/doc/sw/

http://www.emotiv.com/store/app.php

=== Autres Projets BCI ===

http://air.imag.fr/index.php/Armind

https://sites.google.com/site/romaingrandchamp/cerveaurium

= Annexe =

== Journal ==

'''Entrée 1'''

Installation de OpenVibe (en deux fois pour le rendre fonctionnel)

'''Entrée 2'''

Réalisation de l'ensemble des tutoriels disponibles sur le site de l'INRIA mais malheureusement, cela ne nous a pas amené jusqu'à l'utilisation du VRPN. Nous Projetons maintenant d'étudier les moteurs graphiques 3D existant pour en choisir un pour notre développement.

'''Entrée 3'''

Installation de Ogre. Nécessite un IDE ainsi qu'un compilateur (Comblock + MinGW pour Windows)

Configuration : Installation de MinGW à la racine de C:/ Installation de Ogre Installation de Comblock
Problème pour compiller

Fichier:Roll2.png

2014-02-06T22:17:39Z

Tchampag :

Fichier:Roll1.png

2014-02-06T22:16:11Z

Tchampag :

Fichier:Piano.png

2014-02-06T22:15:36Z

Tchampag : a téléversé une nouvelle version de « Fichier:Piano.png »

Fichier:Piano.png

2014-02-06T22:13:40Z

Tchampag :

BCI : Interface Cerveau Ordinateur

2014-02-06T22:13:09Z

Tchampag : /* Réalisation */

= Présentation =

== Contexte : ==

Le but général est de faciliter la vie des personnes paralysées avec un système interprétant directement leurs signaux cérébraux pour communiquer ou agir avec leur environnement. Les patients susceptibles d'utiliser cette technologie sont ceux atteint de paralysie musculaire complète (LIS : Locked In Syndrom) ou de SLA (Sclérose Latérale Amyotrophique). Ces maladies affectant très peu les fonctions cérébrales, cette technologie semble pouvoir devenir LA solution pour pallier au handicap. Ce projet est réalisé en collaboration avec l'équipe BCI du LAGIS.

Voilà ce que fait l'interface cerveau ordinateur (BCI : Brain Computer Interface ou BMI : Brain Machine Interface) de façon détaillée : les signaux électroencéphalographiques (EEG) sont acquis, numérisés et traités pour pouvoir ensuite être transformés en commandes. Une partie de ces informations est aussi affichée de manière simple pour l'utilisateur pour lui permettre un apprentissage plus rapide grâce à ce retour visuel.

Comment ?

[[Fichier:Schema-bci.png|600px|center]]

=== Acquisition ===

L'information cérébrale peut-être acquise de différentes manières :

- La première est non invasive, c'est à dire qu'elle ne nécessite pas d'intervention chirurgical visant à implanter un quelconque dispositif dans le corps du patient. A l'aide d'un casque muni d'électrodes placés sur le crane, on peut acquérir les signaux cérébraux passant à travers la boite crânienne (appelés signaux EEG). L'ordre de grandeur de ces signaux électriques ne dépasse pas le microvolt et les signaux acquis sont très fortement bruités. Mais ce dispositif est simple à mettre en œuvre et peut être utilisé aussi bien par les patients que par les chercheurs lors d'une phase expérimentale qu'est la nôtre.

- La seconde est semi-invasive, l’électrode servant à l'acquisition des signaux est implanté sous la surface de la boîte crânienne (ECoG : électrocorticogramme). Cette méthode permet d'augmenter considérablement la qualité des signaux qui sont beaucoup moins bruités que les signaux EEG. De plus, elle présente peu de risque puisque l’électrode est situé à l’extérieur de la dure-mère.

- La dernière est dite invasive, dans le sens où on vient placer des électrodes directement dans la masse cérébrale. Cette méthode a deja fait ses preuves : en 2005 un patient tétraplégique était capable de contrôler une prothèse robotique grâce à ce dispositif. Néanmoins, les électrodes ont une durée de vie limitée et les lésions cérébrales, dues à l’implantation des électrodes, sont irréversibles.

Une autre méthode consiste à détecter des signaux résultant de stimuli extérieurs connus (ERP : Event Related Potentials). Dans le cadre de notre projet, nous allons développer une interface graphique qui va être intégrer dans une interface BCI de type asynchrone basée sur l'analyse des signaux EEG acquis dans le cas de mouvements imaginés des pieds et des mains gauche ou droite. Les EEG considérés sont issus des activités ipsilatérales et contralatérales du cortex pré-moteur.

=== Traitement des signaux EEG ===

L'objectif du traitement des signaux EEG est de discriminer le mouvement imaginé par le patient (main droite, main gauche, pied). Pour cela, il est nécessaire d'extraire des signaux EEG un certains nombre d'attributs qui vont permettre de prendre une décision sur la commande à effectuer au sein de l'interface BCI en cours de developpement au LAGIS. Il est effectué par un logiciel d'analyse numérique comme MatLab, OpenVibe.

Les attributs extraits sont les amplitudes des signaux cérébraux dans certaines bandes de fréquence. Exemple, l'amplitude du rythme µ (entre 8Hz et 15Hz) disparait environ une seconde avant et pendant un mouvement des pieds ou des mains, mais aussi avant et pendant l'imagination de ce mouvement. Dans le même contexte on peut observer de grandes modifications d'amplitude du signal EEG dans la bande ß (entre 15Hz et 35Hz) occurrentes avant, pendant et juste après un mouvement. Ces signaux sont toujours très brefs mais la manière dont ils sont acquis (niveau d'invasivité) change complètement la manière dont ils seront traités. Les signaux mesurés à la surface du cerveau sont les plus problématiques car ils résultent de l'activité de millions de neurones.

Le pré-traitement a pour fonction l’élimination des artefacts (signaux induits par une autre activité corporelle que celle observée comme le clignement des yeux, la déglutition...) ainsi que l'amélioration du rapport signal sur bruit, bruit venant de tous les signaux à proximité, autant dire de tous les neurones à proximité donc quelques millions par point de mesure. Pour ce faire, différentes techniques sont mises en œuvre :

-Filtrage spatial : Combinaison linéaire des signaux des électrodes voisines. Par exemple le filtrage Laplacien, consistant à soustraire à un signal, la moyenne de ces voisins : très répandu car aussi simple qu’efficace pour éliminer le bruit.

-Filtrage fréquentiel : Sachant que nous cherchons à mesure l'amplitude des signaux dans les bandes de fréquence 8-35Hz il convient d'effectuer un filtrage fréquentiel éliminant toutes les fréquences hors de cette plage.

-Interface Synchrone : Une interface est dite Synchrone lorsque ce n'est pas l'activité spontanée du cerveau qui est analysée mais la réponse attendu à des stimulus générés par l'interface. Des signaux réflexifs sont générés de manière mécanique et inconsciente ce qui rend la phase d'apprentissage beaucoup plus simple.

-Interface Asynchrone : Une interface asynchrone à contrario analyse les signaux à tous moments. Et même si l'on peut sélectionner les zones du cerveaux à observer en choisissant l'emplacement des électrodes il n’empêche que les signaux observés sont le résultat de la somme de toutes les activités cérébrales avoisinante. Dans le cas de la réalisation ou de l'imagination de mouvements des mains (droite ou gauche) par exemple, il s'agit de reconnaitre dans les signaux cérébraux, le moment où un événement se produit et le type d'événement généré (droite ou gauche). Dans le cas de l'interface développée par le LAGIS les signaux EEG sont analysés en s'appuyant sur l'expertise des neurophysiologistes qui ont mis en évidence des modifications des signaux EEG dans certaines bandes de fréquence dans la zone moteur du cortex avant, pendant et après l'imagination ou la réalisation du mouvement.

=== Méthode d'exploitation des signaux cérébraux acquis (ou paradigme) ===
Afin de transformer les signaux acquis en commande d'un vas, d'un fauteuil roulant, ou autre, il est nécessaire de définir un paradigme expérimental. En d'autre termes : la manière dont les signaux cérébraux vont être exploités au sein de l'interface. Il est possible de distinguer deux grandes catégories d'interfaces BCI dans ce cas : les interfaces synchrones et les interfaces asynchrones.

=== Classification ===

A l'issue de la phase de traitement précédemment décrite, nous disposons d'un ensemble d'attributs mesurés sur les signaux à intervalles réguliers (tous les dixièmes de seconde).
A partir de ces vecteurs d'attributs, il s'agit d'identifier le type de mouvement réalisé ou imaginé(dans le cas d'une interface asynchrone) ou de décider si le sujet a répondu positivement au stimulus ou non (dans le cas d'une interface synchrone).

Il s'agit donc de décider si le vecteur d'attributs considéré est caractéristique d'un mouvement ou d'une réponse positive au stimulus. Ceci est le propre de ce que l'on appelle la classification.

Il existe deux grandes familles de techniques de classification : la classification supervisée et la classification non supervisée. La classification non supervisée consiste à prendre une décision d'identification sans aucune connaissance à priori sur les vecteurs d'attributs (ou éléments) à classer.

La classification supervisée part de la connaissance à priori des éléments que l'on vise à identifier et se décline en deux phases successives :

'''Offline'''
Une phase d'apprentissage basée sur l'analyse d'éléments connus et parfaitement identifiés. Il s'agit alors d'ajuster les paramètres du classifieur en fonction des éléments à priori identifiés

'''Online'''
Une phase de classement des éléments inconnus en utilisant le classifieur paramétré dans la phase précédente.

Dans le domaine des interfaces BCI, les techniques de classification les plus utilisées sont de type supervisées. Les plus courantes :

-LDA

-Les réseaux de neurones

-La classification floue

Cette étape a pour but d'exploiter les éléments caractéristiques extraits précédemment. Les méthodes choisies dépendent du type d'interface, on distinguera deux types d'interfaces: synchrones ou asynchrones. Le logiciel remplissant cette fonction a été développé par l'INRIA, il s'agit d'OpenVibe.

=== Commande ===

Le résultat de la classification des attributs extraits des signaux cérébraux st généralement mise sous forme de décision binaire. Par exemple : "Y a t il imagination de mouvement de la main droite?" Résultat : "Oui ou Non". Nous pouvons alors relier ce résultat à la partie opérative de l'interface et piloter ainsi un actionneur. Le nombre d'actionneur devant bien sur être adapté à l'interface qui les exploitera.

=== Interfaces BCI Existantes ===

'''Interface Synchrone'''

[[Fichier:Doc BoxAlgorithm P300SpellerVisualisation Snapshot.png|400px|right]]
Des applications ont déjà été créées pour permettre à une personne complètement immobile de communiquer ou de se déplacer. En terme d'interface de communication, le P300 Speller qui est basé sur la détection de potentiels endogènes évoqués, signaux correspondant à une activité cognitive. Cette interface permet à un sujet entraîné d’écrire plusieurs caractères par minute. Le principe est simple: le sujet regarde une matrice de caractères dont les colonnes et les lignes sont mises en surbrillance de manière aléatoire, il doit alors se concentrer sur le caractère qu'il veut écrire et compter son nombre d'illuminations. A chaque fois que la lettre est comptée une modifications des signaux se produit 300ms plus tard. Il est ainsi possible de détecter la colonne et la ligne sur lesquelles se situe le caractère intéressant. Après plusieurs scintillement on peut donc connaître la lettre choisi par le patient.

[[Fichier:Online-shooter.png|445px|left]]Il existe également tout un ensemble d'interface développées à partir de l'analyse et l'interprétation des signaux SSVEP (Steady-State Visual Evoked Potential). Ceux-ci ne sont pas générés par une action cognitive mais inconsciemment par notre cerveau. Lorsque nous regardons un objet clignotant sur l’écran, on retrouve la fréquence de ce clignotement sur notre lobe occipital. Ainsi, en créant une interface graphique constituée de plusieurs objets clignotants à différentes fréquences (de l'ordre de quelques dizaines de hertz), et en analysant les signaux évoqués, on peut reconnaitre l'objet observé par le sujet. Cette technique basée sur l'analyse de signaux reflexes s'avère très efficace et ne nécessite aucune phase d'apprentissage. L'exemple ci dessous pourrait représenter l'écran de saisie des commandes de pilotage d'un fauteuil roulant. Les deux carrés pourraient représenter une demande de rotation gauche ou droite tandis que le triangle représenterait une demande de marche avant.

[[Fichier:MuseumImmersive1.jpg|right|400px]]

'''Interface Asynchrone'''

La dernière technique est la plus complexe mais aussi celle avec le plus grand potentiel. Elle consiste à analyser les signaux cérébraux en vue de détecter la réalisation ou l'imagination de mouvements de différentes parties du corps. Dans notre cas, ce sont les mouvements des deux mains et des pieds qui sont exploités car plus présents au niveau du cortex moteur et donc plus faciles à détecter. L'identification de ces mouvements fournit donc un total de 3 commandes complètement indépendantes de toute stimulation extérieure. On ne peut prévoir à l'avance quand le sujet décidera d'imaginer un mouvement d'une des parties de son corps. Ce paradigme a déjà été exploité par l'INRIA de Rennes pour diriger un avatar dans un espace 3D virtuel matérialisant une visite virtuelle d'un musée. Les signaux correspondant aux mouvements de la main droite sont utilisés pour tourner à droite, ceux de la main gauche pour tourner à gauche et les mouvements des pieds pour avancer.

Des applications interfaces BCI ont aussi été développées pour commander des prothèses ou des fauteuils roulants. En effet, des expériences ont été menées avec succès sur un patient équipé d'une interface non invasive. Il a réussi à contrôler une main robotique grâce à l'analyse de ses rythmes sensorimoteurs, exploités pour détecter l'imagination de mouvement de la main. Ces essais ont été fais sur des personnes valides mais on peut imaginer les possibilités qui s'offrent à des personnes paralysées ou amputées.

== Objectif : ==

=== Formulation des besoins ===

[[Fichier:main3d.jpg|right|200px]]
Notre projet consiste au développement de l'interface graphique 3D d'une BCI, de type asynchrone basée su l'analyse de mouvements, réels ou imaginés, fournissant à l'utilisateur un feedback visuel ds commandes qu'il effectue. L'interface doit être composée de 2 couches graphiques dissociables :

- Une couche que nous appelons "la couche Feedback" : c'est la couche est au premier-plan. Elle affichera un avatar virtuel qui va exécuter le mouvement réel ou imaginé par le sujet. Par exemple, dans le cas d'un mouvement imaginé de la main, nous devons représenter graphiquement une main exécutant le mouvement imaginé par le sujet. Il peut s'agir d'une rotation du poignet, d'un mouvement de préhension, de mouvements des doigts etc. La visualisation du mouvement que le sujet imagine (le feedback) permettra peut-être un apprentissage de l'interface dit plus aisé pour le sujet mais on doit essayer de s'assurer qu'il ne soit pas un élément perturbateur. Nos inquiétudes sont fondées sur le même principe que l'instabilité des systèmes bouclés en général. On ne peut pas être certain qu'en observant son avatar à l'écran, le cerveau du sujet ne génère pas les sinusaux électriques correspondant au mouvement qu'il observe.

[[Fichier:piano 3d.jpg|300px|left]]
- Une couche ludique : celle-ci se situe au second-plan. Elle présente un objectif à réaliser par l'utilisateur en cohérence avec l'action imaginée et représentée par l'avatar. On peut par exemple imaginer un clavier de piano dans le cas d'un mouvement des doigts, d'un ballon qui se gonfle dans le cas de mouvements de préhension répétés.L'objectif permet de créer une forte motivation de l'utilisateur qui facilitera inconsciemment sa concentration. Par exemple : Si le mouvement imaginé par le sujet est de fermer et d'ouvrir la main, on sélectionnera une interface montrant par exemple une main actionnant une pompe et un arrière plan, des ballons à gonfler. Ou encore, avec un mouvement de doigt tapoter sur une table, on choisira d'avantage un piano en arrière plan joué par cette/ces main(s), ou même, avec un mouvement de serrage de vis avec la main, un meuble à monter le plus rapidement possible.

Ces couches doivent être affichables une par une ou en même temps. Le but est de pouvoir analyser l'impact du feedback sur les performances du sujet lors l'utilisation de l'interface BCI. Ainsi que de fournir au sujet un feedback "réaliste" des mouvements qu'il réalise ou imagine plutôt qu'un curseur sur un graphique.
[[Fichier:Piano main 3d.jpg|430px|center]]

=== Spécifications ===

Au sein de l'équipe BCI du LAGIS, les outils de développement les plus utilisés sont :

-MatLab : Pour le traitement des signaux.

-OpenVibe : Logiciel dédié BCI développé par l'INRIA de Rennes, pour la partie acquisition, traitement et feedback visuel.

-C++ : Pour le développement des blocs OpenVibe additionnels

Les contraintes à respecter dans le cadre de notre projet sont les suivantes :

-Respect et/ou compatibilité avec les technologies utilisées : Compatibilité de l'interface graphique avec OpenVibe. Compatibilité entre l'application et le nombre de signaux de commandes en sortie d'OpenVibe (main gauche, main droite, pieds, repos).

-Grande configurabilité : Ne connaissant pas l'utilisateur qui va utiliser le système, il doit être le plus personnalisable possible. Le but est que chacun puisse s'identifier à notre application pour obtenir les meilleurs résultats possibles. Cela implique donc d'assurer une grande configurabilité des objectifs pour l'utilisateur mais aussi de la manière d'afficher la complétion de ces objectifs et ses performances. Enfin il est important d'assurer une grande configurabilité du mouvement du feedback pour le rendre plus cohérent possible avec celui du sujet.

-Facilité de configuration : l'utilisateur doit pouvoir changer les options facilement et rapidement.

-Modulation du programme : le code source doit être le plus générique possible, documenté, commenté et le plus facilement modifiable possible.

= Étude des différents moteurs graphiques 3D =

== Spécifications ==

Les contraintes de choix du moteur 3D sont les suivantes par ordre de priorités décroissantes :

-Compatibilité avec le VRPN de Openvibe

-Permettre le développement multiplateforme (Linux, Windows, MacOS)

-Simplicité de développement

-Ressources nécessaires pour le mettre en œuvre minimisées

-Rendu visuel de qualité

== Choix d'un moteur ==

=== Moteur Jeux Vidéos Grand Public ===

Les moteurs suivants sont utilisés par les développeurs de jeux vidéos actuels. Leurs rendus graphiques sont les meilleurs, donc nous n'avons analysé en premier lieu que leurs autres caractéristiques :

-Anvil (Assassin's Creed) : License propriétaire privée d'Ubisoft, impossible d'acheter le DK

-CryEngine (Crysis) : Gratuit pour une utilisation non commerciale

-Dunia Engine (Farcry) : Non distribué

-Frostbite (Battlefield) : Non distribué

-Havok (Halo) :

-Hero Engine (Star Wars : Old Republic)

-Quest3D (Audiosurf)

-Source (Portal) : Non distribué

-Unreal Engine (Borderlands)

La plupart de ces moteurs sont très performants, ce qui implique l'utilisation de machines suffisamment puissantes pour les mettre en œuvre. De plus, certains sont conçus exclusivement pour du développement de jeu pour console de salon. Même si leur complexité de programmation est tout aussi abordable que les autres, nous ne pouvons pas choisir ces derniers.

=== Etude Comparative des Moteurs Graphiques ===

-Outerra : Ce moteur permet surtout la génération d'immenses espaces 3D jusqu'à des planètes entières. Le rendu global est effectivement très joli mais les détails de petits éléments sont assez simplistes. Ce moteur n'est donc pas du tout adapté à notre projet.

[[Fichier:Engines.png]]

=== Choix final ===

[[Fichier:Blender_logo.jpg]]

Après cette étude nous avons retenus '''Blender''' car il permet un développement très performant et rapide de model 3D réalistes. Nous comptons utiliser son moteur de jeu BlenderGame qui permet des interactions avec les models pour faire fonctionner nos interfaces. La difficulté que cela soulève est l'absence de VRPN dans ce moteur. Outil qui permet la communication entre un système tier et une interface de réalité virtuel. La suite va donc consister à interfacer Blender et Openvibe

= Développement d'une interface logicielle OpenVibe <-> Blender =

Notre objectif est de permettre une communication entre le logiciel OpenVibe, et le moteur graphique de Blender. Plusieurs protocoles de communication sont alors exploitables.

[[Fichier:Blender-Openvibe.png]]

== Reflexion ==

=== TCP/IP ===

Nos recherches nous ont amené à entrer en relation avec Romain Grandchamp, un doctorant ayant déjà travaillé sur ce sujet : c'est lui qui a réalisé une interface BCI implémentant une liaison TCP/IP entre Blender et BCI2000, un logiciel similaire à OpenVibe pour l'utilisation en recherche en BCI. C'est lui qui nous a proposée cette éventualité. Voici l'un de ses projets en cours : https://sites.google.com/site/romaingrandchamp/cerveaurium

Blender permet ce type de communication grace à un script python, mais ce n'est pas le cas d'OpenVibe.

Notre objectif ici est donc de créer un bloc OpenVibe qui implémentera une fonction de communication via ce protocole.

Ce bloc prendra en entrée un vecteur de donnée issu du classifieur. Le programmeur de scénario OpenVibe pourra paramétrer le message envoyé et pour quel donné du vecteur.
L'idée est donc d'importer des bibliothèques de communication tcp/ip dans openvibe pour développer un bloc pouvant communiquer aussi bien avec Blender qu'avec un autre programme voire un autre système en réseau. Au niveau du choix de protocole TCP ou UDP, c'est le protocole TCP qui satisfera le mieux notre besoin car il garantit l'intégrité des paquets transmis. Sachant que les messages seront transmis à chaque changement d'état d'un des paramètre d'entrée de la boite, il faut absolument que l'ordre soit correctement transmis à Blender. Le protocole UDP permettrai une meilleure réactivité, car plus rapide, mais il ne garantis pas le bon fonctionnement à chaque transmission, on pourrait envisager ce protocole dans le cas d'échanges de messages cadencé à une certaine fréquence, où la quantité rattrape la qualité de la communication.

La difficulté rencontrée ici est l'implémentation d'un bloc nouveau dans OpenVibe. Nous nous somme inscrits sur le forum d'OpenVibe pour nous faire aider de la communauté associée.

=== VRPN ===

Un autre moyen de communication est l'utilisation d'un VRPN, un ensemble de librairies permettant la liaison entre un moteur graphique et une interface de réalité virtuelle.
La bibliothèque VRPN est implémentée nativement dans OpenVibe ce qui nous amène à envisager d'implémenter cette même bibliothèque coté Blender. Le problème étant que nous n'avons pas de garantis que ceci soit possible. Il est possible d'étendre Blender grâce à des scripts python donc nous pensons que c'est effectivement faisable mais ne comprenons pas pourquoi est ce que cette fonction n'a pas déjà été implémenté étant donné la manière dont Blender est répandu et son aspet opensource. Cela dit, la communication VRPN utilise en réalité la communication réseau TCP classique comme base (port par défaut 3883), il s'agit donc en fait d'un protocole spécifique ajouté sur la base dont nous avons pas forcément utilité.

Après des recherches approfondies nous avons découvert qu'il existe un patch permettant de transformer Blender en BlenderCave. http://blendercave.limsi.fr/doku.php
Celui ci intègre de nouvelles fonctions notamment la possibilité de faire de la 3D stéréoscopique mais qui intègrerai également un VRPN.
L'inconvénient principal de cette configuration est que ce patch ne peut être utilisé que sur une révision précise de Blender.

L'objectif serait de vérifier sa compatibilité entre OpenVibe et ce dernier. Si c'est le cas, essayer de porter la fonctionnalité VRPN vers une version quelconque de Blender.

== Développement ==

Nous choisissons donc de développer un système de communication TCP car les briques de bases sont disponibles de chaque coté. En effet la bibliothèque VRPN utilise en fait une communication TCP, donc OpenVibe devrait pouvoir communiquer par TCP.

=== Objectif ===

Réaliser un nouveau bloc OpenVibe permettant de transmettre des données via TCP ou UDP. Nous sommes inscrits sur le Forum OpenVibe : http://openvibe.inria.fr/forum/
Et partons suivre les tutos OpenVibe sur la créations de nouveaux blocs : http://openvibe.inria.fr/introduction-algo-boxes/

=== Réalisation ===

'''Bloc OpenVibe'''

[[Fichier:BCI TCP Writer Champeirock.png|left]][[Fichier:Wireshark Icon BCI Champeiro.png|right|50px]]
Après avoir commencé à développer notre Bloc nous avons été informé par la communauté qu'un bloc TCP Writer avait déjà été développé mais était en version Non Stable. Nous sommes donc repartis de cette base-ci. Doc TCP Writer : http://openvibe.inria.fr/documentation/unstable/Doc_BoxAlgorithm_TCPWriter.html
Nous avons donc analysé la structure de la transmission avec un outils type WireShark
La boite fait office de Server TCP qui transmet son vecteur d'information d'entrée sur une Socket TCP. On peut choisir 3 types de données de sorties : Raw, Hexa ou String.
Mais en pratique, on ne peut utiliser les formats Hex ou String que pour transmettre des données de stimulation, ce qui n'est pas notre cas ici vu que nous voulons transmettre un vecteur d'information. Nous allons donc nous intéresser au format du message transmis au format Raw.
- La boîte envoie d'abord à chaque client qui se connecte huit variables uint32 :
numéro de version
endianness : 0 == inconnue , 1 == little , 2 == big, 3 == PDP
la fréquence d'échantillonnage du signal
le nombre de canaux (nb de lignes de la matrice d'info transmise)
le nombre d'échantillons par bloc (colonnes de la matrice)
Trois variables de rembourrage

8 * 4 = 32 octets au total. Les 6 dernières variables sont dans l'ordre des octets du flux.

Plusieurs clients peuvent se connecter à la socket. La boîte continue à envoyer des données à chaque client jusqu'à ce que le scénario OpenVibe se termine ou que le client se déconnecte.

Analyse détaillée d'une trame pour la transmission d'une Matrice (1,1) :
La trame est composé d'un total de 74 Octets :
14 Octets Ethernets (Addresses, Type)
20 Octets d'en-tête IPv4
32 Octets TCP (ceux détaillé au dessus)
8 Octets de Données

'''Script Blender'''

Grâce à la communauté Blender il est aisée de trouver un bout de code python implémentant des fonctionnalités réseaux.
Sources : http://blenderartists.org/forum/showthread.php?280465-setblocking%280%29-PROBLEM!&highlight=setblocking

= Développement du retour graphique sous blender =

== Objectif ==

Le développement sous Blender consiste à créer un feedback visuel pour l’utilisateur. Il faut donc modéliser une main qui bouge selon la volonté de mouvement de l’utilisateur. Dans un premier temps, il faut créer une main, et lui associer une animation pour qu’elle pianote, superposée à un piano dont les touches bougent en même temps que les doigts ; l’objectif est que lorsque l’utilisateur veut pianoter, il voit la main pianoter à sa place et appuyer sur les touches du piano. Le logiciel de création de Blender permet d’associer un signal d’entrée, par exemple l’appui sur une touche du clavier (d’ordinateur), à l’animation de la main et du piano. L’intérêt serait alors que le signal d’entrée soit provoqué par le logiciel OpenVibe lors de l’imagination de mouvement de l’utilisateur.

== Réalisation ==

Une main déjà modélisée et articulée, ainsi qu’un décor d’opéra contenant un piano, ont été trouvés sur des sites communautaires de Blender.
Pour le piano, il a été nécessaire de recréer le clavier (l’ensemble des touches) car dans le modèle utilisé, elles étaient toutes solidaires. Le clavier à touches indépendantes a donc été placé à la place du clavier original. Maintenant, il est donc possible de faire bouger chaque touche indépendamment, et donc de créer l’animation des touches qui s’enfoncent.
[[Fichier:piano.png]]

Pour la main, une animation était déjà pré-programmée, qui montrait la main d’abord fermée, puis qui s’ouvrait le plus possible, sans que le rendu paraisse irréaliste. La construction de l’animation est basée sur une série de marqueurs qui indiquent la position que doivent avoir chaque membres à certaines images de l’animation. En réutilisant ces marqueurs, il est donc possible de créer le mouvement de pianotement voulu.
[[Fichier:roll1.png]] [[Fichier:roll2.png]]

Une étape intéressante serait de pouvoir agir sur la vitesse de l’animation de la main, en fonction de l’intensité de l’imagination du mouvement par l’utilisateur.

= Gestion de Projet et Sources =

== Planning ==

[[Fichier:Gant PFE BCI.png|650px]]

'''Présentation Mi-PFE'''

10/12/2013

'''Présentation BCI

21/02/2014

'''Présentation Polytech'Lille'''

27/02/2014

== Bibliographie ==

=== OpenVibe ===

http://openvibe.inria.fr/

http://openvibe.inria.fr/tag/vrpn/

http://openvibe.inria.fr/documentation-index/#User+Documentation

=== Moteur 3D ===

https://fr.wikipedia.org/wiki/Moteur_3D

http://www.desura.com/search?q=engine+3d&sa.x=0&sa.y=0

http://www.ogre3d.fr/

http://www.outerra.com/forum/index.php?topic=637.0

http://jeux.developpez.com/tutoriels/?page=prog-3d#ogre-3d

http://mycryengine.com/index.php?conid=70

http://www.havok.com/try-havok

http://www.desura.com/engines/unreal-development-kit/downloads/udk

http://www.truevision3d.com/downloads.php

http://hub.jmonkeyengine.org/

http://www.neoaxis.com/neoaxis/licensing

http://www.shivaengine.com/download.html

http://unity3d.com/unity/download

https://store.unity3d.com/

http://www.twinmotion.com/acheter.html

http://www.worldofleveldesign.com/categories/level_design_tutorials/recommended-game-engines.php

=== Blender ===

http://www.blender.org/education-help/tutorials/game-engine/

http://blendercave.limsi.fr/doku.php

http://www.blendswap.com/

=== EEG ===

http://openeeg.sourceforge.net/doc/sw/

http://www.emotiv.com/store/app.php

=== Autres Projets BCI ===

http://air.imag.fr/index.php/Armind

https://sites.google.com/site/romaingrandchamp/cerveaurium

= Annexe =

== Journal ==

'''Entrée 1'''

Installation de OpenVibe (en deux fois pour le rendre fonctionnel)

'''Entrée 2'''

Réalisation de l'ensemble des tutoriels disponibles sur le site de l'INRIA mais malheureusement, cela ne nous a pas amené jusqu'à l'utilisation du VRPN. Nous Projetons maintenant d'étudier les moteurs graphiques 3D existant pour en choisir un pour notre développement.

'''Entrée 3'''

Installation de Ogre. Nécessite un IDE ainsi qu'un compilateur (Comblock + MinGW pour Windows)

Configuration : Installation de MinGW à la racine de C:/ Installation de Ogre Installation de Comblock
Problème pour compiller

BCI : Interface Cerveau Ordinateur

2014-02-06T21:55:52Z

Tchampag : /* Développement du retour graphique sous blender */

= Présentation =

== Contexte : ==

Le but général est de faciliter la vie des personnes paralysées avec un système interprétant directement leurs signaux cérébraux pour communiquer ou agir avec leur environnement. Les patients susceptibles d'utiliser cette technologie sont ceux atteint de paralysie musculaire complète (LIS : Locked In Syndrom) ou de SLA (Sclérose Latérale Amyotrophique). Ces maladies affectant très peu les fonctions cérébrales, cette technologie semble pouvoir devenir LA solution pour pallier au handicap. Ce projet est réalisé en collaboration avec l'équipe BCI du LAGIS.

Voilà ce que fait l'interface cerveau ordinateur (BCI : Brain Computer Interface ou BMI : Brain Machine Interface) de façon détaillée : les signaux électroencéphalographiques (EEG) sont acquis, numérisés et traités pour pouvoir ensuite être transformés en commandes. Une partie de ces informations est aussi affichée de manière simple pour l'utilisateur pour lui permettre un apprentissage plus rapide grâce à ce retour visuel.

Comment ?

[[Fichier:Schema-bci.png|600px|center]]

=== Acquisition ===

L'information cérébrale peut-être acquise de différentes manières :

- La première est non invasive, c'est à dire qu'elle ne nécessite pas d'intervention chirurgical visant à implanter un quelconque dispositif dans le corps du patient. A l'aide d'un casque muni d'électrodes placés sur le crane, on peut acquérir les signaux cérébraux passant à travers la boite crânienne (appelés signaux EEG). L'ordre de grandeur de ces signaux électriques ne dépasse pas le microvolt et les signaux acquis sont très fortement bruités. Mais ce dispositif est simple à mettre en œuvre et peut être utilisé aussi bien par les patients que par les chercheurs lors d'une phase expérimentale qu'est la nôtre.

- La seconde est semi-invasive, l’électrode servant à l'acquisition des signaux est implanté sous la surface de la boîte crânienne (ECoG : électrocorticogramme). Cette méthode permet d'augmenter considérablement la qualité des signaux qui sont beaucoup moins bruités que les signaux EEG. De plus, elle présente peu de risque puisque l’électrode est situé à l’extérieur de la dure-mère.

- La dernière est dite invasive, dans le sens où on vient placer des électrodes directement dans la masse cérébrale. Cette méthode a deja fait ses preuves : en 2005 un patient tétraplégique était capable de contrôler une prothèse robotique grâce à ce dispositif. Néanmoins, les électrodes ont une durée de vie limitée et les lésions cérébrales, dues à l’implantation des électrodes, sont irréversibles.

Une autre méthode consiste à détecter des signaux résultant de stimuli extérieurs connus (ERP : Event Related Potentials). Dans le cadre de notre projet, nous allons développer une interface graphique qui va être intégrer dans une interface BCI de type asynchrone basée sur l'analyse des signaux EEG acquis dans le cas de mouvements imaginés des pieds et des mains gauche ou droite. Les EEG considérés sont issus des activités ipsilatérales et contralatérales du cortex pré-moteur.

=== Traitement des signaux EEG ===

L'objectif du traitement des signaux EEG est de discriminer le mouvement imaginé par le patient (main droite, main gauche, pied). Pour cela, il est nécessaire d'extraire des signaux EEG un certains nombre d'attributs qui vont permettre de prendre une décision sur la commande à effectuer au sein de l'interface BCI en cours de developpement au LAGIS. Il est effectué par un logiciel d'analyse numérique comme MatLab, OpenVibe.

Les attributs extraits sont les amplitudes des signaux cérébraux dans certaines bandes de fréquence. Exemple, l'amplitude du rythme µ (entre 8Hz et 15Hz) disparait environ une seconde avant et pendant un mouvement des pieds ou des mains, mais aussi avant et pendant l'imagination de ce mouvement. Dans le même contexte on peut observer de grandes modifications d'amplitude du signal EEG dans la bande ß (entre 15Hz et 35Hz) occurrentes avant, pendant et juste après un mouvement. Ces signaux sont toujours très brefs mais la manière dont ils sont acquis (niveau d'invasivité) change complètement la manière dont ils seront traités. Les signaux mesurés à la surface du cerveau sont les plus problématiques car ils résultent de l'activité de millions de neurones.

Le pré-traitement a pour fonction l’élimination des artefacts (signaux induits par une autre activité corporelle que celle observée comme le clignement des yeux, la déglutition...) ainsi que l'amélioration du rapport signal sur bruit, bruit venant de tous les signaux à proximité, autant dire de tous les neurones à proximité donc quelques millions par point de mesure. Pour ce faire, différentes techniques sont mises en œuvre :

-Filtrage spatial : Combinaison linéaire des signaux des électrodes voisines. Par exemple le filtrage Laplacien, consistant à soustraire à un signal, la moyenne de ces voisins : très répandu car aussi simple qu’efficace pour éliminer le bruit.

-Filtrage fréquentiel : Sachant que nous cherchons à mesure l'amplitude des signaux dans les bandes de fréquence 8-35Hz il convient d'effectuer un filtrage fréquentiel éliminant toutes les fréquences hors de cette plage.

-Interface Synchrone : Une interface est dite Synchrone lorsque ce n'est pas l'activité spontanée du cerveau qui est analysée mais la réponse attendu à des stimulus générés par l'interface. Des signaux réflexifs sont générés de manière mécanique et inconsciente ce qui rend la phase d'apprentissage beaucoup plus simple.

-Interface Asynchrone : Une interface asynchrone à contrario analyse les signaux à tous moments. Et même si l'on peut sélectionner les zones du cerveaux à observer en choisissant l'emplacement des électrodes il n’empêche que les signaux observés sont le résultat de la somme de toutes les activités cérébrales avoisinante. Dans le cas de la réalisation ou de l'imagination de mouvements des mains (droite ou gauche) par exemple, il s'agit de reconnaitre dans les signaux cérébraux, le moment où un événement se produit et le type d'événement généré (droite ou gauche). Dans le cas de l'interface développée par le LAGIS les signaux EEG sont analysés en s'appuyant sur l'expertise des neurophysiologistes qui ont mis en évidence des modifications des signaux EEG dans certaines bandes de fréquence dans la zone moteur du cortex avant, pendant et après l'imagination ou la réalisation du mouvement.

=== Méthode d'exploitation des signaux cérébraux acquis (ou paradigme) ===
Afin de transformer les signaux acquis en commande d'un vas, d'un fauteuil roulant, ou autre, il est nécessaire de définir un paradigme expérimental. En d'autre termes : la manière dont les signaux cérébraux vont être exploités au sein de l'interface. Il est possible de distinguer deux grandes catégories d'interfaces BCI dans ce cas : les interfaces synchrones et les interfaces asynchrones.

=== Classification ===

A l'issue de la phase de traitement précédemment décrite, nous disposons d'un ensemble d'attributs mesurés sur les signaux à intervalles réguliers (tous les dixièmes de seconde).
A partir de ces vecteurs d'attributs, il s'agit d'identifier le type de mouvement réalisé ou imaginé(dans le cas d'une interface asynchrone) ou de décider si le sujet a répondu positivement au stimulus ou non (dans le cas d'une interface synchrone).

Il s'agit donc de décider si le vecteur d'attributs considéré est caractéristique d'un mouvement ou d'une réponse positive au stimulus. Ceci est le propre de ce que l'on appelle la classification.

Il existe deux grandes familles de techniques de classification : la classification supervisée et la classification non supervisée. La classification non supervisée consiste à prendre une décision d'identification sans aucune connaissance à priori sur les vecteurs d'attributs (ou éléments) à classer.

La classification supervisée part de la connaissance à priori des éléments que l'on vise à identifier et se décline en deux phases successives :

'''Offline'''
Une phase d'apprentissage basée sur l'analyse d'éléments connus et parfaitement identifiés. Il s'agit alors d'ajuster les paramètres du classifieur en fonction des éléments à priori identifiés

'''Online'''
Une phase de classement des éléments inconnus en utilisant le classifieur paramétré dans la phase précédente.

Dans le domaine des interfaces BCI, les techniques de classification les plus utilisées sont de type supervisées. Les plus courantes :

-LDA

-Les réseaux de neurones

-La classification floue

Cette étape a pour but d'exploiter les éléments caractéristiques extraits précédemment. Les méthodes choisies dépendent du type d'interface, on distinguera deux types d'interfaces: synchrones ou asynchrones. Le logiciel remplissant cette fonction a été développé par l'INRIA, il s'agit d'OpenVibe.

=== Commande ===

Le résultat de la classification des attributs extraits des signaux cérébraux st généralement mise sous forme de décision binaire. Par exemple : "Y a t il imagination de mouvement de la main droite?" Résultat : "Oui ou Non". Nous pouvons alors relier ce résultat à la partie opérative de l'interface et piloter ainsi un actionneur. Le nombre d'actionneur devant bien sur être adapté à l'interface qui les exploitera.

=== Interfaces BCI Existantes ===

'''Interface Synchrone'''

[[Fichier:Doc BoxAlgorithm P300SpellerVisualisation Snapshot.png|400px|right]]
Des applications ont déjà été créées pour permettre à une personne complètement immobile de communiquer ou de se déplacer. En terme d'interface de communication, le P300 Speller qui est basé sur la détection de potentiels endogènes évoqués, signaux correspondant à une activité cognitive. Cette interface permet à un sujet entraîné d’écrire plusieurs caractères par minute. Le principe est simple: le sujet regarde une matrice de caractères dont les colonnes et les lignes sont mises en surbrillance de manière aléatoire, il doit alors se concentrer sur le caractère qu'il veut écrire et compter son nombre d'illuminations. A chaque fois que la lettre est comptée une modifications des signaux se produit 300ms plus tard. Il est ainsi possible de détecter la colonne et la ligne sur lesquelles se situe le caractère intéressant. Après plusieurs scintillement on peut donc connaître la lettre choisi par le patient.

[[Fichier:Online-shooter.png|445px|left]]Il existe également tout un ensemble d'interface développées à partir de l'analyse et l'interprétation des signaux SSVEP (Steady-State Visual Evoked Potential). Ceux-ci ne sont pas générés par une action cognitive mais inconsciemment par notre cerveau. Lorsque nous regardons un objet clignotant sur l’écran, on retrouve la fréquence de ce clignotement sur notre lobe occipital. Ainsi, en créant une interface graphique constituée de plusieurs objets clignotants à différentes fréquences (de l'ordre de quelques dizaines de hertz), et en analysant les signaux évoqués, on peut reconnaitre l'objet observé par le sujet. Cette technique basée sur l'analyse de signaux reflexes s'avère très efficace et ne nécessite aucune phase d'apprentissage. L'exemple ci dessous pourrait représenter l'écran de saisie des commandes de pilotage d'un fauteuil roulant. Les deux carrés pourraient représenter une demande de rotation gauche ou droite tandis que le triangle représenterait une demande de marche avant.

[[Fichier:MuseumImmersive1.jpg|right|400px]]

'''Interface Asynchrone'''

La dernière technique est la plus complexe mais aussi celle avec le plus grand potentiel. Elle consiste à analyser les signaux cérébraux en vue de détecter la réalisation ou l'imagination de mouvements de différentes parties du corps. Dans notre cas, ce sont les mouvements des deux mains et des pieds qui sont exploités car plus présents au niveau du cortex moteur et donc plus faciles à détecter. L'identification de ces mouvements fournit donc un total de 3 commandes complètement indépendantes de toute stimulation extérieure. On ne peut prévoir à l'avance quand le sujet décidera d'imaginer un mouvement d'une des parties de son corps. Ce paradigme a déjà été exploité par l'INRIA de Rennes pour diriger un avatar dans un espace 3D virtuel matérialisant une visite virtuelle d'un musée. Les signaux correspondant aux mouvements de la main droite sont utilisés pour tourner à droite, ceux de la main gauche pour tourner à gauche et les mouvements des pieds pour avancer.

Des applications interfaces BCI ont aussi été développées pour commander des prothèses ou des fauteuils roulants. En effet, des expériences ont été menées avec succès sur un patient équipé d'une interface non invasive. Il a réussi à contrôler une main robotique grâce à l'analyse de ses rythmes sensorimoteurs, exploités pour détecter l'imagination de mouvement de la main. Ces essais ont été fais sur des personnes valides mais on peut imaginer les possibilités qui s'offrent à des personnes paralysées ou amputées.

== Objectif : ==

=== Formulation des besoins ===

[[Fichier:main3d.jpg|right|200px]]
Notre projet consiste au développement de l'interface graphique 3D d'une BCI, de type asynchrone basée su l'analyse de mouvements, réels ou imaginés, fournissant à l'utilisateur un feedback visuel ds commandes qu'il effectue. L'interface doit être composée de 2 couches graphiques dissociables :

- Une couche que nous appelons "la couche Feedback" : c'est la couche est au premier-plan. Elle affichera un avatar virtuel qui va exécuter le mouvement réel ou imaginé par le sujet. Par exemple, dans le cas d'un mouvement imaginé de la main, nous devons représenter graphiquement une main exécutant le mouvement imaginé par le sujet. Il peut s'agir d'une rotation du poignet, d'un mouvement de préhension, de mouvements des doigts etc. La visualisation du mouvement que le sujet imagine (le feedback) permettra peut-être un apprentissage de l'interface dit plus aisé pour le sujet mais on doit essayer de s'assurer qu'il ne soit pas un élément perturbateur. Nos inquiétudes sont fondées sur le même principe que l'instabilité des systèmes bouclés en général. On ne peut pas être certain qu'en observant son avatar à l'écran, le cerveau du sujet ne génère pas les sinusaux électriques correspondant au mouvement qu'il observe.

[[Fichier:piano 3d.jpg|300px|left]]
- Une couche ludique : celle-ci se situe au second-plan. Elle présente un objectif à réaliser par l'utilisateur en cohérence avec l'action imaginée et représentée par l'avatar. On peut par exemple imaginer un clavier de piano dans le cas d'un mouvement des doigts, d'un ballon qui se gonfle dans le cas de mouvements de préhension répétés.L'objectif permet de créer une forte motivation de l'utilisateur qui facilitera inconsciemment sa concentration. Par exemple : Si le mouvement imaginé par le sujet est de fermer et d'ouvrir la main, on sélectionnera une interface montrant par exemple une main actionnant une pompe et un arrière plan, des ballons à gonfler. Ou encore, avec un mouvement de doigt tapoter sur une table, on choisira d'avantage un piano en arrière plan joué par cette/ces main(s), ou même, avec un mouvement de serrage de vis avec la main, un meuble à monter le plus rapidement possible.

Ces couches doivent être affichables une par une ou en même temps. Le but est de pouvoir analyser l'impact du feedback sur les performances du sujet lors l'utilisation de l'interface BCI. Ainsi que de fournir au sujet un feedback "réaliste" des mouvements qu'il réalise ou imagine plutôt qu'un curseur sur un graphique.
[[Fichier:Piano main 3d.jpg|430px|center]]

=== Spécifications ===

Au sein de l'équipe BCI du LAGIS, les outils de développement les plus utilisés sont :

-MatLab : Pour le traitement des signaux.

-OpenVibe : Logiciel dédié BCI développé par l'INRIA de Rennes, pour la partie acquisition, traitement et feedback visuel.

-C++ : Pour le développement des blocs OpenVibe additionnels

Les contraintes à respecter dans le cadre de notre projet sont les suivantes :

-Respect et/ou compatibilité avec les technologies utilisées : Compatibilité de l'interface graphique avec OpenVibe. Compatibilité entre l'application et le nombre de signaux de commandes en sortie d'OpenVibe (main gauche, main droite, pieds, repos).

-Grande configurabilité : Ne connaissant pas l'utilisateur qui va utiliser le système, il doit être le plus personnalisable possible. Le but est que chacun puisse s'identifier à notre application pour obtenir les meilleurs résultats possibles. Cela implique donc d'assurer une grande configurabilité des objectifs pour l'utilisateur mais aussi de la manière d'afficher la complétion de ces objectifs et ses performances. Enfin il est important d'assurer une grande configurabilité du mouvement du feedback pour le rendre plus cohérent possible avec celui du sujet.

-Facilité de configuration : l'utilisateur doit pouvoir changer les options facilement et rapidement.

-Modulation du programme : le code source doit être le plus générique possible, documenté, commenté et le plus facilement modifiable possible.

= Étude des différents moteurs graphiques 3D =

== Spécifications ==

Les contraintes de choix du moteur 3D sont les suivantes par ordre de priorités décroissantes :

-Compatibilité avec le VRPN de Openvibe

-Permettre le développement multiplateforme (Linux, Windows, MacOS)

-Simplicité de développement

-Ressources nécessaires pour le mettre en œuvre minimisées

-Rendu visuel de qualité

== Choix d'un moteur ==

=== Moteur Jeux Vidéos Grand Public ===

Les moteurs suivants sont utilisés par les développeurs de jeux vidéos actuels. Leurs rendus graphiques sont les meilleurs, donc nous n'avons analysé en premier lieu que leurs autres caractéristiques :

-Anvil (Assassin's Creed) : License propriétaire privée d'Ubisoft, impossible d'acheter le DK

-CryEngine (Crysis) : Gratuit pour une utilisation non commerciale

-Dunia Engine (Farcry) : Non distribué

-Frostbite (Battlefield) : Non distribué

-Havok (Halo) :

-Hero Engine (Star Wars : Old Republic)

-Quest3D (Audiosurf)

-Source (Portal) : Non distribué

-Unreal Engine (Borderlands)

La plupart de ces moteurs sont très performants, ce qui implique l'utilisation de machines suffisamment puissantes pour les mettre en œuvre. De plus, certains sont conçus exclusivement pour du développement de jeu pour console de salon. Même si leur complexité de programmation est tout aussi abordable que les autres, nous ne pouvons pas choisir ces derniers.

=== Etude Comparative des Moteurs Graphiques ===

-Outerra : Ce moteur permet surtout la génération d'immenses espaces 3D jusqu'à des planètes entières. Le rendu global est effectivement très joli mais les détails de petits éléments sont assez simplistes. Ce moteur n'est donc pas du tout adapté à notre projet.

[[Fichier:Engines.png]]

=== Choix final ===

[[Fichier:Blender_logo.jpg]]

Après cette étude nous avons retenus '''Blender''' car il permet un développement très performant et rapide de model 3D réalistes. Nous comptons utiliser son moteur de jeu BlenderGame qui permet des interactions avec les models pour faire fonctionner nos interfaces. La difficulté que cela soulève est l'absence de VRPN dans ce moteur. Outil qui permet la communication entre un système tier et une interface de réalité virtuel. La suite va donc consister à interfacer Blender et Openvibe

= Développement d'une interface logicielle OpenVibe <-> Blender =

Notre objectif est de permettre une communication entre le logiciel OpenVibe, et le moteur graphique de Blender. Plusieurs protocoles de communication sont alors exploitables.

[[Fichier:Blender-Openvibe.png]]

== Reflexion ==

=== TCP/IP ===

Nos recherches nous ont amené à entrer en relation avec Romain Grandchamp, un doctorant ayant déjà travaillé sur ce sujet : c'est lui qui a réalisé une interface BCI implémentant une liaison TCP/IP entre Blender et BCI2000, un logiciel similaire à OpenVibe pour l'utilisation en recherche en BCI. C'est lui qui nous a proposée cette éventualité. Voici l'un de ses projets en cours : https://sites.google.com/site/romaingrandchamp/cerveaurium

Blender permet ce type de communication grace à un script python, mais ce n'est pas le cas d'OpenVibe.

Notre objectif ici est donc de créer un bloc OpenVibe qui implémentera une fonction de communication via ce protocole.

Ce bloc prendra en entrée un vecteur de donnée issu du classifieur. Le programmeur de scénario OpenVibe pourra paramétrer le message envoyé et pour quel donné du vecteur.
L'idée est donc d'importer des bibliothèques de communication tcp/ip dans openvibe pour développer un bloc pouvant communiquer aussi bien avec Blender qu'avec un autre programme voire un autre système en réseau. Au niveau du choix de protocole TCP ou UDP, c'est le protocole TCP qui satisfera le mieux notre besoin car il garantit l'intégrité des paquets transmis. Sachant que les messages seront transmis à chaque changement d'état d'un des paramètre d'entrée de la boite, il faut absolument que l'ordre soit correctement transmis à Blender. Le protocole UDP permettrai une meilleure réactivité, car plus rapide, mais il ne garantis pas le bon fonctionnement à chaque transmission, on pourrait envisager ce protocole dans le cas d'échanges de messages cadencé à une certaine fréquence, où la quantité rattrape la qualité de la communication.

La difficulté rencontrée ici est l'implémentation d'un bloc nouveau dans OpenVibe. Nous nous somme inscrits sur le forum d'OpenVibe pour nous faire aider de la communauté associée.

=== VRPN ===

Un autre moyen de communication est l'utilisation d'un VRPN, un ensemble de librairies permettant la liaison entre un moteur graphique et une interface de réalité virtuelle.
La bibliothèque VRPN est implémentée nativement dans OpenVibe ce qui nous amène à envisager d'implémenter cette même bibliothèque coté Blender. Le problème étant que nous n'avons pas de garantis que ceci soit possible. Il est possible d'étendre Blender grâce à des scripts python donc nous pensons que c'est effectivement faisable mais ne comprenons pas pourquoi est ce que cette fonction n'a pas déjà été implémenté étant donné la manière dont Blender est répandu et son aspet opensource. Cela dit, la communication VRPN utilise en réalité la communication réseau TCP classique comme base (port par défaut 3883), il s'agit donc en fait d'un protocole spécifique ajouté sur la base dont nous avons pas forcément utilité.

Après des recherches approfondies nous avons découvert qu'il existe un patch permettant de transformer Blender en BlenderCave. http://blendercave.limsi.fr/doku.php
Celui ci intègre de nouvelles fonctions notamment la possibilité de faire de la 3D stéréoscopique mais qui intègrerai également un VRPN.
L'inconvénient principal de cette configuration est que ce patch ne peut être utilisé que sur une révision précise de Blender.

L'objectif serait de vérifier sa compatibilité entre OpenVibe et ce dernier. Si c'est le cas, essayer de porter la fonctionnalité VRPN vers une version quelconque de Blender.

== Développement ==

Nous choisissons donc de développer un système de communication TCP car les briques de bases sont disponibles de chaque coté. En effet la bibliothèque VRPN utilise en fait une communication TCP, donc OpenVibe devrait pouvoir communiquer par TCP.

=== Objectif ===

Réaliser un nouveau bloc OpenVibe permettant de transmettre des données via TCP ou UDP. Nous sommes inscrits sur le Forum OpenVibe : http://openvibe.inria.fr/forum/
Et partons suivre les tutos OpenVibe sur la créations de nouveaux blocs : http://openvibe.inria.fr/introduction-algo-boxes/

=== Réalisation ===

'''Bloc OpenVibe'''

[[Fichier:BCI TCP Writer Champeirock.png|left]][[Fichier:Wireshark Icon BCI Champeiro.png|right|50px]]
Après avoir commencé à développer notre Bloc nous avons été informé par la communauté qu'un bloc TCP Writer avait déjà été développé mais était en version Non Stable. Nous sommes donc repartis de cette base-ci. Doc TCP Writer : http://openvibe.inria.fr/documentation/unstable/Doc_BoxAlgorithm_TCPWriter.html
Nous avons donc analysé la structure de la transmission avec un outils type WireShark
La boite fait office de Server TCP qui transmet son vecteur d'information d'entrée sur une Socket TCP. On peut choisir 3 types de données de sorties : Raw, Hexa ou String.
Mais en pratique, on ne peut utiliser les formats Hex ou String que pour transmettre des données de stimulation, ce qui n'est pas notre cas ici vu que nous voulons transmettre un vecteur d'information. Nous allons donc nous intéresser au format du message transmis au format Raw.
- La boîte envoie d'abord à chaque client qui se connecte huit variables uint32 :
numéro de version
endianness : 0 == inconnue , 1 == little , 2 == big, 3 == PDP
la fréquence d'échantillonnage du signal
le nombre de canaux (nb de lignes de la matrice d'info transmise)
le nombre d'échantillons par bloc (colonnes de la matrice)
Trois variables de rembourrage

8 * 4 = 32 octets au total. Les 6 dernières variables sont dans l'ordre des octets du flux.

Plusieurs clients peuvent se connecter à la socket. La boîte continue à envoyer des données à chaque client jusqu'à ce que le scénario OpenVibe se termine ou que le client se déconnecte.

Analyse détaillée d'une trame pour la transmission d'une Matrice (1,1) :
La trame est composé d'un total de 74 Octets :
14 Octets Ethernets (Addresses, Type)
20 Octets d'en-tête IPv4
32 Octets TCP (ceux détaillé au dessus)
8 Octets de Données

'''Script Blender'''

Grâce à la communauté Blender il est aisée de trouver un bout de code python implémentant des fonctionnalités réseaux.
Sources : http://blenderartists.org/forum/showthread.php?280465-setblocking%280%29-PROBLEM!&highlight=setblocking

= Développement du retour graphique sous blender =

== Objectif ==

Le développement sous Blender consiste à créer un feedback visuel pour l’utilisateur. Il faut donc modéliser une main qui bouge selon la volonté de mouvement de l’utilisateur. Dans un premier temps, il faut créer une main, et lui associer une animation pour qu’elle pianote, superposée à un piano dont les touches bougent en même temps que les doigts ; l’objectif est que lorsque l’utilisateur veut pianoter, il voit la main pianoter à sa place et appuyer sur les touches du piano. Le logiciel de création de Blender permet d’associer un signal d’entrée, par exemple l’appui sur une touche du clavier (d’ordinateur), à l’animation de la main et du piano. L’intérêt serait alors que le signal d’entrée soit provoqué par le logiciel OpenVibe lors de l’imagination de mouvement de l’utilisateur.

== Réalisation ==

Une main déjà modélisée et articulée, ainsi qu’un décor d’opéra contenant un piano, ont été trouvés sur des sites communautaires de Blender.
Pour le piano, il a été nécessaire de recréer le clavier (l’ensemble des touches) car dans le modèle utilisé, elles étaient toutes solidaires. Le clavier à touches indépendantes a donc été placé à la place du clavier original. Maintenant, il est donc possible de faire bouger chaque touche indépendamment, et donc de créer l’animation des touches qui s’enfoncent.

Pour la main, une animation était déjà pré-programmée, qui montrait la main d’abord fermée, puis qui s’ouvrait le plus possible, sans que le rendu paraisse irréaliste. La construction de l’animation est basée sur une série de marqueurs qui indiquent la position que doivent avoir chaque membres à certaines images de l’animation. En réutilisant ces marqueurs, il est donc possible de créer le mouvement de pianotement voulu.

Une étape intéressante serait de pouvoir agir sur la vitesse de l’animation de la main, en fonction de l’intensité de l’imagination du mouvement par l’utilisateur.

= Gestion de Projet et Sources =

== Planning ==

[[Fichier:Gant PFE BCI.png|650px]]

'''Présentation Mi-PFE'''

10/12/2013

'''Présentation BCI

21/02/2014

'''Présentation Polytech'Lille'''

27/02/2014

== Bibliographie ==

=== OpenVibe ===

http://openvibe.inria.fr/

http://openvibe.inria.fr/tag/vrpn/

http://openvibe.inria.fr/documentation-index/#User+Documentation

=== Moteur 3D ===

https://fr.wikipedia.org/wiki/Moteur_3D

http://www.desura.com/search?q=engine+3d&sa.x=0&sa.y=0

http://www.ogre3d.fr/

http://www.outerra.com/forum/index.php?topic=637.0

http://jeux.developpez.com/tutoriels/?page=prog-3d#ogre-3d

http://mycryengine.com/index.php?conid=70

http://www.havok.com/try-havok

http://www.desura.com/engines/unreal-development-kit/downloads/udk

http://www.truevision3d.com/downloads.php

http://hub.jmonkeyengine.org/

http://www.neoaxis.com/neoaxis/licensing

http://www.shivaengine.com/download.html

http://unity3d.com/unity/download

https://store.unity3d.com/

http://www.twinmotion.com/acheter.html

http://www.worldofleveldesign.com/categories/level_design_tutorials/recommended-game-engines.php

=== Blender ===

http://www.blender.org/education-help/tutorials/game-engine/

http://blendercave.limsi.fr/doku.php

http://www.blendswap.com/

=== EEG ===

http://openeeg.sourceforge.net/doc/sw/

http://www.emotiv.com/store/app.php

=== Autres Projets BCI ===

http://air.imag.fr/index.php/Armind

https://sites.google.com/site/romaingrandchamp/cerveaurium

= Annexe =

== Journal ==

'''Entrée 1'''

Installation de OpenVibe (en deux fois pour le rendre fonctionnel)

'''Entrée 2'''

Réalisation de l'ensemble des tutoriels disponibles sur le site de l'INRIA mais malheureusement, cela ne nous a pas amené jusqu'à l'utilisation du VRPN. Nous Projetons maintenant d'étudier les moteurs graphiques 3D existant pour en choisir un pour notre développement.

'''Entrée 3'''

Installation de Ogre. Nécessite un IDE ainsi qu'un compilateur (Comblock + MinGW pour Windows)

Configuration : Installation de MinGW à la racine de C:/ Installation de Ogre Installation de Comblock
Problème pour compiller

BCI : Interface Cerveau Ordinateur

2014-02-06T21:54:48Z

Tchampag : /* Développement d'une interface logicielle OpenVibe Blender */

BCI : Interface Cerveau Ordinateur

2014-01-17T11:06:24Z

Tchampag : /* Développement d'une interface logicielle OpenVibe Blender */

BCI : Interface Cerveau Ordinateur

2013-10-14T09:59:55Z

Tchampag : /* Moteur 3D */

= Présentation =

== Objectif : ==

Développer une interface cerveau-ordinateur ergonomique et conviviale.

== Description : ==

Ce projet est réalisé en collaboration avec l'équipe du LAGIS. Le but premier est de faciliter la vie des personnes paralysées avec un système interprétant directement leurs signaux cérébraux pour communiquer ou agir avec leur environnement.
Des applications ont déjà été créées pour permettre à une personne complétement immobile de communiquer.

== Spécifications ==

Les contraintes à respecter sont les suivantes :

-Respect et/ou compatibilité avec les technologies utilisées : Compatibilité de l'interface graphique avec OpenVibe. Compatibilité entre l'application et les signaux EEG utilisés, dans notre cas, principalement les électrodes C3 C4 et CZ correspondant respectivement aux mouvements de la main droite de la main gauche et des pieds mais aussi les signaux du lobe occipitale correspondant à la vision pour l'utilisation de SSVEP (Steady-State Visual Evoked Potential)

-Grande configurabilité : Ne connaissant pas l'utilisateur qui viendra utiliser le système, il doit être le plus personnalisable possible. Le but est que chacun puisse s'identifier à notre application pour obtenir les meilleurs résultats possibles. Configurabilité des objectifs pour l'utilisateur ainsi que la manière d'afficher la complétion de ces objectifs et ses performances. ET configurabilité du mouvement du feedback pour le rendre plus cohérent avec celui de l'utilisateur.

-Facilité de configuration : l'utilisateur doit pouvoir changer les options facilement et rapidement.

-Modulation du programme : le code source doit être le plus générique possible, documenté, commenté et le plus facilement modifiable possible.

= Journal =

== Entrée 1 ==

Installation de OpenVibe (en deux fois pour le rendre fonctionnel)
Suivi du tutoriel 1 proposé sur le site de l'INRIA : http://openvibe.inria.fr/designer-tutorial-1/

== Entrée 2 ==

Nous avons finalement réalisé l'ensemble des tutoriels disponibles sur le site de l'INRIA mais malheureusement, cela ne nous a pas amené jusqu'à l'utilisation du VRPN. Nous Projetons maintenant d'étudier les moteurs graphiques 3D existant pour en choisir un pour notre développement.

== Entrée 3 ==

Redéfinition du sujet et précision des spécifications techniques du projet et du moteur graphique.

= Étude des différents moteur graphique 3D =

== Spécifications ==

Les contraintes de choix du moteur 3D sont les suivantes par ordre de priorités décroissantes :

-Compatibilité avec le VRPN de Openvibe

-Permettre le développement multiplateforme (Linux, Windows, MacOS)

-Simplicité de développement

-Ressources nécessaires pour le mettre en œuvre minimisées

-Rendu visuel de qualité

== Choix d'un moteur ==

Nous sommes partis de la liste de moteurs graphiques disponible sur Wikipédia plus quelques autres trouvés grâce à Google

=== Moteurs à Analyser ===
Twinmotion ! NOVA 2010 ! Id Tech 5 ! NX Engine ! Crystal Space ! Irrlicht ! OGRE ! Unity3D ! Revolution3D ! Truevision3D ! Unigine ! redway3D ! NSRE GX ! JMonkeyEngine ! REA Fox Two

=== Moteur Jeux Vidéos ===

Les moteurs suivants sont utilisés par les développeurs de jeux vidéos actuels. Leurs rendus graphiques sont les meilleurs, donc nous n'avons analysé en premier lieu que leurs autres caractéristiques :

-Anvil (Assassin's Creed)

-CryEngine (Crysis)

-Dunia Engine (Farcry)

-Frostbite (Battlefield)

-Havok (Halo)

-Hero Engine (Star Wars : Old Republic)

-Quest3D (Audiosurf)

-Source (Portal)

-Unreal Engine (Borderlands)

La plupart de ces moteurs sont très performants, ce qui implique l'utilisation de machines suffisamment puissantes pour les mettre en œuvre. De plus, certains sont conçus exclusivement pour du développement de jeu pour console de salon. Même si leur complexité de programmation est tout aussi abordable que les autres, nous ne pouvons pas choisir ces derniers.

=== Autres Moteurs ===

-Outerra : Ce moteur permet surtout la génération d'immenses espaces 3D jusqu'à des planètes entières. Le rendu global est effectivement très joli mais les détails de petits éléments sont assez simplistes. Ce moteur n'est donc pas du tout adapté à notre projet.

= Gestion de Projet et Sources =

== Planning ==

=== Présentation ===

27/02/2014

== Bibliographie ==

=== OpenVibe ===

http://openvibe.inria.fr/

http://openvibe.inria.fr/tag/vrpn/

http://openvibe.inria.fr/documentation-index/#User+Documentation

=== Moteur 3D ===

https://fr.wikipedia.org/wiki/Moteur_3D

http://www.outerra.com/forum/index.php?topic=637.0

http://www.ogre3d.fr/

http://jeux.developpez.com/tutoriels/?page=prog-3d#ogre-3d

http://www.worldofleveldesign.com/categories/level_design_tutorials/recommended-game-engines.php

=== EEG ===

http://openeeg.sourceforge.net/doc/sw/

http://www.emotiv.com/store/app.php

BCI : Interface Cerveau Ordinateur

2013-10-13T21:26:50Z

Tchampag : /* Journal */

= Présentation =

== Objectif : ==

Développer une interface cerveau-ordinateur ergonomique et conviviale.

== Description : ==

Ce projet est réalisé en collaboration avec l'équipe du LAGIS. Le but premier est de faciliter la vie des personnes paralysées avec un système interprétant directement leurs signaux cérébraux pour communiquer ou agir avec leur environnement.
Des applications ont déjà été créées pour permettre à une personne complétement immobile de communiquer.

== Spécifications ==

Les contraintes à respecter sont les suivantes :

-Respect et/ou compatibilité avec les technologies utilisées : Compatibilité de l'interface graphique avec OpenVibe. Compatibilité entre l'application et les signaux EEG utilisés (mains gauche et droite et pieds ou SSVEP)

-Grande configurabilité : Ne connaissant pas l'utilisateur qui viendra utiliser le système, il doit être le plus personnalisable possible. Le but est que chacun puisse s'identifier à notre application pour obtenir les meilleurs résultats possibles. Configurabilité de l'interface de "fond" ou du "jeu" ET configurabilité du mouvement du feedback.

-Facilité de configuration : l'utilisateur doit pouvoir changer les options facilement et rapidement.

-Modulation du programme : le code source doit être le plus générique possible, documenté, commenté et le plus facilement modifiable possible.

= Journal =

== Entrée 1 ==

Installation de OpenVibe (en deux fois pour le rendre fonctionnel)
Suivi du tutoriel 1 proposé sur le site de l'INRIA : http://openvibe.inria.fr/designer-tutorial-1/

== Entrée 2 ==

Nous avons finalement réalisé l'ensemble des tutoriels disponibles sur le site de l'INRIA mais malheureusement, cela ne nous a pas amené jusqu'à l'utilisation du VRPN. Nous Projetons maintenant d'étudier les moteurs graphiques 3D existant pour en choisir un pour notre développement.

== Entrée 3 ==

Redéfinition du sujet et précision des spécifications techniques du projet et du moteur graphique.

= Étude des différents moteur graphique 3D =

== Spécifications ==

Les contraintes de choix du moteur 3D sont les suivantes par ordre de priorités décroissantes :

-Compatibilité avec le VRPN de Openvibe

-Permettre le développement multiplateforme (Linux, Windows, MacOS)

-Simplicité de développement

-Ressources nécessaires pour le mettre en œuvre minimisées

-Rendu visuel de qualité

== Choix d'un moteur ==

Nous sommes partis de la liste de moteurs graphiques disponible sur Wikipédia plus quelques autres trouvés grâce à Google

=== Moteurs à Analyser ===
Twinmotion ! NOVA 2010 ! Id Tech 5 ! NX Engine ! Crystal Space ! Irrlicht ! OGRE ! Unity3D ! Revolution3D ! Truevision3D ! Unigine ! redway3D ! NSRE GX ! JMonkeyEngine ! REA Fox Two

=== Moteur Jeux Vidéos ===

Les moteurs suivants sont utilisés par les développeurs de jeux vidéos actuels. Leurs rendus graphiques sont les meilleurs, donc nous n'avons analysé en premier lieu que leurs autres caractéristiques :

-Anvil (Assassin's Creed)

-CryEngine (Crysis)

-Dunia Engine (Farcry)

-Frostbite (Battlefield)

-Havok (Halo)

-Hero Engine (Star Wars : Old Republic)

-Quest3D (Audiosurf)

-Source (Portal)

-Unreal Engine (Borderlands)

La plupart de ces moteurs sont très performants, ce qui implique l'utilisation de machines suffisamment puissantes pour les mettre en œuvre. De plus, certains sont conçus exclusivement pour du développement de jeu pour console de salon. Même si leur complexité de programmation est tout aussi abordable que les autres, nous ne pouvons pas choisir ces derniers.

=== Autres Moteurs ===

-Outerra : Ce moteur permet surtout la génération d'immenses espaces 3D jusqu'à des planètes entières. Le rendu global est effectivement très joli mais les détails de petits éléments sont assez simplistes. Ce moteur n'est donc pas du tout adapté à notre projet.

= Gestion de Projet et Sources =

== Planning ==

=== Présentation ===

27/02/2014

== Bibliographie ==

=== OpenVibe ===

http://openvibe.inria.fr/

http://openvibe.inria.fr/tag/vrpn/

http://openvibe.inria.fr/documentation-index/#User+Documentation

=== Moteur 3D ===

https://fr.wikipedia.org/wiki/Moteur_3D

http://www.outerra.com/forum/index.php?topic=637.0

http://www.ogre3d.fr/

http://jeux.developpez.com/tutoriels/?page=prog-3d#ogre-3d

=== EEG ===

http://openeeg.sourceforge.net/doc/sw/

http://www.emotiv.com/store/app.php

BCI : Interface Cerveau Ordinateur

2013-10-13T21:25:15Z

Tchampag : /* Spécifications */

= Présentation =

== Objectif : ==

Développer une interface cerveau-ordinateur ergonomique et conviviale.

== Description : ==

Ce projet est réalisé en collaboration avec l'équipe du LAGIS. Le but premier est de faciliter la vie des personnes paralysées avec un système interprétant directement leurs signaux cérébraux pour communiquer ou agir avec leur environnement.
Des applications ont déjà été créées pour permettre à une personne complétement immobile de communiquer.

== Spécifications ==

Les contraintes à respecter sont les suivantes :

-Respect et/ou compatibilité avec les technologies utilisées : Compatibilité de l'interface graphique avec OpenVibe. Compatibilité entre l'application et les signaux EEG utilisés (mains gauche et droite et pieds ou SSVEP)

-Grande configurabilité : Ne connaissant pas l'utilisateur qui viendra utiliser le système, il doit être le plus personnalisable possible. Le but est que chacun puisse s'identifier à notre application pour obtenir les meilleurs résultats possibles. Configurabilité de l'interface de "fond" ou du "jeu" ET configurabilité du mouvement du feedback.

-Facilité de configuration : l'utilisateur doit pouvoir changer les options facilement et rapidement.

-Modulation du programme : le code source doit être le plus générique possible, documenté, commenté et le plus facilement modifiable possible.

= Journal =

== Entrée 1 ==

Installation de OpenVibe (en deux fois pour le rendre fonctionnel)
Suivi du tutoriel 1 proposé sur le site de l'INRIA : http://openvibe.inria.fr/designer-tutorial-1/

== Entrée 2 ==

Nous avons finalement réalisé l'ensemble des tutoriels disponible sur le site de l'INRIA mais malheureusement, cela ne nous a pas amener jusqu'à l'utilisation du VRPN. Nous Projetons maintenant d'étudier les moteurs graphiques 3D existant pour en choisir un pour notre développement.

== Entrée 3 ==

Redéfinition du sujet et précision des spécifications techniques du projet et du moteur graphique

= Étude des différents moteur graphique 3D =

== Spécifications ==

Les contraintes de choix du moteur 3D sont les suivantes par ordre de priorités décroissantes :

-Compatibilité avec le VRPN de Openvibe

-Permettre le développement multiplateforme (Linux, Windows, MacOS)

-Simplicité de développement

-Ressources nécessaires pour le mettre en œuvre minimisées

-Rendu visuel de qualité

== Choix d'un moteur ==

Nous sommes partis de la liste de moteurs graphiques disponible sur Wikipédia plus quelques autres trouvés grâce à Google

=== Moteurs à Analyser ===
Twinmotion ! NOVA 2010 ! Id Tech 5 ! NX Engine ! Crystal Space ! Irrlicht ! OGRE ! Unity3D ! Revolution3D ! Truevision3D ! Unigine ! redway3D ! NSRE GX ! JMonkeyEngine ! REA Fox Two

=== Moteur Jeux Vidéos ===

Les moteurs suivants sont utilisés par les développeurs de jeux vidéos actuels. Leurs rendus graphiques sont les meilleurs, donc nous n'avons analysé en premier lieu que leurs autres caractéristiques :

-Anvil (Assassin's Creed)

-CryEngine (Crysis)

-Dunia Engine (Farcry)

-Frostbite (Battlefield)

-Havok (Halo)

-Hero Engine (Star Wars : Old Republic)

-Quest3D (Audiosurf)

-Source (Portal)

-Unreal Engine (Borderlands)

La plupart de ces moteurs sont très performants, ce qui implique l'utilisation de machines suffisamment puissantes pour les mettre en œuvre. De plus, certains sont conçus exclusivement pour du développement de jeu pour console de salon. Même si leur complexité de programmation est tout aussi abordable que les autres, nous ne pouvons pas choisir ces derniers.

=== Autres Moteurs ===

-Outerra : Ce moteur permet surtout la génération d'immenses espaces 3D jusqu'à des planètes entières. Le rendu global est effectivement très joli mais les détails de petits éléments sont assez simplistes. Ce moteur n'est donc pas du tout adapté à notre projet.

= Gestion de Projet et Sources =

== Planning ==

=== Présentation ===

27/02/2014

== Bibliographie ==

=== OpenVibe ===

http://openvibe.inria.fr/

http://openvibe.inria.fr/tag/vrpn/

http://openvibe.inria.fr/documentation-index/#User+Documentation

=== Moteur 3D ===

https://fr.wikipedia.org/wiki/Moteur_3D

http://www.outerra.com/forum/index.php?topic=637.0

http://www.ogre3d.fr/

http://jeux.developpez.com/tutoriels/?page=prog-3d#ogre-3d

=== EEG ===

http://openeeg.sourceforge.net/doc/sw/

http://www.emotiv.com/store/app.php

BCI : Interface Cerveau Ordinateur

2013-10-13T21:24:42Z

Tchampag : /* Choix d'un moteur */

= Présentation =

== Objectif : ==

Développer une interface cerveau-ordinateur ergonomique et conviviale.

== Description : ==

Ce projet est réalisé en collaboration avec l'équipe du LAGIS. Le but premier est de faciliter la vie des personnes paralysées avec un système interprétant directement leurs signaux cérébraux pour communiquer ou agir avec leur environnement.
Des applications ont déjà été créées pour permettre à une personne complétement immobile de communiquer.

== Spécifications ==

Les contraintes à respecter sont les suivantes :

-Respect et/ou compatibilité avec les technologies utilisées : Compatibilité de l'interface graphique avec OpenVibe. Compatibilité entre l'application et les signaux EEG utilisés (mains gauche et droite et pieds ou SSVEP)

-Grande configurabilité : Ne connaissant pas l'utilisateur qui viendra utiliser le système, il doit être le plus personnalisable possible. Le but est que chacun puisse s'identifier à notre application pour obtenir les meilleurs résultats possibles. Configurabilité de l'interface de "fond" ou du "jeu" ET configurabilité du mouvement du feedback.

-Facilité de configuration : l'utilisateur doit pouvoir changer les options facilement et rapidement.

-Modulation du programme : le code source doit être le plus générique possible, documenté, commenté et le plus facilement modifiable possible.

= Journal =

== Entrée 1 ==

Installation de OpenVibe (en deux fois pour le rendre fonctionnel)
Suivi du tutoriel 1 proposé sur le site de l'INRIA : http://openvibe.inria.fr/designer-tutorial-1/

== Entrée 2 ==

Nous avons finalement réalisé l'ensemble des tutoriels disponible sur le site de l'INRIA mais malheureusement, cela ne nous a pas amener jusqu'à l'utilisation du VRPN. Nous Projetons maintenant d'étudier les moteurs graphiques 3D existant pour en choisir un pour notre développement.

== Entrée 3 ==

Redéfinition du sujet et précision des spécifications techniques du projet et du moteur graphique

= Étude des différents moteur graphique 3D =

== Spécifications ==

Les contraintes de choix du moteur 3D sont les suivantes par ordre de priorités décroissantes :

-Compatibilité avec le VRPN de Openvibe

-Permettre le développement multiplateforme (Linux, Windows, MacOS)

-Simplicité de développement

-Ressources nécessaire pour le mettre en œuvre minimisées

-Rendu visuel de qualité

== Choix d'un moteur ==

Nous sommes partis de la liste de moteurs graphiques disponible sur Wikipédia plus quelques autres trouvés grâce à Google

=== Moteurs à Analyser ===
Twinmotion ! NOVA 2010 ! Id Tech 5 ! NX Engine ! Crystal Space ! Irrlicht ! OGRE ! Unity3D ! Revolution3D ! Truevision3D ! Unigine ! redway3D ! NSRE GX ! JMonkeyEngine ! REA Fox Two

=== Moteur Jeux Vidéos ===

Les moteurs suivants sont utilisés par les développeurs de jeux vidéos actuels. Leurs rendus graphiques sont les meilleurs, donc nous n'avons analysé en premier lieu que leurs autres caractéristiques :

-Anvil (Assassin's Creed)

-CryEngine (Crysis)

-Dunia Engine (Farcry)

-Frostbite (Battlefield)

-Havok (Halo)

-Hero Engine (Star Wars : Old Republic)

-Quest3D (Audiosurf)

-Source (Portal)

-Unreal Engine (Borderlands)

La plupart de ces moteurs sont très performants, ce qui implique l'utilisation de machines suffisamment puissantes pour les mettre en œuvre. De plus, certains sont conçus exclusivement pour du développement de jeu pour console de salon. Même si leur complexité de programmation est tout aussi abordable que les autres, nous ne pouvons pas choisir ces derniers.

=== Autres Moteurs ===

-Outerra : Ce moteur permet surtout la génération d'immenses espaces 3D jusqu'à des planètes entières. Le rendu global est effectivement très joli mais les détails de petits éléments sont assez simplistes. Ce moteur n'est donc pas du tout adapté à notre projet.

= Gestion de Projet et Sources =

== Planning ==

=== Présentation ===

27/02/2014

== Bibliographie ==

=== OpenVibe ===

http://openvibe.inria.fr/

http://openvibe.inria.fr/tag/vrpn/

http://openvibe.inria.fr/documentation-index/#User+Documentation

=== Moteur 3D ===

https://fr.wikipedia.org/wiki/Moteur_3D

http://www.outerra.com/forum/index.php?topic=637.0

http://www.ogre3d.fr/

http://jeux.developpez.com/tutoriels/?page=prog-3d#ogre-3d

=== EEG ===

http://openeeg.sourceforge.net/doc/sw/

http://www.emotiv.com/store/app.php

BCI : Interface Cerveau Ordinateur

2013-10-13T21:23:40Z

Tchampag : /* Moteur Jeux Vidéos */

= Présentation =

== Objectif : ==

Développer une interface cerveau-ordinateur ergonomique et conviviale.

== Description : ==

Ce projet est réalisé en collaboration avec l'équipe du LAGIS. Le but premier est de faciliter la vie des personnes paralysées avec un système interprétant directement leurs signaux cérébraux pour communiquer ou agir avec leur environnement.
Des applications ont déjà été créées pour permettre à une personne complétement immobile de communiquer.

== Spécifications ==

Les contraintes à respecter sont les suivantes :

-Respect et/ou compatibilité avec les technologies utilisées : Compatibilité de l'interface graphique avec OpenVibe. Compatibilité entre l'application et les signaux EEG utilisés (mains gauche et droite et pieds ou SSVEP)

-Grande configurabilité : Ne connaissant pas l'utilisateur qui viendra utiliser le système, il doit être le plus personnalisable possible. Le but est que chacun puisse s'identifier à notre application pour obtenir les meilleurs résultats possibles. Configurabilité de l'interface de "fond" ou du "jeu" ET configurabilité du mouvement du feedback.

-Facilité de configuration : l'utilisateur doit pouvoir changer les options facilement et rapidement.

-Modulation du programme : le code source doit être le plus générique possible, documenté, commenté et le plus facilement modifiable possible.

= Journal =

== Entrée 1 ==

Installation de OpenVibe (en deux fois pour le rendre fonctionnel)
Suivi du tutoriel 1 proposé sur le site de l'INRIA : http://openvibe.inria.fr/designer-tutorial-1/

== Entrée 2 ==

Nous avons finalement réalisé l'ensemble des tutoriels disponible sur le site de l'INRIA mais malheureusement, cela ne nous a pas amener jusqu'à l'utilisation du VRPN. Nous Projetons maintenant d'étudier les moteurs graphiques 3D existant pour en choisir un pour notre développement.

== Entrée 3 ==

Redéfinition du sujet et précision des spécifications techniques du projet et du moteur graphique

= Étude des différents moteur graphique 3D =

== Spécifications ==

Les contraintes de choix du moteur 3D sont les suivantes par ordre de priorités décroissantes :

-Compatibilité avec le VRPN de Openvibe

-Permettre le développement multiplateforme (Linux, Windows, MacOS)

-Simplicité de développement

-Ressources nécessaire pour le mettre en œuvre minimisées

-Rendu visuel de qualité

== Choix d'un moteur ==

Nous sommes partis de la liste de moteur graphiques disponible sur Wikipédia plus quelques autres trouvés grâce à Google

=== Moteurs à Analyser ===
Twinmotion ! NOVA 2010 ! Id Tech 5 ! NX Engine ! Crystal Space ! Irrlicht ! OGRE ! Unity3D ! Revolution3D ! Truevision3D ! Unigine ! redway3D ! NSRE GX ! JMonkeyEngine ! REA Fox Two

=== Moteur Jeux Vidéos ===

Les moteurs suivants sont utilisés par les développeurs de jeux vidéos actuels. Leurs rendus graphiques sont les meilleurs, donc nous n'avons analysé en premier lieu que leurs autres caractéristiques :

-Anvil (Assassin's Creed)

-CryEngine (Crysis)

-Dunia Engine (Farcry)

-Frostbite (Battlefield)

-Havok (Halo)

-Hero Engine (Star Wars : Old Republic)

-Quest3D (Audiosurf)

-Source (Portal)

-Unreal Engine (Borderlands)

La plupart de ces moteurs sont très performants, ce qui implique l'utilisation de machines suffisamment puissantes pour les mettre en œuvre. De plus, certains sont conçus exclusivement pour du développement de jeu pour console de salon. Même si leur complexité de programmation est tout aussi abordable que les autres, nous ne pouvons pas choisir ces derniers.

=== Autres Moteurs ===

-Outerra : Ce moteur permet surtout la génération d'immenses espaces 3D jusqu'à des planètes entières. Le rendu global est effectivement très joli mais les détails de petits éléments sont assez simplistes. Ce moteur n'est donc pas du tout adapté à notre projet.

= Gestion de Projet et Sources =

== Planning ==

=== Présentation ===

27/02/2014

== Bibliographie ==

=== OpenVibe ===

http://openvibe.inria.fr/

http://openvibe.inria.fr/tag/vrpn/

http://openvibe.inria.fr/documentation-index/#User+Documentation

=== Moteur 3D ===

https://fr.wikipedia.org/wiki/Moteur_3D

http://www.outerra.com/forum/index.php?topic=637.0

http://www.ogre3d.fr/

http://jeux.developpez.com/tutoriels/?page=prog-3d#ogre-3d

=== EEG ===

http://openeeg.sourceforge.net/doc/sw/

http://www.emotiv.com/store/app.php

BCI : Interface Cerveau Ordinateur

2013-10-13T21:21:53Z

Tchampag : /* Autres Moteurs */

= Présentation =

== Objectif : ==

Développer une interface cerveau-ordinateur ergonomique et conviviale.

== Description : ==

Ce projet est réalisé en collaboration avec l'équipe du LAGIS. Le but premier est de faciliter la vie des personnes paralysées avec un système interprétant directement leurs signaux cérébraux pour communiquer ou agir avec leur environnement.
Des applications ont déjà été créées pour permettre à une personne complétement immobile de communiquer.

== Spécifications ==

Les contraintes à respecter sont les suivantes :

-Respect et/ou compatibilité avec les technologies utilisées : Compatibilité de l'interface graphique avec OpenVibe. Compatibilité entre l'application et les signaux EEG utilisés (mains gauche et droite et pieds ou SSVEP)

-Grande configurabilité : Ne connaissant pas l'utilisateur qui viendra utiliser le système, il doit être le plus personnalisable possible. Le but est que chacun puisse s'identifier à notre application pour obtenir les meilleurs résultats possibles. Configurabilité de l'interface de "fond" ou du "jeu" ET configurabilité du mouvement du feedback.

-Facilité de configuration : l'utilisateur doit pouvoir changer les options facilement et rapidement.

-Modulation du programme : le code source doit être le plus générique possible, documenté, commenté et le plus facilement modifiable possible.

= Journal =

== Entrée 1 ==

Installation de OpenVibe (en deux fois pour le rendre fonctionnel)
Suivi du tutoriel 1 proposé sur le site de l'INRIA : http://openvibe.inria.fr/designer-tutorial-1/

== Entrée 2 ==

Nous avons finalement réalisé l'ensemble des tutoriels disponible sur le site de l'INRIA mais malheureusement, cela ne nous a pas amener jusqu'à l'utilisation du VRPN. Nous Projetons maintenant d'étudier les moteurs graphiques 3D existant pour en choisir un pour notre développement.

== Entrée 3 ==

Redéfinition du sujet et précision des spécifications techniques du projet et du moteur graphique

= Étude des différents moteur graphique 3D =

== Spécifications ==

Les contraintes de choix du moteur 3D sont les suivantes par ordre de priorités décroissantes :

-Compatibilité avec le VRPN de Openvibe

-Permettre le développement multiplateforme (Linux, Windows, MacOS)

-Simplicité de développement

-Ressources nécessaire pour le mettre en œuvre minimisées

-Rendu visuel de qualité

== Choix d'un moteur ==

Nous sommes partis de la liste de moteur graphiques disponible sur Wikipédia plus quelques autres trouvés grâce à Google

=== Moteurs à Analyser ===
Twinmotion ! NOVA 2010 ! Id Tech 5 ! NX Engine ! Crystal Space ! Irrlicht ! OGRE ! Unity3D ! Revolution3D ! Truevision3D ! Unigine ! redway3D ! NSRE GX ! JMonkeyEngine ! REA Fox Two

=== Moteur Jeux Vidéos ===

Les moteurs suivant sont utilisés par les développeurs de jeux vidéos actuel leurs rendus graphiques sont les meilleures, donc nous n'avons analysé en premier lieu que leurs autres caractéristiques :

-Anvil (Assassin's Creed)

-CryEngine (Crysis)

-Dunia Engine (Farcry)

-Frostbite (Battlefield)

-Havok (Halo)

-Hero Engine (Star Wars : Old Republic)

-Quest3D (Audiosurf)

-Source (Portal)

-Unreal Engine (Borderlands)

La plupart de ces moteurs sont très performants, ce qui implique l'utilisation de machines suffisamment puissante pour les mettre en œuvre. De plus, certain sont conçu exclusivement pour du développement de jeu pour console de salon. Même si leur complexité de programmation est tout aussi abordable que les autres, nous ne pouvons pas choisir ces derniers.

=== Autres Moteurs ===

-Outerra : Ce moteur permet surtout la génération d'immenses espaces 3D jusqu'à des planètes entières. Le rendu global est effectivement très joli mais les détails de petits éléments sont assez simplistes. Ce moteur n'est donc pas du tout adapté à notre projet.

= Gestion de Projet et Sources =

== Planning ==

=== Présentation ===

27/02/2014

== Bibliographie ==

=== OpenVibe ===

http://openvibe.inria.fr/

http://openvibe.inria.fr/tag/vrpn/

http://openvibe.inria.fr/documentation-index/#User+Documentation

=== Moteur 3D ===

https://fr.wikipedia.org/wiki/Moteur_3D

http://www.outerra.com/forum/index.php?topic=637.0

http://www.ogre3d.fr/

http://jeux.developpez.com/tutoriels/?page=prog-3d#ogre-3d

=== EEG ===

http://openeeg.sourceforge.net/doc/sw/

http://www.emotiv.com/store/app.php

BCI : Interface Cerveau Ordinateur

2013-10-13T21:20:50Z

Tchampag : /* Présentation */

= Présentation =

== Objectif : ==

Développer une interface cerveau-ordinateur ergonomique et conviviale.

== Description : ==

Ce projet est réalisé en collaboration avec l'équipe du LAGIS. Le but premier est de faciliter la vie des personnes paralysées avec un système interprétant directement leurs signaux cérébraux pour communiquer ou agir avec leur environnement.
Des applications ont déjà été créées pour permettre à une personne complétement immobile de communiquer.

== Spécifications ==

Les contraintes à respecter sont les suivantes :

-Respect et/ou compatibilité avec les technologies utilisées : Compatibilité de l'interface graphique avec OpenVibe. Compatibilité entre l'application et les signaux EEG utilisés (mains gauche et droite et pieds ou SSVEP)

-Grande configurabilité : Ne connaissant pas l'utilisateur qui viendra utiliser le système, il doit être le plus personnalisable possible. Le but est que chacun puisse s'identifier à notre application pour obtenir les meilleurs résultats possibles. Configurabilité de l'interface de "fond" ou du "jeu" ET configurabilité du mouvement du feedback.

-Facilité de configuration : l'utilisateur doit pouvoir changer les options facilement et rapidement.

-Modulation du programme : le code source doit être le plus générique possible, documenté, commenté et le plus facilement modifiable possible.

= Journal =

== Entrée 1 ==

Installation de OpenVibe (en deux fois pour le rendre fonctionnel)
Suivi du tutoriel 1 proposé sur le site de l'INRIA : http://openvibe.inria.fr/designer-tutorial-1/

== Entrée 2 ==

Nous avons finalement réalisé l'ensemble des tutoriels disponible sur le site de l'INRIA mais malheureusement, cela ne nous a pas amener jusqu'à l'utilisation du VRPN. Nous Projetons maintenant d'étudier les moteurs graphiques 3D existant pour en choisir un pour notre développement.

== Entrée 3 ==

Redéfinition du sujet et précision des spécifications techniques du projet et du moteur graphique

= Étude des différents moteur graphique 3D =

== Spécifications ==

Les contraintes de choix du moteur 3D sont les suivantes par ordre de priorités décroissantes :

-Compatibilité avec le VRPN de Openvibe

-Permettre le développement multiplateforme (Linux, Windows, MacOS)

-Simplicité de développement

-Ressources nécessaire pour le mettre en œuvre minimisées

-Rendu visuel de qualité

== Choix d'un moteur ==

Nous sommes partis de la liste de moteur graphiques disponible sur Wikipédia plus quelques autres trouvés grâce à Google

=== Moteurs à Analyser ===
Twinmotion ! NOVA 2010 ! Id Tech 5 ! NX Engine ! Crystal Space ! Irrlicht ! OGRE ! Unity3D ! Revolution3D ! Truevision3D ! Unigine ! redway3D ! NSRE GX ! JMonkeyEngine ! REA Fox Two

=== Moteur Jeux Vidéos ===

Les moteurs suivant sont utilisés par les développeurs de jeux vidéos actuel leurs rendus graphiques sont les meilleures, donc nous n'avons analysé en premier lieu que leurs autres caractéristiques :

-Anvil (Assassin's Creed)

-CryEngine (Crysis)

-Dunia Engine (Farcry)

-Frostbite (Battlefield)

-Havok (Halo)

-Hero Engine (Star Wars : Old Republic)

-Quest3D (Audiosurf)

-Source (Portal)

-Unreal Engine (Borderlands)

La plupart de ces moteurs sont très performants, ce qui implique l'utilisation de machines suffisamment puissante pour les mettre en œuvre. De plus, certain sont conçu exclusivement pour du développement de jeu pour console de salon. Même si leur complexité de programmation est tout aussi abordable que les autres, nous ne pouvons pas choisir ces derniers.

=== Autres Moteurs ===

-Outerra : Ce moteur permet surtout la génération d'immense espace 3D jusqu'à des planètes entières le rendu global est effectivement très joli mais les détails de petits éléments sont assez simpliste. Ce moteur n'est donc pas du tout adapter à notre projet.

= Gestion de Projet et Sources =

== Planning ==

=== Présentation ===

27/02/2014

== Bibliographie ==

=== OpenVibe ===

http://openvibe.inria.fr/

http://openvibe.inria.fr/tag/vrpn/

http://openvibe.inria.fr/documentation-index/#User+Documentation

=== Moteur 3D ===

https://fr.wikipedia.org/wiki/Moteur_3D

http://www.outerra.com/forum/index.php?topic=637.0

http://www.ogre3d.fr/

http://jeux.developpez.com/tutoriels/?page=prog-3d#ogre-3d

=== EEG ===

http://openeeg.sourceforge.net/doc/sw/

http://www.emotiv.com/store/app.php

Mindstorm

2013-03-07T09:15:22Z

Tchampag : /* 06/03/2013 */

== Objectif: ==

Concevoir une brique materielle qui fera l'interface entre la brique Mindstorm et les capteurs et actionneurs divers

Développer une brique logicielle utilisable dans l'interface de programmation Labview livrée avec le MindStorm.

Schéma du montage :

[[Fichier:Schema_Montage.jpg]]

== Avancement : ==

Apres de multiples test, il n'y a qu'un capteur qui s'avère communiquer en utilisant le protocole I2C.
Les Ports du NXT ne sont donc pas parallellisés.
Nous avons donc prévu de repartir de la brique RFID pour creer une nouvelle brique communiquant avec un Microcontroleur.
Le microcontroleur se fera passer pour esclave du NXT en scrutant le bus et en décodant le message pour renvoyer au NXT l'information d'un des capteurs qui auront été branchés au µC

Nous avons pu récuperer des informations sur la maniere de creer un bloc labview ou mindstorm. Ce sera notre prochain objectif.

Sources:
Brochage Port Mindstorm : https://sites.google.com/site/mccolganrobotics/

Brique RFID http://www.generationrobots.com/capteur-rfid-pour-robot-lego-mindstorms-nxt-codatex,fr,4,Capteur-RFID-NXT.cfm

== 27/02/2013 ==
Test de l'accéléromètre par communication I2C avec l'arduino : résultats encourageants, l'arduino reçoit des valeurs correspondant à la position du capteur ainsi qu'à ses mouvements.
[[Fichier:Infos-serie-accel.png]]

Code utilisé : http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/Magneto/LSM303_Example.zip.

Nous sommes partis de cette exemple et l'avons adapté pour qu'il concorde avec les versions plus récentes de la bibliothèque utilisée.
Brochage I2C de l'arduino trouvable à l'adresse : http://arduino.cc/en/Reference/Wire .

== 04/03/2013 ==
Nous avons réussi à établir le schéma de la structure du câble I2C du Mindstorm :

[[Fichier:Schéma-cable-i2c.jpg]]

== 06/03/2013 ==
'''Partie Arduino :'''

Il a fallu réaliser un programme sur l'Arduino prenant en compte le protocole suivant :

La brique NXT envoie des messages en I2C ; l'un d'entre eux signifiera qu'il s'adresse à l'Arduino. Quand ce dernier lit ce message précis, il doit attendre que la brique NXT lui envoie un second message contenant un code désignant le capteur dont on désire avoir les informations (on pourra relier des capteurs analogiques sur les broches A0, A1, A2 et A3 ainsi que des capteurs digitaux sur les broches 2 à 12). Grâce à ce dernier code, l'Arduino saura laquelle de ses entrées elle doit lire, et pourra ainsi réceptionner les données générées par le capteur correspondant ; ainsi, les données du capteur pourront être envoyées par l'Arduino en I2C à la brique NXT.

== 07/03/2013 ==
'''Partie Arduino:'''

L'Arduino doit être remplacé par un microcontrôleur ATTiny13. Pour créer le circuit, il faut créer un typon sous Altium. Toutefois, certains éléments, comme le microcontrôleur ou la connectique femelle du câble Mindstorm, ne sont pas reconnus par les librairies installées sur Altium : il faudra donc les créer nous-mêmes.

== To Do : ==
'''Matériel : '''

Faire communiquer l'arduino avec la brique programmable du Mindstorm.

Remplacer l'Arduino par un microcontrolleur.

'''Logiciel : '''

Faire un bloc LabView permettant à l'utilisateur de programmer le robot Mindstorm en fonction des connexions de l'arduino.

Mindstorm

2013-03-06T17:14:28Z

Tchampag : /* To Do : */

Mindstorm

2013-03-06T15:38:55Z

Tchampag : /* To Do : */

Mindstorm

2013-03-06T15:38:35Z

Tchampag : /* 06/03/2013 */

Mindstorm

2013-03-06T15:38:24Z

Tchampag : /* 04/03/2013 */

Mindstorm

2013-03-06T15:38:14Z

Tchampag : /* 04/03/2013 */

Mindstorm

2013-03-04T17:02:39Z

Tchampag : /* 27/02/2013 */

Fichier:Schéma-cable-i2c.jpg

2013-03-04T17:02:25Z

Tchampag :

Mindstorm

2013-02-28T07:26:25Z

Tchampag : /* Objectif: */

Fichier:Schema Montage.jpg

2013-02-28T07:26:09Z

Tchampag : a téléversé une nouvelle version de « Fichier:Schema Montage.jpg »

Fichier:Schema Montage.jpg

2013-02-28T07:24:23Z

Tchampag :

Mindstorm

2013-02-27T16:41:37Z

Tchampag : /* 27/02/2013 */

== Objectif: ==

Concevoir une brique materielle qui fera l'interface entre la brique Mindstorm et les capteurs et actionneurs divers

Développer une brique logicielle utilisable dans l'interface de programmation Labview livrée avec le MindStorm.

== Avancement : ==

Prise en main et test du bus I2C

URL Mindstorm/Arduino : https://sites.google.com/site/mccolganrobotics/

== 27/02/2013 ==
Test de l'accéléromètre par communication I2C avec l'arduino : résultats encourageants, l'arduino reçoit des valeurs correspondant à la position du capteur ainsi qu'à ses mouvements.
[[Fichier:Infos-serie-accel.png]]

Code utilisé : http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/Magneto/LSM303_Example.zip.

Nous sommes partis de cette exemple et l'avons adapté pour qu'il concorde avec les versions plus récentes de la bibliothèque utilisée.
Brochage I2C de l'arduino trouvable à l'adresse : http://arduino.cc/en/Reference/Wire .

== To Do : ==
'''Matériel : '''

Faire communiquer l'arduino avec la brique programmable du Mindstorm.

Brancher plusieurs capteurs I2C sur un seul arduino, et les mettre en oeuvre.

'''Logiciel : '''

Faire un bloc LabView permettant à l'utilisateur de programmer le robot Mindstorm en fonction des connexions de l'arduino.

Mindstorm

2013-02-27T16:40:58Z

Tchampag : /* 27/02/2013 */

== Objectif: ==

Concevoir une brique materielle qui fera l'interface entre la brique Mindstorm et les capteurs et actionneurs divers

Développer une brique logicielle utilisable dans l'interface de programmation Labview livrée avec le MindStorm.

== Avancement : ==

Prise en main et test du bus I2C

URL Mindstorm/Arduino : https://sites.google.com/site/mccolganrobotics/

== 27/02/2013 ==
Test de l'accéléromètre par communication I2C avec l'arduino : résultats encourageants, l'arduino reçoit des valeurs correspondant à la position du capteur ainsi qu'à ses mouvements.
[[Fichier:Infos-serie-accel.png]]

Code utilisé : http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/Magneto/LSM303_Example.zip.

Nous sommes partis de cette exemple et l'avons adapté pour qu'il concorde avec les versions plus récentes de la bibliothèque utilisée.
Brochage I2C de l'arduino trouvalble à l'adresse : http://arduino.cc/en/Reference/Wire .

== To Do : ==
'''Matériel : '''

Faire communiquer l'arduino avec la brique programmable du Mindstorm.

Brancher plusieurs capteurs I2C sur un seul arduino, et les mettre en oeuvre.

'''Logiciel : '''

Faire un bloc LabView permettant à l'utilisateur de programmer le robot Mindstorm en fonction des connexions de l'arduino.

Mindstorm

2013-02-27T16:40:33Z

Tchampag : /* To Do : */

== Objectif: ==

Concevoir une brique materielle qui fera l'interface entre la brique Mindstorm et les capteurs et actionneurs divers

Développer une brique logicielle utilisable dans l'interface de programmation Labview livrée avec le MindStorm.

== Avancement : ==

Prise en main et test du bus I2C

URL Mindstorm/Arduino : https://sites.google.com/site/mccolganrobotics/

== 27/02/2013 ==
Test de l'accéléromètre par communication I2C avec l'arduino : résultats encourageants, l'arduino reçoit des valeurs correspondant à la position du capteur ainsi qu'à ses mouvements.
[[Fichier:Infos-serie-accel.png]]

Code utilisé : http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/Magneto/LSM303_Example.zip . Nous sommes partis de cette exemple et l'avons adapté pour qu'il concorde avec les versions plus récentes de la bibliothèque utilisée.
Brochage I2C de l'arduino trouvalble à l'adresse : http://arduino.cc/en/Reference/Wire .

== To Do : ==
'''Matériel : '''

Faire communiquer l'arduino avec la brique programmable du Mindstorm.

Brancher plusieurs capteurs I2C sur un seul arduino, et les mettre en oeuvre.

'''Logiciel : '''

Faire un bloc LabView permettant à l'utilisateur de programmer le robot Mindstorm en fonction des connexions de l'arduino.

Mindstorm

2013-02-27T16:40:04Z

Tchampag :

== Objectif: ==

Concevoir une brique materielle qui fera l'interface entre la brique Mindstorm et les capteurs et actionneurs divers

Développer une brique logicielle utilisable dans l'interface de programmation Labview livrée avec le MindStorm.

== Avancement : ==

Prise en main et test du bus I2C

URL Mindstorm/Arduino : https://sites.google.com/site/mccolganrobotics/

== 27/02/2013 ==
Test de l'accéléromètre par communication I2C avec l'arduino : résultats encourageants, l'arduino reçoit des valeurs correspondant à la position du capteur ainsi qu'à ses mouvements.
[[Fichier:Infos-serie-accel.png]]

Code utilisé : http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/Magneto/LSM303_Example.zip . Nous sommes partis de cette exemple et l'avons adapté pour qu'il concorde avec les versions plus récentes de la bibliothèque utilisée.
Brochage I2C de l'arduino trouvalble à l'adresse : http://arduino.cc/en/Reference/Wire .

== To Do : ==
'''Matériel : '''
Faire communiquer l'arduino avec la brique programmable du Mindstorm.

Brancher plusieurs capteurs I2C sur un seul arduino, et les mettre en oeuvre.

'''Logiciel : '''
Faire un bloc LabView permettant à l'utilisateur de programmer le robot Mindstorm en fonction des connexions de l'arduino.

Mindstorm

2013-02-27T16:38:39Z

Tchampag : /* Avancement : */

== Objectif: ==

Concevoir une brique materielle qui fera l'interface entre la brique Mindstorm et les capteurs et actionneurs divers

Développer une brique logicielle utilisable dans l'interface de programmation Labview livrée avec le MindStorm.

== Avancement : ==

Prise en main et test du bus I2C

URL Mindstorm/Arduino : https://sites.google.com/site/mccolganrobotics/

== 27/02/2013 ==
Test de l'accéléromètre par communication I2C avec l'arduino : résultats encourageants, l'arduino reçoit des valeurs correspondant à la position du capteur ainsi qu'à ses mouvements.
[[Fichier:Infos-serie-accel.png]]

Code utilisé : http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/Magneto/LSM303_Example.zip . Nous sommes partis de cette exemple et l'avons adapté pour qu'il concorde avec les versions plus récentes de la bibliothèque utilisée.
Brochage I2C de l'arduino trouvalble à l'adresse : http://arduino.cc/en/Reference/Wire .

== Objectifs : ==
'''Matériel : '''
Faire communiquer l'arduino avec la brique programmable du Mindstorm.
Brancher plusieurs capteurs I2C sur un seul arduino, et les mettre en oeuvre.

'''Logiciel : '''
Faire un bloc LabView permettant à l'utilisateur de programmer le robot Mindstorm en fonction des connexions de l'arduino.

Fichier:Infos-serie-accel.png

2013-02-27T16:24:10Z

Tchampag :

Contrôle LED 256 couleurs, 2011/2012, TD1

2012-04-08T17:06:40Z