BCI : Interface Cerveau Ordinateur - Historique des versions

Cmonteir : /* Réalisation */

2014-02-24T00:03:49Z

‎Réalisation

Tchampag : /* Objectifs Futurs */

2014-02-23T15:52:53Z

‎Objectifs Futurs

Tchampag : /* Réalisation */

2014-02-23T14:35:58Z

‎Réalisation

Cmonteir : /* Réalisation */

2014-02-23T14:00:34Z

‎Réalisation

Cmonteir : /* Réalisation */

2014-02-18T11:33:10Z

‎Réalisation

Tchampag : /* Réalisation */

2014-02-17T16:00:57Z

‎Réalisation

Cmonteir : /* Réalisation */

2014-02-14T20:22:57Z

‎Réalisation

Cmonteir : /* Réalisation */

2014-02-14T20:21:18Z

‎Réalisation

Cmonteir : /* Réalisation */

2014-02-14T20:19:13Z

‎Réalisation

Cmonteir : /* Réalisation */

2014-02-14T20:04:07Z

‎Réalisation

@@ Ligne 374 : / Ligne 374 : @@
   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.
+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 standard et avons donc essayer de contacter le développeur de cette fonction, mais nous n'avons pas eu plus d'information sur les envois de données que celle rappelées plus haut.
@@ Ligne 417 : / Ligne 417 : @@
 </code>
+La communication TCP étant fonctionnelle, nous avons analysé les échanges OpenVibe<->Blender avec WireShark. Le script client est 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. Chose qui n'arrive malheureusement pas.
 [[Fichier:BCI WireShark TCP OVtoB.png]]
@@ Ligne 425 : / Ligne 425 : @@
 '''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.
@@ Ligne 437 : / Ligne 438 : @@
 [[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.
+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 adapté ce parser à nos besoins en rajoutant les identifieurs qui nous sont utiles.
 '''Client VRPN'''

← Version précédente		Version du 23 février 2014 à 15:52
Ligne 467 :		Ligne 467 :

	== Objectifs Futurs ==		== 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 =		= Gestion de Projet et Sources =

← Version précédente		Version du 23 février 2014 à 14:35
Ligne 464 :		Ligne 464 :

	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.		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 =		= Gestion de Projet et Sources =

@@ Ligne 419 : / Ligne 419 : @@
-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é.
+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.

← Version précédente		Version du 18 février 2014 à 11:33
Ligne 437 :		Ligne 437 :

	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.		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 =		= Développement du retour graphique sous blender =

@@ Ligne 449 : / Ligne 449 : @@
 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]]
+[[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:roll1.png]]  [[Fichier:roll2.png]]
+[[Fichier:BCI_roll1_Champeiro.png]]  [[Fichier:BCI_roll2_Champeiro.png]]
 ''Vue du modèle de la main au repos et pendant le pianotement''

← Version précédente		Version du 14 février 2014 à 20:22
Ligne 262 :		Ligne 262 :

	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.		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 (<span style="color: #888888">Addresses</span>, <span style="color: #0e84b5">Type</span>)
		+	<span style="color: #008800">20 Octets d'en-tête IPv4</span>
		+	<span style="color: #880000">32 Octets TCP</span>
		+	4 Octets de Données

	1er Envoi		1er Envoi

@@ Ligne 269 : / Ligne 269 : @@
 00 fe 2c 00 00 01 01  08 0a 09 34 a6 e9 09 34
    a6 c9</span> 00 00 00 01
-Numéro de version de 1
+Numéro de version : 1, semble correspondre au numéro de version du bloc TCP Writer plus qu'à la version d'OpenVibe
 em Envoi

@@ Ligne 270 : / Ligne 270 : @@
    a6 c9</span> 00 00 00 01
 Numéro de version de 1
 em Envoi
    <span style="color: #888888">00 00 00 00 00 00 00 00  00 00 00 00</span><span style="color: #0e84b5"> 08 00</span><span style="color: #008800"> 45 00
@@ Ligne 277 : / Ligne 278 : @@
    a6 e9</span> 00 00 00 01
 Endianness : Little Endian
 em Envoi
    <span style="color: #888888">00 00 00 00 00 00 00 00  00 00 00 00</span><span style="color: #0e84b5"> 08 00</span><span style="color: #008800"> 45 00
@@ Ligne 283 : / Ligne 285 : @@
 00 fe 2c 00 00 01 01  08 0a 09 34 a6 ea 09 34
    a6 ea</span> 00 00 00 00
 em Envoi
    <span style="color: #888888">00 00 00 00 00 00 00 00  00 00 00 00</span><span style="color: #0e84b5"> 08 00</span><span style="color: #008800"> 45 00
@@ Ligne 289 : / Ligne 293 : @@
 00 fe 2c 00 00 01 01  08 0a 09 34 a6 ea 09 34
    a6 ea</span> 01 00 00 00
 em Envoi
    <span style="color: #888888">00 00 00 00 00 00 00 00  00 00 00 00</span><span style="color: #0e84b5"> 08 00</span><span style="color: #008800"> 45 00
@@ Ligne 295 : / Ligne 301 : @@
 00 fe 2c 00 00 01 01  08 0a 09 34 a6 ea 09 34
    a6 ea</span> 00 00 00 01
 em Envoi
    <span style="color: #888888">00 00 00 00 00 00 00 00  00 00 00 00</span><span style="color: #0e84b5"> 08 00</span><span style="color: #008800"> 45 00
@@ Ligne 301 : / Ligne 309 : @@
 00 fe 2c 00 00 01 01  08 0a 09 34 a6 ea 09 34
    a6 ea</span> 00 00 00 00
 em Envoi
    <span style="color: #888888">00 00 00 00 00 00 00 00  00 00 00 00</span><span style="color: #0e84b5"> 08 00</span><span style="color: #008800"> 45 00
@@ Ligne 307 : / Ligne 317 : @@
 00 fe 2c 00 00 01 01  08 0a 09 34 a6 ea 09 34
    a6 ea</span> 00 00 00 00
 em Envoi
    <span style="color: #888888">00 00 00 00 00 00 00 00  00 00 00 00</span><span style="color: #0e84b5"> 08 00</span><span style="color: #008800"> 45 00
@@ Ligne 313 : / Ligne 325 : @@
 00 fe 2c 00 00 01 01  08 0a 09 34 a6 ea 09 34
    a6 ea</span> 00 00 00 00
+Variable de rembourrage 3
 Ensuite La trame est composé d'un total de 74 Octets :