Polytech Projets Ge

%{color:red}1. Résumé% 

%{color:red}2. Abstract% 

%{color:red}3. Introduction% 

%{color:red}4. Présentation du Sujet% 

%{color:red}5. Cahier des charges% 

%{color:red}6. Développement% 

p(. %{color:red}1. Problématiques%

p(. %{color:red}2. Solutions existantes et proposées%

p(. %{color:red}3. Faisabilité de nos solutions%

%{color:red}7. Gestion de Projet%

p(. %{color:red}1. W.B.S.%

p(. %{color:red}2. Gantt%

p(. %{color:red}3. Coûts du projet%

%{color:red}8. Bilan%

p(. %{color:red}1. Etat d'avancement%

p(. %{color:red}2. Analyse Critique%

p(. %{color:red}3. Perspectives%

%{color:red}9. Webographie% 

%{color:red}10. Documents% 

---

p=. Résumé

Le but de ce projet est de concevoir deux systèmes différents de capture vidéo pilotables à l’aide d’un signal électrique. Pour cela, nous avons déjà effectué des tests pré qualificatifs afin d’évaluer la faisabilité du projet, ayant l’objectif final d’aboutir à deux solutions clés en main et parfaitement abouties. Pour ce faire, nous utiliserons deux plateformes complètements différentes qui seront : la reproduction d’une commande infrarouge pour une caméra type « go pro » et le développement d’une caméra autonome basée sur la plateforme « Raspberry pi ». Ces deux systèmes ont pour but d’améliorer le confort et les résultats des chercheurs de l’équipe Demar, travaillant pour le laboratoire Inria à Montpellier. En effet, celle-ci travaille sur la récupération et la rééducation du mouvement via stimulations électriques. Ainsi lorsqu’ils effectuent des tests et des expériences, les chercheurs doivent récupérer des données provenant de différents capteurs installés sur un patient, mais aussi garder une trace vidéo des expériences afin de synchroniser les mouvements d’un patient avec les données des capteurs. Aujourd’hui, cette phase est faite manuellement par les chercheurs. Nos systèmes permettraient donc d’automatiser cette phase et d’améliorer, d’une part, le confort des chercheurs, et d’autre part d’éviter les erreurs humaines dues à une synchronisation manuelle.

---

p=.  Abstract

The goal of this project is to design two different systems of video capture switchable using an electrical signal. Some tests have already been realized for the project’s feasibility study, which will in the end provide two accomplished solutions. To do so, one of them is the reproduction of a camera’s infra-red instruction, the other one is the development of an autonomous camera based on the “Raspberry pi” platform. Both are designed to improve comfort and the results researchers form the Demar team, working for the Inria laboratory in Montpellier. Demar team works on muscular reeducation thanks to electrical stimulation. Thus when conducting tests, the researchers need to retrieve data from different sensors on a patient, and to keep a video record of the experiences to synchronize patient’s movements with the data captured by sensors. Currently, this phase is done manually by researchers. Our systems would enable to automate this in order to improve the comfort’s researchers and to avoid human errors due to manual synchronization.

---

p=. Introduction

Dans le cadre de notre formation d’ingénieur au département Génie électrique de Polytech Clermont-Ferrand, nous travaillons sur un projet technique qui se déroule sur une année. Nous avons ainsi eu la possibilité de travailler sur le sujet suivant : « Synchronisation et récupération de données hétérogènes » dont nous venons de terminer la 1ère phase (de mars à mai 2015) concernant l’organisation et la gestion du projet, mais aussi des tests pré qualificatif pour vérifier la faisabilité de certains points du projet. La 2ème phase a ainsi été préparée et se déroulera de septembre 2015 à janvier 2016. Elle consistera à mettre en exécution les choix que nous avons faits en phase 1.

Les clients de ce projet sont des ingénieurs chercheurs de l’équipe Démar du laboratoire Inria de Montpellier. Cette équipe travaille sur la rééducation et la récupération de mouvements, en effectuant des expériences sur des patients atteints de maladie comme celle du « pied tombant » ou encore Parkinson. Pour cela, ils élaborent des algorithmes qui enverront des impulsions électriques aux muscles afin de les stimuler au moment opportun. De ce fait, lorsque ces chercheurs effectuent ces expériences, ils récoltent des données provenant de différents capteurs reliés au patient, mais aussi une vidéo qui doit être synchronisée manuellement avec les données capteurs.

Le problème de cette méthode est que la personne filmant l’expérience doit avoir un témoin lumineux (une LED clignotante) dans son champ pour commencer ou arrêter l’enregistrement de cette vidéo. Cette étape peut provoquer des erreurs de synchronisation et est très laborieuse. Ainsi les chercheurs ont proposé d’améliorer cette étape de synchronisation en la rendant automatique. Les enjeux de ce projet seront donc d’améliorer le confort des chercheurs, mais aussi d’améliorer leurs résultats en évitant toutes erreurs humaines.

De ce fait, notre rôle dans de ce projet est donc d’élaborer deux systèmes vidéos ayant une approche différente dans leurs conceptions, mais un résultat final identique : synchroniser les données capteurs avec le démarrage et l’arrêt de la capture vidéo automatiquement lors de la réception d’un signal électrique.

Dans un premier temps seront présentés les clients, le contexte du projet, la problématique et le cahier des charges imposé. Ensuite, nous aborderons la démarche avec laquelle nous proposons de résoudre le problème et les solutions techniques retenues. Puis pour terminer, nous indiquerons quels ont été les résultats des tests pré qualificatif et quelles conclusions nous avons pu en tirer.

---

p=. Présentation du sujet

Le contexte du projet est en fait décomposé en deux grandes parties :

p(((. Une partie capteur

p(((. Une partie caméra

En effet, comme indiqué sur le synoptique global (Figure 1), créé pour le projet, un patient est équipé de plusieurs capteurs (Figure 2) et un chercheur avec une caméra mobile se tient prêt à filmer les différents évènements.

p=. !https://forge.clermont-universite.fr/attachments/download/15926/Synoptique_global_20150525231330_20150525231409.bmp!

p=. Figure 1 — Synoptique présentant le contexte du projet

De ce fait, dès lors qu’un signal électrique est envoyé par un opérateur, les capteurs doivent commencer l’enregistrement des données et la caméra doit aussi enregistrer pour garder une trace visuelle de l’évènement.

p=. !https://forge.clermont-universite.fr/attachments/download/15927/Patient_20150525232658_20150525232733.png!

p=. Figure 2 — Patient équipé de différents capteurs (Equipe Demar)

Cela implique donc la synchronisation des données capteurs avec l’image filmée par la caméra. Cette synchronisation est primordiale, car lorsque l’équipe de chercheurs voudra analyser les résultats de leurs expériences et les utiliser, il faudra qu’ils puissent comprendre ce qu’il se passe lorsqu’un capteur affiche, par exemple, une valeur importante ou intéressante. Ainsi, la synchronisation avec la vidéo permettra de bien comprendre cette donnée.

Concernant l’environnement du sujet, il n’est pour l’instant pas considéré comme un milieu hospitalier, car les expériences sont effectuées dans le contexte d’un laboratoire. Cependant, étant donné que ce système est voué à évoluer, il nous a été tout de même demandé de prendre en compte cet aspect. En effet, le marché cible du projet est celui de de la médecine, et si le projet évolue cette donnée deviendra très importante. C’est pourquoi il faudra faire attention à l’émissivité et la susceptibilité électromagnétique de notre système (CEM) pour ne pas perturber d’autres systèmes présents dans un hôpital par exemple. 

---

p=. *Cahier des charges*

Le cahier des charges imposé par le client est de concevoir deux systèmes mobiles permettant la capture vidéo et pilotables à partir d’un signal électrique. Pour ces deux systèmes, deux approches différentes ont été demandées pour résoudre le problème :

* +Concevoir un système basé sur la reproduction d’une commande infrarouge pour une caméra, que l’on nommera type « go pro ».

Le terme « go pro »+ est utilisé car il représente la marque ayant démocratisé l’utilisation de petites caméras portables et polyvalentes, très souvent utilisées pour les sports extrêmes. On utilise donc ce terme par analogie pour de petites caméras de ce type.

* +Concevoir une solution basée sur du matériel peu coûteux et reproductible facilement.+

Cette solution est plus libre concernant le choix du matériel et a pour objectif d’être reproductible facilement, ceci permettra aux clients de, s’ils le souhaitent, concevoir eux-mêmes un autre système vidéo de ce type.

Arrivent ensuite les contraintes techniques imposées par les clients et qui sont communes aux deux solutions :

p(((. Une qualité d’image suffisante 720p -1080p. Ceci permettra aux chercheurs de pouvoir bien exploiter les vidéos et comprendre les phénomènes observés.

p(((. Une fluidité d’image suffisante 30 images par seconde minimum. Ainsi l’image ne sera pas saccadée et sera mieux exploitable.

p(((. Délais d’activation suite à la réception du signal électrique ~30 à 40 ms. On justifiera ce choix en indiquant que c’est le temps séparant deux images vidéo.

p(((. Il faudra impérativement éviter la perte de données qui est un point crucial pour les chercheurs.

p(((. Une autonomie d’environ 7 h sans recharge entre chaque session d’expérience est le minimum requis. En effet cela permettra aux chercheurs de ne pas se préoccuper de la charge de la caméra afin d'éviter une panne en pleine manipulation.

p(((. Il faudra au final un produit bien fini, totalement mobile et prêt à l’emploi pour une utilisation immédiate.

---

p=. *Développement*

Dans cette partie nous allons présenter la problématique à laquelle doit répondre notre projet, rechercher s'il existe déjà des solutions pouvant y répondre et la faisabilité des solutions que nous apportons.

---

p=. *Problématique*

Pour le moment, la phase de synchronisation expliquée ci-dessus doit se faire manuellement par un des chercheurs. En effet, alors que les capteurs sont activés dès la réception du signal électrique voulu, la caméra ne l’est pas.

Ainsi, le chercheur filmant les expériences, doit observer une diode électroluminescente indiquant suivant son clignotement le moment où il faut commencer l’enregistrement. Pour le moment, c'est la solution qui a été retenue pour effectuer cette phase de synchronisation. Cependant, comme elle est effectuée manuellement, cette étape manque de précision et surtout est très laborieuse pour les chercheurs. De plus des erreurs de manipulations peuvent être faites en essayant d'être précis et réactif pour permettre une bonne synchronisation. C’est ainsi que le projet « Synchronisation et récupération de données hétérogènes » a été proposé.

Ainsi comme vous l'aurez compris le besoin de nos clients est d’automatiser cette étape de synchronisation, pour l'instant manuelle, afin de s’affranchir des erreurs qu'elle peut engendrer dans les résultats des expériences. Il sera demandé, en fonction du signal électrique envoyé aux capteurs, que la caméra commence ou arrête l'enregistrement vidéo automatiquement. C’est pourquoi le projet consiste à élaborer des systèmes de capture vidéo, prêts à l’emploi et pilotables à l’aide d’un signal électrique. Ceci permettra au chercheur filmant l’expérience de ne pas se préoccuper de la synchronisation de la vidéo et de se focaliser sur les différents événements relatifs à l'expérience. De plus les erreurs dues à la synchronisation disparaîtront, ce qui améliorera les résultats et le confort des chercheurs tout au long de leurs expériences.

---

p=. *Solutions existantes et proposées*

Aucune solution répondant parfaitement aux attentes n’a été trouvé sur le marché, ceci même après plusieurs recherches, soit une caméra portable et commandable via un signal électrique. Cette remarque a également été faite par les clients.

Voici donc les solutions retenues pour le projet.

- La première, est basée sur la reproduction d’une commande infrarouge pour une caméra type « go pro », qui sera en fait une caméra fournie avec une télécommande infrarouge par l’équipe de chercheurs. Cela impliquera un stockage des vidéos sur carte SD ainsi que l’utilisation d’une carte de synthèse fournie par Polytech, déjà utilisée en première année d’école d’ingénieur. Cela facilitera le développement du programme. Pour finir, il faudra choisir une LED IR ayant un spectre d’émission compatible avec la caméra et élaborer ou sélectionner un système d’accroche permettant la mise en place de cette carte sur la caméra.

- La deuxième solution, plus libre, sera basée sur un Raspberry pi 2 qui est une petite carte électronique. Le choix de cette plateforme s’est fait car elle est peu coûteuse et performante. Elle est très polyvalente et sa documentation importante sur internet aidera fortement pour le développement. Comme pour la solution précédente, le stockage des vidéos s’effectuera sur une carte SD car ce moyen de stockage est compact et robuste. Pour terminer, il faudra créer un boîtier en plastique en utilisant par exemple l'imprimante 3D fournie par l’école, ou par le laboratoire des clients. Tout ceci permettra d’avoir un produit bien fini et prêt à l’emploi pour les clients.

---

p=. *Faisabilité de nos solutions*

Les premiers tests de faisabilité, que l’on nommera test pré qualificatifs, nous ont permis d’entrevoir les possibilités qu’offrent les solutions retenues pour le projet.

Pour la solution 1, basé sur la reproduction d'une commande infrarouge, nous avons rencontré quelques difficultés notamment sur la réémission du signal, ce qui à légèrement retardé son avancement. Cependant, malgré quelques difficultés à prévoir également sur l'enregistrement des trames avec l'ajout de mémoires, les tests effectués nous laissent envisager la réalisation finale de cette solution pour la fin du projet, en janvier 2016.

Pour la solution 2, les libertés accordées ont permis d'envisager la solution dans sa globalité. Le choix s'est ainsi porté sur une carte Raspberry pi 2 puisqu'il s'agit d'un matériel peu coûteux, accompagné du module spécifique caméra pi, d'un batterie très performante pour l'autonomie et d'une carte mémoire volumineuse pour stocker plusieurs vidéos d'expériences. Le choix des fournisseurs fut assez évident et la mise en place plutôt rapide une fois le matériel livré.

La vaste documentation présente sur internet pour la programmation et l'état d'avancement actuel de cette solution nous permettent de croire en l'aboutissement de celle-ci en un produit finit et ce dès janvier 2016. De plus la reproduction par le client de cette solution sera très facile.

---

p=. *Gestion de Projet*

Sera présenté ici le découpage, les plannings et les coûts du projet.

---

p=. *W.B.S.*

Comme mentionné dans les parties précédentes, le projet est scindé en deux grandes phases dont voici les spécificités :

p(((. La phase 1 - de mars à mai 2015 : concerne les tests pré qualificatifs

p(((. La phase 2 - de septembre à janvier 2016 : concerne la réalisation du planning et des livrables.

Ces deux phases sont représentées sur le schéma suivant (Figure 3) :

p=. !https://forge.clermont-universite.fr/attachments/download/15928/W.B.S_20150525232658_20150525232950.png!

p=. Figure 3 — Présentation des deux phases du projet

De plus, on remarquera que ces deux phases sont ensuite divisées en deux parties représentant chacune un des systèmes vidéo à concevoir correspondant aux solutions retenues. D’un côté nous aurons donc la solution basée sur un Raspberry pi, et de l’autre la solution basée sur la reproduction d’une commande infrarouge pour une caméra type « go pro ». Mais ces parties peuvent encore être découpées.

Tout d’abord, lors du développement de la 1ère phase, on retrouve deux axes pour chacune des solutions retenues (Annexes I et II du fichier "Annexes.pdf" en bas de page). Une première partie concerne l’architecture matérielle, tandis que la deuxième partie correspond à l’architecture logicielle des deux solutions. En effet, ces deux parties sont primordiales pour les premiers tests.

Ensuite, lors du développement de la 2ème phase (Annexes III et IV du fichier "Annexes.pdf" en bas de page), on évoluera pour avoir des livrables prêts à l’emploi. C’est pourquoi on retrouve encore les deux axes architectures matérielles et logicielles qui permettront à la fois une optimisation des architectures déjà développées lors des tests pré qualificatifs, mais aussi l’ajout des nouvelles fonctionnalités. De plus pour cette deuxième phase, a été ajouté un troisième axe qui se focalisera sur le packaging des solutions conçues. En effet, les clients voulant un produit bien fini, il faudra soigner l’aspect final de ces solutions.

Suite au découpage du projet, vient la présentation des plannings des phases 1 et 2.

---

p=. *Gantt

+Phase1:+

Les premiers tests de faisabilité que l’on nommera test pré qualificatifs, nous ont permis d’entrevoir les possibilités qu’offrent les solutions retenues pour le projet. Ainsi sera présenté le planning de la phase 1 qui s’est déroulée de mars à mai 2015 et son état d’avancement. De plus un bilan et les conclusions tirées de cette phase seront exprimés un peu plus loin.

p=. !https://forge.clermont-universite.fr/attachments/download/15929/gantt_phase1v2_20150503214628_20150503214643.jpg!

p=. Figure 4 — Gantt de la première phase

Le planning se décompose en deux parties. Chaque partie correspond aux premiers tests prévus pour chaque solution. On remarquera, que pour la solution du Raspberry pi les premiers tests se sont montrés concluants même si quelques points doivent être améliorés, ainsi le planning a pu se dérouler correctement. Cependant pour la solution commandant un signal IR, quelques tests ne se sont pas déroulés comme prévu, ce qui a retardé l’avancement de cette solution. C’est pourquoi le planning est resté bloqué notamment au niveau de la partie émission pour cette partie. Les problèmes rencontrés et les résultats des premiers tests pré qualificatifs sont présentés plus en détail dans la prochaine partie.

+Phase2:+