Armind
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
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
Le besoin
Le client
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.
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 :
- un bras manipulateur RB-Lyn-322 : Kit Bras Robotique AL5D à 4 Degrés de Liberté Lynxmotion
- Robot Autonome en Kit A4WD1 Aluminium Lynxmotion
- Kit Little Grip Lynxmotion (Avec Servomoteurs)
- Casque et SDK Emotiv EPOC
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 | 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 | 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 | 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 | 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.
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
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.
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 en page suivante) :
- 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.
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
- 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
- Projet bras robotique 2012
- cours Etude d'Approfondissement 2012
- Puzzlebox Brainstorms - Wheelchair Demo @ Noisebridge
- Site du logiciel Openvibe nécessaire pour interpréter les signaux du casque neuronal