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

Réalité Augmentée pour la chirurgie

2014-02-27T15:47:43Z

Cdelberg : /* Semaine 3 */

Papa Momar MBOUP/ Calvin DELBERGHE

= Présentation =

== Description et Objectif: ==

Notre projet consiste à assister les chirurgiens lors de chirurgies laparoscopiques. La chirurgie laparoscopique est une technique chirurgicale minimalement invasive où le chirurgien réalise une opération de l'abdomen par de petites incisions où sont placés des trocars qui permettent le passage de fins instruments chirurgicaux. Dans le cadre de ce projet, il s’agit de réaliser l’ablation de la(des) tumeur(s) présente(s) dans le foie du patient. La localisation des tumeurs ainsi que de l’ensemble du réseau vasculaire peut etre réalisé grâce à un scanner pré-opératoire et donc reconstruits en 3D. Cependant, ils ne peuvent pas être visualisés par la caméra lors de l’opération chirurgicale.

Ainsi, le chirurgien ne peut en aucun cas connaitre la localisation de la tumeur et ne peut pas se représenter la distance qui la sépare des parois du foie. D’où le but de notre projet: aider les chirurgiens dans ces opérations. Des travaux récents de l'équipe de recherche Shacra ont permis de suivre avec une bonne précision le mouvement de structures internes du foie pendant une opération laparoscopique. Le projet consiste à utiliser ces travaux pour mélanger le flux vidéo fourni par l'endoscope aux informations calculées par la simulation pour fournir aux chirurgiens des informations utiles sur la position des structures internes du foie lors de la manipulation. Différentes pistes pourront être explorées pour ne pas surcharger le flux vidéo tout en fournissant les informations importantes (position, profondeur, distance à la surface du foie...)

== Environnement de travail :==
1 ordinateur

OpenGL 3.3

SDL 2.0

IDE CodeBlocks

= Plan d'action / Gestion de projet =
Dans un premier temps, nous allons commencer à suivre des tutoriaux sur le framework OpenGL. Quand on sera assez avancé, nous débuterons le codage du programme principal. Donc pour le premier semestre, le plan est de mettre en place la base du programme et de bien maîtriser OpenGL pour la suite quand on ajoutera des fonctions plus poussées dans le programme.

= Réalisation =

== Semaine 37 ==
Présentation et Choix du sujet.

== Semaine 38 ==
Rencontre avec les encadrants du projet:
Explication détaillée du sujet ainsi que les attentes du projet.
Réception des premières données pour débuter quelques tests avec OpenGL.
== Semaine 39 ==
Installation d'OpenGL sous Windows avec CodeBlocks.
Début des tutoriaux sur le site du zéro:

http://fr.openclassrooms.com/informatique/cours/developpez-vos-applications-3d-avec-opengl-3-3

== Semaine 40 ==
Poursuite des tutoriaux.

== Semaine 41 ==
Poursuite des tutoriaux.

== Semaine 42 ==
Poursuite des tutoriaux.

== Semaine 43 ==
Poursuite des tutoriaux

== Semaine 44 ==
Poursuite des tutoriaux

== Semaine 45 ==
Poursuite des tutoriaux

== Semaine 46 ==
Poursuite des tutoriaux

== Semaine 47 ==
Fin de la première partie des tutoriaux.

== Semaine 48 ==
Démarrage du code du programme à partir du code réalisé pendant les tutoriels.

== Semaine 49 ==
Ajout de la fonction permettant de récupérer les données des fichiers .obj contenant les vertices, les coordonnées de texture, les vecteurs normaux et les références aux faces (triangles) constituant l'objet 3D.

== Semaine 50 ==
Nous sommes arrivé durant cette semaine à représenter une tumeur correctement en 3D.

Pour représenter un structure en 3D, nous allons utiliser un ensemble de triangle. Chaque triangle est constitué de 3 vertices qui sont ces sommets. Un vertex est tout simplement un point avec trois dimensions : x,y et z. Ainsi, le but est de relier les trois sommets (vertices) formant un triangle et ensuite de relier tous les triangles. Ainsi, nous obtiendront notre structure en 3D.

Cependant, nous rencontrons un problème quand on a un nombre de vertices élevés à représenter (de l'ordre de 20000 vertices). Une des pistes pour la résolution de ce problème est d'utiliser les display list. Cependant, les display List n'existent plus en OpenGL 3.3. Donc le problème reste irrésolu pour l'instant. On va regarder du coté des VBO (Vertex Buffer Object) et VBA(Vertex Buffer Array).

Les "Display List" permettent un stockage des données sur la carte graphique mais ne permettent pas de mettre à jour ces données. Les "VertexArray" conservent les données dans des tampons en mémoire système ce qui permet de les modifier mais oblige à transférer toutes ces données à chaque fois qu'elles doivent être affichées.

Un VBO est un objet OpenGL qui contient des données relatives à un modèle 3D comme les vertices, les coordonnées de texture, les normales (pour les lumières), ... Sa particularité vient du fait que les données qu'il contient se trouvent non pas dans la RAM mais directement dans la carte graphique.

Les VBO permettent de gagner un temps considérable à OpenGL en évitant de faire des aller-retours inutiles entre la RAM et la mémoire graphique:
[[Fichier:interet_VBO.png]]

[[Fichier:chargement_avec_VBO.png]]

[[Fichier:affichage_avec_VBO.png]]

Images prises sur : http://fr.openclassrooms.com/informatique/cours/developpez-vos-applications-3d-avec-opengl-3-3/c-est-quoi-un-vbo

On économise ainsi le transfert de centaines de milliers de données à chaque affichage, la carte graphique peut travailler plus rapidement.

Nous avons aussi trouvé durant cette semaine ce site qui explique très bien la théorie de l'intersection rayon/triangle avec une traduction en code.

http://www.scratchapixel.com/lessons/3d-basic-lessons/lesson-9-ray-triangle-intersection/ray-triangle-intersection-geometric-solution/

Nous avons grâce à ceci pu coder une méthode adaptée pour tester les triangles de la surface du foie et voir s'ils sont en intersection avec le rayon partant du barycentre de la tumeur et ayant pour vecteur directeur X, Y, ou Z. Une fois le bon triangle trouvé, la fonction se charge de renvoyer le point d'intersection, et il ne reste qu'a récupérer sa coordonnée en X,Y,ou Z (suivant le vecteur directeur précisé dans l'appel à la fonction) qui se trouve être la distance entre la tumeur et la surface du foie. Pour affiner un peu notre méthode, il faut d'abord l'appliquer à l'enveloppe de la tumeur elle même, puis faire de même avec la surface du foie, et soustraire les coordonnées obtenues pour les points d'intersections dans chacune des 3 direction afin d'obtenir une distance correcte pour chaque direction.

== Semaine 51 ==
Rédaction du rapport d'avancement

Rédaction de la présentation oral

= Conclusion Première partie =

Ce premier semestre à travailler sur ce projet a été des plus instructifs pour nous,
nous permettant de mieux concevoir la charge de travail que représentait celuici,
de
réaliser la chance qu’il nous était donnée de pouvoir apporter notre contribution dans le
domaine concret et important qu’est la médecine. Cela nous aura aussi permis de nous
cultiver sur les méthodes utilisées aujourd’hui en chirurgie, ainsi que de découvrir OpenGL
et la modélisation dans l’espace.
Les bases de l’application sont bien en place et le cahier des charges bien défini. Il
reste donc pour la seconde moitié de l’année à finaliser la modélisation des structures
ainsi que l’affichage de la distance entre la tumeur et la surface du foie. De plus, nous
devrons rendre l’application dynamique avec la récupération des flux de données en
temps réel par la caméra.

= Deuxième partie =
== Objectifs ==

-Résoudre le problème d'affichage du foie grâce aux VBO

-Finir l'implémentation du calcul de distances

-Réaliser des propositions d'affichage des distances

== Semaine 1 ==
Nous avons créé une classe foie pour représenter ce dernier. De ce fait, notre programme sera plus lisible et ordonné.

== Semaine 2 ==
On arrive enfin à représenter le foie. Pour celà donc, nous avons utilisé les VBO afin d'aboutir à ce résultat.
La prochaine étape est de représenter la tumeur et le foie en même temps.
Nous avons créé une classe tumeur qui s'occupe du chargement et de l'affichage de la tumeur.
Nous arrivons maintenant à afficher le foie et la tumeur en même temps. Cependant, vu que la tumeur se trouve à l'intérieur du foie,
nous allons changer l'affichage du foie de tel sorte que l'on voit que les traits reliant les triangles sans couleur ni texture.
On affiche désormais le foie et la tumeur ensemble avec pour le foie juste des traits pour avoir une meilleure vision de la position de la tumeur.

== Semaine 3 ==
Pour cette semaine, nous sommes arrivés à calculer les distances séparant la tumeur et la surface du foie.

Afin de récupérer la distance séparant la tumeur et le foie, on réalise des tests d’intersection rayon-triangle avec les triangles composant les meshs du foie et de la tumeur. En effet, en réalisant ce test entre un rayon partant du barycentre de la tumeur suivant la direction X,Y ou Z, et les triangles constituant le foie d’une part, et la tumeur d’autre part, on obtient deux distances (toujours selon X, Y, ou Z). La première, distance entre la paroi du foie et le barycentre de la tumeur, la seconde, distance entre la paroi de la tumeur et le barycentre de celle ci. En soustrayant la seconde à la première, on obtient la distance séparant la paroi du foie et la paroi de la tumeur selon un axe prédéfini (X, Y ou Z de notre repère). Il suffit ensuite de réaliser le calcul une fois pour chaque axe.
Ce calcul se réalise en plusieurs étapes mathématiques présentées ci dessous :

::[[Fichier:Raytracing.png]]

Afin de savoir s’il y a intersection entre un rayon et un triangle, il est plus aisé de commencer tout d’abord par vérifier s’il y a intersection entre ce même rayon et le plan contenant le triangle.
Pour cela, on calcule le vecteur normal du plan. Le vecteur normal du plan s’obtient en faisant le produit vectoriel de deux vecteurs non colinéaires du plan. On connaît 3 points du plan (les points constituant le triangle en train d’être testé), que l’on nommera ici v0, v1 et v2. On peut donc calculer le produit vectoriel de v0v1 et v0v2 par exemple, pour obtenir le vecteur normal N(A,B,C). Une fois le vecteur normal obtenu, on réalise le produit scalaire entre N et le rayon. Si le résultat est nul, le plan et le rayon sont parallèles donc il n’y a pas intersection. Sinon on a confirmation que le rayon et le plan entrent en intersection.

Cela permet ensuite, si intersection il y a, de calculer les coordonnées du point d’intersection P entre le rayon et le plan. P est défini de cette façon:

P = O + t * D
:::-O l’origine (ici le barycentre de la tumeur)
:::-D le vecteur directeur du rayon
:::-t la distance entre O et P

L’équation du plan contenant le triangle est celle-ci:

A * x + B * y + C * z + d = 0
:::-A,B et C sont les composantes du vecteur normal au
:::plan N(A,B,C).
:::-(x,y,z) un point du plan.
:::-d la distance de l’origine (du repère) au plan, suivant la direction du vecteur normal au plan.

Grâce aux deux formules précedentes, on en déduit le calcul de t :

t = - ( N . O + d ) / ( N . D)

Une fois t calculé, on peut aisément obtenir les coordonnées de P. On peut maintenant passer au deuxième test à réaliser, qui est le test d’appartenance d’un point à un triangle.

::[[Fichier:Raytracing1.png]]

Le principe de ce test est le suivant:

On calcule les vecteurs partant des points du triangle et allant vers P : v0P, v1P, v2P.

On calcule de même les vecteurs correspondants aux cotés du triangle : v0v1, v1v2, v2v0.

On calcule le produit vectoriel de chacun de ces vecteurs avec les vecteurs contenant P:

u = v0v1 ^ v0P, v = v1v2 ^ v1P, w = v2v0 ^ v2P.

Si P appartient au triangle, les vecteurs u, v et w ainsi calculés seront colinéaires de même sens avec le vecteur normal au triangle N. (voir Figure 11)

On réalise donc les tests suivants: (produit scalaire)

N . u, N . v, N . w

Si le résultat est positif, P est placé à l’intérieur du triangle par rapport au coté testé. (u teste le coté v0v1, v teste v1v2, w teste v2v0)
Si les trois tests sont positifs, cela signifie que P est bien à l’intérieur du triangle.

::[[Fichier:Raytracing2.png]]

Une fois ces tests concluants, on récupère la distance voulue avec le calcul suivant :

Distance = t * D(x,y,z)

Ceci nous donne une distance selon les 3 axes, grâce à une comparaison du vecteur directeur et des vecteurs X, Y, et Z, on récupère uniquement la distance voulue :

Distance = t * D.x ou t * D.y ou t *D.z

Pour le temps restant au projet, nous allons proposer différentes solutions pour l'affichage de ces distances.
De même, nous allons rédiger notre rapport et nous préparer à la soutenance finale.

== Semaine 4 ==

= Conclusion =
Diagramme UML de notre application finale:

[[Fichier:UML.PNG]]

Voici un bref résumé de chacune des classes et de leurs fonctions :

La classe Camera.cpp s’occupe de gérer tous les placements et les orientations que la caméra va prendre.

La classe Input.cpp s’occupe de gérer tous les évènements clavier et souris, les rendant plus simples d’utilisation.

La classe Shader.cpp permet de charger et de compiler le shader en charge de l’affichage de couleurs sur notre représentation.

La classe principale: SceneOpenGL.cpp qui met en relation les différentes classes, permet la création de la scène, et dans laquelle nous avons codé les différentes fonctions nécessaires au programme, notamment la fonction de calcul des distances.

La classe Texture.cpp permet de charger des textures à la place des couleurs.

La classe Tumor.cpp permet de récupérer les vertices de la tumeur et de l’afficher.

La classe Liver.cpp permet de récupérer les vertices du foie et de l’afficher.

La classe DistanceDisplay.cpp permet d’afficher les distances séparant la tumeur de la surface du foie suivant les trois axes x, y et z.

Réalité Augmentée pour la chirurgie

2014-02-27T15:08:29Z

Cdelberg : /* Semaine 3 */

Papa Momar MBOUP/ Calvin DELBERGHE

= Présentation =

== Description et Objectif: ==

Notre projet consiste à assister les chirurgiens lors de chirurgies laparoscopiques. La chirurgie laparoscopique est une technique chirurgicale minimalement invasive où le chirurgien réalise une opération de l'abdomen par de petites incisions où sont placés des trocars qui permettent le passage de fins instruments chirurgicaux. Dans le cadre de ce projet, il s’agit de réaliser l’ablation de la(des) tumeur(s) présente(s) dans le foie du patient. La localisation des tumeurs ainsi que de l’ensemble du réseau vasculaire peut etre réalisé grâce à un scanner pré-opératoire et donc reconstruits en 3D. Cependant, ils ne peuvent pas être visualisés par la caméra lors de l’opération chirurgicale.

Ainsi, le chirurgien ne peut en aucun cas connaitre la localisation de la tumeur et ne peut pas se représenter la distance qui la sépare des parois du foie. D’où le but de notre projet: aider les chirurgiens dans ces opérations. Des travaux récents de l'équipe de recherche Shacra ont permis de suivre avec une bonne précision le mouvement de structures internes du foie pendant une opération laparoscopique. Le projet consiste à utiliser ces travaux pour mélanger le flux vidéo fourni par l'endoscope aux informations calculées par la simulation pour fournir aux chirurgiens des informations utiles sur la position des structures internes du foie lors de la manipulation. Différentes pistes pourront être explorées pour ne pas surcharger le flux vidéo tout en fournissant les informations importantes (position, profondeur, distance à la surface du foie...)

== Environnement de travail :==
1 ordinateur

OpenGL 3.3

SDL 2.0

IDE CodeBlocks

= Plan d'action / Gestion de projet =
Dans un premier temps, nous allons commencer à suivre des tutoriaux sur le framework OpenGL. Quand on sera assez avancé, nous débuterons le codage du programme principal. Donc pour le premier semestre, le plan est de mettre en place la base du programme et de bien maîtriser OpenGL pour la suite quand on ajoutera des fonctions plus poussées dans le programme.

= Réalisation =

== Semaine 37 ==
Présentation et Choix du sujet.

== Semaine 38 ==
Rencontre avec les encadrants du projet:
Explication détaillée du sujet ainsi que les attentes du projet.
Réception des premières données pour débuter quelques tests avec OpenGL.
== Semaine 39 ==
Installation d'OpenGL sous Windows avec CodeBlocks.
Début des tutoriaux sur le site du zéro:

http://fr.openclassrooms.com/informatique/cours/developpez-vos-applications-3d-avec-opengl-3-3

== Semaine 40 ==
Poursuite des tutoriaux.

== Semaine 41 ==
Poursuite des tutoriaux.

== Semaine 42 ==
Poursuite des tutoriaux.

== Semaine 43 ==
Poursuite des tutoriaux

== Semaine 44 ==
Poursuite des tutoriaux

== Semaine 45 ==
Poursuite des tutoriaux

== Semaine 46 ==
Poursuite des tutoriaux

== Semaine 47 ==
Fin de la première partie des tutoriaux.

== Semaine 48 ==
Démarrage du code du programme à partir du code réalisé pendant les tutoriels.

== Semaine 49 ==
Ajout de la fonction permettant de récupérer les données des fichiers .obj contenant les vertices, les coordonnées de texture, les vecteurs normaux et les références aux faces (triangles) constituant l'objet 3D.

== Semaine 50 ==
Nous sommes arrivé durant cette semaine à représenter une tumeur correctement en 3D.

Pour représenter un structure en 3D, nous allons utiliser un ensemble de triangle. Chaque triangle est constitué de 3 vertices qui sont ces sommets. Un vertex est tout simplement un point avec trois dimensions : x,y et z. Ainsi, le but est de relier les trois sommets (vertices) formant un triangle et ensuite de relier tous les triangles. Ainsi, nous obtiendront notre structure en 3D.

Cependant, nous rencontrons un problème quand on a un nombre de vertices élevés à représenter (de l'ordre de 20000 vertices). Une des pistes pour la résolution de ce problème est d'utiliser les display list. Cependant, les display List n'existent plus en OpenGL 3.3. Donc le problème reste irrésolu pour l'instant. On va regarder du coté des VBO (Vertex Buffer Object) et VBA(Vertex Buffer Array).

Les "Display List" permettent un stockage des données sur la carte graphique mais ne permettent pas de mettre à jour ces données. Les "VertexArray" conservent les données dans des tampons en mémoire système ce qui permet de les modifier mais oblige à transférer toutes ces données à chaque fois qu'elles doivent être affichées.

Un VBO est un objet OpenGL qui contient des données relatives à un modèle 3D comme les vertices, les coordonnées de texture, les normales (pour les lumières), ... Sa particularité vient du fait que les données qu'il contient se trouvent non pas dans la RAM mais directement dans la carte graphique.

Les VBO permettent de gagner un temps considérable à OpenGL en évitant de faire des aller-retours inutiles entre la RAM et la mémoire graphique:
[[Fichier:interet_VBO.png]]

[[Fichier:chargement_avec_VBO.png]]

[[Fichier:affichage_avec_VBO.png]]

Images prises sur : http://fr.openclassrooms.com/informatique/cours/developpez-vos-applications-3d-avec-opengl-3-3/c-est-quoi-un-vbo

On économise ainsi le transfert de centaines de milliers de données à chaque affichage, la carte graphique peut travailler plus rapidement.

Nous avons aussi trouvé durant cette semaine ce site qui explique très bien la théorie de l'intersection rayon/triangle avec une traduction en code.

http://www.scratchapixel.com/lessons/3d-basic-lessons/lesson-9-ray-triangle-intersection/ray-triangle-intersection-geometric-solution/

Nous avons grâce à ceci pu coder une méthode adaptée pour tester les triangles de la surface du foie et voir s'ils sont en intersection avec le rayon partant du barycentre de la tumeur et ayant pour vecteur directeur X, Y, ou Z. Une fois le bon triangle trouvé, la fonction se charge de renvoyer le point d'intersection, et il ne reste qu'a récupérer sa coordonnée en X,Y,ou Z (suivant le vecteur directeur précisé dans l'appel à la fonction) qui se trouve être la distance entre la tumeur et la surface du foie. Pour affiner un peu notre méthode, il faut d'abord l'appliquer à l'enveloppe de la tumeur elle même, puis faire de même avec la surface du foie, et soustraire les coordonnées obtenues pour les points d'intersections dans chacune des 3 direction afin d'obtenir une distance correcte pour chaque direction.

== Semaine 51 ==
Rédaction du rapport d'avancement

Rédaction de la présentation oral

= Conclusion Première partie =

Ce premier semestre à travailler sur ce projet a été des plus instructifs pour nous,
nous permettant de mieux concevoir la charge de travail que représentait celuici,
de
réaliser la chance qu’il nous était donnée de pouvoir apporter notre contribution dans le
domaine concret et important qu’est la médecine. Cela nous aura aussi permis de nous
cultiver sur les méthodes utilisées aujourd’hui en chirurgie, ainsi que de découvrir OpenGL
et la modélisation dans l’espace.
Les bases de l’application sont bien en place et le cahier des charges bien défini. Il
reste donc pour la seconde moitié de l’année à finaliser la modélisation des structures
ainsi que l’affichage de la distance entre la tumeur et la surface du foie. De plus, nous
devrons rendre l’application dynamique avec la récupération des flux de données en
temps réel par la caméra.

= Deuxième partie =
== Objectifs ==

-Résoudre le problème d'affichage du foie grâce aux VBO

-Finir l'implémentation du calcul de distances

-Réaliser des propositions d'affichage des distances

== Semaine 1 ==
Nous avons créé une classe foie pour représenter ce dernier. De ce fait, notre programme sera plus lisible et ordonné.

== Semaine 2 ==
On arrive enfin à représenter le foie. Pour celà donc, nous avons utilisé les VBO afin d'aboutir à ce résultat.
La prochaine étape est de représenter la tumeur et le foie en même temps.
Nous avons créé une classe tumeur qui s'occupe du chargement et de l'affichage de la tumeur.
Nous arrivons maintenant à afficher le foie et la tumeur en même temps. Cependant, vu que la tumeur se trouve à l'intérieur du foie,
nous allons changer l'affichage du foie de tel sorte que l'on voit que les traits reliant les triangles sans couleur ni texture.
On affiche désormais le foie et la tumeur ensemble avec pour le foie juste des traits pour avoir une meilleure vision de la position de la tumeur.

== Semaine 3 ==
Pour cette semaine, nous sommes arrivés à calculer les distances séparant la tumeur et la surface du foie.

Afin de récupérer la distance séparant la tumeur et le foie, on réalise des tests d’intersection rayon-triangle avec les triangles composant les meshs du foie et de la tumeur. En effet, en réalisant ce test entre un rayon partant du barycentre de la tumeur suivant la direction X,Y ou Z, et les triangles constituant le foie d’une part, et la tumeur d’autre part, on obtient deux distances (toujours selon X, Y, ou Z). La première, distance entre la paroi du foie et le barycentre de la tumeur, la seconde, distance entre la paroi de la tumeur et le barycentre de celle ci. En soustrayant la seconde à la première, on obtient la distance séparant la paroi du foie et la paroi de la tumeur selon un axe prédéfini (X, Y ou Z de notre repère). Il suffit ensuite de réaliser le calcul une fois pour chaque axe.
Ce calcul se réalise en plusieurs étapes mathématiques présentées ci dessous :

Image rayon [[Fichier:Raytracing.png]]

Afin de savoir s’il y a intersection entre un rayon et un triangle, il est plus aisé de commencer tout d’abord par vérifier s’il y a intersection entre ce même rayon et le plan contenant le triangle.
Pour cela, on calcule le vecteur normal du plan. Le vecteur normal du plan s’obtient en faisant le produit vectoriel de deux vecteurs non colinéaires du plan. On connaît 3 points du plan (les points constituant le triangle en train d’être testé), que l’on nommera ici v0, v1 et v2. On peut donc calculer le produit vectoriel de v0v1 et v0v2 par exemple, pour obtenir le vecteur normal N(A,B,C). Une fois le vecteur normal obtenu, on réalise le produit scalaire entre N et le rayon. Si le résultat est nul, le plan et le rayon sont parallèles donc il n’y a pas intersection. Sinon on a confirmation que le rayon et le plan entrent en intersection.

Cela permet ensuite, si intersection il y a, de calculer les coordonnées du point d’intersection P entre le rayon et le plan. P est défini de cette façon:

P = O + t * D
:::-O l’origine (ici le barycentre de la tumeur)
:::-D le vecteur directeur du rayon
:::-t la distance entre O et P

L’équation du plan contenant le triangle est celle-ci:

A * x + B * y + C * z + d = 0
:::-A,B et C sont les composantes du vecteur normal au
:::plan N(A,B,C).
:::-(x,y,z) un point du plan.
:::-d la distance de l’origine (du repère) au plan, suivant la direction du vecteur normal au plan.

Grâce aux deux formules précedentes, on en déduit le calcul de t :

t = - ( N . O + d ) / ( N . D)

Une fois t calculé, on peut aisément obtenir les coordonnées de P. On peut maintenant passer au deuxième test à réaliser, qui est le test d’appartenance d’un point à un triangle.

[[Fichier:Raytracing1.png]]

Le principe de ce test est le suivant:

On calcule les vecteurs partant des points du triangle et allant vers P : v0P, v1P, v2P.

On calcule de même les vecteurs correspondants aux cotés du triangle : v0v1, v1v2, v2v0.

On calcule le produit vectoriel de chacun de ces vecteurs avec les vecteurs contenant P:

u = v0v1 ^ v0P, v = v1v2 ^ v1P, w = v2v0 ^ v2P.

Si P appartient au triangle, les vecteurs u, v et w ainsi calculés seront colinéaires de même sens avec le vecteur normal au triangle N. (voir Figure 11)

On réalise donc les tests suivants: (produit scalaire)

N . u, N . v, N . w

Si le résultat est positif, P est placé à l’intérieur du triangle par rapport au coté testé. (u teste le coté v0v1, v teste v1v2, w teste v2v0)
Si les trois tests sont positifs, cela signifie que P est bien à l’intérieur du triangle.

[[Fichier:Raytracing2.png]]

Une fois ces tests concluants, on récupère la distance voulue avec le calcul suivant :

Distance = t * D(x,y,z)

Ceci nous donne une distance selon les 3 axes, grâce à une comparaison du vecteur directeur et des vecteurs X, Y, et Z, on récupère uniquement la distance voulue :

Distance = t * D.x ou t * D.y ou t *D.z

Pour le temps restant au projet, nous allons proposer différentes solutions pour l'affichage de ces distances.
De même, nous allons rédiger notre rapport et nous préparer à la soutenance finale.

== Semaine 4 ==

= Conclusion =
Diagramme UML de notre application finale:

[[Fichier:UML.PNG]]

Voici un bref résumé de chacune des classes et de leurs fonctions :

La classe Camera.cpp s’occupe de gérer tous les placements et les orientations que la caméra va prendre.

La classe Input.cpp s’occupe de gérer tous les évènements clavier et souris, les rendant plus simples d’utilisation.

La classe Shader.cpp permet de charger et de compiler le shader en charge de l’affichage de couleurs sur notre représentation.

La classe principale: SceneOpenGL.cpp qui met en relation les différentes classes, permet la création de la scène, et dans laquelle nous avons codé les différentes fonctions nécessaires au programme, notamment la fonction de calcul des distances.

La classe Texture.cpp permet de charger des textures à la place des couleurs.

La classe Tumor.cpp permet de récupérer les vertices de la tumeur et de l’afficher.

La classe Liver.cpp permet de récupérer les vertices du foie et de l’afficher.

La classe DistanceDisplay.cpp permet d’afficher les distances séparant la tumeur de la surface du foie suivant les trois axes x, y et z.

Réalité Augmentée pour la chirurgie

2014-02-27T15:07:34Z

Cdelberg : /* Semaine 3 */

Papa Momar MBOUP/ Calvin DELBERGHE

= Présentation =

== Description et Objectif: ==

Notre projet consiste à assister les chirurgiens lors de chirurgies laparoscopiques. La chirurgie laparoscopique est une technique chirurgicale minimalement invasive où le chirurgien réalise une opération de l'abdomen par de petites incisions où sont placés des trocars qui permettent le passage de fins instruments chirurgicaux. Dans le cadre de ce projet, il s’agit de réaliser l’ablation de la(des) tumeur(s) présente(s) dans le foie du patient. La localisation des tumeurs ainsi que de l’ensemble du réseau vasculaire peut etre réalisé grâce à un scanner pré-opératoire et donc reconstruits en 3D. Cependant, ils ne peuvent pas être visualisés par la caméra lors de l’opération chirurgicale.

Ainsi, le chirurgien ne peut en aucun cas connaitre la localisation de la tumeur et ne peut pas se représenter la distance qui la sépare des parois du foie. D’où le but de notre projet: aider les chirurgiens dans ces opérations. Des travaux récents de l'équipe de recherche Shacra ont permis de suivre avec une bonne précision le mouvement de structures internes du foie pendant une opération laparoscopique. Le projet consiste à utiliser ces travaux pour mélanger le flux vidéo fourni par l'endoscope aux informations calculées par la simulation pour fournir aux chirurgiens des informations utiles sur la position des structures internes du foie lors de la manipulation. Différentes pistes pourront être explorées pour ne pas surcharger le flux vidéo tout en fournissant les informations importantes (position, profondeur, distance à la surface du foie...)

== Environnement de travail :==
1 ordinateur

OpenGL 3.3

SDL 2.0

IDE CodeBlocks

= Plan d'action / Gestion de projet =
Dans un premier temps, nous allons commencer à suivre des tutoriaux sur le framework OpenGL. Quand on sera assez avancé, nous débuterons le codage du programme principal. Donc pour le premier semestre, le plan est de mettre en place la base du programme et de bien maîtriser OpenGL pour la suite quand on ajoutera des fonctions plus poussées dans le programme.

= Réalisation =

== Semaine 37 ==
Présentation et Choix du sujet.

== Semaine 38 ==
Rencontre avec les encadrants du projet:
Explication détaillée du sujet ainsi que les attentes du projet.
Réception des premières données pour débuter quelques tests avec OpenGL.
== Semaine 39 ==
Installation d'OpenGL sous Windows avec CodeBlocks.
Début des tutoriaux sur le site du zéro:

http://fr.openclassrooms.com/informatique/cours/developpez-vos-applications-3d-avec-opengl-3-3

== Semaine 40 ==
Poursuite des tutoriaux.

== Semaine 41 ==
Poursuite des tutoriaux.

== Semaine 42 ==
Poursuite des tutoriaux.

== Semaine 43 ==
Poursuite des tutoriaux

== Semaine 44 ==
Poursuite des tutoriaux

== Semaine 45 ==
Poursuite des tutoriaux

== Semaine 46 ==
Poursuite des tutoriaux

== Semaine 47 ==
Fin de la première partie des tutoriaux.

== Semaine 48 ==
Démarrage du code du programme à partir du code réalisé pendant les tutoriels.

== Semaine 49 ==
Ajout de la fonction permettant de récupérer les données des fichiers .obj contenant les vertices, les coordonnées de texture, les vecteurs normaux et les références aux faces (triangles) constituant l'objet 3D.

== Semaine 50 ==
Nous sommes arrivé durant cette semaine à représenter une tumeur correctement en 3D.

Pour représenter un structure en 3D, nous allons utiliser un ensemble de triangle. Chaque triangle est constitué de 3 vertices qui sont ces sommets. Un vertex est tout simplement un point avec trois dimensions : x,y et z. Ainsi, le but est de relier les trois sommets (vertices) formant un triangle et ensuite de relier tous les triangles. Ainsi, nous obtiendront notre structure en 3D.

Cependant, nous rencontrons un problème quand on a un nombre de vertices élevés à représenter (de l'ordre de 20000 vertices). Une des pistes pour la résolution de ce problème est d'utiliser les display list. Cependant, les display List n'existent plus en OpenGL 3.3. Donc le problème reste irrésolu pour l'instant. On va regarder du coté des VBO (Vertex Buffer Object) et VBA(Vertex Buffer Array).

Les "Display List" permettent un stockage des données sur la carte graphique mais ne permettent pas de mettre à jour ces données. Les "VertexArray" conservent les données dans des tampons en mémoire système ce qui permet de les modifier mais oblige à transférer toutes ces données à chaque fois qu'elles doivent être affichées.

Un VBO est un objet OpenGL qui contient des données relatives à un modèle 3D comme les vertices, les coordonnées de texture, les normales (pour les lumières), ... Sa particularité vient du fait que les données qu'il contient se trouvent non pas dans la RAM mais directement dans la carte graphique.

Les VBO permettent de gagner un temps considérable à OpenGL en évitant de faire des aller-retours inutiles entre la RAM et la mémoire graphique:
[[Fichier:interet_VBO.png]]

[[Fichier:chargement_avec_VBO.png]]

[[Fichier:affichage_avec_VBO.png]]

Images prises sur : http://fr.openclassrooms.com/informatique/cours/developpez-vos-applications-3d-avec-opengl-3-3/c-est-quoi-un-vbo

On économise ainsi le transfert de centaines de milliers de données à chaque affichage, la carte graphique peut travailler plus rapidement.

Nous avons aussi trouvé durant cette semaine ce site qui explique très bien la théorie de l'intersection rayon/triangle avec une traduction en code.

http://www.scratchapixel.com/lessons/3d-basic-lessons/lesson-9-ray-triangle-intersection/ray-triangle-intersection-geometric-solution/

Nous avons grâce à ceci pu coder une méthode adaptée pour tester les triangles de la surface du foie et voir s'ils sont en intersection avec le rayon partant du barycentre de la tumeur et ayant pour vecteur directeur X, Y, ou Z. Une fois le bon triangle trouvé, la fonction se charge de renvoyer le point d'intersection, et il ne reste qu'a récupérer sa coordonnée en X,Y,ou Z (suivant le vecteur directeur précisé dans l'appel à la fonction) qui se trouve être la distance entre la tumeur et la surface du foie. Pour affiner un peu notre méthode, il faut d'abord l'appliquer à l'enveloppe de la tumeur elle même, puis faire de même avec la surface du foie, et soustraire les coordonnées obtenues pour les points d'intersections dans chacune des 3 direction afin d'obtenir une distance correcte pour chaque direction.

== Semaine 51 ==
Rédaction du rapport d'avancement

Rédaction de la présentation oral

= Conclusion Première partie =

Ce premier semestre à travailler sur ce projet a été des plus instructifs pour nous,
nous permettant de mieux concevoir la charge de travail que représentait celuici,
de
réaliser la chance qu’il nous était donnée de pouvoir apporter notre contribution dans le
domaine concret et important qu’est la médecine. Cela nous aura aussi permis de nous
cultiver sur les méthodes utilisées aujourd’hui en chirurgie, ainsi que de découvrir OpenGL
et la modélisation dans l’espace.
Les bases de l’application sont bien en place et le cahier des charges bien défini. Il
reste donc pour la seconde moitié de l’année à finaliser la modélisation des structures
ainsi que l’affichage de la distance entre la tumeur et la surface du foie. De plus, nous
devrons rendre l’application dynamique avec la récupération des flux de données en
temps réel par la caméra.

= Deuxième partie =
== Objectifs ==

-Résoudre le problème d'affichage du foie grâce aux VBO

-Finir l'implémentation du calcul de distances

-Réaliser des propositions d'affichage des distances

== Semaine 1 ==
Nous avons créé une classe foie pour représenter ce dernier. De ce fait, notre programme sera plus lisible et ordonné.

== Semaine 2 ==
On arrive enfin à représenter le foie. Pour celà donc, nous avons utilisé les VBO afin d'aboutir à ce résultat.
La prochaine étape est de représenter la tumeur et le foie en même temps.
Nous avons créé une classe tumeur qui s'occupe du chargement et de l'affichage de la tumeur.
Nous arrivons maintenant à afficher le foie et la tumeur en même temps. Cependant, vu que la tumeur se trouve à l'intérieur du foie,
nous allons changer l'affichage du foie de tel sorte que l'on voit que les traits reliant les triangles sans couleur ni texture.
On affiche désormais le foie et la tumeur ensemble avec pour le foie juste des traits pour avoir une meilleure vision de la position de la tumeur.

== Semaine 3 ==
Pour cette semaine, nous sommes arrivés à calculer les distances séparant la tumeur et la surface du foie.

Afin de récupérer la distance séparant la tumeur et le foie, on réalise des tests d’intersection rayon-triangle avec les triangles composant les meshs du foie et de la tumeur. En effet, en réalisant ce test entre un rayon partant du barycentre de la tumeur suivant la direction X,Y ou Z, et les triangles constituant le foie d’une part, et la tumeur d’autre part, on obtient deux distances (toujours selon X, Y, ou Z). La première, distance entre la paroi du foie et le barycentre de la tumeur, la seconde, distance entre la paroi de la tumeur et le barycentre de celle ci. En soustrayant la seconde à la première, on obtient la distance séparant la paroi du foie et la paroi de la tumeur selon un axe prédéfini (X, Y ou Z de notre repère). Il suffit ensuite de réaliser le calcul une fois pour chaque axe.
Ce calcul se réalise en plusieurs étapes mathématiques présentées ci dessous :

Image rayon [[Fichier:Raytracing.png]]

Afin de savoir s’il y a intersection entre un rayon et un triangle, il est plus aisé de commencer tout d’abord par vérifier s’il y a intersection entre ce même rayon et le plan contenant le triangle.
Pour cela, on calcule le vecteur normal du plan. Le vecteur normal du plan s’obtient en faisant le produit vectoriel de deux vecteurs non colinéaires du plan. On connaît 3 points du plan (les points constituant le triangle en train d’être testé), que l’on nommera ici v0, v1 et v2. On peut donc calculer le produit vectoriel de v0v1 et v0v2 par exemple, pour obtenir le vecteur normal N(A,B,C). Une fois le vecteur normal obtenu, on réalise le produit scalaire entre N et le rayon. Si le résultat est nul, le plan et le rayon sont parallèles donc il n’y a pas intersection. Sinon on a confirmation que le rayon et le plan entrent en intersection.

Cela permet ensuite, si intersection il y a, de calculer les coordonnées du point d’intersection P entre le rayon et le plan. P est défini de cette façon:

P = O + t * D
:::-O l’origine (ici le barycentre de la tumeur)
:::-D le vecteur directeur du rayon
:::-t la distance entre O et P

L’équation du plan contenant le triangle est celle-ci:

A * x + B * y + C * z + d = 0
:::-A,B et C sont les composantes du vecteur normal au
:::plan N(A,B,C).
:::-(x,y,z) un point du plan.
:::-d la distance de l’origine (du repère) au plan, suivant la direction du vecteur normal au plan.

Grâce aux deux formules précedentes, on en déduit le calcul de t :

t = - ( N . O + d ) / ( N . D)

Une fois t calculé, on peut aisément obtenir les coordonnées de P. On peut maintenant passer au deuxième test à réaliser, qui est le test d’appartenance d’un point à un triangle.

[[Fichier:Raytracing1.png]]

Le principe de ce test est le suivant:
On calcule les vecteurs partant des points du triangle et allant vers P : v0P, v1P, v2P.
On calcule de même les vecteurs correspondants aux cotés du triangle : v0v1, v1v2, v2v0.
On calcule le produit vectoriel de chacun de ces vecteurs avec les vecteurs contenant P:
u = v0v1 ^ v0P, v = v1v2 ^ v1P, w = v2v0 ^ v2P.
Si P appartient au triangle, les vecteurs u, v et w ainsi calculés seront colinéaires de même sens avec le vecteur normal au triangle N. (voir Figure 11)

On réalise donc les tests suivants: (produit scalaire)
N . u, N . v, N . w

Si le résultat est positif, P est placé à l’intérieur du triangle par rapport au coté testé. (u teste le coté v0v1, v teste v1v2, w teste v2v0)
Si les trois tests sont positifs, cela signifie que P est bien à l’intérieur du triangle.

[[Fichier:Raytracing2.png]]

Une fois ces tests concluants, on récupère la distance voulue avec le calcul suivant :
Distance = t * D(x,y,z)
Ceci nous donne une distance selon les 3 axes, grâce à une comparaison du vecteur directeur et des vecteurs X, Y, et Z, on récupère uniquement la distance voulue :
Distance = t * D.x ou t * D.y ou t *D.z

Pour le temps restant au projet, nous allons proposer différentes solutions pour l'affichage de ces distances.
De même, nous allons rédiger notre rapport et nous préparer à la soutenance finale.

== Semaine 4 ==

= Conclusion =
Diagramme UML de notre application finale:

[[Fichier:UML.PNG]]

Voici un bref résumé de chacune des classes et de leurs fonctions :

La classe Camera.cpp s’occupe de gérer tous les placements et les orientations que la caméra va prendre.

La classe Input.cpp s’occupe de gérer tous les évènements clavier et souris, les rendant plus simples d’utilisation.

La classe Shader.cpp permet de charger et de compiler le shader en charge de l’affichage de couleurs sur notre représentation.

La classe principale: SceneOpenGL.cpp qui met en relation les différentes classes, permet la création de la scène, et dans laquelle nous avons codé les différentes fonctions nécessaires au programme, notamment la fonction de calcul des distances.

La classe Texture.cpp permet de charger des textures à la place des couleurs.

La classe Tumor.cpp permet de récupérer les vertices de la tumeur et de l’afficher.

La classe Liver.cpp permet de récupérer les vertices du foie et de l’afficher.

La classe DistanceDisplay.cpp permet d’afficher les distances séparant la tumeur de la surface du foie suivant les trois axes x, y et z.

Réalité Augmentée pour la chirurgie

2014-02-27T15:01:59Z

Cdelberg : /* Objectifs */

Papa Momar MBOUP/ Calvin DELBERGHE

= Présentation =

== Description et Objectif: ==

Notre projet consiste à assister les chirurgiens lors de chirurgies laparoscopiques. La chirurgie laparoscopique est une technique chirurgicale minimalement invasive où le chirurgien réalise une opération de l'abdomen par de petites incisions où sont placés des trocars qui permettent le passage de fins instruments chirurgicaux. Dans le cadre de ce projet, il s’agit de réaliser l’ablation de la(des) tumeur(s) présente(s) dans le foie du patient. La localisation des tumeurs ainsi que de l’ensemble du réseau vasculaire peut etre réalisé grâce à un scanner pré-opératoire et donc reconstruits en 3D. Cependant, ils ne peuvent pas être visualisés par la caméra lors de l’opération chirurgicale.

Ainsi, le chirurgien ne peut en aucun cas connaitre la localisation de la tumeur et ne peut pas se représenter la distance qui la sépare des parois du foie. D’où le but de notre projet: aider les chirurgiens dans ces opérations. Des travaux récents de l'équipe de recherche Shacra ont permis de suivre avec une bonne précision le mouvement de structures internes du foie pendant une opération laparoscopique. Le projet consiste à utiliser ces travaux pour mélanger le flux vidéo fourni par l'endoscope aux informations calculées par la simulation pour fournir aux chirurgiens des informations utiles sur la position des structures internes du foie lors de la manipulation. Différentes pistes pourront être explorées pour ne pas surcharger le flux vidéo tout en fournissant les informations importantes (position, profondeur, distance à la surface du foie...)

== Environnement de travail :==
1 ordinateur

OpenGL 3.3

SDL 2.0

IDE CodeBlocks

= Plan d'action / Gestion de projet =
Dans un premier temps, nous allons commencer à suivre des tutoriaux sur le framework OpenGL. Quand on sera assez avancé, nous débuterons le codage du programme principal. Donc pour le premier semestre, le plan est de mettre en place la base du programme et de bien maîtriser OpenGL pour la suite quand on ajoutera des fonctions plus poussées dans le programme.

= Réalisation =

== Semaine 37 ==
Présentation et Choix du sujet.

== Semaine 38 ==
Rencontre avec les encadrants du projet:
Explication détaillée du sujet ainsi que les attentes du projet.
Réception des premières données pour débuter quelques tests avec OpenGL.
== Semaine 39 ==
Installation d'OpenGL sous Windows avec CodeBlocks.
Début des tutoriaux sur le site du zéro:

http://fr.openclassrooms.com/informatique/cours/developpez-vos-applications-3d-avec-opengl-3-3

== Semaine 40 ==
Poursuite des tutoriaux.

== Semaine 41 ==
Poursuite des tutoriaux.

== Semaine 42 ==
Poursuite des tutoriaux.

== Semaine 43 ==
Poursuite des tutoriaux

== Semaine 44 ==
Poursuite des tutoriaux

== Semaine 45 ==
Poursuite des tutoriaux

== Semaine 46 ==
Poursuite des tutoriaux

== Semaine 47 ==
Fin de la première partie des tutoriaux.

== Semaine 48 ==
Démarrage du code du programme à partir du code réalisé pendant les tutoriels.

== Semaine 49 ==
Ajout de la fonction permettant de récupérer les données des fichiers .obj contenant les vertices, les coordonnées de texture, les vecteurs normaux et les références aux faces (triangles) constituant l'objet 3D.

== Semaine 50 ==
Nous sommes arrivé durant cette semaine à représenter une tumeur correctement en 3D.

Pour représenter un structure en 3D, nous allons utiliser un ensemble de triangle. Chaque triangle est constitué de 3 vertices qui sont ces sommets. Un vertex est tout simplement un point avec trois dimensions : x,y et z. Ainsi, le but est de relier les trois sommets (vertices) formant un triangle et ensuite de relier tous les triangles. Ainsi, nous obtiendront notre structure en 3D.

Cependant, nous rencontrons un problème quand on a un nombre de vertices élevés à représenter (de l'ordre de 20000 vertices). Une des pistes pour la résolution de ce problème est d'utiliser les display list. Cependant, les display List n'existent plus en OpenGL 3.3. Donc le problème reste irrésolu pour l'instant. On va regarder du coté des VBO (Vertex Buffer Object) et VBA(Vertex Buffer Array).

Les "Display List" permettent un stockage des données sur la carte graphique mais ne permettent pas de mettre à jour ces données. Les "VertexArray" conservent les données dans des tampons en mémoire système ce qui permet de les modifier mais oblige à transférer toutes ces données à chaque fois qu'elles doivent être affichées.

Un VBO est un objet OpenGL qui contient des données relatives à un modèle 3D comme les vertices, les coordonnées de texture, les normales (pour les lumières), ... Sa particularité vient du fait que les données qu'il contient se trouvent non pas dans la RAM mais directement dans la carte graphique.

Les VBO permettent de gagner un temps considérable à OpenGL en évitant de faire des aller-retours inutiles entre la RAM et la mémoire graphique:
[[Fichier:interet_VBO.png]]

[[Fichier:chargement_avec_VBO.png]]

[[Fichier:affichage_avec_VBO.png]]

Images prises sur : http://fr.openclassrooms.com/informatique/cours/developpez-vos-applications-3d-avec-opengl-3-3/c-est-quoi-un-vbo

On économise ainsi le transfert de centaines de milliers de données à chaque affichage, la carte graphique peut travailler plus rapidement.

Nous avons aussi trouvé durant cette semaine ce site qui explique très bien la théorie de l'intersection rayon/triangle avec une traduction en code.

http://www.scratchapixel.com/lessons/3d-basic-lessons/lesson-9-ray-triangle-intersection/ray-triangle-intersection-geometric-solution/

Nous avons grâce à ceci pu coder une méthode adaptée pour tester les triangles de la surface du foie et voir s'ils sont en intersection avec le rayon partant du barycentre de la tumeur et ayant pour vecteur directeur X, Y, ou Z. Une fois le bon triangle trouvé, la fonction se charge de renvoyer le point d'intersection, et il ne reste qu'a récupérer sa coordonnée en X,Y,ou Z (suivant le vecteur directeur précisé dans l'appel à la fonction) qui se trouve être la distance entre la tumeur et la surface du foie. Pour affiner un peu notre méthode, il faut d'abord l'appliquer à l'enveloppe de la tumeur elle même, puis faire de même avec la surface du foie, et soustraire les coordonnées obtenues pour les points d'intersections dans chacune des 3 direction afin d'obtenir une distance correcte pour chaque direction.

== Semaine 51 ==
Rédaction du rapport d'avancement

Rédaction de la présentation oral

= Conclusion Première partie =

Ce premier semestre à travailler sur ce projet a été des plus instructifs pour nous,
nous permettant de mieux concevoir la charge de travail que représentait celuici,
de
réaliser la chance qu’il nous était donnée de pouvoir apporter notre contribution dans le
domaine concret et important qu’est la médecine. Cela nous aura aussi permis de nous
cultiver sur les méthodes utilisées aujourd’hui en chirurgie, ainsi que de découvrir OpenGL
et la modélisation dans l’espace.
Les bases de l’application sont bien en place et le cahier des charges bien défini. Il
reste donc pour la seconde moitié de l’année à finaliser la modélisation des structures
ainsi que l’affichage de la distance entre la tumeur et la surface du foie. De plus, nous
devrons rendre l’application dynamique avec la récupération des flux de données en
temps réel par la caméra.

= Deuxième partie =
== Objectifs ==

-Résoudre le problème d'affichage du foie grâce aux VBO

-Finir l'implémentation du calcul de distances

-Réaliser des propositions d'affichage des distances

== Semaine 1 ==
Nous avons créé une classe foie pour représenter ce dernier. De ce fait, notre programme sera plus lisible et ordonné.

== Semaine 2 ==
On arrive enfin à représenter le foie. Pour celà donc, nous avons utilisé les VBO afin d'aboutir à ce résultat.
La prochaine étape est de représenter la tumeur et le foie en même temps.
Nous avons créé une classe tumeur qui s'occupe du chargement et de l'affichage de la tumeur.
Nous arrivons maintenant à afficher le foie et la tumeur en même temps. Cependant, vu que la tumeur se trouve à l'intérieur du foie,
nous allons changer l'affichage du foie de tel sorte que l'on voit que les traits reliant les triangles sans couleur ni texture.
On affiche désormais le foie et la tumeur ensemble avec pour le foie juste des traits pour avoir une meilleure vision de la position de la tumeur.

== Semaine 3 ==
Pour cette semaine, nous sommes arrivés à calculer les distances séparant la tumeur et la surface du foie.

Afin de récupérer la distance séparant la tumeur et le foie, on réalise des tests d’intersection rayon-triangle avec les triangles composant les meshs du foie et de la tumeur. En effet, en réalisant ce test entre un rayon partant du barycentre de la tumeur suivant la direction X,Y ou Z, et les triangles constituant le foie d’une part, et la tumeur d’autre part, on obtient deux distances (toujours selon X, Y, ou Z). La première, distance entre la paroi du foie et le barycentre de la tumeur, la seconde, distance entre la paroi de la tumeur et le barycentre de celle ci. En soustrayant la seconde à la première, on obtient la distance séparant la paroi du foie et la paroi de la tumeur selon un axe prédéfini (X, Y ou Z de notre repère). Il suffit ensuite de réaliser le calcul une fois pour chaque axe.
Ce calcul se réalise en plusieurs étapes mathématiques présentées ci dessous :

Image rayon [[Fichier:Raytracing.png]]

Afin de savoir s’il y a intersection entre un rayon et un triangle, il est plus aisé de commencer tout d’abord par vérifier s’il y a intersection entre ce même rayon et le plan contenant le triangle.
Pour cela, on calcule le vecteur normal du plan. Le vecteur normal du plan s’obtient en faisant le produit vectoriel de deux vecteurs non colinéaires du plan. On connaît 3 points du plan (les points constituant le triangle en train d’être testé), que l’on nommera ici v0, v1 et v2. On peut donc calculer le produit vectoriel de v0v1 et v0v2 par exemple, pour obtenir le vecteur normal N(A,B,C). Une fois le vecteur normal obtenu, on réalise le produit scalaire entre N et le rayon. Si le résultat est nul, le plan et le rayon sont parallèles donc il n’y a pas intersection. Sinon on a confirmation que le rayon et le plan entrent en intersection.
Cela permet ensuite, si intersection il y a, de calculer les coordonnées du point d’intersection P entre le rayon et le plan. P est défini de cette façon:
P = O + t * D -O l’origine (ici le barycentre de la tumeur)
-D le vecteur directeur du rayon
-t la distance entre O et P

L’équation du plan contenant le triangle est celle-ci:
A * x + B * y + C * z + d = 0 -A,B et C sont les composantes du vecteur normal au
plan N(A,B,C).
-(x,y,z) un point du plan.
-d la distance de l’origine (du repère) au plan, suivant la direction du vecteur normal au plan.

Grâce aux deux formules précedentes, on en déduit le calcul de t :
t = - ( N . O + d ) / ( N . D)

Une fois t calculé, on peut aisément obtenir les coordonnées de P. On peut maintenant passer au deuxième test à réaliser, qui est le test d’appartenance d’un point à un triangle.

[[Fichier:Raytracing1.png]]

Le principe de ce test est le suivant:
On calcule les vecteurs partant des points du triangle et allant vers P : v0P, v1P, v2P.
On calcule de même les vecteurs correspondants aux cotés du triangle : v0v1, v1v2, v2v0.
On calcule le produit vectoriel de chacun de ces vecteurs avec les vecteurs contenant P:
u = v0v1 ^ v0P, v = v1v2 ^ v1P, w = v2v0 ^ v2P.
Si P appartient au triangle, les vecteurs u, v et w ainsi calculés seront colinéaires de même sens avec le vecteur normal au triangle N. (voir Figure 11)

On réalise donc les tests suivants: (produit scalaire)
N . u, N . v, N . w

Si le résultat est positif, P est placé à l’intérieur du triangle par rapport au coté testé. (u teste le coté v0v1, v teste v1v2, w teste v2v0)
Si les trois tests sont positifs, cela signifie que P est bien à l’intérieur du triangle.

[[Fichier:Raytracing2.png]]

Une fois ces tests concluants, on récupère la distance voulue avec le calcul suivant :
Distance = t * D(x,y,z)
Ceci nous donne une distance selon les 3 axes, grâce à une comparaison du vecteur directeur et des vecteurs X, Y, et Z, on récupère uniquement la distance voulue :
Distance = t * D.x ou t * D.y ou t *D.z

Pour le temps restant au projet, nous allons proposer différentes solutions pour l'affichage de ces distances.
De même, nous allons rédiger notre rapport et nous préparer à la soutenance finale.

== Semaine 4 ==

= Conclusion =
Diagramme UML de notre application finale:

[[Fichier:UML.PNG]]

Voici un bref résumé de chacune des classes et de leurs fonctions :

La classe Camera.cpp s’occupe de gérer tous les placements et les orientations que la caméra va prendre.

La classe Input.cpp s’occupe de gérer tous les évènements clavier et souris, les rendant plus simples d’utilisation.

La classe Shader.cpp permet de charger et de compiler le shader en charge de l’affichage de couleurs sur notre représentation.

La classe principale: SceneOpenGL.cpp qui met en relation les différentes classes, permet la création de la scène, et dans laquelle nous avons codé les différentes fonctions nécessaires au programme, notamment la fonction de calcul des distances.

La classe Texture.cpp permet de charger des textures à la place des couleurs.

La classe Tumor.cpp permet de récupérer les vertices de la tumeur et de l’afficher.

La classe Liver.cpp permet de récupérer les vertices du foie et de l’afficher.

La classe DistanceDisplay.cpp permet d’afficher les distances séparant la tumeur de la surface du foie suivant les trois axes x, y et z.

Réalité Augmentée pour la chirurgie

2014-02-27T15:01:24Z

Cdelberg : /* Conclusion */

Papa Momar MBOUP/ Calvin DELBERGHE

= Présentation =

== Description et Objectif: ==

Notre projet consiste à assister les chirurgiens lors de chirurgies laparoscopiques. La chirurgie laparoscopique est une technique chirurgicale minimalement invasive où le chirurgien réalise une opération de l'abdomen par de petites incisions où sont placés des trocars qui permettent le passage de fins instruments chirurgicaux. Dans le cadre de ce projet, il s’agit de réaliser l’ablation de la(des) tumeur(s) présente(s) dans le foie du patient. La localisation des tumeurs ainsi que de l’ensemble du réseau vasculaire peut etre réalisé grâce à un scanner pré-opératoire et donc reconstruits en 3D. Cependant, ils ne peuvent pas être visualisés par la caméra lors de l’opération chirurgicale.

Ainsi, le chirurgien ne peut en aucun cas connaitre la localisation de la tumeur et ne peut pas se représenter la distance qui la sépare des parois du foie. D’où le but de notre projet: aider les chirurgiens dans ces opérations. Des travaux récents de l'équipe de recherche Shacra ont permis de suivre avec une bonne précision le mouvement de structures internes du foie pendant une opération laparoscopique. Le projet consiste à utiliser ces travaux pour mélanger le flux vidéo fourni par l'endoscope aux informations calculées par la simulation pour fournir aux chirurgiens des informations utiles sur la position des structures internes du foie lors de la manipulation. Différentes pistes pourront être explorées pour ne pas surcharger le flux vidéo tout en fournissant les informations importantes (position, profondeur, distance à la surface du foie...)

== Environnement de travail :==
1 ordinateur

OpenGL 3.3

SDL 2.0

IDE CodeBlocks

= Plan d'action / Gestion de projet =
Dans un premier temps, nous allons commencer à suivre des tutoriaux sur le framework OpenGL. Quand on sera assez avancé, nous débuterons le codage du programme principal. Donc pour le premier semestre, le plan est de mettre en place la base du programme et de bien maîtriser OpenGL pour la suite quand on ajoutera des fonctions plus poussées dans le programme.

= Réalisation =

== Semaine 37 ==
Présentation et Choix du sujet.

== Semaine 38 ==
Rencontre avec les encadrants du projet:
Explication détaillée du sujet ainsi que les attentes du projet.
Réception des premières données pour débuter quelques tests avec OpenGL.
== Semaine 39 ==
Installation d'OpenGL sous Windows avec CodeBlocks.
Début des tutoriaux sur le site du zéro:

http://fr.openclassrooms.com/informatique/cours/developpez-vos-applications-3d-avec-opengl-3-3

== Semaine 40 ==
Poursuite des tutoriaux.

== Semaine 41 ==
Poursuite des tutoriaux.

== Semaine 42 ==
Poursuite des tutoriaux.

== Semaine 43 ==
Poursuite des tutoriaux

== Semaine 44 ==
Poursuite des tutoriaux

== Semaine 45 ==
Poursuite des tutoriaux

== Semaine 46 ==
Poursuite des tutoriaux

== Semaine 47 ==
Fin de la première partie des tutoriaux.

== Semaine 48 ==
Démarrage du code du programme à partir du code réalisé pendant les tutoriels.

== Semaine 49 ==
Ajout de la fonction permettant de récupérer les données des fichiers .obj contenant les vertices, les coordonnées de texture, les vecteurs normaux et les références aux faces (triangles) constituant l'objet 3D.

== Semaine 50 ==
Nous sommes arrivé durant cette semaine à représenter une tumeur correctement en 3D.

Pour représenter un structure en 3D, nous allons utiliser un ensemble de triangle. Chaque triangle est constitué de 3 vertices qui sont ces sommets. Un vertex est tout simplement un point avec trois dimensions : x,y et z. Ainsi, le but est de relier les trois sommets (vertices) formant un triangle et ensuite de relier tous les triangles. Ainsi, nous obtiendront notre structure en 3D.

Cependant, nous rencontrons un problème quand on a un nombre de vertices élevés à représenter (de l'ordre de 20000 vertices). Une des pistes pour la résolution de ce problème est d'utiliser les display list. Cependant, les display List n'existent plus en OpenGL 3.3. Donc le problème reste irrésolu pour l'instant. On va regarder du coté des VBO (Vertex Buffer Object) et VBA(Vertex Buffer Array).

Les "Display List" permettent un stockage des données sur la carte graphique mais ne permettent pas de mettre à jour ces données. Les "VertexArray" conservent les données dans des tampons en mémoire système ce qui permet de les modifier mais oblige à transférer toutes ces données à chaque fois qu'elles doivent être affichées.

Un VBO est un objet OpenGL qui contient des données relatives à un modèle 3D comme les vertices, les coordonnées de texture, les normales (pour les lumières), ... Sa particularité vient du fait que les données qu'il contient se trouvent non pas dans la RAM mais directement dans la carte graphique.

Les VBO permettent de gagner un temps considérable à OpenGL en évitant de faire des aller-retours inutiles entre la RAM et la mémoire graphique:
[[Fichier:interet_VBO.png]]

[[Fichier:chargement_avec_VBO.png]]

[[Fichier:affichage_avec_VBO.png]]

Images prises sur : http://fr.openclassrooms.com/informatique/cours/developpez-vos-applications-3d-avec-opengl-3-3/c-est-quoi-un-vbo

On économise ainsi le transfert de centaines de milliers de données à chaque affichage, la carte graphique peut travailler plus rapidement.

Nous avons aussi trouvé durant cette semaine ce site qui explique très bien la théorie de l'intersection rayon/triangle avec une traduction en code.

http://www.scratchapixel.com/lessons/3d-basic-lessons/lesson-9-ray-triangle-intersection/ray-triangle-intersection-geometric-solution/

Nous avons grâce à ceci pu coder une méthode adaptée pour tester les triangles de la surface du foie et voir s'ils sont en intersection avec le rayon partant du barycentre de la tumeur et ayant pour vecteur directeur X, Y, ou Z. Une fois le bon triangle trouvé, la fonction se charge de renvoyer le point d'intersection, et il ne reste qu'a récupérer sa coordonnée en X,Y,ou Z (suivant le vecteur directeur précisé dans l'appel à la fonction) qui se trouve être la distance entre la tumeur et la surface du foie. Pour affiner un peu notre méthode, il faut d'abord l'appliquer à l'enveloppe de la tumeur elle même, puis faire de même avec la surface du foie, et soustraire les coordonnées obtenues pour les points d'intersections dans chacune des 3 direction afin d'obtenir une distance correcte pour chaque direction.

== Semaine 51 ==
Rédaction du rapport d'avancement

Rédaction de la présentation oral

= Conclusion Première partie =

Ce premier semestre à travailler sur ce projet a été des plus instructifs pour nous,
nous permettant de mieux concevoir la charge de travail que représentait celuici,
de
réaliser la chance qu’il nous était donnée de pouvoir apporter notre contribution dans le
domaine concret et important qu’est la médecine. Cela nous aura aussi permis de nous
cultiver sur les méthodes utilisées aujourd’hui en chirurgie, ainsi que de découvrir OpenGL
et la modélisation dans l’espace.
Les bases de l’application sont bien en place et le cahier des charges bien défini. Il
reste donc pour la seconde moitié de l’année à finaliser la modélisation des structures
ainsi que l’affichage de la distance entre la tumeur et la surface du foie. De plus, nous
devrons rendre l’application dynamique avec la récupération des flux de données en
temps réel par la caméra.

= Deuxième partie =
== Objectifs ==

-Résoudre le problème d'affichage du foie grâce aux VBO
-Finir l'implémentation du calcul de distances
-Réaliser des propositions d'affichage des distances

== Semaine 1 ==
Nous avons créé une classe foie pour représenter ce dernier. De ce fait, notre programme sera plus lisible et ordonné.

== Semaine 2 ==
On arrive enfin à représenter le foie. Pour celà donc, nous avons utilisé les VBO afin d'aboutir à ce résultat.
La prochaine étape est de représenter la tumeur et le foie en même temps.
Nous avons créé une classe tumeur qui s'occupe du chargement et de l'affichage de la tumeur.
Nous arrivons maintenant à afficher le foie et la tumeur en même temps. Cependant, vu que la tumeur se trouve à l'intérieur du foie,
nous allons changer l'affichage du foie de tel sorte que l'on voit que les traits reliant les triangles sans couleur ni texture.
On affiche désormais le foie et la tumeur ensemble avec pour le foie juste des traits pour avoir une meilleure vision de la position de la tumeur.

== Semaine 3 ==
Pour cette semaine, nous sommes arrivés à calculer les distances séparant la tumeur et la surface du foie.

Afin de récupérer la distance séparant la tumeur et le foie, on réalise des tests d’intersection rayon-triangle avec les triangles composant les meshs du foie et de la tumeur. En effet, en réalisant ce test entre un rayon partant du barycentre de la tumeur suivant la direction X,Y ou Z, et les triangles constituant le foie d’une part, et la tumeur d’autre part, on obtient deux distances (toujours selon X, Y, ou Z). La première, distance entre la paroi du foie et le barycentre de la tumeur, la seconde, distance entre la paroi de la tumeur et le barycentre de celle ci. En soustrayant la seconde à la première, on obtient la distance séparant la paroi du foie et la paroi de la tumeur selon un axe prédéfini (X, Y ou Z de notre repère). Il suffit ensuite de réaliser le calcul une fois pour chaque axe.
Ce calcul se réalise en plusieurs étapes mathématiques présentées ci dessous :

Image rayon [[Fichier:Raytracing.png]]

Afin de savoir s’il y a intersection entre un rayon et un triangle, il est plus aisé de commencer tout d’abord par vérifier s’il y a intersection entre ce même rayon et le plan contenant le triangle.
Pour cela, on calcule le vecteur normal du plan. Le vecteur normal du plan s’obtient en faisant le produit vectoriel de deux vecteurs non colinéaires du plan. On connaît 3 points du plan (les points constituant le triangle en train d’être testé), que l’on nommera ici v0, v1 et v2. On peut donc calculer le produit vectoriel de v0v1 et v0v2 par exemple, pour obtenir le vecteur normal N(A,B,C). Une fois le vecteur normal obtenu, on réalise le produit scalaire entre N et le rayon. Si le résultat est nul, le plan et le rayon sont parallèles donc il n’y a pas intersection. Sinon on a confirmation que le rayon et le plan entrent en intersection.
Cela permet ensuite, si intersection il y a, de calculer les coordonnées du point d’intersection P entre le rayon et le plan. P est défini de cette façon:
P = O + t * D -O l’origine (ici le barycentre de la tumeur)
-D le vecteur directeur du rayon
-t la distance entre O et P

L’équation du plan contenant le triangle est celle-ci:
A * x + B * y + C * z + d = 0 -A,B et C sont les composantes du vecteur normal au
plan N(A,B,C).
-(x,y,z) un point du plan.
-d la distance de l’origine (du repère) au plan, suivant la direction du vecteur normal au plan.

Grâce aux deux formules précedentes, on en déduit le calcul de t :
t = - ( N . O + d ) / ( N . D)

Une fois t calculé, on peut aisément obtenir les coordonnées de P. On peut maintenant passer au deuxième test à réaliser, qui est le test d’appartenance d’un point à un triangle.

[[Fichier:Raytracing1.png]]

Le principe de ce test est le suivant:
On calcule les vecteurs partant des points du triangle et allant vers P : v0P, v1P, v2P.
On calcule de même les vecteurs correspondants aux cotés du triangle : v0v1, v1v2, v2v0.
On calcule le produit vectoriel de chacun de ces vecteurs avec les vecteurs contenant P:
u = v0v1 ^ v0P, v = v1v2 ^ v1P, w = v2v0 ^ v2P.
Si P appartient au triangle, les vecteurs u, v et w ainsi calculés seront colinéaires de même sens avec le vecteur normal au triangle N. (voir Figure 11)

On réalise donc les tests suivants: (produit scalaire)
N . u, N . v, N . w

Si le résultat est positif, P est placé à l’intérieur du triangle par rapport au coté testé. (u teste le coté v0v1, v teste v1v2, w teste v2v0)
Si les trois tests sont positifs, cela signifie que P est bien à l’intérieur du triangle.

[[Fichier:Raytracing2.png]]

Une fois ces tests concluants, on récupère la distance voulue avec le calcul suivant :
Distance = t * D(x,y,z)
Ceci nous donne une distance selon les 3 axes, grâce à une comparaison du vecteur directeur et des vecteurs X, Y, et Z, on récupère uniquement la distance voulue :
Distance = t * D.x ou t * D.y ou t *D.z

Pour le temps restant au projet, nous allons proposer différentes solutions pour l'affichage de ces distances.
De même, nous allons rédiger notre rapport et nous préparer à la soutenance finale.

== Semaine 4 ==

= Conclusion =
Diagramme UML de notre application finale:

[[Fichier:UML.PNG]]

Voici un bref résumé de chacune des classes et de leurs fonctions :

La classe Camera.cpp s’occupe de gérer tous les placements et les orientations que la caméra va prendre.

La classe Input.cpp s’occupe de gérer tous les évènements clavier et souris, les rendant plus simples d’utilisation.

La classe Shader.cpp permet de charger et de compiler le shader en charge de l’affichage de couleurs sur notre représentation.

La classe principale: SceneOpenGL.cpp qui met en relation les différentes classes, permet la création de la scène, et dans laquelle nous avons codé les différentes fonctions nécessaires au programme, notamment la fonction de calcul des distances.

La classe Texture.cpp permet de charger des textures à la place des couleurs.

La classe Tumor.cpp permet de récupérer les vertices de la tumeur et de l’afficher.

La classe Liver.cpp permet de récupérer les vertices du foie et de l’afficher.

La classe DistanceDisplay.cpp permet d’afficher les distances séparant la tumeur de la surface du foie suivant les trois axes x, y et z.

Fichier:UML.PNG

2014-02-27T15:01:04Z

Cdelberg :

Réalité Augmentée pour la chirurgie

2014-02-27T14:59:20Z

Cdelberg : /* Conclusion */

Papa Momar MBOUP/ Calvin DELBERGHE

= Présentation =

== Description et Objectif: ==

Notre projet consiste à assister les chirurgiens lors de chirurgies laparoscopiques. La chirurgie laparoscopique est une technique chirurgicale minimalement invasive où le chirurgien réalise une opération de l'abdomen par de petites incisions où sont placés des trocars qui permettent le passage de fins instruments chirurgicaux. Dans le cadre de ce projet, il s’agit de réaliser l’ablation de la(des) tumeur(s) présente(s) dans le foie du patient. La localisation des tumeurs ainsi que de l’ensemble du réseau vasculaire peut etre réalisé grâce à un scanner pré-opératoire et donc reconstruits en 3D. Cependant, ils ne peuvent pas être visualisés par la caméra lors de l’opération chirurgicale.

Ainsi, le chirurgien ne peut en aucun cas connaitre la localisation de la tumeur et ne peut pas se représenter la distance qui la sépare des parois du foie. D’où le but de notre projet: aider les chirurgiens dans ces opérations. Des travaux récents de l'équipe de recherche Shacra ont permis de suivre avec une bonne précision le mouvement de structures internes du foie pendant une opération laparoscopique. Le projet consiste à utiliser ces travaux pour mélanger le flux vidéo fourni par l'endoscope aux informations calculées par la simulation pour fournir aux chirurgiens des informations utiles sur la position des structures internes du foie lors de la manipulation. Différentes pistes pourront être explorées pour ne pas surcharger le flux vidéo tout en fournissant les informations importantes (position, profondeur, distance à la surface du foie...)

== Environnement de travail :==
1 ordinateur

OpenGL 3.3

SDL 2.0

IDE CodeBlocks

= Plan d'action / Gestion de projet =
Dans un premier temps, nous allons commencer à suivre des tutoriaux sur le framework OpenGL. Quand on sera assez avancé, nous débuterons le codage du programme principal. Donc pour le premier semestre, le plan est de mettre en place la base du programme et de bien maîtriser OpenGL pour la suite quand on ajoutera des fonctions plus poussées dans le programme.

= Réalisation =

== Semaine 37 ==
Présentation et Choix du sujet.

== Semaine 38 ==
Rencontre avec les encadrants du projet:
Explication détaillée du sujet ainsi que les attentes du projet.
Réception des premières données pour débuter quelques tests avec OpenGL.
== Semaine 39 ==
Installation d'OpenGL sous Windows avec CodeBlocks.
Début des tutoriaux sur le site du zéro:

http://fr.openclassrooms.com/informatique/cours/developpez-vos-applications-3d-avec-opengl-3-3

== Semaine 40 ==
Poursuite des tutoriaux.

== Semaine 41 ==
Poursuite des tutoriaux.

== Semaine 42 ==
Poursuite des tutoriaux.

== Semaine 43 ==
Poursuite des tutoriaux

== Semaine 44 ==
Poursuite des tutoriaux

== Semaine 45 ==
Poursuite des tutoriaux

== Semaine 46 ==
Poursuite des tutoriaux

== Semaine 47 ==
Fin de la première partie des tutoriaux.

== Semaine 48 ==
Démarrage du code du programme à partir du code réalisé pendant les tutoriels.

== Semaine 49 ==
Ajout de la fonction permettant de récupérer les données des fichiers .obj contenant les vertices, les coordonnées de texture, les vecteurs normaux et les références aux faces (triangles) constituant l'objet 3D.

== Semaine 50 ==
Nous sommes arrivé durant cette semaine à représenter une tumeur correctement en 3D.

Pour représenter un structure en 3D, nous allons utiliser un ensemble de triangle. Chaque triangle est constitué de 3 vertices qui sont ces sommets. Un vertex est tout simplement un point avec trois dimensions : x,y et z. Ainsi, le but est de relier les trois sommets (vertices) formant un triangle et ensuite de relier tous les triangles. Ainsi, nous obtiendront notre structure en 3D.

Cependant, nous rencontrons un problème quand on a un nombre de vertices élevés à représenter (de l'ordre de 20000 vertices). Une des pistes pour la résolution de ce problème est d'utiliser les display list. Cependant, les display List n'existent plus en OpenGL 3.3. Donc le problème reste irrésolu pour l'instant. On va regarder du coté des VBO (Vertex Buffer Object) et VBA(Vertex Buffer Array).

Les "Display List" permettent un stockage des données sur la carte graphique mais ne permettent pas de mettre à jour ces données. Les "VertexArray" conservent les données dans des tampons en mémoire système ce qui permet de les modifier mais oblige à transférer toutes ces données à chaque fois qu'elles doivent être affichées.

Un VBO est un objet OpenGL qui contient des données relatives à un modèle 3D comme les vertices, les coordonnées de texture, les normales (pour les lumières), ... Sa particularité vient du fait que les données qu'il contient se trouvent non pas dans la RAM mais directement dans la carte graphique.

Les VBO permettent de gagner un temps considérable à OpenGL en évitant de faire des aller-retours inutiles entre la RAM et la mémoire graphique:
[[Fichier:interet_VBO.png]]

[[Fichier:chargement_avec_VBO.png]]

[[Fichier:affichage_avec_VBO.png]]

Images prises sur : http://fr.openclassrooms.com/informatique/cours/developpez-vos-applications-3d-avec-opengl-3-3/c-est-quoi-un-vbo

On économise ainsi le transfert de centaines de milliers de données à chaque affichage, la carte graphique peut travailler plus rapidement.

Nous avons aussi trouvé durant cette semaine ce site qui explique très bien la théorie de l'intersection rayon/triangle avec une traduction en code.

http://www.scratchapixel.com/lessons/3d-basic-lessons/lesson-9-ray-triangle-intersection/ray-triangle-intersection-geometric-solution/

Nous avons grâce à ceci pu coder une méthode adaptée pour tester les triangles de la surface du foie et voir s'ils sont en intersection avec le rayon partant du barycentre de la tumeur et ayant pour vecteur directeur X, Y, ou Z. Une fois le bon triangle trouvé, la fonction se charge de renvoyer le point d'intersection, et il ne reste qu'a récupérer sa coordonnée en X,Y,ou Z (suivant le vecteur directeur précisé dans l'appel à la fonction) qui se trouve être la distance entre la tumeur et la surface du foie. Pour affiner un peu notre méthode, il faut d'abord l'appliquer à l'enveloppe de la tumeur elle même, puis faire de même avec la surface du foie, et soustraire les coordonnées obtenues pour les points d'intersections dans chacune des 3 direction afin d'obtenir une distance correcte pour chaque direction.

== Semaine 51 ==
Rédaction du rapport d'avancement

Rédaction de la présentation oral

= Conclusion Première partie =

Ce premier semestre à travailler sur ce projet a été des plus instructifs pour nous,
nous permettant de mieux concevoir la charge de travail que représentait celuici,
de
réaliser la chance qu’il nous était donnée de pouvoir apporter notre contribution dans le
domaine concret et important qu’est la médecine. Cela nous aura aussi permis de nous
cultiver sur les méthodes utilisées aujourd’hui en chirurgie, ainsi que de découvrir OpenGL
et la modélisation dans l’espace.
Les bases de l’application sont bien en place et le cahier des charges bien défini. Il
reste donc pour la seconde moitié de l’année à finaliser la modélisation des structures
ainsi que l’affichage de la distance entre la tumeur et la surface du foie. De plus, nous
devrons rendre l’application dynamique avec la récupération des flux de données en
temps réel par la caméra.

= Deuxième partie =
== Objectifs ==

-Résoudre le problème d'affichage du foie grâce aux VBO
-Finir l'implémentation du calcul de distances
-Réaliser des propositions d'affichage des distances

== Semaine 1 ==
Nous avons créé une classe foie pour représenter ce dernier. De ce fait, notre programme sera plus lisible et ordonné.

== Semaine 2 ==
On arrive enfin à représenter le foie. Pour celà donc, nous avons utilisé les VBO afin d'aboutir à ce résultat.
La prochaine étape est de représenter la tumeur et le foie en même temps.
Nous avons créé une classe tumeur qui s'occupe du chargement et de l'affichage de la tumeur.
Nous arrivons maintenant à afficher le foie et la tumeur en même temps. Cependant, vu que la tumeur se trouve à l'intérieur du foie,
nous allons changer l'affichage du foie de tel sorte que l'on voit que les traits reliant les triangles sans couleur ni texture.
On affiche désormais le foie et la tumeur ensemble avec pour le foie juste des traits pour avoir une meilleure vision de la position de la tumeur.

== Semaine 3 ==
Pour cette semaine, nous sommes arrivés à calculer les distances séparant la tumeur et la surface du foie.

Afin de récupérer la distance séparant la tumeur et le foie, on réalise des tests d’intersection rayon-triangle avec les triangles composant les meshs du foie et de la tumeur. En effet, en réalisant ce test entre un rayon partant du barycentre de la tumeur suivant la direction X,Y ou Z, et les triangles constituant le foie d’une part, et la tumeur d’autre part, on obtient deux distances (toujours selon X, Y, ou Z). La première, distance entre la paroi du foie et le barycentre de la tumeur, la seconde, distance entre la paroi de la tumeur et le barycentre de celle ci. En soustrayant la seconde à la première, on obtient la distance séparant la paroi du foie et la paroi de la tumeur selon un axe prédéfini (X, Y ou Z de notre repère). Il suffit ensuite de réaliser le calcul une fois pour chaque axe.
Ce calcul se réalise en plusieurs étapes mathématiques présentées ci dessous :

Image rayon [[Fichier:Raytracing.png]]

Afin de savoir s’il y a intersection entre un rayon et un triangle, il est plus aisé de commencer tout d’abord par vérifier s’il y a intersection entre ce même rayon et le plan contenant le triangle.
Pour cela, on calcule le vecteur normal du plan. Le vecteur normal du plan s’obtient en faisant le produit vectoriel de deux vecteurs non colinéaires du plan. On connaît 3 points du plan (les points constituant le triangle en train d’être testé), que l’on nommera ici v0, v1 et v2. On peut donc calculer le produit vectoriel de v0v1 et v0v2 par exemple, pour obtenir le vecteur normal N(A,B,C). Une fois le vecteur normal obtenu, on réalise le produit scalaire entre N et le rayon. Si le résultat est nul, le plan et le rayon sont parallèles donc il n’y a pas intersection. Sinon on a confirmation que le rayon et le plan entrent en intersection.
Cela permet ensuite, si intersection il y a, de calculer les coordonnées du point d’intersection P entre le rayon et le plan. P est défini de cette façon:
P = O + t * D -O l’origine (ici le barycentre de la tumeur)
-D le vecteur directeur du rayon
-t la distance entre O et P

L’équation du plan contenant le triangle est celle-ci:
A * x + B * y + C * z + d = 0 -A,B et C sont les composantes du vecteur normal au
plan N(A,B,C).
-(x,y,z) un point du plan.
-d la distance de l’origine (du repère) au plan, suivant la direction du vecteur normal au plan.

Grâce aux deux formules précedentes, on en déduit le calcul de t :
t = - ( N . O + d ) / ( N . D)

Une fois t calculé, on peut aisément obtenir les coordonnées de P. On peut maintenant passer au deuxième test à réaliser, qui est le test d’appartenance d’un point à un triangle.

[[Fichier:Raytracing1.png]]

Le principe de ce test est le suivant:
On calcule les vecteurs partant des points du triangle et allant vers P : v0P, v1P, v2P.
On calcule de même les vecteurs correspondants aux cotés du triangle : v0v1, v1v2, v2v0.
On calcule le produit vectoriel de chacun de ces vecteurs avec les vecteurs contenant P:
u = v0v1 ^ v0P, v = v1v2 ^ v1P, w = v2v0 ^ v2P.
Si P appartient au triangle, les vecteurs u, v et w ainsi calculés seront colinéaires de même sens avec le vecteur normal au triangle N. (voir Figure 11)

On réalise donc les tests suivants: (produit scalaire)
N . u, N . v, N . w

Si le résultat est positif, P est placé à l’intérieur du triangle par rapport au coté testé. (u teste le coté v0v1, v teste v1v2, w teste v2v0)
Si les trois tests sont positifs, cela signifie que P est bien à l’intérieur du triangle.

[[Fichier:Raytracing2.png]]

Une fois ces tests concluants, on récupère la distance voulue avec le calcul suivant :
Distance = t * D(x,y,z)
Ceci nous donne une distance selon les 3 axes, grâce à une comparaison du vecteur directeur et des vecteurs X, Y, et Z, on récupère uniquement la distance voulue :
Distance = t * D.x ou t * D.y ou t *D.z

Pour le temps restant au projet, nous allons proposer différentes solutions pour l'affichage de ces distances.
De même, nous allons rédiger notre rapport et nous préparer à la soutenance finale.

== Semaine 4 ==

= Conclusion =
Diagramme UML de notre application finale:

Voici un bref résumé de chacune des classes et de leurs fonctions :

La classe Camera.cpp s’occupe de gérer tous les placements et les orientations que la caméra va prendre.

La classe Input.cpp s’occupe de gérer tous les évènements clavier et souris, les rendant plus simples d’utilisation.

La classe Shader.cpp permet de charger et de compiler le shader en charge de l’affichage de couleurs sur notre représentation.

La classe principale: SceneOpenGL.cpp qui met en relation les différentes classes, permet la création de la scène, et dans laquelle nous avons codé les différentes fonctions nécessaires au programme, notamment la fonction de calcul des distances.

La classe Texture.cpp permet de charger des textures à la place des couleurs.

La classe Tumor.cpp permet de récupérer les vertices de la tumeur et de l’afficher.

La classe Liver.cpp permet de récupérer les vertices du foie et de l’afficher.

La classe DistanceDisplay.cpp permet d’afficher les distances séparant la tumeur de la surface du foie suivant les trois axes x, y et z.

Réalité Augmentée pour la chirurgie

2014-02-27T14:56:47Z

Cdelberg : /* Deuxième partie */

Papa Momar MBOUP/ Calvin DELBERGHE

= Présentation =

== Description et Objectif: ==

Notre projet consiste à assister les chirurgiens lors de chirurgies laparoscopiques. La chirurgie laparoscopique est une technique chirurgicale minimalement invasive où le chirurgien réalise une opération de l'abdomen par de petites incisions où sont placés des trocars qui permettent le passage de fins instruments chirurgicaux. Dans le cadre de ce projet, il s’agit de réaliser l’ablation de la(des) tumeur(s) présente(s) dans le foie du patient. La localisation des tumeurs ainsi que de l’ensemble du réseau vasculaire peut etre réalisé grâce à un scanner pré-opératoire et donc reconstruits en 3D. Cependant, ils ne peuvent pas être visualisés par la caméra lors de l’opération chirurgicale.

Ainsi, le chirurgien ne peut en aucun cas connaitre la localisation de la tumeur et ne peut pas se représenter la distance qui la sépare des parois du foie. D’où le but de notre projet: aider les chirurgiens dans ces opérations. Des travaux récents de l'équipe de recherche Shacra ont permis de suivre avec une bonne précision le mouvement de structures internes du foie pendant une opération laparoscopique. Le projet consiste à utiliser ces travaux pour mélanger le flux vidéo fourni par l'endoscope aux informations calculées par la simulation pour fournir aux chirurgiens des informations utiles sur la position des structures internes du foie lors de la manipulation. Différentes pistes pourront être explorées pour ne pas surcharger le flux vidéo tout en fournissant les informations importantes (position, profondeur, distance à la surface du foie...)

== Environnement de travail :==
1 ordinateur

OpenGL 3.3

SDL 2.0

IDE CodeBlocks

= Plan d'action / Gestion de projet =
Dans un premier temps, nous allons commencer à suivre des tutoriaux sur le framework OpenGL. Quand on sera assez avancé, nous débuterons le codage du programme principal. Donc pour le premier semestre, le plan est de mettre en place la base du programme et de bien maîtriser OpenGL pour la suite quand on ajoutera des fonctions plus poussées dans le programme.

= Réalisation =

== Semaine 37 ==
Présentation et Choix du sujet.

== Semaine 38 ==
Rencontre avec les encadrants du projet:
Explication détaillée du sujet ainsi que les attentes du projet.
Réception des premières données pour débuter quelques tests avec OpenGL.
== Semaine 39 ==
Installation d'OpenGL sous Windows avec CodeBlocks.
Début des tutoriaux sur le site du zéro:

http://fr.openclassrooms.com/informatique/cours/developpez-vos-applications-3d-avec-opengl-3-3

== Semaine 40 ==
Poursuite des tutoriaux.

== Semaine 41 ==
Poursuite des tutoriaux.

== Semaine 42 ==
Poursuite des tutoriaux.

== Semaine 43 ==
Poursuite des tutoriaux

== Semaine 44 ==
Poursuite des tutoriaux

== Semaine 45 ==
Poursuite des tutoriaux

== Semaine 46 ==
Poursuite des tutoriaux

== Semaine 47 ==
Fin de la première partie des tutoriaux.

== Semaine 48 ==
Démarrage du code du programme à partir du code réalisé pendant les tutoriels.

== Semaine 49 ==
Ajout de la fonction permettant de récupérer les données des fichiers .obj contenant les vertices, les coordonnées de texture, les vecteurs normaux et les références aux faces (triangles) constituant l'objet 3D.

== Semaine 50 ==
Nous sommes arrivé durant cette semaine à représenter une tumeur correctement en 3D.

Pour représenter un structure en 3D, nous allons utiliser un ensemble de triangle. Chaque triangle est constitué de 3 vertices qui sont ces sommets. Un vertex est tout simplement un point avec trois dimensions : x,y et z. Ainsi, le but est de relier les trois sommets (vertices) formant un triangle et ensuite de relier tous les triangles. Ainsi, nous obtiendront notre structure en 3D.

Cependant, nous rencontrons un problème quand on a un nombre de vertices élevés à représenter (de l'ordre de 20000 vertices). Une des pistes pour la résolution de ce problème est d'utiliser les display list. Cependant, les display List n'existent plus en OpenGL 3.3. Donc le problème reste irrésolu pour l'instant. On va regarder du coté des VBO (Vertex Buffer Object) et VBA(Vertex Buffer Array).

Les "Display List" permettent un stockage des données sur la carte graphique mais ne permettent pas de mettre à jour ces données. Les "VertexArray" conservent les données dans des tampons en mémoire système ce qui permet de les modifier mais oblige à transférer toutes ces données à chaque fois qu'elles doivent être affichées.

Un VBO est un objet OpenGL qui contient des données relatives à un modèle 3D comme les vertices, les coordonnées de texture, les normales (pour les lumières), ... Sa particularité vient du fait que les données qu'il contient se trouvent non pas dans la RAM mais directement dans la carte graphique.

Les VBO permettent de gagner un temps considérable à OpenGL en évitant de faire des aller-retours inutiles entre la RAM et la mémoire graphique:
[[Fichier:interet_VBO.png]]

[[Fichier:chargement_avec_VBO.png]]

[[Fichier:affichage_avec_VBO.png]]

Images prises sur : http://fr.openclassrooms.com/informatique/cours/developpez-vos-applications-3d-avec-opengl-3-3/c-est-quoi-un-vbo

On économise ainsi le transfert de centaines de milliers de données à chaque affichage, la carte graphique peut travailler plus rapidement.

Nous avons aussi trouvé durant cette semaine ce site qui explique très bien la théorie de l'intersection rayon/triangle avec une traduction en code.

http://www.scratchapixel.com/lessons/3d-basic-lessons/lesson-9-ray-triangle-intersection/ray-triangle-intersection-geometric-solution/

Nous avons grâce à ceci pu coder une méthode adaptée pour tester les triangles de la surface du foie et voir s'ils sont en intersection avec le rayon partant du barycentre de la tumeur et ayant pour vecteur directeur X, Y, ou Z. Une fois le bon triangle trouvé, la fonction se charge de renvoyer le point d'intersection, et il ne reste qu'a récupérer sa coordonnée en X,Y,ou Z (suivant le vecteur directeur précisé dans l'appel à la fonction) qui se trouve être la distance entre la tumeur et la surface du foie. Pour affiner un peu notre méthode, il faut d'abord l'appliquer à l'enveloppe de la tumeur elle même, puis faire de même avec la surface du foie, et soustraire les coordonnées obtenues pour les points d'intersections dans chacune des 3 direction afin d'obtenir une distance correcte pour chaque direction.

== Semaine 51 ==
Rédaction du rapport d'avancement

Rédaction de la présentation oral

= Conclusion Première partie =

Ce premier semestre à travailler sur ce projet a été des plus instructifs pour nous,
nous permettant de mieux concevoir la charge de travail que représentait celuici,
de
réaliser la chance qu’il nous était donnée de pouvoir apporter notre contribution dans le
domaine concret et important qu’est la médecine. Cela nous aura aussi permis de nous
cultiver sur les méthodes utilisées aujourd’hui en chirurgie, ainsi que de découvrir OpenGL
et la modélisation dans l’espace.
Les bases de l’application sont bien en place et le cahier des charges bien défini. Il
reste donc pour la seconde moitié de l’année à finaliser la modélisation des structures
ainsi que l’affichage de la distance entre la tumeur et la surface du foie. De plus, nous
devrons rendre l’application dynamique avec la récupération des flux de données en
temps réel par la caméra.

= Deuxième partie =
== Objectifs ==

-Résoudre le problème d'affichage du foie grâce aux VBO
-Finir l'implémentation du calcul de distances
-Réaliser des propositions d'affichage des distances

== Semaine 1 ==
Nous avons créé une classe foie pour représenter ce dernier. De ce fait, notre programme sera plus lisible et ordonné.

== Semaine 2 ==
On arrive enfin à représenter le foie. Pour celà donc, nous avons utilisé les VBO afin d'aboutir à ce résultat.
La prochaine étape est de représenter la tumeur et le foie en même temps.
Nous avons créé une classe tumeur qui s'occupe du chargement et de l'affichage de la tumeur.
Nous arrivons maintenant à afficher le foie et la tumeur en même temps. Cependant, vu que la tumeur se trouve à l'intérieur du foie,
nous allons changer l'affichage du foie de tel sorte que l'on voit que les traits reliant les triangles sans couleur ni texture.
On affiche désormais le foie et la tumeur ensemble avec pour le foie juste des traits pour avoir une meilleure vision de la position de la tumeur.

== Semaine 3 ==
Pour cette semaine, nous sommes arrivés à calculer les distances séparant la tumeur et la surface du foie.

Afin de récupérer la distance séparant la tumeur et le foie, on réalise des tests d’intersection rayon-triangle avec les triangles composant les meshs du foie et de la tumeur. En effet, en réalisant ce test entre un rayon partant du barycentre de la tumeur suivant la direction X,Y ou Z, et les triangles constituant le foie d’une part, et la tumeur d’autre part, on obtient deux distances (toujours selon X, Y, ou Z). La première, distance entre la paroi du foie et le barycentre de la tumeur, la seconde, distance entre la paroi de la tumeur et le barycentre de celle ci. En soustrayant la seconde à la première, on obtient la distance séparant la paroi du foie et la paroi de la tumeur selon un axe prédéfini (X, Y ou Z de notre repère). Il suffit ensuite de réaliser le calcul une fois pour chaque axe.
Ce calcul se réalise en plusieurs étapes mathématiques présentées ci dessous :

Image rayon [[Fichier:Raytracing.png]]

Afin de savoir s’il y a intersection entre un rayon et un triangle, il est plus aisé de commencer tout d’abord par vérifier s’il y a intersection entre ce même rayon et le plan contenant le triangle.
Pour cela, on calcule le vecteur normal du plan. Le vecteur normal du plan s’obtient en faisant le produit vectoriel de deux vecteurs non colinéaires du plan. On connaît 3 points du plan (les points constituant le triangle en train d’être testé), que l’on nommera ici v0, v1 et v2. On peut donc calculer le produit vectoriel de v0v1 et v0v2 par exemple, pour obtenir le vecteur normal N(A,B,C). Une fois le vecteur normal obtenu, on réalise le produit scalaire entre N et le rayon. Si le résultat est nul, le plan et le rayon sont parallèles donc il n’y a pas intersection. Sinon on a confirmation que le rayon et le plan entrent en intersection.
Cela permet ensuite, si intersection il y a, de calculer les coordonnées du point d’intersection P entre le rayon et le plan. P est défini de cette façon:
P = O + t * D -O l’origine (ici le barycentre de la tumeur)
-D le vecteur directeur du rayon
-t la distance entre O et P

L’équation du plan contenant le triangle est celle-ci:
A * x + B * y + C * z + d = 0 -A,B et C sont les composantes du vecteur normal au
plan N(A,B,C).
-(x,y,z) un point du plan.
-d la distance de l’origine (du repère) au plan, suivant la direction du vecteur normal au plan.

Grâce aux deux formules précedentes, on en déduit le calcul de t :
t = - ( N . O + d ) / ( N . D)

Une fois t calculé, on peut aisément obtenir les coordonnées de P. On peut maintenant passer au deuxième test à réaliser, qui est le test d’appartenance d’un point à un triangle.

[[Fichier:Raytracing1.png]]

Le principe de ce test est le suivant:
On calcule les vecteurs partant des points du triangle et allant vers P : v0P, v1P, v2P.
On calcule de même les vecteurs correspondants aux cotés du triangle : v0v1, v1v2, v2v0.
On calcule le produit vectoriel de chacun de ces vecteurs avec les vecteurs contenant P:
u = v0v1 ^ v0P, v = v1v2 ^ v1P, w = v2v0 ^ v2P.
Si P appartient au triangle, les vecteurs u, v et w ainsi calculés seront colinéaires de même sens avec le vecteur normal au triangle N. (voir Figure 11)

On réalise donc les tests suivants: (produit scalaire)
N . u, N . v, N . w

Si le résultat est positif, P est placé à l’intérieur du triangle par rapport au coté testé. (u teste le coté v0v1, v teste v1v2, w teste v2v0)
Si les trois tests sont positifs, cela signifie que P est bien à l’intérieur du triangle.

[[Fichier:Raytracing2.png]]

Une fois ces tests concluants, on récupère la distance voulue avec le calcul suivant :
Distance = t * D(x,y,z)
Ceci nous donne une distance selon les 3 axes, grâce à une comparaison du vecteur directeur et des vecteurs X, Y, et Z, on récupère uniquement la distance voulue :
Distance = t * D.x ou t * D.y ou t *D.z

Pour le temps restant au projet, nous allons proposer différentes solutions pour l'affichage de ces distances.
De même, nous allons rédiger notre rapport et nous préparer à la soutenance finale.

== Semaine 4 ==

= Conclusion =

Réalité Augmentée pour la chirurgie

2014-02-27T14:54:15Z

Cdelberg : /* Semaine 3 de Mars */

Papa Momar MBOUP/ Calvin DELBERGHE

= Présentation =

== Description et Objectif: ==

Notre projet consiste à assister les chirurgiens lors de chirurgies laparoscopiques. La chirurgie laparoscopique est une technique chirurgicale minimalement invasive où le chirurgien réalise une opération de l'abdomen par de petites incisions où sont placés des trocars qui permettent le passage de fins instruments chirurgicaux. Dans le cadre de ce projet, il s’agit de réaliser l’ablation de la(des) tumeur(s) présente(s) dans le foie du patient. La localisation des tumeurs ainsi que de l’ensemble du réseau vasculaire peut etre réalisé grâce à un scanner pré-opératoire et donc reconstruits en 3D. Cependant, ils ne peuvent pas être visualisés par la caméra lors de l’opération chirurgicale.

Ainsi, le chirurgien ne peut en aucun cas connaitre la localisation de la tumeur et ne peut pas se représenter la distance qui la sépare des parois du foie. D’où le but de notre projet: aider les chirurgiens dans ces opérations. Des travaux récents de l'équipe de recherche Shacra ont permis de suivre avec une bonne précision le mouvement de structures internes du foie pendant une opération laparoscopique. Le projet consiste à utiliser ces travaux pour mélanger le flux vidéo fourni par l'endoscope aux informations calculées par la simulation pour fournir aux chirurgiens des informations utiles sur la position des structures internes du foie lors de la manipulation. Différentes pistes pourront être explorées pour ne pas surcharger le flux vidéo tout en fournissant les informations importantes (position, profondeur, distance à la surface du foie...)

== Environnement de travail :==
1 ordinateur

OpenGL 3.3

SDL 2.0

IDE CodeBlocks

= Plan d'action / Gestion de projet =
Dans un premier temps, nous allons commencer à suivre des tutoriaux sur le framework OpenGL. Quand on sera assez avancé, nous débuterons le codage du programme principal. Donc pour le premier semestre, le plan est de mettre en place la base du programme et de bien maîtriser OpenGL pour la suite quand on ajoutera des fonctions plus poussées dans le programme.

= Réalisation =

== Semaine 37 ==
Présentation et Choix du sujet.

== Semaine 38 ==
Rencontre avec les encadrants du projet:
Explication détaillée du sujet ainsi que les attentes du projet.
Réception des premières données pour débuter quelques tests avec OpenGL.
== Semaine 39 ==
Installation d'OpenGL sous Windows avec CodeBlocks.
Début des tutoriaux sur le site du zéro:

http://fr.openclassrooms.com/informatique/cours/developpez-vos-applications-3d-avec-opengl-3-3

== Semaine 40 ==
Poursuite des tutoriaux.

== Semaine 41 ==
Poursuite des tutoriaux.

== Semaine 42 ==
Poursuite des tutoriaux.

== Semaine 43 ==
Poursuite des tutoriaux

== Semaine 44 ==
Poursuite des tutoriaux

== Semaine 45 ==
Poursuite des tutoriaux

== Semaine 46 ==
Poursuite des tutoriaux

== Semaine 47 ==
Fin de la première partie des tutoriaux.

== Semaine 48 ==
Démarrage du code du programme à partir du code réalisé pendant les tutoriels.

== Semaine 49 ==
Ajout de la fonction permettant de récupérer les données des fichiers .obj contenant les vertices, les coordonnées de texture, les vecteurs normaux et les références aux faces (triangles) constituant l'objet 3D.

== Semaine 50 ==
Nous sommes arrivé durant cette semaine à représenter une tumeur correctement en 3D.

Pour représenter un structure en 3D, nous allons utiliser un ensemble de triangle. Chaque triangle est constitué de 3 vertices qui sont ces sommets. Un vertex est tout simplement un point avec trois dimensions : x,y et z. Ainsi, le but est de relier les trois sommets (vertices) formant un triangle et ensuite de relier tous les triangles. Ainsi, nous obtiendront notre structure en 3D.

Cependant, nous rencontrons un problème quand on a un nombre de vertices élevés à représenter (de l'ordre de 20000 vertices). Une des pistes pour la résolution de ce problème est d'utiliser les display list. Cependant, les display List n'existent plus en OpenGL 3.3. Donc le problème reste irrésolu pour l'instant. On va regarder du coté des VBO (Vertex Buffer Object) et VBA(Vertex Buffer Array).

Les "Display List" permettent un stockage des données sur la carte graphique mais ne permettent pas de mettre à jour ces données. Les "VertexArray" conservent les données dans des tampons en mémoire système ce qui permet de les modifier mais oblige à transférer toutes ces données à chaque fois qu'elles doivent être affichées.

Un VBO est un objet OpenGL qui contient des données relatives à un modèle 3D comme les vertices, les coordonnées de texture, les normales (pour les lumières), ... Sa particularité vient du fait que les données qu'il contient se trouvent non pas dans la RAM mais directement dans la carte graphique.

Les VBO permettent de gagner un temps considérable à OpenGL en évitant de faire des aller-retours inutiles entre la RAM et la mémoire graphique:
[[Fichier:interet_VBO.png]]

[[Fichier:chargement_avec_VBO.png]]

[[Fichier:affichage_avec_VBO.png]]

Images prises sur : http://fr.openclassrooms.com/informatique/cours/developpez-vos-applications-3d-avec-opengl-3-3/c-est-quoi-un-vbo

On économise ainsi le transfert de centaines de milliers de données à chaque affichage, la carte graphique peut travailler plus rapidement.

Nous avons aussi trouvé durant cette semaine ce site qui explique très bien la théorie de l'intersection rayon/triangle avec une traduction en code.

http://www.scratchapixel.com/lessons/3d-basic-lessons/lesson-9-ray-triangle-intersection/ray-triangle-intersection-geometric-solution/

Nous avons grâce à ceci pu coder une méthode adaptée pour tester les triangles de la surface du foie et voir s'ils sont en intersection avec le rayon partant du barycentre de la tumeur et ayant pour vecteur directeur X, Y, ou Z. Une fois le bon triangle trouvé, la fonction se charge de renvoyer le point d'intersection, et il ne reste qu'a récupérer sa coordonnée en X,Y,ou Z (suivant le vecteur directeur précisé dans l'appel à la fonction) qui se trouve être la distance entre la tumeur et la surface du foie. Pour affiner un peu notre méthode, il faut d'abord l'appliquer à l'enveloppe de la tumeur elle même, puis faire de même avec la surface du foie, et soustraire les coordonnées obtenues pour les points d'intersections dans chacune des 3 direction afin d'obtenir une distance correcte pour chaque direction.

== Semaine 51 ==
Rédaction du rapport d'avancement

Rédaction de la présentation oral

= Conclusion Première partie =

Ce premier semestre à travailler sur ce projet a été des plus instructifs pour nous,
nous permettant de mieux concevoir la charge de travail que représentait celuici,
de
réaliser la chance qu’il nous était donnée de pouvoir apporter notre contribution dans le
domaine concret et important qu’est la médecine. Cela nous aura aussi permis de nous
cultiver sur les méthodes utilisées aujourd’hui en chirurgie, ainsi que de découvrir OpenGL
et la modélisation dans l’espace.
Les bases de l’application sont bien en place et le cahier des charges bien défini. Il
reste donc pour la seconde moitié de l’année à finaliser la modélisation des structures
ainsi que l’affichage de la distance entre la tumeur et la surface du foie. De plus, nous
devrons rendre l’application dynamique avec la récupération des flux de données en
temps réel par la caméra.

= Deuxième partie =
== Objectifs ==
Les objectifs pour cette seconde partie sont représentés dans notre planning:

'''PHOTO''' '''PHOTO''' '''PHOTO''' '''PHOTO'''

== Semaine 1 de Mars ==
Nous avons créé une classe foie pour représenter ce dernier. De ce fait, notre programme sera plus lisible et ordonné.

== Semaine 2 de Mars ==
On arrive enfin à représenter le foie. Pour celà donc, nous avons utilisé les VBO afin d'aboutir à ce résultat.
La prochaine étape est de représenter la tumeur et le foie en même temps.
Nous avons créé une classe tumeur qui s'occupe du chargement et de l'affichage de la tumeur.
Nous arrivons maintenant à afficher le foie et la tumeur en même temps. Cependant, vu que la tumeur se trouve à l'intérieur du foie,
nous allons changer l'affichage du foie de tel sorte que l'on voit que les traits reliant les triangles sans couleur ni texture.
On affiche désormais le foie et la tumeur ensemble avec pour le foie juste des traits pour avoir une meilleure vision de la position de la tumeur.

== Semaine 3 ==
Pour cette semaine, nous sommes arrivés à calculer les distances séparant la tumeur et la surface du foie.

Afin de récupérer la distance séparant la tumeur et le foie, on réalise des tests d’intersection rayon-triangle avec les triangles composant les meshs du foie et de la tumeur. En effet, en réalisant ce test entre un rayon partant du barycentre de la tumeur suivant la direction X,Y ou Z, et les triangles constituant le foie d’une part, et la tumeur d’autre part, on obtient deux distances (toujours selon X, Y, ou Z). La première, distance entre la paroi du foie et le barycentre de la tumeur, la seconde, distance entre la paroi de la tumeur et le barycentre de celle ci. En soustrayant la seconde à la première, on obtient la distance séparant la paroi du foie et la paroi de la tumeur selon un axe prédéfini (X, Y ou Z de notre repère). Il suffit ensuite de réaliser le calcul une fois pour chaque axe.
Ce calcul se réalise en plusieurs étapes mathématiques présentées ci dessous :

Image rayon [[Fichier:Raytracing.png]]

Afin de savoir s’il y a intersection entre un rayon et un triangle, il est plus aisé de commencer tout d’abord par vérifier s’il y a intersection entre ce même rayon et le plan contenant le triangle.
Pour cela, on calcule le vecteur normal du plan. Le vecteur normal du plan s’obtient en faisant le produit vectoriel de deux vecteurs non colinéaires du plan. On connaît 3 points du plan (les points constituant le triangle en train d’être testé), que l’on nommera ici v0, v1 et v2. On peut donc calculer le produit vectoriel de v0v1 et v0v2 par exemple, pour obtenir le vecteur normal N(A,B,C). Une fois le vecteur normal obtenu, on réalise le produit scalaire entre N et le rayon. Si le résultat est nul, le plan et le rayon sont parallèles donc il n’y a pas intersection. Sinon on a confirmation que le rayon et le plan entrent en intersection.
Cela permet ensuite, si intersection il y a, de calculer les coordonnées du point d’intersection P entre le rayon et le plan. P est défini de cette façon:
P = O + t * D -O l’origine (ici le barycentre de la tumeur)
-D le vecteur directeur du rayon
-t la distance entre O et P

L’équation du plan contenant le triangle est celle-ci:
A * x + B * y + C * z + d = 0 -A,B et C sont les composantes du vecteur normal au
plan N(A,B,C).
-(x,y,z) un point du plan.
-d la distance de l’origine (du repère) au plan, suivant la direction du vecteur normal au plan.

Grâce aux deux formules précedentes, on en déduit le calcul de t :
t = - ( N . O + d ) / ( N . D)

Une fois t calculé, on peut aisément obtenir les coordonnées de P. On peut maintenant passer au deuxième test à réaliser, qui est le test d’appartenance d’un point à un triangle.

[[Fichier:Raytracing1.png]]

Le principe de ce test est le suivant:
On calcule les vecteurs partant des points du triangle et allant vers P : v0P, v1P, v2P.
On calcule de même les vecteurs correspondants aux cotés du triangle : v0v1, v1v2, v2v0.
On calcule le produit vectoriel de chacun de ces vecteurs avec les vecteurs contenant P:
u = v0v1 ^ v0P, v = v1v2 ^ v1P, w = v2v0 ^ v2P.
Si P appartient au triangle, les vecteurs u, v et w ainsi calculés seront colinéaires de même sens avec le vecteur normal au triangle N. (voir Figure 11)

On réalise donc les tests suivants: (produit scalaire)
N . u, N . v, N . w

Si le résultat est positif, P est placé à l’intérieur du triangle par rapport au coté testé. (u teste le coté v0v1, v teste v1v2, w teste v2v0)
Si les trois tests sont positifs, cela signifie que P est bien à l’intérieur du triangle.

[[Fichier:Raytracing2.png]]

Une fois ces tests concluants, on récupère la distance voulue avec le calcul suivant :
Distance = t * D(x,y,z)
Ceci nous donne une distance selon les 3 axes, grâce à une comparaison du vecteur directeur et des vecteurs X, Y, et Z, on récupère uniquement la distance voulue :
Distance = t * D.x ou t * D.y ou t *D.z

Pour le temps restant au projet, nous allons proposer différentes solutions pour l'affichage de ces distances.
De même, nous allons rédiger notre rapport et nous préparer à la soutenance finale.

== Semaine 4 de Mars ==
= Conclusion =

Fichier:Raytracing2.png

2014-02-27T14:51:45Z

Cdelberg :

Fichier:Raytracing1.png

2014-02-27T14:51:37Z

Cdelberg :

Fichier:Raytracing.png

2014-02-27T14:51:14Z

Cdelberg :

Réalité Augmentée pour la chirurgie

2013-12-18T11:58:11Z

Cdelberg : /* Semaine 49 */

Réalité Augmentée pour la chirurgie

2013-12-18T11:56:12Z

Cdelberg : /* Semaine 48 */

Réalité Augmentée pour la chirurgie

2013-12-18T11:54:24Z

Cdelberg : /* Semaine 50 */

Objets communiquants et gestion de l'énergie

2013-02-25T07:14:26Z

Cdelberg : /* Le code du Arduino */

== Présentation du projet ==

=== Planning prévisionnel provisoire (jusqu'à la pré-soutenance)===

Ce planning pourrait être amené à être modifié.

'''''I) Etat de l'art''''' ( ~2-3 semaines)

-Energy harvesting (Calvin)

-Batteries (Justin)

'''''II) Mesure de puissance des différents appareil Arduino''''' ( ~2 semaines)

'''''III) Confronter théorie/réalité''''' ( ~1 semaine)
-estimer consommation de puissance

-vérifier en pratique

'''Amené à être ajouté:'''

Mesure du Arduino de sa propre consommation.

Mesure de la consommation du code (?)

Applications:

-Envoi des valeurs de l'Arduino au serveur.

-Interface web pour interagir avec l'objet.

== Etat de l'art ==

=== Energy Harvesting ===
 
* Mosquino:

''Mosquino'' est un matériel compatible avec le développement logiciel et dérivé de ''Arduino'', il permet de récupérer de l'énergie des sources ambiantes (chaleur, luminosité, vibrations)
Il n'est destiné qu'aux faibles consommations électriques et n'est encore qu'en phase de développement, il n'a pas encore été véritablement testé. 
http://tim.cexx.org/?page_id=760
 
* Breakout board BOB-o9946 :

Cette carte utilise le collecteur d'énergie piezoelectrique LTC3588 de Linear Technologies et permet non seulement de récupérer l'énergie piezoélectrique mais aussi l'énergie solaire. Initialement prévu pour fonctionner à faible voltage, la capacité de sortie peut-être dimensionnée pour recevoir une salve de courant de sortie plus élevée. 
https://www.sparkfun.com/products/9946
 
=== Batteries ===
 
* nouvelles technologies:

ces dernières années, de nouvelles technologies sont apparues, sans être encore réellement utilisées. je pense notamment aux batteries contenues dans des câbles:
http://phys.org/news/2012-09-lg-chem-cable-batteries-reshape.html

ainsi qu'aux batteries ultra fines dévellopées par thinergy:
http://www.infinitepowersolutions.com/products.html

Néanmoins, les tensions pouvant etre délivrées par ces technologies naissantes sont loin de pouvoir alimenter le materiel qui nous interresse, à savoir des Arduino (necessitant une alimentation comprise entre 7V-12V)

D'autres techno sont encore en phase de développement, comme les batteries lithium-Air d'IBM, les piles au graphène utilisant la chaleur pour produire de l’énergie (plutôt de l'energy harvesting pour le coup). Comme ces technologies sont encore en phase de développement, elles n’apparaîtrons pas sur le marché avant au moins 10 ans.

http://www.metro.co.uk/tech/news/897731-technology-companies-charge-towards-next-generation-battery-future

* technologies adaptée à notre usage:

comme je l'ai rappelé plus haut, ce PFE tourne principalement autour d'Arduino. ces plates-formes nécessitant une tension d'alimentation supérieure à 7V, le choix le plus intéressant reste les piles rechargeable.

Seulement, il existe plusieurs types de piles rechargeables. dans l'usage qu'il en sera fait, et si ces batteries sont couplées à des technologies de récupération d'énergie, il est important de choisir des piles Lithium-Ion.

En effet, ces piles sont les plus intéressantes pour plusieurs raisons:

tout d'abord, elles sont insensibles à l'effet mémoire. du coup elles ne perdent pas de leur capacité de stockage d’énergie au cours du temps.

le circuit intégré à ces piles empêche toute surtension lors de la charge.

elles peuvent être rechargée en même temps qu'elles sont utilisées.

dans une époque ou la pollution est un sujet préoccupation, ces piles sont moins dangereuse pour l’environnement que leurs homologues au nickel-Cadmium

le seul problème pourrais venir du fait qu'elles ne supporte pas bien la chaleur, mais à moins de les coller à un radiateur, il ne devrais pas y avoir de soucis.

=== Mesure de la consommation énergétique ===

WSIM permet la simulation de capteurs sans fil. Il permet notamment d'estimer la consommation électrique http://wsim.gforge.inria.fr/index.html
Pour l'instant il ne fonctionne qu'avec des microcontrolleurs TI. Le support des AVR est en cours.
L'estimation de la consommation énergétique utilise esimu http://esimu.gforge.inria.fr/index.html

== Réalisation ==
===Le Arduino===
====Architecture de l'objet communiquant====

*Un Arduino Mega 2560
*Un XBee
*Un capteur de température
*Un capteur de luminosité

====Le code du Arduino====

<code>
#include <XBee.h>

// Define variables, pins..
int sensorTempPin = 0;
int Temp;
int sensorLightPin = 1;
int Light;

uint8_t values[] = { 0, 0, 0, 0 };
XBee xbee = XBee();
XBeeResponse response = XBeeResponse();
Rx16Response rx = Rx16Response();
Tx16Request tx = Tx16Request(0x1111, values, sizeof(values));
TxStatusResponse txStatus = TxStatusResponse();

void setup()
{
// Initialise xbee / serial
xbee.begin(9600);
Serial.begin(9600);
}

void loop()
{
// Read the values on analog pins
Light = analogRead(sensorLightPin);
Temp = analogRead(sensorTempPin);

// Listens on the Xbee protocol for any packet incoming.
xbee.readPacket();

if(xbee.getResponse().isAvailable()){
// Got something
Serial.print("Got something\n");
// Break the 10-bits of information retrieved from light
// and temperature into 2 bytes for each.
values[0] = Temp >> 8 & 0xff;
values[1] = Temp & 0xff;
values[2] = Light >> 8 & 0xff;
values[3] = Light & 0xff;
Serial.print(values[0]);

// Sending values to server
xbee.send(tx);

// After sending a tx request, we expect a status response
// from the server
// Wait up to 5 seconds for the status response

if (xbee.readPacket(5000)) {
// We got a response!
Serial.print("We got a response\n");

// It should be a znet tx status
if (xbee.getResponse().getApiId() == TX_STATUS_RESPONSE) {
xbee.getResponse().getZBTxStatusResponse(txStatus);

// get the delivery status, the fifth byte
if (txStatus.getStatus() == SUCCESS){
// Success! Time to celebrate
Serial.print("SUCCESS! Time to celebrate\n");
} else {
// The remote XBee did not receive our packet. Is it powered on?
Serial.print("The remote Xbee did not receive our packet\n");
}
}
} else {
// local XBee did not provide a timely TX Status Response -- should not happen
Serial.print("Local Xbee did not provide a timely TX Status Response\n");
}

}

delay(500);
}
</code>
Ce code fonctionne de la manière suivante:
=====Fonction setup():=====
Une fois implémenté sur le Arduino, la fonction setup va faire démarrer le protocole XBee et le protocole Série afin de pouvoir envoyer et recevoir des messages par XBee, et d'imprimer les messages d'erreur sur le port Série s'il y a lieu.
=====Fonction loop():=====
Cette fonction va réaliser une boucle toutes les 0.5s pour mettre a jour les données des différents capteurs et les envoyer au serveur au travers du protocole XBee. Pour plus de détails voir les commentaires expliquant chaque étape du déroulement de la boucle.

===Le programme LINKER===

Code du programme de liaison

ce programme en java est constitué de 5 classes

====Le Main====
<code>
public class main {

public static SQLinker linker;
public static Xbee xbee;

public static void main(String[] args){
String address = new String("jdbc:mysql://sitedb.polytech-lille.net/cdelberg?");
String user = new String("user=cdelberg&password=myLo9ufonese");
String COM;

// We ask the user on the Communication Port to connect the XBee
System.out.println("Please enter the Communication port of the Xbee");
Scanner sc = new Scanner(System.in);
COM = sc.next();
System.out.println("COM port changed to: "+COM);

//Creation of the Variables that will be used to connect to the Database and the Xbee
linker = new SQLinker(address, user);
linker.FillArdList();
xbee = new Xbee(COM);

//Creating the Updates Threads
W8Thread thread1 = new W8Thread();
thread1.start();
UpTestThread thread2 = new UpTestThread();
thread2.start();

//We now allow the user to enter a command
String command;
System.out.println("vous pouvez maintenant lancer une commande si vous le souhaitez");
System.out.println("tapez help pour plus d'informations");
boolean exit=false;

while(exit==false){
command=sc.next();

if(command.equals("help")){
System.out.println("print => affiche la liste des arduinos");
System.out.println("exit => ferme le programme");
}
if(command.equals("print")){linker.PrintArdList();}
if(command.equals("exit")){exit=true;}

}
//if the user ask to stop the program, it will do those final commands
sc.close();
thread1.stop();
thread2.stop();
xbee.XbeeClosing();
//System.out.println("Program finished successfully");

}

}

</code>

Le main est la racine du programme. Il va créer les ressources nécessaires pour la connexion à la base de donnée et au XBee lui même connecté au PC.
Il crée ensuite 2 threads, l'un faisant une MAJ des valeurs des Arduinos dans la base de donnée à intervalles réguliers.
L'autre regarde sur la base de donnée si un utilisateur a fait une demande de MAJ, et ce toute les secondes, puis y répond.

====La classe SQLinker====
<code>
public class SQLinker {

Connection connect;
Statement stmt;
PreparedStatement pst;
ResultSet rs;
int[] ArdList = new int[10];
int[][] ArdListMatrix = new int[10][2];
String[] table = {"Battery", "Light", "Temperature", "Updating"};
//List of variables used to connect to the database and store some informations

//Constructor, create a connection when called
public SQLinker(String address, String user){

try{
Class.forName("com.mysql.jdbc.Driver").newInstance();
} catch(Exception ex){
System.out.println("can't register the Driver");
}

try{
connect = DriverManager.getConnection(address+user);
stmt = connect.createStatement();
} catch(Exception ex){
System.out.println("connection issue");
System.out.println("SQLException: " + ex.getMessage());
}
if (connect!= null){
System.out.println("connected to the database " + address);
}

}
//Fill a matrix with the list of Arduinos stored in the database
public void FillArdList(){
try{
rs = stmt.executeQuery("SELECT Arduino FROM Arduinos");
int i=0;
int m,c,d,u;
while(rs.next()){
ArdList[i] = Integer.parseInt(rs.getString(1));
m=ArdList[i]/1000;
c=(ArdList[i]-m*1000)/100;
d=(ArdList[i]-m*1000-c*100)/10;
u=(ArdList[i]-m*1000-c*100-d*10);
ArdListMatrix[i][0]=(m*10+c);
ArdListMatrix[i][1]=(d*10+u);
i++;
}
ArdList[i]=-1;
} catch (SQLException e){
System.out.println("SQLException: " + e.getMessage());
System.out.println("SQLState: " + e.getSQLState());
System.out.println("VendorError: " + e.getErrorCode());
}
}

//print the list of arduinos stored in the program
public void PrintArdList(){
int i=0;
while(ArdList[i]!=-1){
i++;
System.out.println("Code Arduino n°"+i+": "+ArdList[i]);

}
}

//Print the values of a specific arduino
public void PrintArdValues(int ard){
for(int i=0; i<=2;i++){

try {
rs = stmt.executeQuery("SELECT " +table[i]+" FROM Arduinos WHERE Arduino ="+ard);
} catch (SQLException e) {
e.printStackTrace();
}
try {
while(rs.next()){
System.out.println(table[i] +"=" + rs.getString(1));
}
} catch (SQLException e) {
e.printStackTrace();
}

}
}

//print the values of every arduino stored in the program
public void PrintAllArdValues(){
int i=0;
while(ArdList[i]!=-1){
this.PrintArdValues(i);
}
}

//set the values obtained from an arduino to the database
public void SetArdValues(int Ard, int[] values){
int i=0;
while(values[i]!=-1){

try {
pst = connect.prepareStatement("UPDATE Arduinos SET "+table[values[i]]+" = "+values[i+1] +" WHERE Arduino ="+Ard);
pst.executeUpdate();
} catch (SQLException e){
e.printStackTrace();
}

i+=2;
}
}

//verify if an update as been demanded by a user on the website
public int CheckUpdate(){
int i=0;
int ret=0;
while(ArdList[i]!=-1 && ret!=1){
try {
rs = stmt.executeQuery("SELECT Updating FROM Arduinos WHERE Arduino ="+ArdList[i]);
while(rs.next()){
ret = Integer.parseInt(rs.getString(1));
}
} catch (SQLException e) {
e.printStackTrace();
}
i++;
}
return ret; //return 1 if update demanded

}
}

</code>
Cette classe regroupe toutes les fonctions permettant de se connecter à une base de donnée et d'en traiter les données.

=== Liste du matériel à acheter ===

Objets communiquants et gestion de l'énergie

2013-02-25T07:14:07Z

Cdelberg : /* Le Arduino */

== Présentation du projet ==

=== Planning prévisionnel provisoire (jusqu'à la pré-soutenance)===

Ce planning pourrait être amené à être modifié.

'''''I) Etat de l'art''''' ( ~2-3 semaines)

-Energy harvesting (Calvin)

-Batteries (Justin)

'''''II) Mesure de puissance des différents appareil Arduino''''' ( ~2 semaines)

'''''III) Confronter théorie/réalité''''' ( ~1 semaine)
-estimer consommation de puissance

-vérifier en pratique

'''Amené à être ajouté:'''

Mesure du Arduino de sa propre consommation.

Mesure de la consommation du code (?)

Applications:

-Envoi des valeurs de l'Arduino au serveur.

-Interface web pour interagir avec l'objet.

== Etat de l'art ==

=== Energy Harvesting ===
 
* Mosquino:

''Mosquino'' est un matériel compatible avec le développement logiciel et dérivé de ''Arduino'', il permet de récupérer de l'énergie des sources ambiantes (chaleur, luminosité, vibrations)
Il n'est destiné qu'aux faibles consommations électriques et n'est encore qu'en phase de développement, il n'a pas encore été véritablement testé. 
http://tim.cexx.org/?page_id=760
 
* Breakout board BOB-o9946 :

Cette carte utilise le collecteur d'énergie piezoelectrique LTC3588 de Linear Technologies et permet non seulement de récupérer l'énergie piezoélectrique mais aussi l'énergie solaire. Initialement prévu pour fonctionner à faible voltage, la capacité de sortie peut-être dimensionnée pour recevoir une salve de courant de sortie plus élevée. 
https://www.sparkfun.com/products/9946
 
=== Batteries ===
 
* nouvelles technologies:

ces dernières années, de nouvelles technologies sont apparues, sans être encore réellement utilisées. je pense notamment aux batteries contenues dans des câbles:
http://phys.org/news/2012-09-lg-chem-cable-batteries-reshape.html

ainsi qu'aux batteries ultra fines dévellopées par thinergy:
http://www.infinitepowersolutions.com/products.html

Néanmoins, les tensions pouvant etre délivrées par ces technologies naissantes sont loin de pouvoir alimenter le materiel qui nous interresse, à savoir des Arduino (necessitant une alimentation comprise entre 7V-12V)

D'autres techno sont encore en phase de développement, comme les batteries lithium-Air d'IBM, les piles au graphène utilisant la chaleur pour produire de l’énergie (plutôt de l'energy harvesting pour le coup). Comme ces technologies sont encore en phase de développement, elles n’apparaîtrons pas sur le marché avant au moins 10 ans.

http://www.metro.co.uk/tech/news/897731-technology-companies-charge-towards-next-generation-battery-future

* technologies adaptée à notre usage:

comme je l'ai rappelé plus haut, ce PFE tourne principalement autour d'Arduino. ces plates-formes nécessitant une tension d'alimentation supérieure à 7V, le choix le plus intéressant reste les piles rechargeable.

Seulement, il existe plusieurs types de piles rechargeables. dans l'usage qu'il en sera fait, et si ces batteries sont couplées à des technologies de récupération d'énergie, il est important de choisir des piles Lithium-Ion.

En effet, ces piles sont les plus intéressantes pour plusieurs raisons:

tout d'abord, elles sont insensibles à l'effet mémoire. du coup elles ne perdent pas de leur capacité de stockage d’énergie au cours du temps.

le circuit intégré à ces piles empêche toute surtension lors de la charge.

elles peuvent être rechargée en même temps qu'elles sont utilisées.

dans une époque ou la pollution est un sujet préoccupation, ces piles sont moins dangereuse pour l’environnement que leurs homologues au nickel-Cadmium

le seul problème pourrais venir du fait qu'elles ne supporte pas bien la chaleur, mais à moins de les coller à un radiateur, il ne devrais pas y avoir de soucis.

=== Mesure de la consommation énergétique ===

WSIM permet la simulation de capteurs sans fil. Il permet notamment d'estimer la consommation électrique http://wsim.gforge.inria.fr/index.html
Pour l'instant il ne fonctionne qu'avec des microcontrolleurs TI. Le support des AVR est en cours.
L'estimation de la consommation énergétique utilise esimu http://esimu.gforge.inria.fr/index.html

== Réalisation ==
===Le Arduino===
====Architecture de l'objet communiquant====

*Un Arduino Mega 2560
*Un XBee
*Un capteur de température
*Un capteur de luminosité

====Le code du Arduino====

<code>
#include <XBee.h>

// Define variables, pins..
int sensorTempPin = 0;
int Temp;
int sensorLightPin = 1;
int Light;
int XPin = 2;
int YPin = 3;
int ZPin = 4;

uint8_t values[] = { 0, 0, 0, 0 };
XBee xbee = XBee();
XBeeResponse response = XBeeResponse();
Rx16Response rx = Rx16Response();
Tx16Request tx = Tx16Request(0x1111, values, sizeof(values));
TxStatusResponse txStatus = TxStatusResponse();

void setup()
{
// Initialise xbee / serial
xbee.begin(9600);
Serial.begin(9600);
}

void loop()
{
// Read the values on analog pins
Light = analogRead(sensorLightPin);
Temp = analogRead(sensorTempPin);

// Listens on the Xbee protocol for any packet incoming.
xbee.readPacket();

if(xbee.getResponse().isAvailable()){
// Got something
Serial.print("Got something\n");
// Break the 10-bits of information retrieved from light
// and temperature into 2 bytes for each.
values[0] = Temp >> 8 & 0xff;
values[1] = Temp & 0xff;
values[2] = Light >> 8 & 0xff;
values[3] = Light & 0xff;
Serial.print(values[0]);

// Sending values to server
xbee.send(tx);

// After sending a tx request, we expect a status response
// from the server
// Wait up to 5 seconds for the status response

if (xbee.readPacket(5000)) {
// We got a response!
Serial.print("We got a response\n");

// It should be a znet tx status
if (xbee.getResponse().getApiId() == TX_STATUS_RESPONSE) {
xbee.getResponse().getZBTxStatusResponse(txStatus);

// get the delivery status, the fifth byte
if (txStatus.getStatus() == SUCCESS){
// Success! Time to celebrate
Serial.print("SUCCESS! Time to celebrate\n");
} else {
// The remote XBee did not receive our packet. Is it powered on?
Serial.print("The remote Xbee did not receive our packet\n");
}
}
} else {
// local XBee did not provide a timely TX Status Response -- should not happen
Serial.print("Local Xbee did not provide a timely TX Status Response\n");
}

}

delay(500);
}
</code>
Ce code fonctionne de la manière suivante:
=====Fonction setup():=====
Une fois implémenté sur le Arduino, la fonction setup va faire démarrer le protocole XBee et le protocole Série afin de pouvoir envoyer et recevoir des messages par XBee, et d'imprimer les messages d'erreur sur le port Série s'il y a lieu.
=====Fonction loop():=====
Cette fonction va réaliser une boucle toutes les 0.5s pour mettre a jour les données des différents capteurs et les envoyer au serveur au travers du protocole XBee. Pour plus de détails voir les commentaires expliquant chaque étape du déroulement de la boucle.

===Le programme LINKER===

Code du programme de liaison

ce programme en java est constitué de 5 classes

====Le Main====
<code>
public class main {

public static SQLinker linker;
public static Xbee xbee;

public static void main(String[] args){
String address = new String("jdbc:mysql://sitedb.polytech-lille.net/cdelberg?");
String user = new String("user=cdelberg&password=myLo9ufonese");
String COM;

// We ask the user on the Communication Port to connect the XBee
System.out.println("Please enter the Communication port of the Xbee");
Scanner sc = new Scanner(System.in);
COM = sc.next();
System.out.println("COM port changed to: "+COM);

//Creation of the Variables that will be used to connect to the Database and the Xbee
linker = new SQLinker(address, user);
linker.FillArdList();
xbee = new Xbee(COM);

//Creating the Updates Threads
W8Thread thread1 = new W8Thread();
thread1.start();
UpTestThread thread2 = new UpTestThread();
thread2.start();

//We now allow the user to enter a command
String command;
System.out.println("vous pouvez maintenant lancer une commande si vous le souhaitez");
System.out.println("tapez help pour plus d'informations");
boolean exit=false;

while(exit==false){
command=sc.next();

if(command.equals("help")){
System.out.println("print => affiche la liste des arduinos");
System.out.println("exit => ferme le programme");
}
if(command.equals("print")){linker.PrintArdList();}
if(command.equals("exit")){exit=true;}

}
//if the user ask to stop the program, it will do those final commands
sc.close();
thread1.stop();
thread2.stop();
xbee.XbeeClosing();
//System.out.println("Program finished successfully");

}

}

</code>

Le main est la racine du programme. Il va créer les ressources nécessaires pour la connexion à la base de donnée et au XBee lui même connecté au PC.
Il crée ensuite 2 threads, l'un faisant une MAJ des valeurs des Arduinos dans la base de donnée à intervalles réguliers.
L'autre regarde sur la base de donnée si un utilisateur a fait une demande de MAJ, et ce toute les secondes, puis y répond.

====La classe SQLinker====
<code>
public class SQLinker {

Connection connect;
Statement stmt;
PreparedStatement pst;
ResultSet rs;
int[] ArdList = new int[10];
int[][] ArdListMatrix = new int[10][2];
String[] table = {"Battery", "Light", "Temperature", "Updating"};
//List of variables used to connect to the database and store some informations

//Constructor, create a connection when called
public SQLinker(String address, String user){

try{
Class.forName("com.mysql.jdbc.Driver").newInstance();
} catch(Exception ex){
System.out.println("can't register the Driver");
}

try{
connect = DriverManager.getConnection(address+user);
stmt = connect.createStatement();
} catch(Exception ex){
System.out.println("connection issue");
System.out.println("SQLException: " + ex.getMessage());
}
if (connect!= null){
System.out.println("connected to the database " + address);
}

}
//Fill a matrix with the list of Arduinos stored in the database
public void FillArdList(){
try{
rs = stmt.executeQuery("SELECT Arduino FROM Arduinos");
int i=0;
int m,c,d,u;
while(rs.next()){
ArdList[i] = Integer.parseInt(rs.getString(1));
m=ArdList[i]/1000;
c=(ArdList[i]-m*1000)/100;
d=(ArdList[i]-m*1000-c*100)/10;
u=(ArdList[i]-m*1000-c*100-d*10);
ArdListMatrix[i][0]=(m*10+c);
ArdListMatrix[i][1]=(d*10+u);
i++;
}
ArdList[i]=-1;
} catch (SQLException e){
System.out.println("SQLException: " + e.getMessage());
System.out.println("SQLState: " + e.getSQLState());
System.out.println("VendorError: " + e.getErrorCode());
}
}

//print the list of arduinos stored in the program
public void PrintArdList(){
int i=0;
while(ArdList[i]!=-1){
i++;
System.out.println("Code Arduino n°"+i+": "+ArdList[i]);

}
}

//Print the values of a specific arduino
public void PrintArdValues(int ard){
for(int i=0; i<=2;i++){

try {
rs = stmt.executeQuery("SELECT " +table[i]+" FROM Arduinos WHERE Arduino ="+ard);
} catch (SQLException e) {
e.printStackTrace();
}
try {
while(rs.next()){
System.out.println(table[i] +"=" + rs.getString(1));
}
} catch (SQLException e) {
e.printStackTrace();
}

}
}

//print the values of every arduino stored in the program
public void PrintAllArdValues(){
int i=0;
while(ArdList[i]!=-1){
this.PrintArdValues(i);
}
}

//set the values obtained from an arduino to the database
public void SetArdValues(int Ard, int[] values){
int i=0;
while(values[i]!=-1){

try {
pst = connect.prepareStatement("UPDATE Arduinos SET "+table[values[i]]+" = "+values[i+1] +" WHERE Arduino ="+Ard);
pst.executeUpdate();
} catch (SQLException e){
e.printStackTrace();
}

i+=2;
}
}

//verify if an update as been demanded by a user on the website
public int CheckUpdate(){
int i=0;
int ret=0;
while(ArdList[i]!=-1 && ret!=1){
try {
rs = stmt.executeQuery("SELECT Updating FROM Arduinos WHERE Arduino ="+ArdList[i]);
while(rs.next()){
ret = Integer.parseInt(rs.getString(1));
}
} catch (SQLException e) {
e.printStackTrace();
}
i++;
}
return ret; //return 1 if update demanded

}
}

</code>
Cette classe regroupe toutes les fonctions permettant de se connecter à une base de donnée et d'en traiter les données.

=== Liste du matériel à acheter ===

Objets communiquants et gestion de l'énergie

2013-02-22T16:33:52Z

Cdelberg : /* le programme LINKER */

== Présentation du projet ==

=== Planning prévisionnel provisoire (jusqu'à la pré-soutenance)===

Ce planning pourrait être amené à être modifié.

'''''I) Etat de l'art''''' ( ~2-3 semaines)

-Energy harvesting (Calvin)

-Batteries (Justin)

'''''II) Mesure de puissance des différents appareil Arduino''''' ( ~2 semaines)

'''''III) Confronter théorie/réalité''''' ( ~1 semaine)
-estimer consommation de puissance

-vérifier en pratique

'''Amené à être ajouté:'''

Mesure du Arduino de sa propre consommation.

Mesure de la consommation du code (?)

Applications:

-Envoi des valeurs de l'Arduino au serveur.

-Interface web pour interagir avec l'objet.

== Etat de l'art ==

=== Energy Harvesting ===
 
* Mosquino:

''Mosquino'' est un matériel compatible avec le développement logiciel et dérivé de ''Arduino'', il permet de récupérer de l'énergie des sources ambiantes (chaleur, luminosité, vibrations)
Il n'est destiné qu'aux faibles consommations électriques et n'est encore qu'en phase de développement, il n'a pas encore été véritablement testé. 
http://tim.cexx.org/?page_id=760
 
* Breakout board BOB-o9946 :

Cette carte utilise le collecteur d'énergie piezoelectrique LTC3588 de Linear Technologies et permet non seulement de récupérer l'énergie piezoélectrique mais aussi l'énergie solaire. Initialement prévu pour fonctionner à faible voltage, la capacité de sortie peut-être dimensionnée pour recevoir une salve de courant de sortie plus élevée. 
https://www.sparkfun.com/products/9946
 
=== Batteries ===
 
* nouvelles technologies:

ces dernières années, de nouvelles technologies sont apparues, sans être encore réellement utilisées. je pense notamment aux batteries contenues dans des câbles:
http://phys.org/news/2012-09-lg-chem-cable-batteries-reshape.html

ainsi qu'aux batteries ultra fines dévellopées par thinergy:
http://www.infinitepowersolutions.com/products.html

Néanmoins, les tensions pouvant etre délivrées par ces technologies naissantes sont loin de pouvoir alimenter le materiel qui nous interresse, à savoir des Arduino (necessitant une alimentation comprise entre 7V-12V)

D'autres techno sont encore en phase de développement, comme les batteries lithium-Air d'IBM, les piles au graphène utilisant la chaleur pour produire de l’énergie (plutôt de l'energy harvesting pour le coup). Comme ces technologies sont encore en phase de développement, elles n’apparaîtrons pas sur le marché avant au moins 10 ans.

http://www.metro.co.uk/tech/news/897731-technology-companies-charge-towards-next-generation-battery-future

* technologies adaptée à notre usage:

comme je l'ai rappelé plus haut, ce PFE tourne principalement autour d'Arduino. ces plates-formes nécessitant une tension d'alimentation supérieure à 7V, le choix le plus intéressant reste les piles rechargeable.

Seulement, il existe plusieurs types de piles rechargeables. dans l'usage qu'il en sera fait, et si ces batteries sont couplées à des technologies de récupération d'énergie, il est important de choisir des piles Lithium-Ion.

En effet, ces piles sont les plus intéressantes pour plusieurs raisons:

tout d'abord, elles sont insensibles à l'effet mémoire. du coup elles ne perdent pas de leur capacité de stockage d’énergie au cours du temps.

le circuit intégré à ces piles empêche toute surtension lors de la charge.

elles peuvent être rechargée en même temps qu'elles sont utilisées.

dans une époque ou la pollution est un sujet préoccupation, ces piles sont moins dangereuse pour l’environnement que leurs homologues au nickel-Cadmium

le seul problème pourrais venir du fait qu'elles ne supporte pas bien la chaleur, mais à moins de les coller à un radiateur, il ne devrais pas y avoir de soucis.

=== Mesure de la consommation énergétique ===

WSIM permet la simulation de capteurs sans fil. Il permet notamment d'estimer la consommation électrique http://wsim.gforge.inria.fr/index.html
Pour l'instant il ne fonctionne qu'avec des microcontrolleurs TI. Le support des AVR est en cours.
L'estimation de la consommation énergétique utilise esimu http://esimu.gforge.inria.fr/index.html

== Réalisation ==
===Le Arduino===
====Architecture de l'objet communiquant====

*Un Arduino Mega 2560
*Un XBee
*Un capteur de température
*Un capteur de luminosité
*Un accéléromètre (dont les valeurs ne seront pas utilisées mais qui devait servir d'appareil supplémentaire pour la problématique de consommation)

====Le code du Arduino====

<code>
#include <XBee.h>

// Define variables, pins..
int sensorTempPin = 0;
int Temp;
int sensorLightPin = 1;
int Light;
int XPin = 2;
int YPin = 3;
int ZPin = 4;
int XValue;
int YValue;
int ZValue;

uint8_t values[] = { 0, 0, 0, 0 };
XBee xbee = XBee();
XBeeResponse response = XBeeResponse();
Rx16Response rx = Rx16Response();
Tx16Request tx = Tx16Request(0x1111, values, sizeof(values));
TxStatusResponse txStatus = TxStatusResponse();

void setup()
{
// Initialise xbee / serial
xbee.begin(9600);
Serial.begin(9600);
}

void loop()
{
// Read the values on analog pins
Light = analogRead(sensorLightPin);
Temp = analogRead(sensorTempPin);
//XValue = analogRead(XPin);//
//YValue = analogRead(YPin);//Not used
//ZValue = analogRead(ZPin);//

// Listens on the Xbee protocol for any packet incoming.
xbee.readPacket();

if(xbee.getResponse().isAvailable()){
// Got something
Serial.print("Got something\n");
// Break the 10-bits of information retrieved from light
// and temperature into 2 bytes for each.
values[0] = Temp >> 8 & 0xff;
values[1] = Temp & 0xff;
values[2] = Light >> 8 & 0xff;
values[3] = Light & 0xff;
Serial.print(values[0]);

// Sending values to server
xbee.send(tx);

// After sending a tx request, we expect a status response
// from the server
// Wait up to 5 seconds for the status response

if (xbee.readPacket(5000)) {
// We got a response!
Serial.print("We got a response\n");

// It should be a znet tx status
if (xbee.getResponse().getApiId() == TX_STATUS_RESPONSE) {
xbee.getResponse().getZBTxStatusResponse(txStatus);

// get the delivery status, the fifth byte
if (txStatus.getStatus() == SUCCESS){
// Success! Time to celebrate
Serial.print("SUCCESS! Time to celebrate\n");
} else {
// The remote XBee did not receive our packet. Is it powered on?
Serial.print("The remote Xbee did not receive our packet\n");
}
}
} else {
// local XBee did not provide a timely TX Status Response -- should not happen
Serial.print("Local Xbee did not provide a timely TX Status Response\n");
}

}

delay(500);
}
</code>
Ce code fonctionne de la manière suivante:
=====Fonction setup():=====
Une fois implémenté sur le Arduino, la fonction setup va faire démarrer le protocole XBee et le protocole Série afin de pouvoir envoyer et recevoir des messages par XBee, et d'imprimer les messages d'erreur sur le port Série s'il y a lieu.
=====Fonction loop():=====
Cette fonction va réaliser une boucle toutes les 0.5s pour mettre a jour les données des différents capteurs et les envoyer au serveur au travers du protocole XBee. Pour plus de détails voir les commentaires expliquant chaque étape du déroulement de la boucle.

===Le programme LINKER===

Code du programme de liaison

ce programme en java est constitué de 5 classes

====Le Main====
<code>
public class main {

public static SQLinker linker;
public static Xbee xbee;

public static void main(String[] args){
String address = new String("jdbc:mysql://sitedb.polytech-lille.net/cdelberg?");
String user = new String("user=cdelberg&password=myLo9ufonese");
String COM;

// We ask the user on the Communication Port to connect the XBee
System.out.println("Please enter the Communication port of the Xbee");
Scanner sc = new Scanner(System.in);
COM = sc.next();
System.out.println("COM port changed to: "+COM);

//Creation of the Variables that will be used to connect to the Database and the Xbee
linker = new SQLinker(address, user);
linker.FillArdList();
xbee = new Xbee(COM);

//Creating the Updates Threads
W8Thread thread1 = new W8Thread();
thread1.start();
UpTestThread thread2 = new UpTestThread();
thread2.start();

//We now allow the user to enter a command
String command;
System.out.println("vous pouvez maintenant lancer une commande si vous le souhaitez");
System.out.println("tapez help pour plus d'informations");
boolean exit=false;

while(exit==false){
command=sc.next();

if(command.equals("help")){
System.out.println("print => affiche la liste des arduinos");
System.out.println("exit => ferme le programme");
}
if(command.equals("print")){linker.PrintArdList();}
if(command.equals("exit")){exit=true;}

}
//if the user ask to stop the program, it will do those final commands
sc.close();
thread1.stop();
thread2.stop();
xbee.XbeeClosing();
//System.out.println("Program finished successfully");

}

}

</code>

Le main est la racine du programme. Il va créer les ressources nécessaires pour la connexion à la base de donnée et au XBee lui même connecté au PC.
Il crée ensuite 2 threads, l'un faisant une MAJ des valeurs des Arduinos dans la base de donnée à intervalles réguliers.
L'autre regarde sur la base de donnée si un utilisateur a fait une demande de MAJ, et ce toute les secondes, puis y répond.

====La classe SQLinker====
<code>
public class SQLinker {

Connection connect;
Statement stmt;
PreparedStatement pst;
ResultSet rs;
int[] ArdList = new int[10];
int[][] ArdListMatrix = new int[10][2];
String[] table = {"Battery", "Light", "Temperature", "Updating"};
//List of variables used to connect to the database and store some informations

//Constructor, create a connection when called
public SQLinker(String address, String user){

try{
Class.forName("com.mysql.jdbc.Driver").newInstance();
} catch(Exception ex){
System.out.println("can't register the Driver");
}

try{
connect = DriverManager.getConnection(address+user);
stmt = connect.createStatement();
} catch(Exception ex){
System.out.println("connection issue");
System.out.println("SQLException: " + ex.getMessage());
}
if (connect!= null){
System.out.println("connected to the database " + address);
}

}
//Fill a matrix with the list of Arduinos stored in the database
public void FillArdList(){
try{
rs = stmt.executeQuery("SELECT Arduino FROM Arduinos");
int i=0;
int m,c,d,u;
while(rs.next()){
ArdList[i] = Integer.parseInt(rs.getString(1));
m=ArdList[i]/1000;
c=(ArdList[i]-m*1000)/100;
d=(ArdList[i]-m*1000-c*100)/10;
u=(ArdList[i]-m*1000-c*100-d*10);
ArdListMatrix[i][0]=(m*10+c);
ArdListMatrix[i][1]=(d*10+u);
i++;
}
ArdList[i]=-1;
} catch (SQLException e){
System.out.println("SQLException: " + e.getMessage());
System.out.println("SQLState: " + e.getSQLState());
System.out.println("VendorError: " + e.getErrorCode());
}
}

//print the list of arduinos stored in the program
public void PrintArdList(){
int i=0;
while(ArdList[i]!=-1){
i++;
System.out.println("Code Arduino n°"+i+": "+ArdList[i]);

}
}

//Print the values of a specific arduino
public void PrintArdValues(int ard){
for(int i=0; i<=2;i++){

try {
rs = stmt.executeQuery("SELECT " +table[i]+" FROM Arduinos WHERE Arduino ="+ard);
} catch (SQLException e) {
e.printStackTrace();
}
try {
while(rs.next()){
System.out.println(table[i] +"=" + rs.getString(1));
}
} catch (SQLException e) {
e.printStackTrace();
}

}
}

//print the values of every arduino stored in the program
public void PrintAllArdValues(){
int i=0;
while(ArdList[i]!=-1){
this.PrintArdValues(i);
}
}

//set the values obtained from an arduino to the database
public void SetArdValues(int Ard, int[] values){
int i=0;
while(values[i]!=-1){

try {
pst = connect.prepareStatement("UPDATE Arduinos SET "+table[values[i]]+" = "+values[i+1] +" WHERE Arduino ="+Ard);
pst.executeUpdate();
} catch (SQLException e){
e.printStackTrace();
}

i+=2;
}
}

//verify if an update as been demanded by a user on the website
public int CheckUpdate(){
int i=0;
int ret=0;
while(ArdList[i]!=-1 && ret!=1){
try {
rs = stmt.executeQuery("SELECT Updating FROM Arduinos WHERE Arduino ="+ArdList[i]);
while(rs.next()){
ret = Integer.parseInt(rs.getString(1));
}
} catch (SQLException e) {
e.printStackTrace();
}
i++;
}
return ret; //return 1 if update demanded

}
}

</code>
Cette classe regroupe toutes les fonctions permettant de se connecter à une base de donnée et d'en traiter les données.

=== Liste du matériel à acheter ===

Objets communiquants et gestion de l'énergie

2013-02-22T15:35:23Z

Cdelberg : /* Le code du Arduino */

== Présentation du projet ==

=== Planning prévisionnel provisoire (jusqu'à la pré-soutenance)===

Ce planning pourrait être amené à être modifié.

'''''I) Etat de l'art''''' ( ~2-3 semaines)

-Energy harvesting (Calvin)

-Batteries (Justin)

'''''II) Mesure de puissance des différents appareil Arduino''''' ( ~2 semaines)

'''''III) Confronter théorie/réalité''''' ( ~1 semaine)
-estimer consommation de puissance

-vérifier en pratique

'''Amené à être ajouté:'''

Mesure du Arduino de sa propre consommation.

Mesure de la consommation du code (?)

Applications:

-Envoi des valeurs de l'Arduino au serveur.

-Interface web pour interagir avec l'objet.

== Etat de l'art ==

=== Energy Harvesting ===
 
* Mosquino:

''Mosquino'' est un matériel compatible avec le développement logiciel et dérivé de ''Arduino'', il permet de récupérer de l'énergie des sources ambiantes (chaleur, luminosité, vibrations)
Il n'est destiné qu'aux faibles consommations électriques et n'est encore qu'en phase de développement, il n'a pas encore été véritablement testé. 
http://tim.cexx.org/?page_id=760
 
* Breakout board BOB-o9946 :

Cette carte utilise le collecteur d'énergie piezoelectrique LTC3588 de Linear Technologies et permet non seulement de récupérer l'énergie piezoélectrique mais aussi l'énergie solaire. Initialement prévu pour fonctionner à faible voltage, la capacité de sortie peut-être dimensionnée pour recevoir une salve de courant de sortie plus élevée. 
https://www.sparkfun.com/products/9946
 
=== Batteries ===
 
* nouvelles technologies:

ces dernières années, de nouvelles technologies sont apparues, sans être encore réellement utilisées. je pense notamment aux batteries contenues dans des câbles:
http://phys.org/news/2012-09-lg-chem-cable-batteries-reshape.html

ainsi qu'aux batteries ultra fines dévellopées par thinergy:
http://www.infinitepowersolutions.com/products.html

Néanmoins, les tensions pouvant etre délivrées par ces technologies naissantes sont loin de pouvoir alimenter le materiel qui nous interresse, à savoir des Arduino (necessitant une alimentation comprise entre 7V-12V)

D'autres techno sont encore en phase de développement, comme les batteries lithium-Air d'IBM, les piles au graphène utilisant la chaleur pour produire de l’énergie (plutôt de l'energy harvesting pour le coup). Comme ces technologies sont encore en phase de développement, elles n’apparaîtrons pas sur le marché avant au moins 10 ans.

http://www.metro.co.uk/tech/news/897731-technology-companies-charge-towards-next-generation-battery-future

* technologies adaptée à notre usage:

comme je l'ai rappelé plus haut, ce PFE tourne principalement autour d'Arduino. ces plates-formes nécessitant une tension d'alimentation supérieure à 7V, le choix le plus intéressant reste les piles rechargeable.

Seulement, il existe plusieurs types de piles rechargeables. dans l'usage qu'il en sera fait, et si ces batteries sont couplées à des technologies de récupération d'énergie, il est important de choisir des piles Lithium-Ion.

En effet, ces piles sont les plus intéressantes pour plusieurs raisons:

tout d'abord, elles sont insensibles à l'effet mémoire. du coup elles ne perdent pas de leur capacité de stockage d’énergie au cours du temps.

le circuit intégré à ces piles empêche toute surtension lors de la charge.

elles peuvent être rechargée en même temps qu'elles sont utilisées.

dans une époque ou la pollution est un sujet préoccupation, ces piles sont moins dangereuse pour l’environnement que leurs homologues au nickel-Cadmium

le seul problème pourrais venir du fait qu'elles ne supporte pas bien la chaleur, mais à moins de les coller à un radiateur, il ne devrais pas y avoir de soucis.

=== Mesure de la consommation énergétique ===

WSIM permet la simulation de capteurs sans fil. Il permet notamment d'estimer la consommation électrique http://wsim.gforge.inria.fr/index.html
Pour l'instant il ne fonctionne qu'avec des microcontrolleurs TI. Le support des AVR est en cours.
L'estimation de la consommation énergétique utilise esimu http://esimu.gforge.inria.fr/index.html

== Réalisation ==
===Le Arduino===
====Architecture de l'objet communiquant====

*Un Arduino Mega 2560
*Un XBee
*Un capteur de température
*Un capteur de luminosité
*Un accéléromètre (dont les valeurs ne seront pas utilisées mais qui devait servir d'appareil supplémentaire pour la problématique de consommation)

====Le code du Arduino====

<code>
#include <XBee.h>

// Define variables, pins..
int sensorTempPin = 0;
int Temp;
int sensorLightPin = 1;
int Light;
int XPin = 2;
int YPin = 3;
int ZPin = 4;
int XValue;
int YValue;
int ZValue;

uint8_t values[] = { 0, 0, 0, 0 };
XBee xbee = XBee();
XBeeResponse response = XBeeResponse();
Rx16Response rx = Rx16Response();
Tx16Request tx = Tx16Request(0x1111, values, sizeof(values));
TxStatusResponse txStatus = TxStatusResponse();

void setup()
{
// Initialise xbee / serial
xbee.begin(9600);
Serial.begin(9600);
}

void loop()
{
// Read the values on analog pins
Light = analogRead(sensorLightPin);
Temp = analogRead(sensorTempPin);
//XValue = analogRead(XPin);//
//YValue = analogRead(YPin);//Not used
//ZValue = analogRead(ZPin);//

// Listens on the Xbee protocol for any packet incoming.
xbee.readPacket();

if(xbee.getResponse().isAvailable()){
// Got something
Serial.print("Got something\n");
// Break the 10-bits of information retrieved from light
// and temperature into 2 bytes for each.
values[0] = Temp >> 8 & 0xff;
values[1] = Temp & 0xff;
values[2] = Light >> 8 & 0xff;
values[3] = Light & 0xff;
Serial.print(values[0]);

// Sending values to server
xbee.send(tx);

// After sending a tx request, we expect a status response
// from the server
// Wait up to 5 seconds for the status response

if (xbee.readPacket(5000)) {
// We got a response!
Serial.print("We got a response\n");

// It should be a znet tx status
if (xbee.getResponse().getApiId() == TX_STATUS_RESPONSE) {
xbee.getResponse().getZBTxStatusResponse(txStatus);

// get the delivery status, the fifth byte
if (txStatus.getStatus() == SUCCESS){
// Success! Time to celebrate
Serial.print("SUCCESS! Time to celebrate\n");
} else {
// The remote XBee did not receive our packet. Is it powered on?
Serial.print("The remote Xbee did not receive our packet\n");
}
}
} else {
// local XBee did not provide a timely TX Status Response -- should not happen
Serial.print("Local Xbee did not provide a timely TX Status Response\n");
}

}

delay(500);
}
</code>
Ce code fonctionne de la manière suivante:
=====Fonction setup():=====
Une fois implémenté sur le Arduino, la fonction setup va faire démarrer le protocole XBee et le protocole Série afin de pouvoir envoyer et recevoir des messages par XBee, et d'imprimer les messages d'erreur sur le port Série s'il y a lieu.
=====Fonction loop():=====
Cette fonction va réaliser une boucle toutes les 0.5s pour mettre a jour les données des différents capteurs et les envoyer au serveur au travers du protocole XBee. Pour plus de détails voir les commentaires expliquant chaque étape du déroulement de la boucle.

===le programme LINKER===

Code du programme de liaison

ce programme en java est constitué de 5 classes

====Le Main====
<code>
public class main {

public static SQLinker linker;
public static Xbee xbee;

public static void main(String[] args){
String address = new String("jdbc:mysql://sitedb.polytech-lille.net/cdelberg?");
String user = new String("user=cdelberg&password=myLo9ufonese");
String COM;

// We ask the user on the Communication Port to connect the XBee
System.out.println("Please enter the Communication port of the Xbee");
Scanner sc = new Scanner(System.in);
COM = sc.next();
System.out.println("COM port changed to: "+COM);

//Creation of the Variables that will be used to connect to the Database and the Xbee
linker = new SQLinker(address, user);
linker.FillArdList();
xbee = new Xbee(COM);

//Creating the Updates Threads
W8Thread thread1 = new W8Thread();
thread1.start();
UpTestThread thread2 = new UpTestThread();
thread2.start();

//We now allow the user to enter a command
String command;
System.out.println("vous pouvez maintenant lancer une commande si vous le souhaitez");
System.out.println("tapez help pour plus d'informations");
boolean exit=false;

while(exit==false){
command=sc.next();

if(command.equals("help")){
System.out.println("print => affiche la liste des arduinos");
System.out.println("exit => ferme le programme");
}
if(command.equals("print")){linker.PrintArdList();}
if(command.equals("exit")){exit=true;}

}
//if the user ask to stop the program, it will do those final commands
sc.close();
thread1.stop();
thread2.stop();
xbee.XbeeClosing();
//System.out.println("Program finished successfully");

}

}

</code>

=== Liste du matériel à acheter ===

Objets communiquants et gestion de l'énergie

2013-02-22T15:33:47Z

Cdelberg : /* Fonction loop(): */

== Présentation du projet ==

=== Planning prévisionnel provisoire (jusqu'à la pré-soutenance)===

Ce planning pourrait être amené à être modifié.

'''''I) Etat de l'art''''' ( ~2-3 semaines)

-Energy harvesting (Calvin)

-Batteries (Justin)

'''''II) Mesure de puissance des différents appareil Arduino''''' ( ~2 semaines)

'''''III) Confronter théorie/réalité''''' ( ~1 semaine)
-estimer consommation de puissance

-vérifier en pratique

'''Amené à être ajouté:'''

Mesure du Arduino de sa propre consommation.

Mesure de la consommation du code (?)

Applications:

-Envoi des valeurs de l'Arduino au serveur.

-Interface web pour interagir avec l'objet.

== Etat de l'art ==

=== Energy Harvesting ===
 
* Mosquino:

''Mosquino'' est un matériel compatible avec le développement logiciel et dérivé de ''Arduino'', il permet de récupérer de l'énergie des sources ambiantes (chaleur, luminosité, vibrations)
Il n'est destiné qu'aux faibles consommations électriques et n'est encore qu'en phase de développement, il n'a pas encore été véritablement testé. 
http://tim.cexx.org/?page_id=760
 
* Breakout board BOB-o9946 :

Cette carte utilise le collecteur d'énergie piezoelectrique LTC3588 de Linear Technologies et permet non seulement de récupérer l'énergie piezoélectrique mais aussi l'énergie solaire. Initialement prévu pour fonctionner à faible voltage, la capacité de sortie peut-être dimensionnée pour recevoir une salve de courant de sortie plus élevée. 
https://www.sparkfun.com/products/9946
 
=== Batteries ===
 
* nouvelles technologies:

ces dernières années, de nouvelles technologies sont apparues, sans être encore réellement utilisées. je pense notamment aux batteries contenues dans des câbles:
http://phys.org/news/2012-09-lg-chem-cable-batteries-reshape.html

ainsi qu'aux batteries ultra fines dévellopées par thinergy:
http://www.infinitepowersolutions.com/products.html

Néanmoins, les tensions pouvant etre délivrées par ces technologies naissantes sont loin de pouvoir alimenter le materiel qui nous interresse, à savoir des Arduino (necessitant une alimentation comprise entre 7V-12V)

D'autres techno sont encore en phase de développement, comme les batteries lithium-Air d'IBM, les piles au graphène utilisant la chaleur pour produire de l’énergie (plutôt de l'energy harvesting pour le coup). Comme ces technologies sont encore en phase de développement, elles n’apparaîtrons pas sur le marché avant au moins 10 ans.

http://www.metro.co.uk/tech/news/897731-technology-companies-charge-towards-next-generation-battery-future

* technologies adaptée à notre usage:

comme je l'ai rappelé plus haut, ce PFE tourne principalement autour d'Arduino. ces plates-formes nécessitant une tension d'alimentation supérieure à 7V, le choix le plus intéressant reste les piles rechargeable.

Seulement, il existe plusieurs types de piles rechargeables. dans l'usage qu'il en sera fait, et si ces batteries sont couplées à des technologies de récupération d'énergie, il est important de choisir des piles Lithium-Ion.

En effet, ces piles sont les plus intéressantes pour plusieurs raisons:

tout d'abord, elles sont insensibles à l'effet mémoire. du coup elles ne perdent pas de leur capacité de stockage d’énergie au cours du temps.

le circuit intégré à ces piles empêche toute surtension lors de la charge.

elles peuvent être rechargée en même temps qu'elles sont utilisées.

dans une époque ou la pollution est un sujet préoccupation, ces piles sont moins dangereuse pour l’environnement que leurs homologues au nickel-Cadmium

le seul problème pourrais venir du fait qu'elles ne supporte pas bien la chaleur, mais à moins de les coller à un radiateur, il ne devrais pas y avoir de soucis.

=== Mesure de la consommation énergétique ===

WSIM permet la simulation de capteurs sans fil. Il permet notamment d'estimer la consommation électrique http://wsim.gforge.inria.fr/index.html
Pour l'instant il ne fonctionne qu'avec des microcontrolleurs TI. Le support des AVR est en cours.
L'estimation de la consommation énergétique utilise esimu http://esimu.gforge.inria.fr/index.html

== Réalisation ==
===Le Arduino===
====Architecture de l'objet communiquant====

*Un Arduino Mega 2560
*Un XBee
*Un capteur de température
*Un capteur de luminosité
*Un accéléromètre (dont les valeurs ne seront pas utilisées mais qui devait servir d'appareil supplémentaire pour la problématique de consommation)

====Le code du Arduino====

<code>
#include <XBee.h>

// Define variables, pins..
int sensorTempPin = 0;
int Temp;
int sensorLightPin = 1;
int Light;
int XPin = 2;
int YPin = 3;
int ZPin = 4;
int XValue;
int YValue;
int ZValue;

uint8_t values[] = { 0, 0, 0, 0 };
XBee xbee = XBee();
XBeeResponse response = XBeeResponse();
Rx16Response rx = Rx16Response();
Tx16Request tx = Tx16Request(0x1111, values, sizeof(values));
TxStatusResponse txStatus = TxStatusResponse();

void setup()
{
// Initialise xbee / serial
xbee.begin(9600);
Serial.begin(9600);
}

void loop()
{
// Read the values on analog pins
Light = analogRead(sensorLightPin);
Temp = analogRead(sensorTempPin);
XValue = analogRead(XPin);
YValue = analogRead(YPin);
ZValue = analogRead(ZPin);

// Listens on the Xbee protocol for any packet incoming.
xbee.readPacket();

if(xbee.getResponse().isAvailable()){
// Got something
Serial.print("Got something\n");
// Break the 10-bits of information retrieved from light
// and temperature into 2 bytes for each.
values[0] = Temp >> 8 & 0xff;
values[1] = Temp & 0xff;
values[2] = Light >> 8 & 0xff;
values[3] = Light & 0xff;
Serial.print(values[0]);

// Sending values to server
xbee.send(tx);

// After sending a tx request, we expect a status response
// from the server
// Wait up to 5 seconds for the status response

if (xbee.readPacket(5000)) {
// We got a response!
Serial.print("We got a response\n");

// It should be a znet tx status
if (xbee.getResponse().getApiId() == TX_STATUS_RESPONSE) {
xbee.getResponse().getZBTxStatusResponse(txStatus);

// get the delivery status, the fifth byte
if (txStatus.getStatus() == SUCCESS){
// Success! Time to celebrate
Serial.print("SUCCESS! Time to celebrate\n");
} else {
// The remote XBee did not receive our packet. Is it powered on?
Serial.print("The remote Xbee did not receive our packet\n");
}
}
} else {
// local XBee did not provide a timely TX Status Response -- should not happen
Serial.print("Local Xbee did not provide a timely TX Status Response\n");
}

}

delay(500);
}
</code>
Ce code fonctionne de la manière suivante:
=====Fonction setup():=====
Une fois implémenté sur le Arduino, la fonction setup va faire démarrer le protocole XBee et le protocole Série afin de pouvoir envoyer et recevoir des messages par XBee, et d'imprimer les messages d'erreur sur le port Série s'il y a lieu.
=====Fonction loop():=====
Cette fonction va réaliser une boucle toutes les 0.5s pour mettre a jour les données des différents capteurs et les envoyer au serveur au travers du protocole XBee. Pour plus de détails voir les commentaires expliquant chaque étape du déroulement de la boucle.

===le programme LINKER===

Code du programme de liaison

ce programme en java est constitué de 5 classes

====Le Main====
<code>
public class main {

public static SQLinker linker;
public static Xbee xbee;

public static void main(String[] args){
String address = new String("jdbc:mysql://sitedb.polytech-lille.net/cdelberg?");
String user = new String("user=cdelberg&password=myLo9ufonese");
String COM;

// We ask the user on the Communication Port to connect the XBee
System.out.println("Please enter the Communication port of the Xbee");
Scanner sc = new Scanner(System.in);
COM = sc.next();
System.out.println("COM port changed to: "+COM);

//Creation of the Variables that will be used to connect to the Database and the Xbee
linker = new SQLinker(address, user);
linker.FillArdList();
xbee = new Xbee(COM);

//Creating the Updates Threads
W8Thread thread1 = new W8Thread();
thread1.start();
UpTestThread thread2 = new UpTestThread();
thread2.start();

//We now allow the user to enter a command
String command;
System.out.println("vous pouvez maintenant lancer une commande si vous le souhaitez");
System.out.println("tapez help pour plus d'informations");
boolean exit=false;

while(exit==false){
command=sc.next();

if(command.equals("help")){
System.out.println("print => affiche la liste des arduinos");
System.out.println("exit => ferme le programme");
}
if(command.equals("print")){linker.PrintArdList();}
if(command.equals("exit")){exit=true;}

}
//if the user ask to stop the program, it will do those final commands
sc.close();
thread1.stop();
thread2.stop();
xbee.XbeeClosing();
//System.out.println("Program finished successfully");

}

}

</code>

=== Liste du matériel à acheter ===

Objets communiquants et gestion de l'énergie

2013-02-22T15:33:04Z

Cdelberg : /* Le code du Arduino */

== Présentation du projet ==

=== Planning prévisionnel provisoire (jusqu'à la pré-soutenance)===

Ce planning pourrait être amené à être modifié.

'''''I) Etat de l'art''''' ( ~2-3 semaines)

-Energy harvesting (Calvin)

-Batteries (Justin)

'''''II) Mesure de puissance des différents appareil Arduino''''' ( ~2 semaines)

'''''III) Confronter théorie/réalité''''' ( ~1 semaine)
-estimer consommation de puissance

-vérifier en pratique

'''Amené à être ajouté:'''

Mesure du Arduino de sa propre consommation.

Mesure de la consommation du code (?)

Applications:

-Envoi des valeurs de l'Arduino au serveur.

-Interface web pour interagir avec l'objet.

== Etat de l'art ==

=== Energy Harvesting ===
 
* Mosquino:

''Mosquino'' est un matériel compatible avec le développement logiciel et dérivé de ''Arduino'', il permet de récupérer de l'énergie des sources ambiantes (chaleur, luminosité, vibrations)
Il n'est destiné qu'aux faibles consommations électriques et n'est encore qu'en phase de développement, il n'a pas encore été véritablement testé. 
http://tim.cexx.org/?page_id=760
 
* Breakout board BOB-o9946 :

Cette carte utilise le collecteur d'énergie piezoelectrique LTC3588 de Linear Technologies et permet non seulement de récupérer l'énergie piezoélectrique mais aussi l'énergie solaire. Initialement prévu pour fonctionner à faible voltage, la capacité de sortie peut-être dimensionnée pour recevoir une salve de courant de sortie plus élevée. 
https://www.sparkfun.com/products/9946
 
=== Batteries ===
 
* nouvelles technologies:

ces dernières années, de nouvelles technologies sont apparues, sans être encore réellement utilisées. je pense notamment aux batteries contenues dans des câbles:
http://phys.org/news/2012-09-lg-chem-cable-batteries-reshape.html

ainsi qu'aux batteries ultra fines dévellopées par thinergy:
http://www.infinitepowersolutions.com/products.html

Néanmoins, les tensions pouvant etre délivrées par ces technologies naissantes sont loin de pouvoir alimenter le materiel qui nous interresse, à savoir des Arduino (necessitant une alimentation comprise entre 7V-12V)

D'autres techno sont encore en phase de développement, comme les batteries lithium-Air d'IBM, les piles au graphène utilisant la chaleur pour produire de l’énergie (plutôt de l'energy harvesting pour le coup). Comme ces technologies sont encore en phase de développement, elles n’apparaîtrons pas sur le marché avant au moins 10 ans.

http://www.metro.co.uk/tech/news/897731-technology-companies-charge-towards-next-generation-battery-future

* technologies adaptée à notre usage:

comme je l'ai rappelé plus haut, ce PFE tourne principalement autour d'Arduino. ces plates-formes nécessitant une tension d'alimentation supérieure à 7V, le choix le plus intéressant reste les piles rechargeable.

Seulement, il existe plusieurs types de piles rechargeables. dans l'usage qu'il en sera fait, et si ces batteries sont couplées à des technologies de récupération d'énergie, il est important de choisir des piles Lithium-Ion.

En effet, ces piles sont les plus intéressantes pour plusieurs raisons:

tout d'abord, elles sont insensibles à l'effet mémoire. du coup elles ne perdent pas de leur capacité de stockage d’énergie au cours du temps.

le circuit intégré à ces piles empêche toute surtension lors de la charge.

elles peuvent être rechargée en même temps qu'elles sont utilisées.

dans une époque ou la pollution est un sujet préoccupation, ces piles sont moins dangereuse pour l’environnement que leurs homologues au nickel-Cadmium

le seul problème pourrais venir du fait qu'elles ne supporte pas bien la chaleur, mais à moins de les coller à un radiateur, il ne devrais pas y avoir de soucis.

=== Mesure de la consommation énergétique ===

WSIM permet la simulation de capteurs sans fil. Il permet notamment d'estimer la consommation électrique http://wsim.gforge.inria.fr/index.html
Pour l'instant il ne fonctionne qu'avec des microcontrolleurs TI. Le support des AVR est en cours.
L'estimation de la consommation énergétique utilise esimu http://esimu.gforge.inria.fr/index.html

== Réalisation ==
===Le Arduino===
====Architecture de l'objet communiquant====

*Un Arduino Mega 2560
*Un XBee
*Un capteur de température
*Un capteur de luminosité
*Un accéléromètre (dont les valeurs ne seront pas utilisées mais qui devait servir d'appareil supplémentaire pour la problématique de consommation)

====Le code du Arduino====

<code>
#include <XBee.h>

// Define variables, pins..
int sensorTempPin = 0;
int Temp;
int sensorLightPin = 1;
int Light;
int XPin = 2;
int YPin = 3;
int ZPin = 4;
int XValue;
int YValue;
int ZValue;

uint8_t values[] = { 0, 0, 0, 0 };
XBee xbee = XBee();
XBeeResponse response = XBeeResponse();
Rx16Response rx = Rx16Response();
Tx16Request tx = Tx16Request(0x1111, values, sizeof(values));
TxStatusResponse txStatus = TxStatusResponse();

void setup()
{
// Initialise xbee / serial
xbee.begin(9600);
Serial.begin(9600);
}

void loop()
{
// Read the values on analog pins
Light = analogRead(sensorLightPin);
Temp = analogRead(sensorTempPin);
XValue = analogRead(XPin);
YValue = analogRead(YPin);
ZValue = analogRead(ZPin);

// Listens on the Xbee protocol for any packet incoming.
xbee.readPacket();

if(xbee.getResponse().isAvailable()){
// Got something
Serial.print("Got something\n");
// Break the 10-bits of information retrieved from light
// and temperature into 2 bytes for each.
values[0] = Temp >> 8 & 0xff;
values[1] = Temp & 0xff;
values[2] = Light >> 8 & 0xff;
values[3] = Light & 0xff;
Serial.print(values[0]);

// Sending values to server
xbee.send(tx);

// After sending a tx request, we expect a status response
// from the server
// Wait up to 5 seconds for the status response

if (xbee.readPacket(5000)) {
// We got a response!
Serial.print("We got a response\n");

// It should be a znet tx status
if (xbee.getResponse().getApiId() == TX_STATUS_RESPONSE) {
xbee.getResponse().getZBTxStatusResponse(txStatus);

// get the delivery status, the fifth byte
if (txStatus.getStatus() == SUCCESS){
// Success! Time to celebrate
Serial.print("SUCCESS! Time to celebrate\n");
} else {
// The remote XBee did not receive our packet. Is it powered on?
Serial.print("The remote Xbee did not receive our packet\n");
}
}
} else {
// local XBee did not provide a timely TX Status Response -- should not happen
Serial.print("Local Xbee did not provide a timely TX Status Response\n");
}

}

delay(500);
}
</code>
Ce code fonctionne de la manière suivante:
=====Fonction setup():=====
Une fois implémenté sur le Arduino, la fonction setup va faire démarrer le protocole XBee et le protocole Série afin de pouvoir envoyer et recevoir des messages par XBee, et d'imprimer les messages d'erreur sur le port Série s'il y a lieu.
=====Fonction loop():=====
Cette fonction va réaliser une boucle toutes les 0.5s pour mettre a jour les données des différents capteurs et les envoyer au serveur au travers du protocole XBee.

===le programme LINKER===

Code du programme de liaison

ce programme en java est constitué de 5 classes

====Le Main====
<code>
public class main {

public static SQLinker linker;
public static Xbee xbee;

public static void main(String[] args){
String address = new String("jdbc:mysql://sitedb.polytech-lille.net/cdelberg?");
String user = new String("user=cdelberg&password=myLo9ufonese");
String COM;

// We ask the user on the Communication Port to connect the XBee
System.out.println("Please enter the Communication port of the Xbee");
Scanner sc = new Scanner(System.in);
COM = sc.next();
System.out.println("COM port changed to: "+COM);

//Creation of the Variables that will be used to connect to the Database and the Xbee
linker = new SQLinker(address, user);
linker.FillArdList();
xbee = new Xbee(COM);

//Creating the Updates Threads
W8Thread thread1 = new W8Thread();
thread1.start();
UpTestThread thread2 = new UpTestThread();
thread2.start();

//We now allow the user to enter a command
String command;
System.out.println("vous pouvez maintenant lancer une commande si vous le souhaitez");
System.out.println("tapez help pour plus d'informations");
boolean exit=false;

while(exit==false){
command=sc.next();

if(command.equals("help")){
System.out.println("print => affiche la liste des arduinos");
System.out.println("exit => ferme le programme");
}
if(command.equals("print")){linker.PrintArdList();}
if(command.equals("exit")){exit=true;}

}
//if the user ask to stop the program, it will do those final commands
sc.close();
thread1.stop();
thread2.stop();
xbee.XbeeClosing();
//System.out.println("Program finished successfully");

}

}

</code>

=== Liste du matériel à acheter ===

Objets communiquants et gestion de l'énergie

2013-02-22T15:31:05Z

Cdelberg : /* Fonction loop(): */

== Présentation du projet ==

=== Planning prévisionnel provisoire (jusqu'à la pré-soutenance)===

Ce planning pourrait être amené à être modifié.

'''''I) Etat de l'art''''' ( ~2-3 semaines)

-Energy harvesting (Calvin)

-Batteries (Justin)

'''''II) Mesure de puissance des différents appareil Arduino''''' ( ~2 semaines)

'''''III) Confronter théorie/réalité''''' ( ~1 semaine)
-estimer consommation de puissance

-vérifier en pratique

'''Amené à être ajouté:'''

Mesure du Arduino de sa propre consommation.

Mesure de la consommation du code (?)

Applications:

-Envoi des valeurs de l'Arduino au serveur.

-Interface web pour interagir avec l'objet.

== Etat de l'art ==

=== Energy Harvesting ===
 
* Mosquino:

''Mosquino'' est un matériel compatible avec le développement logiciel et dérivé de ''Arduino'', il permet de récupérer de l'énergie des sources ambiantes (chaleur, luminosité, vibrations)
Il n'est destiné qu'aux faibles consommations électriques et n'est encore qu'en phase de développement, il n'a pas encore été véritablement testé. 
http://tim.cexx.org/?page_id=760
 
* Breakout board BOB-o9946 :

Cette carte utilise le collecteur d'énergie piezoelectrique LTC3588 de Linear Technologies et permet non seulement de récupérer l'énergie piezoélectrique mais aussi l'énergie solaire. Initialement prévu pour fonctionner à faible voltage, la capacité de sortie peut-être dimensionnée pour recevoir une salve de courant de sortie plus élevée. 
https://www.sparkfun.com/products/9946
 
=== Batteries ===
 
* nouvelles technologies:

ces dernières années, de nouvelles technologies sont apparues, sans être encore réellement utilisées. je pense notamment aux batteries contenues dans des câbles:
http://phys.org/news/2012-09-lg-chem-cable-batteries-reshape.html

ainsi qu'aux batteries ultra fines dévellopées par thinergy:
http://www.infinitepowersolutions.com/products.html

Néanmoins, les tensions pouvant etre délivrées par ces technologies naissantes sont loin de pouvoir alimenter le materiel qui nous interresse, à savoir des Arduino (necessitant une alimentation comprise entre 7V-12V)

D'autres techno sont encore en phase de développement, comme les batteries lithium-Air d'IBM, les piles au graphène utilisant la chaleur pour produire de l’énergie (plutôt de l'energy harvesting pour le coup). Comme ces technologies sont encore en phase de développement, elles n’apparaîtrons pas sur le marché avant au moins 10 ans.

http://www.metro.co.uk/tech/news/897731-technology-companies-charge-towards-next-generation-battery-future

* technologies adaptée à notre usage:

comme je l'ai rappelé plus haut, ce PFE tourne principalement autour d'Arduino. ces plates-formes nécessitant une tension d'alimentation supérieure à 7V, le choix le plus intéressant reste les piles rechargeable.

Seulement, il existe plusieurs types de piles rechargeables. dans l'usage qu'il en sera fait, et si ces batteries sont couplées à des technologies de récupération d'énergie, il est important de choisir des piles Lithium-Ion.

En effet, ces piles sont les plus intéressantes pour plusieurs raisons:

tout d'abord, elles sont insensibles à l'effet mémoire. du coup elles ne perdent pas de leur capacité de stockage d’énergie au cours du temps.

le circuit intégré à ces piles empêche toute surtension lors de la charge.

elles peuvent être rechargée en même temps qu'elles sont utilisées.

dans une époque ou la pollution est un sujet préoccupation, ces piles sont moins dangereuse pour l’environnement que leurs homologues au nickel-Cadmium

le seul problème pourrais venir du fait qu'elles ne supporte pas bien la chaleur, mais à moins de les coller à un radiateur, il ne devrais pas y avoir de soucis.

=== Mesure de la consommation énergétique ===

WSIM permet la simulation de capteurs sans fil. Il permet notamment d'estimer la consommation électrique http://wsim.gforge.inria.fr/index.html
Pour l'instant il ne fonctionne qu'avec des microcontrolleurs TI. Le support des AVR est en cours.
L'estimation de la consommation énergétique utilise esimu http://esimu.gforge.inria.fr/index.html

== Réalisation ==
===Le Arduino===
====Architecture de l'objet communiquant====

*Un Arduino Mega 2560
*Un XBee
*Un capteur de température
*Un capteur de luminosité
*Un accéléromètre (dont les valeurs ne seront pas utilisées mais qui devait servir d'appareil supplémentaire pour la problématique de consommation)

====Le code du Arduino====

<code>
#include <XBee.h>

// Define variables, pins..
int sensorTempPin = 0;
int Temp;
int sensorLightPin = 1;
int Light;
int XPin = 2;
int YPin = 3;
int ZPin = 4;
int XValue;
int YValue;
int ZValue;

uint8_t values[] = { 0, 0, 0, 0 };
XBee xbee = XBee();
XBeeResponse response = XBeeResponse();
Rx16Response rx = Rx16Response();
Tx16Request tx = Tx16Request(0x1111, values, sizeof(values));
TxStatusResponse txStatus = TxStatusResponse();

void setup()
{
// Initialise xbee / serial
xbee.begin(9600);
Serial.begin(9600);
}

void loop()
{
// Read the values on analog pins
Light = analogRead(sensorLightPin);
Temp = analogRead(sensorTempPin);
XValue = analogRead(XPin);
YValue = analogRead(YPin);
ZValue = analogRead(ZPin);

xbee.readPacket();

if(xbee.getResponse().isAvailable()){
// Got something
Serial.print("Got something\n");
// Break the 10-bits of information retrieved from light
// and temperature into 2 bytes for each.
values[0] = Temp >> 8 & 0xff;
values[1] = Temp & 0xff;
values[2] = Light >> 8 & 0xff;
values[3] = Light & 0xff;
Serial.print(values[0]);

// Sending values to server
xbee.send(tx);

// After sending a tx request, we expect a status response
// from the server
// Wait up to 5 seconds for the status response

if (xbee.readPacket(5000)) {
// We got a response!
Serial.print("We got a response\n");

// It should be a znet tx status
if (xbee.getResponse().getApiId() == TX_STATUS_RESPONSE) {
xbee.getResponse().getZBTxStatusResponse(txStatus);

// get the delivery status, the fifth byte
if (txStatus.getStatus() == SUCCESS){
// Success! Time to celebrate
Serial.print("SUCCESS! Time to celebrate\n");
} else {
// The remote XBee did not receive our packet. Is it powered on?
Serial.print("The remote Xbee did not receive our packet\n");
}
}
} else {
// local XBee did not provide a timely TX Status Response -- should not happen
Serial.print("Local Xbee did not provide a timely TX Status Response\n");
}

}

delay(500);
}
</code>
Ce code fonctionne de la manière suivante:
=====Fonction setup():=====
Une fois implémenté sur le Arduino, la fonction setup va faire démarrer le protocole XBee et le protocole Série afin de pouvoir envoyer et recevoir des messages par XBee, et d'imprimer les messages d'erreur sur le port Série s'il y a lieu.
=====Fonction loop():=====
Cette fonction va réaliser une boucle toutes les 0.5s pour mettre a jour les données des différents capteurs et les envoyer au serveur au travers du protocole XBee.

===le programme LINKER===

Code du programme de liaison

ce programme en java est constitué de 5 classes

====Le Main====
<code>
public class main {

public static SQLinker linker;
public static Xbee xbee;

public static void main(String[] args){
String address = new String("jdbc:mysql://sitedb.polytech-lille.net/cdelberg?");
String user = new String("user=cdelberg&password=myLo9ufonese");
String COM;

// We ask the user on the Communication Port to connect the XBee
System.out.println("Please enter the Communication port of the Xbee");
Scanner sc = new Scanner(System.in);
COM = sc.next();
System.out.println("COM port changed to: "+COM);

//Creation of the Variables that will be used to connect to the Database and the Xbee
linker = new SQLinker(address, user);
linker.FillArdList();
xbee = new Xbee(COM);

//Creating the Updates Threads
W8Thread thread1 = new W8Thread();
thread1.start();
UpTestThread thread2 = new UpTestThread();
thread2.start();

//We now allow the user to enter a command
String command;
System.out.println("vous pouvez maintenant lancer une commande si vous le souhaitez");
System.out.println("tapez help pour plus d'informations");
boolean exit=false;

while(exit==false){
command=sc.next();

if(command.equals("help")){
System.out.println("print => affiche la liste des arduinos");
System.out.println("exit => ferme le programme");
}
if(command.equals("print")){linker.PrintArdList();}
if(command.equals("exit")){exit=true;}

}
//if the user ask to stop the program, it will do those final commands
sc.close();
thread1.stop();
thread2.stop();
xbee.XbeeClosing();
//System.out.println("Program finished successfully");

}

}

</code>

=== Liste du matériel à acheter ===

Objets communiquants et gestion de l'énergie

2013-02-22T15:29:51Z

Cdelberg : /* Le Arduino */

== Présentation du projet ==

=== Planning prévisionnel provisoire (jusqu'à la pré-soutenance)===

Ce planning pourrait être amené à être modifié.

'''''I) Etat de l'art''''' ( ~2-3 semaines)

-Energy harvesting (Calvin)

-Batteries (Justin)

'''''II) Mesure de puissance des différents appareil Arduino''''' ( ~2 semaines)

'''''III) Confronter théorie/réalité''''' ( ~1 semaine)
-estimer consommation de puissance

-vérifier en pratique

'''Amené à être ajouté:'''

Mesure du Arduino de sa propre consommation.

Mesure de la consommation du code (?)

Applications:

-Envoi des valeurs de l'Arduino au serveur.

-Interface web pour interagir avec l'objet.

== Etat de l'art ==

=== Energy Harvesting ===
 
* Mosquino:

''Mosquino'' est un matériel compatible avec le développement logiciel et dérivé de ''Arduino'', il permet de récupérer de l'énergie des sources ambiantes (chaleur, luminosité, vibrations)
Il n'est destiné qu'aux faibles consommations électriques et n'est encore qu'en phase de développement, il n'a pas encore été véritablement testé. 
http://tim.cexx.org/?page_id=760
 
* Breakout board BOB-o9946 :

Cette carte utilise le collecteur d'énergie piezoelectrique LTC3588 de Linear Technologies et permet non seulement de récupérer l'énergie piezoélectrique mais aussi l'énergie solaire. Initialement prévu pour fonctionner à faible voltage, la capacité de sortie peut-être dimensionnée pour recevoir une salve de courant de sortie plus élevée. 
https://www.sparkfun.com/products/9946
 
=== Batteries ===
 
* nouvelles technologies:

ces dernières années, de nouvelles technologies sont apparues, sans être encore réellement utilisées. je pense notamment aux batteries contenues dans des câbles:
http://phys.org/news/2012-09-lg-chem-cable-batteries-reshape.html

ainsi qu'aux batteries ultra fines dévellopées par thinergy:
http://www.infinitepowersolutions.com/products.html

Néanmoins, les tensions pouvant etre délivrées par ces technologies naissantes sont loin de pouvoir alimenter le materiel qui nous interresse, à savoir des Arduino (necessitant une alimentation comprise entre 7V-12V)

D'autres techno sont encore en phase de développement, comme les batteries lithium-Air d'IBM, les piles au graphène utilisant la chaleur pour produire de l’énergie (plutôt de l'energy harvesting pour le coup). Comme ces technologies sont encore en phase de développement, elles n’apparaîtrons pas sur le marché avant au moins 10 ans.

http://www.metro.co.uk/tech/news/897731-technology-companies-charge-towards-next-generation-battery-future

* technologies adaptée à notre usage:

comme je l'ai rappelé plus haut, ce PFE tourne principalement autour d'Arduino. ces plates-formes nécessitant une tension d'alimentation supérieure à 7V, le choix le plus intéressant reste les piles rechargeable.

Seulement, il existe plusieurs types de piles rechargeables. dans l'usage qu'il en sera fait, et si ces batteries sont couplées à des technologies de récupération d'énergie, il est important de choisir des piles Lithium-Ion.

En effet, ces piles sont les plus intéressantes pour plusieurs raisons:

tout d'abord, elles sont insensibles à l'effet mémoire. du coup elles ne perdent pas de leur capacité de stockage d’énergie au cours du temps.

le circuit intégré à ces piles empêche toute surtension lors de la charge.

elles peuvent être rechargée en même temps qu'elles sont utilisées.

dans une époque ou la pollution est un sujet préoccupation, ces piles sont moins dangereuse pour l’environnement que leurs homologues au nickel-Cadmium

le seul problème pourrais venir du fait qu'elles ne supporte pas bien la chaleur, mais à moins de les coller à un radiateur, il ne devrais pas y avoir de soucis.

=== Mesure de la consommation énergétique ===

WSIM permet la simulation de capteurs sans fil. Il permet notamment d'estimer la consommation électrique http://wsim.gforge.inria.fr/index.html
Pour l'instant il ne fonctionne qu'avec des microcontrolleurs TI. Le support des AVR est en cours.
L'estimation de la consommation énergétique utilise esimu http://esimu.gforge.inria.fr/index.html

== Réalisation ==
===Le Arduino===
====Architecture de l'objet communiquant====

*Un Arduino Mega 2560
*Un XBee
*Un capteur de température
*Un capteur de luminosité
*Un accéléromètre (dont les valeurs ne seront pas utilisées mais qui devait servir d'appareil supplémentaire pour la problématique de consommation)

====Le code du Arduino====

<code>
#include <XBee.h>

// Define variables, pins..
int sensorTempPin = 0;
int Temp;
int sensorLightPin = 1;
int Light;
int XPin = 2;
int YPin = 3;
int ZPin = 4;
int XValue;
int YValue;
int ZValue;

uint8_t values[] = { 0, 0, 0, 0 };
XBee xbee = XBee();
XBeeResponse response = XBeeResponse();
Rx16Response rx = Rx16Response();
Tx16Request tx = Tx16Request(0x1111, values, sizeof(values));
TxStatusResponse txStatus = TxStatusResponse();

void setup()
{
// Initialise xbee / serial
xbee.begin(9600);
Serial.begin(9600);
}

void loop()
{
// Read the values on analog pins
Light = analogRead(sensorLightPin);
Temp = analogRead(sensorTempPin);
XValue = analogRead(XPin);
YValue = analogRead(YPin);
ZValue = analogRead(ZPin);

xbee.readPacket();

if(xbee.getResponse().isAvailable()){
// Got something
Serial.print("Got something\n");
// Break the 10-bits of information retrieved from light
// and temperature into 2 bytes for each.
values[0] = Temp >> 8 & 0xff;
values[1] = Temp & 0xff;
values[2] = Light >> 8 & 0xff;
values[3] = Light & 0xff;
Serial.print(values[0]);

// Sending values to server
xbee.send(tx);

// After sending a tx request, we expect a status response
// from the server
// Wait up to 5 seconds for the status response

if (xbee.readPacket(5000)) {
// We got a response!
Serial.print("We got a response\n");

// It should be a znet tx status
if (xbee.getResponse().getApiId() == TX_STATUS_RESPONSE) {
xbee.getResponse().getZBTxStatusResponse(txStatus);

// get the delivery status, the fifth byte
if (txStatus.getStatus() == SUCCESS){
// Success! Time to celebrate
Serial.print("SUCCESS! Time to celebrate\n");
} else {
// The remote XBee did not receive our packet. Is it powered on?
Serial.print("The remote Xbee did not receive our packet\n");
}
}
} else {
// local XBee did not provide a timely TX Status Response -- should not happen
Serial.print("Local Xbee did not provide a timely TX Status Response\n");
}

}

delay(500);
}
</code>
Ce code fonctionne de la manière suivante:
=====Fonction setup():=====
Une fois implémenté sur le Arduino, la fonction setup va faire démarrer le protocole XBee et le protocole Série afin de pouvoir envoyer et recevoir des messages par XBee, et d'imprimer les messages d'erreur sur le port Série s'il y a lieu.
=====Fonction loop():=====

===le programme LINKER===

Code du programme de liaison

ce programme en java est constitué de 5 classes

====Le Main====
<code>
public class main {

public static SQLinker linker;
public static Xbee xbee;

public static void main(String[] args){
String address = new String("jdbc:mysql://sitedb.polytech-lille.net/cdelberg?");
String user = new String("user=cdelberg&password=myLo9ufonese");
String COM;

// We ask the user on the Communication Port to connect the XBee
System.out.println("Please enter the Communication port of the Xbee");
Scanner sc = new Scanner(System.in);
COM = sc.next();
System.out.println("COM port changed to: "+COM);

//Creation of the Variables that will be used to connect to the Database and the Xbee
linker = new SQLinker(address, user);
linker.FillArdList();
xbee = new Xbee(COM);

//Creating the Updates Threads
W8Thread thread1 = new W8Thread();
thread1.start();
UpTestThread thread2 = new UpTestThread();
thread2.start();

//We now allow the user to enter a command
String command;
System.out.println("vous pouvez maintenant lancer une commande si vous le souhaitez");
System.out.println("tapez help pour plus d'informations");
boolean exit=false;

while(exit==false){
command=sc.next();

if(command.equals("help")){
System.out.println("print => affiche la liste des arduinos");
System.out.println("exit => ferme le programme");
}
if(command.equals("print")){linker.PrintArdList();}
if(command.equals("exit")){exit=true;}

}
//if the user ask to stop the program, it will do those final commands
sc.close();
thread1.stop();
thread2.stop();
xbee.XbeeClosing();
//System.out.println("Program finished successfully");

}

}

</code>

=== Liste du matériel à acheter ===

Objets communiquants et gestion de l'énergie

2013-02-22T15:29:12Z

Cdelberg : /* Le Arduino */

== Présentation du projet ==

=== Planning prévisionnel provisoire (jusqu'à la pré-soutenance)===

Ce planning pourrait être amené à être modifié.

'''''I) Etat de l'art''''' ( ~2-3 semaines)

-Energy harvesting (Calvin)

-Batteries (Justin)

'''''II) Mesure de puissance des différents appareil Arduino''''' ( ~2 semaines)

'''''III) Confronter théorie/réalité''''' ( ~1 semaine)
-estimer consommation de puissance

-vérifier en pratique

'''Amené à être ajouté:'''

Mesure du Arduino de sa propre consommation.

Mesure de la consommation du code (?)

Applications:

-Envoi des valeurs de l'Arduino au serveur.

-Interface web pour interagir avec l'objet.

== Etat de l'art ==

=== Energy Harvesting ===
 
* Mosquino:

''Mosquino'' est un matériel compatible avec le développement logiciel et dérivé de ''Arduino'', il permet de récupérer de l'énergie des sources ambiantes (chaleur, luminosité, vibrations)
Il n'est destiné qu'aux faibles consommations électriques et n'est encore qu'en phase de développement, il n'a pas encore été véritablement testé. 
http://tim.cexx.org/?page_id=760
 
* Breakout board BOB-o9946 :

Cette carte utilise le collecteur d'énergie piezoelectrique LTC3588 de Linear Technologies et permet non seulement de récupérer l'énergie piezoélectrique mais aussi l'énergie solaire. Initialement prévu pour fonctionner à faible voltage, la capacité de sortie peut-être dimensionnée pour recevoir une salve de courant de sortie plus élevée. 
https://www.sparkfun.com/products/9946
 
=== Batteries ===
 
* nouvelles technologies:

ces dernières années, de nouvelles technologies sont apparues, sans être encore réellement utilisées. je pense notamment aux batteries contenues dans des câbles:
http://phys.org/news/2012-09-lg-chem-cable-batteries-reshape.html

ainsi qu'aux batteries ultra fines dévellopées par thinergy:
http://www.infinitepowersolutions.com/products.html

Néanmoins, les tensions pouvant etre délivrées par ces technologies naissantes sont loin de pouvoir alimenter le materiel qui nous interresse, à savoir des Arduino (necessitant une alimentation comprise entre 7V-12V)

D'autres techno sont encore en phase de développement, comme les batteries lithium-Air d'IBM, les piles au graphène utilisant la chaleur pour produire de l’énergie (plutôt de l'energy harvesting pour le coup). Comme ces technologies sont encore en phase de développement, elles n’apparaîtrons pas sur le marché avant au moins 10 ans.

http://www.metro.co.uk/tech/news/897731-technology-companies-charge-towards-next-generation-battery-future

* technologies adaptée à notre usage:

comme je l'ai rappelé plus haut, ce PFE tourne principalement autour d'Arduino. ces plates-formes nécessitant une tension d'alimentation supérieure à 7V, le choix le plus intéressant reste les piles rechargeable.

Seulement, il existe plusieurs types de piles rechargeables. dans l'usage qu'il en sera fait, et si ces batteries sont couplées à des technologies de récupération d'énergie, il est important de choisir des piles Lithium-Ion.

En effet, ces piles sont les plus intéressantes pour plusieurs raisons:

tout d'abord, elles sont insensibles à l'effet mémoire. du coup elles ne perdent pas de leur capacité de stockage d’énergie au cours du temps.

le circuit intégré à ces piles empêche toute surtension lors de la charge.

elles peuvent être rechargée en même temps qu'elles sont utilisées.

dans une époque ou la pollution est un sujet préoccupation, ces piles sont moins dangereuse pour l’environnement que leurs homologues au nickel-Cadmium

le seul problème pourrais venir du fait qu'elles ne supporte pas bien la chaleur, mais à moins de les coller à un radiateur, il ne devrais pas y avoir de soucis.

=== Mesure de la consommation énergétique ===

WSIM permet la simulation de capteurs sans fil. Il permet notamment d'estimer la consommation électrique http://wsim.gforge.inria.fr/index.html
Pour l'instant il ne fonctionne qu'avec des microcontrolleurs TI. Le support des AVR est en cours.
L'estimation de la consommation énergétique utilise esimu http://esimu.gforge.inria.fr/index.html

== Réalisation ==
===Le Arduino===
====Architecture de l'objet communiquant====

*Un Arduino Mega 2560
*Un XBee
*Un capteur de température
*Un capteur de luminosité
*Un accéléromètre (dont les valeurs ne seront pas utilisées mais qui devait servir d'appareil supplémentaire pour la problématique de consommation)

====Le code du Arduino====

<code>
#include <XBee.h>

// Define variables, pins..
int sensorTempPin = 0;
int Temp;
int sensorLightPin = 1;
int Light;
int XPin = 2;
int YPin = 3;
int ZPin = 4;
int XValue;
int YValue;
int ZValue;

uint8_t values[] = { 0, 0, 0, 0 };
XBee xbee = XBee();
XBeeResponse response = XBeeResponse();
Rx16Response rx = Rx16Response();
Tx16Request tx = Tx16Request(0x1111, values, sizeof(values));
TxStatusResponse txStatus = TxStatusResponse();

void setup()
{
// Initialise xbee / serial
xbee.begin(9600);
Serial.begin(9600);
}

void loop()
{
// Read the values on analog pins
Light = analogRead(sensorLightPin);
Temp = analogRead(sensorTempPin);
XValue = analogRead(XPin);
YValue = analogRead(YPin);
ZValue = analogRead(ZPin);

xbee.readPacket();

if(xbee.getResponse().isAvailable()){
// Got something
Serial.print("Got something\n");
// Break the 10-bits of information retrieved from light
// and temperature into 2 bytes for each.
values[0] = Temp >> 8 & 0xff;
values[1] = Temp & 0xff;
values[2] = Light >> 8 & 0xff;
values[3] = Light & 0xff;
Serial.print(values[0]);

// Sending values to server
xbee.send(tx);

// After sending a tx request, we expect a status response
// from the server
// Wait up to 5 seconds for the status response

if (xbee.readPacket(5000)) {
// We got a response!
Serial.print("We got a response\n");

// It should be a znet tx status
if (xbee.getResponse().getApiId() == TX_STATUS_RESPONSE) {
xbee.getResponse().getZBTxStatusResponse(txStatus);

// get the delivery status, the fifth byte
if (txStatus.getStatus() == SUCCESS){
// Success! Time to celebrate
Serial.print("SUCCESS! Time to celebrate\n");
} else {
// The remote XBee did not receive our packet. Is it powered on?
Serial.print("The remote Xbee did not receive our packet\n");
}
}
} else {
// local XBee did not provide a timely TX Status Response -- should not happen
Serial.print("Local Xbee did not provide a timely TX Status Response\n");
}

}

delay(500);
}
</code>
====Ce code fonctionne de la manière suivante:====
=====Fonction setup():=====
Une fois implémenté sur le Arduino, la fonction setup va faire démarrer le protocole XBee et le protocole Série afin de pouvoir envoyer et recevoir des messages par XBee, et d'imprimer les messages d'erreur sur le port Série s'il y a lieu.
=====Fonction loop():=====

===le programme LINKER===

Code du programme de liaison

ce programme en java est constitué de 5 classes

====Le Main====
<code>
public class main {

public static SQLinker linker;
public static Xbee xbee;

public static void main(String[] args){
String address = new String("jdbc:mysql://sitedb.polytech-lille.net/cdelberg?");
String user = new String("user=cdelberg&password=myLo9ufonese");
String COM;

// We ask the user on the Communication Port to connect the XBee
System.out.println("Please enter the Communication port of the Xbee");
Scanner sc = new Scanner(System.in);
COM = sc.next();
System.out.println("COM port changed to: "+COM);

//Creation of the Variables that will be used to connect to the Database and the Xbee
linker = new SQLinker(address, user);
linker.FillArdList();
xbee = new Xbee(COM);

//Creating the Updates Threads
W8Thread thread1 = new W8Thread();
thread1.start();
UpTestThread thread2 = new UpTestThread();
thread2.start();

//We now allow the user to enter a command
String command;
System.out.println("vous pouvez maintenant lancer une commande si vous le souhaitez");
System.out.println("tapez help pour plus d'informations");
boolean exit=false;

while(exit==false){
command=sc.next();

if(command.equals("help")){
System.out.println("print => affiche la liste des arduinos");
System.out.println("exit => ferme le programme");
}
if(command.equals("print")){linker.PrintArdList();}
if(command.equals("exit")){exit=true;}

}
//if the user ask to stop the program, it will do those final commands
sc.close();
thread1.stop();
thread2.stop();
xbee.XbeeClosing();
//System.out.println("Program finished successfully");

}

}

</code>

=== Liste du matériel à acheter ===

Objets communiquants et gestion de l'énergie

2013-02-22T15:28:30Z

Cdelberg : /* Le Arduino */

== Présentation du projet ==

=== Planning prévisionnel provisoire (jusqu'à la pré-soutenance)===

Ce planning pourrait être amené à être modifié.

'''''I) Etat de l'art''''' ( ~2-3 semaines)

-Energy harvesting (Calvin)

-Batteries (Justin)

'''''II) Mesure de puissance des différents appareil Arduino''''' ( ~2 semaines)

'''''III) Confronter théorie/réalité''''' ( ~1 semaine)
-estimer consommation de puissance

-vérifier en pratique

'''Amené à être ajouté:'''

Mesure du Arduino de sa propre consommation.

Mesure de la consommation du code (?)

Applications:

-Envoi des valeurs de l'Arduino au serveur.

-Interface web pour interagir avec l'objet.

== Etat de l'art ==

=== Energy Harvesting ===
 
* Mosquino:

''Mosquino'' est un matériel compatible avec le développement logiciel et dérivé de ''Arduino'', il permet de récupérer de l'énergie des sources ambiantes (chaleur, luminosité, vibrations)
Il n'est destiné qu'aux faibles consommations électriques et n'est encore qu'en phase de développement, il n'a pas encore été véritablement testé. 
http://tim.cexx.org/?page_id=760
 
* Breakout board BOB-o9946 :

Cette carte utilise le collecteur d'énergie piezoelectrique LTC3588 de Linear Technologies et permet non seulement de récupérer l'énergie piezoélectrique mais aussi l'énergie solaire. Initialement prévu pour fonctionner à faible voltage, la capacité de sortie peut-être dimensionnée pour recevoir une salve de courant de sortie plus élevée. 
https://www.sparkfun.com/products/9946
 
=== Batteries ===
 
* nouvelles technologies:

ces dernières années, de nouvelles technologies sont apparues, sans être encore réellement utilisées. je pense notamment aux batteries contenues dans des câbles:
http://phys.org/news/2012-09-lg-chem-cable-batteries-reshape.html

ainsi qu'aux batteries ultra fines dévellopées par thinergy:
http://www.infinitepowersolutions.com/products.html

Néanmoins, les tensions pouvant etre délivrées par ces technologies naissantes sont loin de pouvoir alimenter le materiel qui nous interresse, à savoir des Arduino (necessitant une alimentation comprise entre 7V-12V)

D'autres techno sont encore en phase de développement, comme les batteries lithium-Air d'IBM, les piles au graphène utilisant la chaleur pour produire de l’énergie (plutôt de l'energy harvesting pour le coup). Comme ces technologies sont encore en phase de développement, elles n’apparaîtrons pas sur le marché avant au moins 10 ans.

http://www.metro.co.uk/tech/news/897731-technology-companies-charge-towards-next-generation-battery-future

* technologies adaptée à notre usage:

comme je l'ai rappelé plus haut, ce PFE tourne principalement autour d'Arduino. ces plates-formes nécessitant une tension d'alimentation supérieure à 7V, le choix le plus intéressant reste les piles rechargeable.

Seulement, il existe plusieurs types de piles rechargeables. dans l'usage qu'il en sera fait, et si ces batteries sont couplées à des technologies de récupération d'énergie, il est important de choisir des piles Lithium-Ion.

En effet, ces piles sont les plus intéressantes pour plusieurs raisons:

tout d'abord, elles sont insensibles à l'effet mémoire. du coup elles ne perdent pas de leur capacité de stockage d’énergie au cours du temps.

le circuit intégré à ces piles empêche toute surtension lors de la charge.

elles peuvent être rechargée en même temps qu'elles sont utilisées.

dans une époque ou la pollution est un sujet préoccupation, ces piles sont moins dangereuse pour l’environnement que leurs homologues au nickel-Cadmium

le seul problème pourrais venir du fait qu'elles ne supporte pas bien la chaleur, mais à moins de les coller à un radiateur, il ne devrais pas y avoir de soucis.

=== Mesure de la consommation énergétique ===

WSIM permet la simulation de capteurs sans fil. Il permet notamment d'estimer la consommation électrique http://wsim.gforge.inria.fr/index.html
Pour l'instant il ne fonctionne qu'avec des microcontrolleurs TI. Le support des AVR est en cours.
L'estimation de la consommation énergétique utilise esimu http://esimu.gforge.inria.fr/index.html

== Réalisation ==
===Le Arduino===
====Architecture de l'objet communiquant====

*Un Arduino Mega 2560
*Un XBee
*Un capteur de température
*Un capteur de luminosité
*Un accéléromètre (dont les valeurs ne seront pas utilisées mais qui devait servir d'appareil supplémentaire pour la problématique de consommation)

<code>
#include <XBee.h>

// Define variables, pins..
int sensorTempPin = 0;
int Temp;
int sensorLightPin = 1;
int Light;
int XPin = 2;
int YPin = 3;
int ZPin = 4;
int XValue;
int YValue;
int ZValue;

uint8_t values[] = { 0, 0, 0, 0 };
XBee xbee = XBee();
XBeeResponse response = XBeeResponse();
Rx16Response rx = Rx16Response();
Tx16Request tx = Tx16Request(0x1111, values, sizeof(values));
TxStatusResponse txStatus = TxStatusResponse();

void setup()
{
// Initialise xbee / serial
xbee.begin(9600);
Serial.begin(9600);
}

void loop()
{
// Read the values on analog pins
Light = analogRead(sensorLightPin);
Temp = analogRead(sensorTempPin);
XValue = analogRead(XPin);
YValue = analogRead(YPin);
ZValue = analogRead(ZPin);

xbee.readPacket();

if(xbee.getResponse().isAvailable()){
// Got something
Serial.print("Got something\n");
// Break the 10-bits of information retrieved from light
// and temperature into 2 bytes for each.
values[0] = Temp >> 8 & 0xff;
values[1] = Temp & 0xff;
values[2] = Light >> 8 & 0xff;
values[3] = Light & 0xff;
Serial.print(values[0]);

// Sending values to server
xbee.send(tx);

// After sending a tx request, we expect a status response
// from the server
// Wait up to 5 seconds for the status response

if (xbee.readPacket(5000)) {
// We got a response!
Serial.print("We got a response\n");

// It should be a znet tx status
if (xbee.getResponse().getApiId() == TX_STATUS_RESPONSE) {
xbee.getResponse().getZBTxStatusResponse(txStatus);

// get the delivery status, the fifth byte
if (txStatus.getStatus() == SUCCESS){
// Success! Time to celebrate
Serial.print("SUCCESS! Time to celebrate\n");
} else {
// The remote XBee did not receive our packet. Is it powered on?
Serial.print("The remote Xbee did not receive our packet\n");
}
}
} else {
// local XBee did not provide a timely TX Status Response -- should not happen
Serial.print("Local Xbee did not provide a timely TX Status Response\n");
}

}

delay(500);
}
</code>
====Ce code fonctionne de la manière suivante:====
=====Fonction setup():=====
Une fois implémenté sur le Arduino, la fonction setup va faire démarrer le protocole XBee et le protocole Série afin de pouvoir envoyer et recevoir des messages par XBee, et d'imprimer les messages d'erreur sur le port Série s'il y a lieu.
=====Fonction loop():=====

===le programme LINKER===

Code du programme de liaison

ce programme en java est constitué de 5 classes

====Le Main====
<code>
public class main {

public static SQLinker linker;
public static Xbee xbee;

public static void main(String[] args){
String address = new String("jdbc:mysql://sitedb.polytech-lille.net/cdelberg?");
String user = new String("user=cdelberg&password=myLo9ufonese");
String COM;

// We ask the user on the Communication Port to connect the XBee
System.out.println("Please enter the Communication port of the Xbee");
Scanner sc = new Scanner(System.in);
COM = sc.next();
System.out.println("COM port changed to: "+COM);

//Creation of the Variables that will be used to connect to the Database and the Xbee
linker = new SQLinker(address, user);
linker.FillArdList();
xbee = new Xbee(COM);

//Creating the Updates Threads
W8Thread thread1 = new W8Thread();
thread1.start();
UpTestThread thread2 = new UpTestThread();
thread2.start();

//We now allow the user to enter a command
String command;
System.out.println("vous pouvez maintenant lancer une commande si vous le souhaitez");
System.out.println("tapez help pour plus d'informations");
boolean exit=false;

while(exit==false){
command=sc.next();

if(command.equals("help")){
System.out.println("print => affiche la liste des arduinos");
System.out.println("exit => ferme le programme");
}
if(command.equals("print")){linker.PrintArdList();}
if(command.equals("exit")){exit=true;}

}
//if the user ask to stop the program, it will do those final commands
sc.close();
thread1.stop();
thread2.stop();
xbee.XbeeClosing();
//System.out.println("Program finished successfully");

}

}

</code>

=== Liste du matériel à acheter ===

Objets communiquants et gestion de l'énergie

2013-02-22T15:23:51Z

Cdelberg : /* Code du Arduino */

Objets communiquants et gestion de l'énergie

2013-02-22T15:12:10Z

Cdelberg : /* Code du Arduino */

Objets communiquants et gestion de l'énergie

2013-02-22T15:11:43Z

Cdelberg : /* Réalisation */

Objets communiquants et gestion de l'énergie

2013-02-22T15:10:48Z

Cdelberg : /* Réalisation */

Objets communiquants et gestion de l'énergie

2012-11-28T18:26:56Z

Cdelberg : /* Energy Harvesting */

Objets communiquants et gestion de l'énergie

2012-11-28T18:08:32Z

Cdelberg : /* Etat de l'art */

Kinect2012

2012-05-08T22:24:54Z

Cdelberg : /* Avancement du projet */

= Liste du matériel =

== Présent ==

<ul>
<li>Kinect</li>
</ul>

== A acheter ==

= Présentation =

Ce projet a pour objectif de mettre en place un système de choix d'appareil en espace commercial. Il s'agit, sur la base d'un système existant, d'améliorer le système de sélection des produits afin de le rendre plus ergonomique, de pouvoir le paramétrer plus simplement (par un vendeur), eventuellement d'augmenter le nombre de gestes reconnaissable. La situation d'usage pressentie est une catégorie de vente de produits difficilement déplacable par un client, pour des raisons de poids (par exemple un appareil de musculation) ou de taille (par exemple une tente).

== Avancement du projet==

=== Objectifs suggérés par les encadrants ===

*Objectif principal : Améliorer un dispositif de sélection d'articles par gestes

* Objectifs détaillés :
**Passer à la nouvelle version du SDK
**Enlever la calibration du squelette
**Interface pour un utilisateur lambda

=== Réalisations concrètes ===

=== Séances ===

==== Séance du 08/02/2012 ====
*Récupération des sources stables de OpenNI,PrimeSense Sensor Module for OpenNI et NITE
*Installation des dépendances requises pour installer OpenNI, PrimesSense et NITE d'après les README
*Compilation des sources
*Essais de compilation de quelques samples en java pour reconnaitre une personne ou une main
**Erreurs dans la compilation => Manque de fichiers JAR ?

==== Séance du 13/02/2012 ====

*Installation terminé, la Kinect fonctionne et est reconnue.
*Installation de SensorKinect à la place de PrimeSense Sensor qui n’était pas le driver associé à la kinect (avin2-SensorKinect-faf4994)
*Test des samplesfournis avec OpenNi

==== Séance du 15/02/2012 ====

*Création d'un makefile pour compiler nos projet cpp
*Prise en main de Simpleread (profondeur, largeur, hauteur)
*Développement d'un petit soft "salut ça va" en fonction juste de la position en x,y,z qui marche entre 500 et 800 mm de profondeur
(en dirigeant la main en haut à gauche, le terminal affiche "Salut !", en dirigeant la main en haut à droite, le terminal affiche"ca va")

==== Séance du 20/02/2012 ====

*Récupération du projet de l'an passé ainsi que le rapport rapport de l’an dernier
*Installation de librairie SDL
*Modification du Makefile afin de pouvoir compiler le projet sur un PC
*Test du programme => fonctionne mis à part petit problème de résolution sur l’image d’instruction
*Regarder les exemples de NITE => rien de concluant pour le moment
*Sur le projet de l’an dernier => pas forcément besoin de psy pose pour calibration mais calibration néanmoins nécéssaire.

==== Séance du 22/02/2012 ====

*Résolution du problème d'affichage du programme de l’ancien projet, test du programme.
*Calibration automatique avec la nouvelle version de nite (doc, sans “psi” pose)
? comment intégrer Player-sample au projet ?

==== Séance du 07/03/2012 ====

*Réinstallation compléte de OpenNi, Nite, KinectSensor, ainsi que leurs dépendances respectives et des librairies nécessaires à l'ancien projet car changement d'ordinateur...
*Problème pour lancer les Sample de OpenNi :
''Open failed: Failed to set USB interface!
Press any key to continue . . .''

Résolution : rmmod gspca_kinect

*Création du Makefile pour déveloper avec Nite (Makefile à executer dans Sample Tests du dossier de Nite)
*Aucune idée sur comment aborder l'intégration de NITE au projet de l'an dernier...

==== Séance du 12/03/2012 ====

*Fonction pour sauvegarder et charger des squelette vers / depuis un fichier trouvée et en attente de test faute de kinect accessible.

==== Séance du 14/03/2012 ====

*Ajout de la fonction permettant de sauvegarder un squelette
*La fonction de chargement d’un fichier de squelette nous retourne une erreur :
Function was not implemented!

==== Séance du 19/03/2012 ====

*Bloqué à Loadcalibrationdatatofile
*Confirmation de Laurent Grisoni, ces fonctions ne sont plus implémenter. Il faut installer une version de NITE antérieur pour pouvoir les utiliser.

==== Séance du 21/03/2012 ====
*Installation de libmagick++-dev pour manipuler des images
*Création du programme permettant de prendre une image et un fichier texte en paramètre
l’image peut être un article du magasin tel qu’une tente, le texte correspond à la description de l’article précédemment cité.

Compilation et utilisation :
#gcc -o image image.cpp `Magick++-config --cppflags --cxxflags --ldflags --libs`
#./image
Impossible d'ouvrir le fichier !
Utilisation :
./image nomImage.xxx nomFichier.xxx
# ./image tente.JPG description_tente.txt

==== Séance du 28/03/2012 ====

Réflexions quant à une réelle amélioration du projet :

* Pouvoir calibrer la position d'un objet dans un environnement 3D. Pour l'instant les objets sont définis statiquement dans un tableau du programme. Si on veut changer l'objet de place, il faut que le développeur entre dans les sources et recompose le projet.

* Faire une interface graphique simple en qt en partant un projet/exemple dans qt creator. Cette interface est surtout écrite en qml. Il s'agit d'une grille de rectangle contenant chacun une image. On pourrait ainsi faire un menu avec deux rectangle :
•un menu catalogue
•un menu qui lance le projet de l'an passé

Dans le catalogue on aurait une liste de filtres : sport, randonné, camping etc et les images des objets à vendre par décathlon dans une grille de rectangle.

L'exemple dont je parle plus haut est navigable entièrement avec les flèches du clavier.
Aussi, on pourrait simuler l'appui sur une touche directionnelle des qu'un mouvement spécifique est reconnu par nite.

Travail réalisé lors de la séance :

*Compréhension du placement des items et de comment le modifier dans le cadre du programme que nous voulons créer. (itemsset.cpp, itemsset.hpp)

*Révision du programme de création des images (presque terminé)

*Le vendeur pourra bientôt, depuis le programme principal de la Kinect, afficher ses 8 images/textes, qu'il aura au préalable placés dans un dossier spécifique. Le programme est appelé lors de de l'initialisation du tableau d'items

==== Séance du 04/04/2012 ====

*Exemple pour utiliser la Kinect comme une souris trouvé
http://www.keyboardmods.com/2010/12/howto-use-kinect-as-mouse-in-linux.html
Ce programme permet de simuler le déplacement d'une souris sous linux via la librairie ioinput

*Adaptation du code pour simuler les touches d’un clavier :
gestes reconnus :
** swipe left associé à la touche gauche
** swipe right associé à la touche droite
** swipe up associé à la touche haut
** swipe down associé à la touche bas

Problème : dès qu’un mouvement est reconnu, exemple swipe left, alors le curseur se ballade vers la gauche sans s’arrêter.

*Commencement de la programmation de l’interface à partir d’un exemple sur QTcreator en Qt Quick (focus), pour l’instant possibilité de mettre plusieurs noms rentrés a la main dans une liste, ainsi que différentes images nommées de la façon suivante: “<nom>+(index+1)+<.extension>”.
*En attente d’une solution pour associer une grille d’image différente pour chaque instance de cette liste.
Projet d’interface pouvant être lancé depuis n’importe quel ordinateur sur lequel QTCreator est installé.

==== Séance du 05/04/2012 ====

*Problème d’appui long sur les touches résolu, mais touche entrée (push) et steady toujours pas reconnus.

==== Séance du 11/04/2012 ====

*Le programme reconnait maintenant l’appui sur la touche entrée quand on fait le mouvement push.
*Tentative d’implémenter la combinaison de touche LEFTALT+TAB pour changer de fenêtre mais inefficace. Pourtant le mouvement Circle qui lui est associé est bien reconnu.

==== Séance du 16/04/2012 ====

*Interface opérationnelle sous linux. Problème : reconnaissance des gestes hasardeuse …

*Le programme qui reconnaît les mouvements de la main est capable de lancer en tâche de fond l’interface graphique

*A faire :
**Lier les 2 projets ainsi que le programme utilisant la librairie imagemagick
**Surtout : Comment revenir du projet de l’an passé à celui de cet année : dessiner un cercle avec la main qui enverrait un signal pour tuer le processus ?

*Le context menu :
**Aide sur comment utiliser l’interface ?
**Lancer le projet de l’an passé (javascript?)

*Il faut étoffer aussi le catalogue car pour l’instant, il n’y a que 3 élement dans la liste => télécharger et classer des articles depuis le site de décathlon (faute de base de donnée en ligne)

=== Résultats ===

*Le programme principal:
**On le lance et il lance l'interface graphique créée avec QT dans un fork et il gère la Kinect dans le même temps.
**En faisant un cercle avec la main, on peut passer au programme créé lors du projet de l'an dernier, lorsque l'on fait ce mouvement, le programme principal tue le processus de l'interface et lance celui de l'ancien projet à l'aide d'un nouveau fork.
**De même, lorsque le projet de l'an dernier est lancé, un mouvement circulaire de la main permet de revenir à l'interface.

*Le programme de l'interface:
**On peut naviguer avec le clavier (Touches Haut,Bas,Droite,Gauche pour se déplacer et Tab pour valider) ou en faisant des mouvements avec la main reconnus par la Kinect et le programme(On pousse pour Tab(Push), on bouge la main dans la direction souhaitée pour se déplacer)
**Une aide sur l'utilisation peut être affichée si l'on va a gauche de la liste du catalogue.
**Le programme détecte lorsque l'utilisateur a fini un mouvement et est revenu dans sa position initiale en envoyant le signal de touche y pressée, autorise un autre mouvement et affiche le contour de l'objet selectionné en rouge lorsque c'est le cas.

Controle LED 256 couleurs

2011-05-13T16:17:21Z

Cdelberg :

1ere scéance:

'''Objectifs :'''

<ul>

<li> Étude de la nanoboard </li>

<li> Prise en main de la nanoboard. </li>

<li> Mise en place du travail à effectuer. </li>

<li> Partie FPGA </li>

<li> Commencer la création de l'interface web </li>

</ul>

'''Fin de la scéance :'''

Nous avons compris et presque terminé la partie FPGA, mais n'avons pas encore travaillé sur la partie analogique,

ni sur la création de l'interface web.

2eme scéance:

'''Objectifs :'''

<ul>

<li> Fin partie FPGA </li>

<li> Partie analogique </li>

<li> Réalisation de l'interface web </li>

</ul>

'''Fin de la scéance :'''

Concernant la partie électronique, nous avons testé le PWM mais elle ne fonctionnait pas et nous avons calculé les valeurs des composants nécessaires au filtre passe-bas.

Pour la partie informatique, commencement de la page HTML, recherche de la syntaxe javascript pour faire des sliders sur internet et test du démon série a l'aide du prototype arduino.

3eme scéance:

'''Objectifs :'''

<ul>

<li> Finaliser le PWM </li>

<li> Tester le PWM avec le montage du filtre </li>

<li> Tester la page HTML et le code php/javascript fait chez nous </li>

<li> Implantation sur la FoxBoard </li>

</ul>

<ul>

=====================================FOXBOARD===================================

<li> Adresse ip : 172.26.79.103 </li>
<li> Password : netusg20 </li>

<li> Les fichiers implantés :

<ul>

<li> root/serie </li>

<li> var/www/index2.html </li>

<li> var/www/toC.php </li>

<li> var/www/js/jquery-1.5.1.min.js </li>

<li> var/www/js/jquery-ui-1.8.12.custom.min.js </li>

<li> var/www/css/smoothness/jquery-ui-1.8.12.custom.css </li>

</ul>

<li> Les commandes pour executer le démon sur la foxboard : </li>

<ul>

<li> ssh -l root 172.26.79.103 </li>

<li> netusg20 </li>

<li> su www-data </li>

<li> ./a.out /tmp/serie </li>

<li> la page : http://172.26.79.103/ fonctionne désormais ! </li>

</ul>

Controle LED 256 couleurs

2011-05-13T16:06:49Z

Cdelberg :

Controle LED 256 couleurs

2011-05-13T12:05:31Z

Cdelberg :

Controle LED 256 couleurs

2011-05-11T12:18:25Z

Cdelberg :

Controle LED 256 couleurs

2011-05-11T12:09:46Z

Cdelberg :

1ere scéance:

'''Objectifs :'''

Nous nous interesserons surtout à la partie FPGA (passe-bas et PWM) puis si le temps nous le permet nous nous pencherons sur la création de l'interface web.

2eme scéance:

'''Objectifs :'''

<ul>

<li> Fin partie FPGA </li>

<li> Partie analogique </li>

<li> Réalisation de l'interface web </li>

</ul>

Controle LED 256 couleurs

2011-05-06T12:42:20Z

Cdelberg : Page créée avec « 1ere scéance: <s>'''Objectifs :'''</s> Nous nous interesserons surtout à la partie FPGA (passe-bas et PWM) puis si le temps nous le permet nous nous pencherons sur la cré... »

1ere scéance:

<s>'''Objectifs :'''</s>
Nous nous interesserons surtout à la partie FPGA (passe-bas et PWM) puis si le temps nous le permet nous nous pencherons sur la création de l'interface web.