Difference between revisions of "Armind"

From air
Jump to navigation Jump to search
Line 50: Line 50:
 
Il faut donc obtenir un système fiable et stable si l'on veut le déployer auprès de personnes déjà vulnérables. Il est essentiel de faire attention à ne pas mettre les utilisateurs en danger.
 
Il faut donc obtenir un système fiable et stable si l'on veut le déployer auprès de personnes déjà vulnérables. Il est essentiel de faire attention à ne pas mettre les utilisateurs en danger.
   
[[File:SchemaArmind.gif|200px|center]]
+
[[File:SchemaArmind.gif|500px|center]]
   
 
====Analyse de l'existant====
 
====Analyse de l'existant====

Revision as of 18:26, 20 March 2013

Robotic Arm

Enseignant: Nicolas Glade, Nicolas Vuillerme, Renaud Blanch

Elèves Ingénieurs RICM5 & TIS5: Marie Chevallier (chef de projet), Yacine Fall, Radia Koubaa, Anne Tabard

Description

Projet Armind

Les handicaps sont nombreux et variés. Il est essentiel de pouvoir tenir compte de cette diversité pour améliorer le quotidien des personnes concernées.

Le DefiH organisé par Sogeti et LeMondeInformatique.fr nous offre l'opportunité de nous pencher sur cette question. Notre équipe, issue de l'école Polytech Grenoble a focalisé son attention sur les handicaps des membres supérieurs. Nous travaillons sur la réalisation d'un dispositif de compensation de handicap. Ce dernier est basé sur la commande d„un bras robotisé par la pensée via un casque neuronal. La bonne réalisation d'un projet nécessite la combinaison de deux éléments essentiels : Avoir une bonne idée à développer et assurer un bon suivi du projet à l'aide d'outils de gestion de projet. Il est aussi essentiel de s'assurer de l'utilité du projet en validant le besoin avec l'utilisateur. Son utilisabilité est enfin le dernier point fondamental à respecter en réalisant une solution en adéquation avec le besoin.

L'équipe

Marie Chevallier Yacine Fall Radia Koubaa Anne Tabard Xiao Lu

Le partenaire

Fondation Garches

La Fondation Garches, reconnue d'utilité publique depuis 2005 a pour double objectif le développement de l'autonomie et la réinsertion sociale et professionnelle des personnes en situation de handicap. Cela rejoint les enjeux du projet Armind : permettre à des personnes en difficulté d'interagir avec leur environnement afin de favoriser leur réinsertion professionnelle. Cela passe par le développement d'un dispositif médical de compensation de handicap : un bras robotisé commandé par la pensée via un casque neuronal. La fondation Garches a une forte implication dans le domaine des handicaps moteurs, surtout ceux relatifs aux membres inférieurs. Mais il ne s’agit pas d’un intérêt exclusif.

Le projet Armind vient donc en complément de cette activité. Il est centré sur la personne ayant un handicap des membres supérieurs, mais peut très bien assister une personne à mobilité réduite pour une meilleure interaction avec son environnement (exemple : personne alitée). La solution Armind s’adresse à de nombreux types de paralysie. Elle peut donc aussi concerner des personnes atteintes du syndrome de renfermement (locked-in). Il s’agit d’une paralysie quasi complète de l’organisme à l'exception des capacités cognitives. La cause principale de cette paralysie est la survenue d’un AVC pouvant toucher des personnes très jeunes, et donc professionnellement actives.

Par leur expérience, les membres de la Fondation Garches ont beaucoup à apporter. Ils connaissent les besoins et les attentes des utilisateurs, ainsi que les lacunes à combler dans leur environnement. Par leur expertise, ils pourront nous aider, nous conseiller afin d’obtenir, à long terme, un outil répondant au mieux aux attentes des utilisateurs dans le besoin.

Le besoin

Le client

DéfiH Sogeti Le Monde Informatique

Depuis 2010, Sogeti, via sa Mission Handicap, s'engage à sensibiliser la population aux handicaps et à la réinsertion professionnelle de tous. Cela repose sur cinq principaux engagements :

  • Le recrutement de personnes en situation de handicap
  • Le maintien dans l'emploi
  • L'accueil et la formation de stagiaires
  • Le soutien d‟un milieu adapté et protégé
  • L'information et la sensibilisation

Le DéfiH s'inscrit dans cette mission. Il est organisé en partenariat avec LeMondeInformatique.fr. Il tient compte de la diversité des handicaps et de leur grand nombre. Le besoin premier du client est de développer un système permettant de compenser un handicap quelconque (handicap moteur, mental, cécité, surdité...). Notre équipe a ensuite fait le choix de travailler sur les handicaps moteurs, principalement ceux liés aux membres supérieurs. Cela peut comprendre l'incapacité de mouvoir ses bras, la fatigue rapide, des degrés de libertés limités jusqu'aux paralysies totales (syndrome locked-in). Nous verrons tout au long de ce document que l‟outil proposé peut être utilisé dans diverses situations et est applicable à de nombreux handicaps.

Dans le cadre de notre projet, le client souhaite obtenir un produit de compensation de handicap, basé sur l'usage de systèmes robotiques. Le but n'est pas de remplacer complètement un bras humain, mais de rétablir un équilibre dans le quotidien des personnes en difficulté en comblant au mieux ce manque. Cela passe par l'utilisation d‟un outil permettant d'effectuer des gestes simples de la vie quotidienne, impossible ou difficile pour l'utilisateur, jusque là.

Enjeux et objectifs

Armind est un projet s'insère dans le cadre de nos études, et qui s'inscrit aussi à la deuxième édition du DéfiH. Il s'agit d'un concours entre cinq grandes écoles et universités, organisé par Sogeti et LeMondeInformatique.fr. Le projet présenté cette année par Polytech Grenoble a pour objectif d'accompagner les personnes en situations de handicap moteur. Il cible en particulier les personnes atteintes d'un handicap des membres supérieurs. Il repose sur la combinaison de trois domaines scientifiques : l'informatique, la robotique et les sciences médicales.

Ce projet veut favoriser la formation, l'insertion, le maintien ou le retour à l'emploi de personnes en situation de handicap. En effet, grâce au contrôle mental, l'utilisateur pourra de nouveau avec une interaction avec son environnement, via un bras moteur. Cette innovation en interaction cerveau-machine doit permettre l'amélioration des activités de préhension de la vie quotidienne des personnes à mobilité très réduite ou dotées d'un handicap lourd. Par exemple, une personne incapable de quitter son lit pourra alors utiliser ce contrôle mental à distance pour effectuer un travail à l'aide d'un robot mobile (type robot de téléprésence).

Il faut donc obtenir un système fiable et stable si l'on veut le déployer auprès de personnes déjà vulnérables. Il est essentiel de faire attention à ne pas mettre les utilisateurs en danger.

SchemaArmind.gif

Analyse de l'existant

Une fois l’idée du projet née, il a été essentiel de faire une analyse de l’existant. Le développement d’interfaces cerveau-machine est en plein essor. Peu sont appliquées au milieu médical. Emotiv (développant le casque EPOC) travaille sur de multiples applications ludiques. D’autres ont réalisé des objets (matériel) commandés à distance par la pensée, mais à visée non médicale.

L’utilisation la plus commune des casques neuronaux par le grand public est dédiée aux jeux vidéo et à la réalité augmentée. Nous pouvons citer l’application “use the force” développée par des chercheurs de l’INRIA, faisant référence à la célèbre saga “Star Wars”. Il s’agit d’un jeu commandé par un casque neuronal. L’utilisateur doit par exemple soulever un vaisseau spatial virtuel en imaginant des mouvements de pied. Parallèlement il est possible d’observer en temps réel le neurofeedback. Cette application a été présentée lors de la fête de la Science à ParisTech en Octobre 2011.

Un autre exemple, similaire à notre projet Armind, pouvant être cité est un bras robotique contrôlé par un casque neuronal. Il s’agit du même bras Lynxmotion que celui utilisé dans notre projet. Cependant, le casque utilisé est plus complexe, moins pratique à utiliser que celui d’Emotiv et plus cher.

Une application médicale assez semblable à la notre a été développée par l’équipe d’Andrew Schwartz à l’Université de Pittsburgh. Il s’agit d’un bras robotisé, répondant à l’activité neuronale. Ce dispositif est actuellement implanté chez une patiente (Jan Scheuermann) atteinte de tétraplégie. Ce système est efficace et actuellement utilisé. Malheureusement, il présente un inconvénient majeur : il s’agit en effet d’un système totalement invasif. En effet, deux électrodes sont directement implantées dans le cerveau de la patiente. Ce point justifie la réalisation de notre projet Armind visant à développer un produit non invasif.

Une autre technique potentiellement applicable au projet serait l’eye-tracking. Le but serait de commander le bras à distance à l’aide des yeux. Le système détecte la zone observée par l’utilisateur pour reconnaître l’action choisie. Cette méthode existe actuellement et est maîtrisée. Elle permet d’effectuer des commandes en fixant un point précis sur un écran de façon efficace. Cependant, compte tenu du contexte de notre projet, ce système n’est pas adapté. Effectivement, notre projet Armind vise à mettre en place un produit utilisable par des personnes présentant des handicaps lourds, couramment associés à des saccades oculaires. Notre solution est donc plus adaptée, utilisant la commande du bras par un casque neuronal Epoc, puisque nous pouvons filtrer les artefacts dues aux saccades oculaires.

De plus, l'utilisation pourra aussi être adaptée à des patients atteints du syndrome de renfermement paralysant entièrement le corps à l'exception des facultés cognitives. Un autre facteur favorisant l’utilisation du casque : les systèmes d’eye-tracking sont beaucoup plus cher, et plus difficile d’accès que le casque EPOC Emotiv. Il ne s’agit pas d’un outil accessible au grand public contrairement au casque.

Fonctionnalité du produit

Notre produit est composé de deux principales entités technologiques :

  • Un casque EPOC Emotiv répondant à une activité neuronale
  • Un bras robotisé AL5D Lynxmotion

La finalité est de faire communiquer ces différents acteurs. Le produit, à son terme, devra interpréter le signal neuronal reçu et bouger le bras robotisé en fonction de ce signal afin de saisir des objets. Les fonctionnalités sont regroupées dans les différentes catégories suivantes.

Mouvement

Cette catégorie intègre le bras robotisé. Après divers calculs et traitements, on doit être capable de :

  • Déplacer le bras jusqu’à une distance proche de l’objet
  • Lever ou baisser le bras
  • Faire une rotation du bras pour le mettre en face de l’objet à saisir
  • Saisir un objet
  • Relâcher un objet
Retour utilisateur

Une fois une manœuvre faite (saisie d’un objet, pose d’un objet ou autre), il est important d’avoir un retour de la part du système. Le bras n’ayant pas de retour de force, nous souhaitons intégrer un retour visuel et/ou sonore au système pour informer l’utilisateur. Cela pourra par la suite être réadapté à d’autres handicaps tels que la surdité (retour visuel) ou cécité (retour sonore).

Matériel disponible

Pour le prototype de notre projet, nous considérons :

Nous avons également l'opportunité de travailler sur un Ultrabook Intel.

Les risques

Les risques pouvant intervenir sur notre projet sont de différentes natures. Il est important d’en avoir conscience dès le départ, de les lister et de les suivre régulièrement afin de les éviter ou de les corriger au plus vite s’ils apparaissent. Cette liste est représentée dans les tableaux des risques suivants :

Risques humains
Risques Risque de survenue Impact Criticité Action préventive Action corrective
Maladie 5 5 25 hygiène et prudence médecin
Absence d'un membre 5 1 1 Gestion du planning médecin
Compétences techniques 10 10 100 pré-requis, autoformation importance de validation
Mauvaise compréhension du besoin client 1 5 5 réunion de coaching régulières et commnunication par mail avec les organisateurs en cas de doute redéfinition des besoins si égarement
Manque de connaissance de l'environnement utilisateur 5 5 25 s'informer, rencontrer des utilisateurs finaux potentiels réadaptation du produit
Mésentente des coéquipières 1 10 10 Communiquer - Ecouter les avis de tous - Faire des réunions régulières Organiser une réunion pour résoudre le problème et faire preuve de professionnaliste

Nous utilisons beaucoup d’outils que nous ne connaissons pas et de technologies innovantes. Il va donc nous falloir nous autoformer sur ces technologies et sûrement choisir un certain nombre d’approches (langages, API, Framework,...). Ces choix peuvent s’avérer déterminant dans la réussite ou la tenue des délais de notre projet. Il sera essentiel de faire communiquer les diverses entités utilisées entre elles et de s’assurer que ces communications sont possibles et n'entraînent pas de problème sur la globalité du système.

Risques techniques
Risques Risque de survenue Impact Criticité Action préventive Action corrective
perte de données 5 5 25 sauvegarde sur divers supports récupérer la version n-1
Difficulté d'utilisation du casque 10 10 100 Formation avec la doctorante Nataliya Kosmyna travaillant sur ce casque communiquer avec N. Glade, R. Blanch et N. Kosmyna pour répondre à nos questions
problèmes de calcul de trajectoire 10 10 100 lecture de la documentation du robot et formation correction des calculs
Faible précision de mouvements du bras robotisé 10 5 50 Définir des mouvements simples Réajuster les mouvements définis
Faible précision de commande du casque 10 5 50 Définir des mouvements simples Réajuster les mouvements définis
Faible précision de mouvements du robot mobile 10 1 10 Définir des mouvements simples réajuster les mouvements définis

Les risques techniques concernent chaque composant du système (casque et robot) mais aussi le lien entre eux (programmation).

En ce qui concerne l’utilisation du casque Epoc d’Emotiv, le risque va être de se former sur ces technologies nouvelles (peu de retours sur expérience et peu d’aide technique disponible) en peu de temps (2 mois de projet).

Pour la programmation, faire intervenir du matériel expose à un ensemble de problèmes. Il faut réussir à faire interagir les diverses entités ce qui n’est pas tâche aisée. Selon la stratégie adoptée, pour le bras robotique nous pouvons être confronté au problème de calcul de la trajectoire. Il s’agit de raisonner en logique inversée. Le but est de partir des coordonnées de l’objet et de calculer par la suite les positions et rotations d'articulations du bras afin de saisir l’objet. De plus, il faut tenir compte du fait que le bras robotisé est un outil pédagogique, donc peu précis. De ce fait, il y a un risque sur son utilisation qu’il va falloir gérer.


Risques matériels
Risques Risque de survenue Impact Criticité Action préventive Action corrective
Panne du casque 1 10 10 manipuler avec précaution emprunter le casque du laboratoire de mr R. Blanch
Panne du bras robotisé 5 10 50 manipuler avec précaution réparer avec l'aide des enseignants encadrant
Panne du robot mobile 5 5 25 manipuler avec précaution réparer avec l'aide des enseignants encadrant
Panne d'un PC 5 5 25 manipuler avec précaution + gestion des antivirus réparer et/ou remplacer
Pas de connexion à internet 5 1 5 s'appuyer sur différents réseaux réparer la connexion ou se déplacer pour en trouver une autre
Risques organisationnels
Risques Risque de survenue Impact Criticité Action préventive Action corrective
Problème de correspondance de planning des deux filieres 10 5 50 planning mis en place en tenant compte des emplois du temps disponibles sur ADE réajustement du planning
Pas de salle disponible 1 1 1 planifier le travail dans les salles mises à notre disposition trouver une nouvelle salle libre
Problème de correspondance de planning avec le coach 5 5 25 planifier à l'avance les réunions prévoir la réunion une autre date ou organiser une téléréunion
Problème de correspondance de planning avec intervenants 5 1 5 planifier à l'avance la rencontre organiser la rencontre un autre jour ou en téléréunion

Ce projet regroupe deux filières de l’école Polytech Grenoble (TIS et RICM). Cette cohabitation est une richesse en terme de connaissances mais peut présenter des difficultés d’organisation. En effet, il n’est pas évident de trouver des créneaux convenants aux deux binômes. Il sera donc souvent difficile de regrouper l’ensemble de l’équipe pour la réalisation de cet outil.

Il faut rappeler que notre projet s’inscrit dans deux cadres distincts : un projet de fin d’études au sein de l’école Polytech Grenoble et la participation au DéfiH de Sogeti et LeMondeInformatique.fr. Il sera donc essentiel de pouvoir gérer les deux plannings pour mener à bien ce projet.

Dans la proposition d’une nouvelle solution innovante, si le projet aboutit à la réalisation d’un produit fini novateur, nous pouvons nous interroger sur les éventuelles problématiques de propriété industrielle et intellectuelle. A qui va le brevet (s’il y a lieu d’en déposer un) ? D’autre part, notre produit serait amené à être testé sur une personne. Comment gérer une situation accidentelle pendant le test? (Si la personne est blessée à cause du robot par exemple).

Solution proposée

Ce projet vise à connecter prioritairement les API de deux entités distinctes : Le casque EPOC et le bras robotisé. Le but est de réaliser un logiciel commun à ces deux entités afin qu’elles interagissent pour aboutir à notre produit final : un bras robotique répondant aux commandes neuronales de l’utilisateur. A cela s’ajoutent des retours (feedbacks) visuels et/ou sonores.

En ce qui concerne les choix techniques, nous avons du choisir entre plusieurs possibilités. Effectivement, il existe actuellement plusieurs méthodes pour interpréter des données neuronales. Voici, dans les pages suivantes, une présentation des trois principales méthodes à notre disposition pour utiliser les données de notre casque.

Techniques d'analyse d'activité neuronale

P300

Une grille d’images est présentée à l’utilisateur. Chaque image clignote alternativement, à la même fréquence. L’utilisateur va focaliser son attention sur l’image correspondant à l’action qu’il désire effectuer. La répercussion de ce signal dans le cerveau de l’utilisateur est récupérée par les capteurs (on observe un pic positif, en termes d’activité́ neuronale, 300 millisecondes après la stimulation visuelle). On compte le nombre de stimuli apparus durant une certaine période pour en déduire l’image regardée : même nombre de clignotements que de stimuli (choix de 1 parmi N).

Avantages :

  • Cette méthode est assez robuste
  • On peut exploiter une grille contenant jusqu’à 26 images

Inconvénients :

  • Nécessite une calibration assez longue
  • La latence nécessaire pour compter le nombre de stimuli avant la décision prend plus d’une minute (assez long).
  • Perte de contact avec la réalité́ puisque l’utilisateur doit regarder une grille d’images. Cela nécessitera sûrement de bien concevoir l’IHM pour permettre le contrôle du robot en temps réel (caméra...).

SSVEP

Une grille d’images est présentée à l’utilisateur. Chaque image clignote à une certaine fréquence. L’utilisateur va focaliser son attention sur l’image correspondant à l’action qu’il désire effectuer. Le cerveau génère une activité cérébrale à la même fréquence que celle du stimulus visuel. Ce signal dans le cerveau de l’utilisateur est récupèré par les capteurs et on sélectionne alors l’action la plus probable : celle dont la fréquence de clignotement est la plus proche de la fréquence du signal cérébral (choix de 1 parmi 2 à 6 maximum).

Avantages : + La prise de décision est beaucoup plus rapide qu’avec la technique P300

Inconvénients : - Pour obtenir une bonne fiabilité́, il faut souvent se cantonner à un choix binaire - Les différentes fréquences de clignotement peuvent devenir assez pénibles pour l’utilisateur (fatigue, danger pour les épileptiques,...). - Perte de contact avec la réalité́ puisque l’utilisateur doit regarder une grille d’images. Nécessitera sûrement de bien concevoir l’IHM pour permettre le contrôle du robot en temps réel (camera...).

Graz

Cette technique se base sur l’analyse des zones motrices du cerveau humain. C’est un protocole complet : on calibre et entraîne le système sur des exemples de « pensée de mouvement », ce qui active une certaine zone cérébrale. Lors de l’activation de ces zones en situation d’exercice, on compare ces schémas avec ceux de l'entraînement. On sélectionne alors l’action la plus probable (chois 1 parmi N). Pour ceci, l’Inria a développé OpenVibe : un logiciel libre pour la gestion et le traitement des interfaces cerveau-ordinateur et les neurosciences en temps réel.

Avantages : + Très naturel et complète + Peut couvrir un grand nombre d’actions différentes

Inconvénients : - La phase d’apprentissage peut durer assez longtemps (jusqu’à 30 minutes). - Le casque Epoc d’Emotiv n’est pas réellement adapté à cette utilisation : nécessite 10 électrodes au minimum pour couvrir les zones motrices du cerveau (contre 4 chez Epoc). Ainsi les résultats avec Epoc ne sont fiables qu’à 65% (peut atteindre 80% chez un utilisateur expert et seulement en maintenant les électrodes très proches de la surface du crâne). Une évolution vers la méthode Graz pourra être envisagée (du moins pour quelques tests) pour davantage d’ergonomie, mais nécessiterait sûrement un changement de matériel.

Choix pour la solution : SSVEP

Nous avons convenu de choisir la technique SSVEP (Steady State Visually Evoked Potential). En effet, cette technique est la plus adaptée à notre projet car elle présente un faible temps de réaction (<300ms), ce qui n’était pas le cas avec la technique P300. De plus, la position des électrodes sur le casque Epoc à notre disposition est adaptée à cette méthode, contrairement à la technique Graz. Effectivement, étant donné que nous travaillons sur la zone motrice du cerveau, les 4 électrodes du casque Epoc sur cette zone ne sont pas suffisantes pour obtenir des résultats intéressants.

Nous avons donc un enjeu majeur avec notre choix d’utiliser la SSVEP qui est l’importance de réduire au maximum le nombre de fréquences lors de l’utilisation. Nous avons choisi de fragmenter au maximum les mouvements du bras et d’ajouter une fréquence pour changer de mode. Chaque mode n’aura que deux mouvements possibles.

Schéma des degrés de liberté du bras robotisé

En ce qui concerne le contrôle du bras robotisé, il nous faut définir clairement les actions que nous voulons proposer à l’utilisateur. Nous avons identifié 5 degrés de libertés sur le bras robotisé (voir schéma) :

  • Orientation verticale du poignet
  • Orientation du coude
  • Ouverture ou fermeture de la pince
  • Rotation de la base
  • Orientation de l’épaule


A partir de cela, nous avons décidé d'implémenter les contrôles du robot suivants :

  • Tourner à gauche / tourner à droite
  • Avant / arrière
  • Attraper / lâcher
  • Haut / bas

Pour coder ces solutions, nous avons choisi d’utiliser des environnements de développement pour chaque partie (bras et casque). Pour le casque il s’agit d’appliquer la méthode SSVEP pour étudier l’activité neuronale via OpenVibe (un logiciel libre dédié à la création d'interfaces Machine Ordinateur, développé par l’INRIA). Pour le bras robotisé le travail nécessite de coder les mouvements via l’environnement ROS (Robot Operating System). C’est un système d’exploitation sous licence open source qui va nous permettre de contrôler notre bras robotique.

Maquette d'interface utilisateur

Précisions pour l'installation

OpenVIBE

OpenVIBE est une solution open source, développée par l'INRIA, pour la création, l'utilisation et le test d'interfaces cerveau-machine (en anglais BCI : Brain Computer Interface).

ATTENTION:

  • OpenVIBE est actuellement stable uniquement pour les systèmes Windows XP ou Windows 7. La version Linux (Ubuntu et Fedora) n'est pas compatible pour le contrôle du casque Epoc d'Emotion.
  • Il est nécessaire de posséder la version 1.0.0.3 du SDK Emotiv pour une bonne reconnaissance du driver du casque Epoc sous OpenVIBE . ATTENTION car la version 1.0.0.5 N'EST PAS compatible.


=> Télécharger donc Emotiv Development Kit_v1.0.0.3-PREMIUM et placer ce répertoire dans votre dossier Programmes Files (C:\Program Files (x86) ou C:\Program Files selon votre système).

Synchronisation Epoc-OpenVIBE

Capture d'écran de l'interface du serveur d'acquisition
Capture d'écran de l'interface Device properties
  • Installer OpenVIBE. Pour ceci, suivre les instructions disponibles sur le site d'OpenVIBE.

ATTENTION à ne pas donner un chemin d'accès trop long au fichier.

  • Aller dans le répertoire openvibe\cmake-modules et modifier le fichier FindThirdPartyEmotivAPI.cmake (remplacer son contenu par celui du fichier suivant : File:FindThirdPartyEmotivAPI.txt ).
  • Aller dans le répertoire openvibe\scripts et exécuter win32-install_dependencies.exe. Ceci doit lier correctement les dépendances avec OpenVIBE. Normalement, tout dois bien se passer...
  • Dans le même répertoire, exécuter ensuite win32-build.cmd. Quelques erreurs peuvent survenir, mais normalement ça doit marcher quand même.


A cette étape du processus, OpenVIBE est donc opérationnel.

  • Aller dans le répertoire openvibe\dist et lancer ov-acquisition-server.cmd. Ce serveur permet d'acquérir les données provenant du casque (ou d'en simuler).
  • Sélectionner le driver Emotiv EPOC dans la liste (avec les modifications qu'on a faites précédemment, ce driver doit normalement apparaitre).
  • Cliquer sur le bouton Driver Properties. Une fenêtre Device properties s'ouvre. Modifier le Path to Emotiv Research SDK afin de mettre votre propre chemin vers la bonne version du SDK (voir la partie Précisions pour l'installation => OpenVIBE).
  • Ensuite, pour tester si la synchronisation se passe correctement, il faut lancer le ov-designer.cmd et suivre le tutoriel d'OpenVIBE

Synchronisation OpenVIBE-Application

  • Avec Microsoft Viusal Studio C++ (nous avons utilisé la version Express 2010), créer un nouveau Projet Vide.
  • Créer, dans ce projet, une classe C++ du nom de votre choix.
  • Récupérer le code du programme client présent sur le tutoriel d'OpenVIBE, et remplacer l'ensemble du code auto-généré dans votre nouvelle classe (<maNouvelleClasse>.cpp) par ce code.


Nous allons maintenant lier le projet avec les librairies nécessaires.

  • Cliquer droit sur le projet et sélectionner les Propriétés.
  • Dérouler dans l'onglet Editeur de liens et sélectionner l'option entrée
  • Dans la partie de droite de la fenêtre, cliquer sur la ligne et modifier Dépendances supplémentaires
  • Ajouter alors les librairies vrpn.lib et quat.lib.

ATTENTION : Mettre le chemin complet et séparer les librairies par un retour à la ligne
exemple :

 C:\openvibe\dependencies\vrpn\lib\vrpn.lib
C:\openvibe\dependencies\vrpn\lib\quat.lib
  • Cliquer ensuite sur l'onglet C/C++ et, dans la partie de droite, cliquer sur la ligne et modifier Autres Répertoires Include
  • Ajouter alors le dossier vrpn\include

exemple :

 C:\openvibe\dependencies\vrpn\include
  • Cliquer enfin sur les boutons Appliquer puis OK
  • Il ne reste ensuite plus qu'à lancer votre server d'acquisition et designer, les configurer (pour ceci, suivre le tutoriel d'OpenVIBE) puis compiler et exécuter le projet... Enjoy ;)

ATTENTION : Pour l'exécution du projet, il faut bien vérifier que l'onglet Plateformes Solution soit bien sur Win32 et que Configurations de solutions soit bien en Released (et non en Debug).

Références