1. Résumé
2. Abstract
3. Introduction
4. Présentation du Sujet
5. Cahier des charges
6. Développement

1. Problématiques

2. Solutions existantes et proposées

3. Faisabilité de nos solutions

7. Gestion de Projet

1. W.B.S.

2. Gantt

3. Coûts du projet

8. Bilan

1. Etat d'avancement

2. Analyse Critique

3. Perspectives

9. Webographie
10. Documents


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.


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.


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.


Présentation du sujet

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

Une partie capteur

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.

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.

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.


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 :

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.

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

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.

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

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.

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


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.


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.


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.


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.


Gestion de Projet

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


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 :

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

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) :

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.


*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.

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:

Figure 5 — Gantt de la deuxième phase

Cette phase s’effectuera à partir de septembre 2015 pour se terminer en janvier 2016. Après avoir découpé le projet en différentes tâches à effectuer, le planning de cette 2ème phase (ci-dessus) nous présente les prévisions du déroulement de chacune de ces tâches. Chaque tâche à effectuer y est présentée avec une estimation de sa durée. De plus, pour chaque solution, une partie conception des cartes électroniques a été prévue. Elle sera sous-traitée par les élèves de quatrième année du département Génie Electrique de Polytech, de septembre à novembre 2015. Nous retrouvons trois jalons représentant chacun un grand axe à terminer. Cependant, nous nous préparons à rencontrer des difficultés pour cette deuxième phase et son planning peut évoluer.
En effet, pour la solution basée sur un Raspberry pi l’ajout d’un écran LCD et le packaging peuvent être les points les plus problématiques. En ce qui concerne la solution relative à la commande infrarouge, les étapes qui nous semblent délicates sont l’émission de la commande et encore une fois la partie packaging. En effet, n’ayant aucune expérience dans la création et le design de packaging réalisable via une imprimante 3D, nous pensons que cette partie pourrait poser quelques difficultés pour les deux solutions.

Maintenant que le découpage et le planning du projet ont été présentés, qu’en est-il du coût de ce projet ?


Coûts du projet

Afin de réaliser les tests pré qualificatifs de la phase 1, nous avons eu besoin de matériel. Nous avons donc dressé un tableau des coûts à prévoir pour les tests pré qualificatifs s’élevant à environ deux cents euros (voir Figure 6 ci-dessous). Ce tableau a été présenté au client, qui l’a ensuite validé.
Ces coûts concernent principalement la solution basée sur le Raspberry pi, puisque c’est celle pour laquelle nous étions le plus libre, et qui a donc nécessité le plus de choix et achats de matériel. En effet la caméra type « go pro » de la première solution nous a été fournie par le client et ne rentre donc pas en compte dans ce calcul des coûts du projet. Seul l’achat de la carte mémoire de la caméra y est présenté.
La prévision des coûts pour la phase 2 du projet est également présentée à la suite du tableau. Ceux-ci s’élèvent à un peu plus de 100€ mais il ne s’agit là que de prévisions. Ces montants peuvent donc être amenés à changer dans de petites proportions, cependant nous pouvons prévoir que les coûts de la phase 2 ne devraient pas dépasser 150€.

Figure 6 — Coûts du projet


Bilan

Cette partie permettra de comprendre où en est le projet à ce jour, en présentant quels sont les éléments déjà fonctionnels et ceux à venir.

Solution carte de commande infrarouge
Les tests pré qualificatifs pour la carte de commande infrarouge ont présenté quelques difficultés notamment dans l’acquisition du signal de commande puis sa réémission.
Dans un premier temps, il a été nécessaire d’observer si le signal infrarouge était bien perçu par le capteur TSOP 1736 utilisé, ce qui fut le cas comme nous pouvons le voir sur l’oscillogramme suivant (Figure 7) :

Figure 7 — Trame infrarouge réceptionnée par le capteur TSOP 1736

Une analyse plus approfondie de cette trame avec l'accès notamment aux temps exacts entre chaque front est possible à l'aide du fichier "Fichier LogicData? pour trame IR" disponible en bas de cette page, que l'on peut ouvrir en utilisant le logiciel Logic de Saleae LLC.

La suite fut plus difficile puisque le but du test était de réémettre directement la trame à l’aide d’une LED infrarouge afin de voir si la commande était bien réceptionnée par la caméra. Après quelques recherches sur internet, il s’avéra d’après le sujet « Reverse Engineering : RGB LED Bulb with IR remote » du site « instructables.com » (1) que le code utilisé par la télécommande était le code NEC, modulé à 38kHZ. Le montage utilisé pour la réémission était le suivant :

Figure 8 — Montage pour réception/réémission de la commande infrarouge

Figure 9 — Schéma du montage pour réception/réémission de la commande infrarouge

Ceci n’a pas fonctionné, plusieurs facteurs sont mis en cause. Le générateur de fréquence utilisé pour la modulation du signal ne générait pas une fréquence exacte de 38 kHz et la LED IR utilisée n’émettait peut être pas dans le bon spectre de lumière.
Il fallait donc déterminer dans quel spectre de lumière la télécommande IR émettait son signal. Pour cela, un spectromètre était nécessaire. Grâce à l’aide apportée par Monsieur Réveret et à un spectromètre centré sur la longueur d’onde 940nm, il fut déterminé que le spectre émis par la télécommande IR était centré autour de 940nm comme on peut le voir sur la capture d’écran suivante du logiciel Caliens (Figure 10), il faut préciser pour cela que les pointillés verticaux se situent à la longueur d’onde 940nm.

Figure 10 — Spectre d’émission de la télécommande IR

Il faudra donc commander une LED IR de spectre d’émission centrée autour de 940 nm pour que la caméra puisse réceptionner le signal envoyé par la carte IR. L’accent fut ensuite mis sur la partie programmation de la carte, avec notamment le traitement du signal réceptionné.

Le code NEC utilisé présente des niveaux logiques longs de 560 microsecondes dans le plus petit des cas. Aussi pour avoir une bonne reproduction du signal il paraît judicieux d’utiliser au moins dix points d’échantillonnages par niveau logique successif. Il faudra donc échantillonner le signal toutes les 50 microsecondes, soit à 20 kHz. Pour un aspect pratique, l’acquisition du signal se fera pendant deux secondes après l’appui sur un bouton poussoir. Ceci est amplement suffisant puisque la trame envoyée par la télécommande dure un peu moins de 70 millisecondes. Il faudra donc stocker en mémoire 40kbits soit 5 ko sur la totalité des deux secondes.

Grâce à la carte de synthèse utilisée pendant la phase 1 du projet, une partie du code traitant cette acquisition a pu être faite. Actuellement le code développé (fichier "main.c" accessible dans le dossier "Partie carte IR" de l'archive "code.zip" téléchargeable en bas de page) permet de lancer une routine d’interruption toutes les 50 microsecondes pendant deux secondes, ce qui correspond aux besoins donnés précédemment. Il faudra ensuite acquérir le signal de commande IR et l’enregistrer en mémoire non volatile, puis réémettre la trame enregistrée sur une onde porteuse de 38kHz.

Actuellement, cette solution n’est évidemment pas aboutie, il y aura certainement quelques difficultés pour l’enregistrement des trames qui nécessitera probablement l’ajout de mémoire, celle du PIC n’étant pas suffisante. Cependant, les tests menés permettent de croire en la réalisation finale de cette carte pour janvier 2016.

Solution basée sur un Raspberry pi 2
Pour cette solution, des libertés nous ont été accordées et il a été ainsi possible de choisir le matériel que nous souhaitions, pour réaliser une solution à la fois peu onéreuse, reproductible facilement par le client et capable de respecter toutes les contraintes du cahier des charges. Le choix de se tourner vers une solution basée sur un Raspberry pi 2 a ainsi été pris.
Il a fallu tout d’abord choisir le matériel et le commander. Les choix d’Amazon et de Kubii comme fournisseurs se sont imposés. En effet, ils permettaient d’obtenir des prix défiant toutes concurrences tout en ayant une livraison rapide, ceci afin de commencer les premiers tests le plus rapidement possible. Les différents éléments commandés ont été : un Raspberry pi 2 avec son alimentation et une PiCam? qui est un petit module caméra spécialement adapté pour un Raspberry pi (Figure 11).

De plus, le choix d’une batterie de 9000 mAh s’est fait d’une part, pour son faible prix, et d’autre part, pour sa capacité qui permettra en théorie de garder le Raspberry pi avec sa caméra allumée pendant environ 9 à 10h. De plus le choix d’une carte SD de 32 Go fut pris pour avoir une capacité d’enregistrement vidéo suffisante.
Après réception de tous ces éléments, il a fallu s’adapter à ce type de matériel car nous n’avions jamais travaillé sur une telle plateforme. Cependant, ce travail fut facilité grâce à une documentation fournie sur internet.
La première étape a consisté à installer un système d’exploitation sur la carte SD. Après documentation (2) le choix s’est porté sur Raspbian pour sa stabilité. Ainsi les premiers tests avec la caméra ont pu être effectués avec l’ajout d’un bouton poussoir (Figure 12) installé de la façon suivante :

Figure 12 — Schéma (Raspberry.org) et montage pour les premiers tests

Pour la programmation des différents scripts (accessibles dans le dossier "Partir Raspberry pi" de l'archive "code.zip" en bas de page) tous les deux écrits en python, les sites internet Picamera (3) et GordonProject? (4) ont été très utiles. Ainsi le démarrage et l’arrêt suite à la réception d’un signal électrique a pu être validé.
Ensuite d’autres étapes ont été effectuées comme le reformatage de la carte pour la partitionner afin que les vidéos soient accessibles depuis n’importe quel ordinateur. Ceci a été fait en utilisant le logiciel MiniTool? Partition Wizard et a été une étape délicate. Ensuite l’ajout d’un bouton stop a été décidé, car cela sera utile pour l’utilisateur final qui n’aura pas de clavier pour interagir. Le script permettant cette fonction (dans l'archive "code.zip") a été créé sur la base d’un code déjà existant et disponible sur le site Hardware-libre (5). Puis il a fallu faire exécuter ces scripts lors du démarrage du Raspberry pi en paramétrant un fichier dans Raspbian.
Une fois toutes ces étapes validées, une carte prototype (Figure 13 et archive "cao.zip") a été conçue pour intégrer le bouton d’arrêt mais aussi un étage de régulation. En effet la tension envoyée par le module des chercheurs sera de 5V et les entrées du Raspberry pi n’acceptent que du 3,3V. Pour cela, le choix fut porté sur un régulateur ADP3338 car après discussion avec les clients, leur module envoie une tension entre 5V et 3,7V. De ce fait le régulateur permet d’adapter n’importe quelle tension jusqu’à 8V, alors qu’un simple pont diviseur n'aurait été adapté qu'à une seule tension d'entrée.

Figure 13 — Carte prototype d'adaptation d’entrée du Raspberry Pi

Les premiers tests se sont donc montrés concluants avec une plateforme polyvalente et performante. Cependant des éléments restent à améliorer ou à ajouter. En effet, concernant l’enregistrement des vidéos, les fichiers sont écrasés lorsque l’on éteint le Raspberry. Ceci provoque une perte de données si l’on ne fait pas attention entre deux manipulations. La conservation des données dans n’importe quel cas étant un point crucial pour les chercheurs, il faudra donc lors de la prochaine phase régler ce problème.
Un autre ajout important sera l’intégration d’un écran LCD au Raspberry pi car à l’heure actuelle la personne filmant ne peut pas cadrer de façon précise. De plus, on pourra aussi améliorer les fonctionnalités en effectuant du streaming vidéo sur un téléphone ou un ordinateur. Ces ajouts sont prévus pour la 2ème phase. De même pour la partie packaging qui n'a pas encore commencé. Tous ces éléments devront être effectués pendant la 2ème phase pour remplir les objectifs imposés par le cahier des charges afin d'avoir un objet clés en main et prêt à l’emploi.


Etat d'avancement

a) Solution : Carte Infrarouge commandant une caméra type "go"pro“:

Eléments présents et fonctionnels:

Montage permettant la récupération de la trame de commande de début et fin d'enregistrement à l'aide du TSOP 1736.
Déclenchement d'une interruption toutes les 50 microsecondes pendant deux secondes, suite au passage à 1 d'une entrée de la carte de synthèse.

Eléments à améliorer:

Code pour enregistrement de la trame délivrée en sortie du TSOP 1736, sur une mémoire EEPROM à rajouter.
Réémission de la trame sur une porteuse de 38kHz à l'aide d'une LED dont le spectre d'émission est centré autour de 940nm (infrarouge).
LEDs indiquant l’état de la carte (sauvegarde d’une commande, émission du signal, etc…)
Conception d’une nouvelle carte plus petite pour le transport.
Enregistrement de plusieurs commandes, pour avoir un système compatible avec d'autres caméras, avec analyse du code utilisé pour réémission sur la bonne porteuse.
Intégration d’un écran lcd pour prise en main plus pratique et choix de la commande à envoyer.

b) Solution basée sur un Raspberry pi 2:

Eléments présents et fonctionnels:

Enregistrements de vidéo pilotables via signal un électrique (Figure 14) avec affichage de la date et de l’heure sur chaque vidéo. De plus, ces vidéos sont récupérables depuis n’importe quel ordinateur disposant d’un port de carte SD. Ainsi, les vidéos sont enregistrées sous le format suivant : « Video_#1.h264 ; Video_#2.h264, etc… »
Un bouton-stop a été intégré à la carte de prototype pour éteindre normalement le Raspberry pi même en n’ayant pas accès à un clavier.
Fabrication d’un prototype de carte électronique pour adapter le signal d’entrée.

Figure 14 — Vidéo durant les tests pré qualificatifs du Raspberry pi

Eléments à améliorer:

Eviter l’écrasement des fichiers vidéos à chaque début de séances.
Améliorer le bouton en ON/OFF
Manque de LEDs présentant l’état du Raspberry pi


Analyse Critique

Suite aux premiers résultats des tests pré qualificatifs et à cette première étape d’avant-projet, nous présentons ce qu’a pu nous apporter cette expérience et quelles conclusions nous avons pu en tirer.

Analyse d’Anthony:

Le projet de récupération et synchronisation de données tel qu’il nous a été présenté a quelque peu évolué depuis son départ. En effet, la récupération des données capteurs n’est pas une priorité pour le client, celui-ci nous a dit préférer avoir deux solutions réellement abouties, prêtes à l’emploi. Nous avons bien accueilli cette modification puisque Billy et moi pensons également qu’il est préférable d’aboutir à une solution clé en main, plutôt qu’à une solution présentant plusieurs fonctionnalités, mais pas réellement utilisable dans l’immédiat. La conduite de ce projet pendant ces quelques mois fut très enrichissante. En effet, elle nous a permis tout d’abord d’appréhender la préparation d’un projet, avec l’élaboration du Gantt et du WBS qui permettent d’établir des objectifs liés à certaines parties d’un projet. Ceci nous servira certainement beaucoup dans notre future vie professionnelle en tant qu’ingénieur. En l’occurrence, la phase 1 de notre projet nous a démontré que le suivi du Gantt n’était pas toujours évident et que l’on rencontrait parfois des complications. Cette expérience nous a donc incités à prévoir une marge de manœuvre plus large pour la phase 2 du projet et à réfléchir de manière plus approfondie à la durée probable de réalisation d’un objectif. Ensuite, la conduite d’un projet à deux permet de se plier aux règles d’un travail en équipe qui demande de la concordance dans les actions et des compromis pour accorder les points de vue. Là encore, ceci est primordial dans notre futur métier d’ingénieur. Enfin la revue d’appel d’offre à présenter en fin d’année est un point très positif puisqu’elle nous met dans les conditions de travail d’un ingénieur chef de projet qui doit répondre à un cahier des charges, réfléchir à une solution et la présenter de manière claire et succincte pour être compris par le plus grand nombre. De cette façon, nous comprenons que la présentation de la réponse apportée est aussi importante que la réponse en elle-même, puisque c’est celle-là qui nous permettra de remporter un appel d’offre ou pas, et nous pousse donc à présenter un projet parfois complexe de manière plus simple.
Ce projet fut donc l’occasion d’enrichir ses connaissances autant d’un point de vue technique avec l’élaboration de solutions pour répondre au besoin du client, mais aussi d’un point de vue management et commercial avec la réalisation d’un Gantt et de la revue d’appel d’offre.

Analyse de Billy:

Au départ, lors du choix de ce projet, nous ne connaissions que dans les grandes lignes le travail à effectuer. En effet, c’est seulement après plusieurs échanges avec nos clients et notre tuteur technique que le projet a pu évoluer et est devenu ce qu’il est aujourd’hui. C’est pourquoi le sujet s’est focalisé sur la synchronisation d’une caméra avec les capteurs qui est en en fait le besoin le plus urgent pour aider et améliorer les résultats de ces chercheurs. Le fait que ce projet a évolué dans ce sens a été pour nous une bonne nouvelle, car cela nous permettra de concevoir deux produits bien finis et prêts à l’emploi. C’est une des forces d’un projet industriel, on le voit évoluer et ceci, quel qu’en soit le contenu. En effet, cela nous permet vraiment de percevoir le travail d’un ingénieur et qu’il faut savoir s’adapter rapidement à toutes situations. Mais cette première phase nous a permis aussi des constater d’autres aspects.
C’est pourquoi ce travail en équipe a aussi été un point très enrichissant pour nous deux. En effet, nous avons dû nous répartir les tâches et nous organiser pour que tout avance au meilleur rythme. Et cette phase d’avant-projet est vraiment très enrichissante dans ce sens, car il faut tirer profit de chacun de nous et des domaines où nous nous sentons le mieux pour que le projet puisse être terminé dans les temps. Cette gestion de projet avec ses différents éléments à organiser comme son découpage (WBS) ou encore l’organisation dans le temps de chaque personne (Gantt) est quelque chose qui m’attire beaucoup, c’est à dire : optimiser notre temps et organisation pour terminer dans les délais et cela avec des personnes s’épanouissant dans leurs travaux. Ainsi lors des bilans, on peut observer ce que nous avons bien estimé ou non, pour ainsi apprendre de nos erreurs et nous améliorer pour nos prochains projets. Ainsi, ce projet nous a permis de déjà effectuer les premiers tests. Lors du de la décomposition des différentes tâches à effectuer, j’ai eu la chance d’obtenir grâce à Anthony, la solution Raspberry pi qui m’attirait le plus. En effet, cette plateforme m’avait toujours intriguée du fait que je voulais l’utiliser pour faire mes propres projets dans le domaine de la domotique. C’est pourquoi, j’ai pris un réel plaisir à travailler sur cette solution et cela m’a permis d’améliorer mes compétences notamment en électronique et en programmation, car j’ai pu découvrir le langage python, que l’on commence à trouver dans de nombreuses applications.
Pour conclure, je pense que cette première phase a été très riche en enseignements, d’une part pour son aspect relationnel lors des échanges avec les clients, et d’autre part pour le travail effectué en équipe avec l’organisation qui en découle : l’adaptation et le respect du travail de l’autre. Mais le plus enthousiasment est la gestion de l’avant-projet et voir celui-ci évoluer avec les premiers tests, apercevoir sa faisabilité et obtenir des résultats probants. Ainsi je suis curieux d’être à la phase 2 afin de voir si nos estimations étaient justes.


Perspectives

Pour conclure ce dossier, il faut savoir que l’objectif d’améliorer les résultats et le confort d’ingénieurs chercheurs travaillant sur la récupération du mouvement à l’aide d’une stimulation des muscles, doit se faire en concevant deux systèmes de captures vidéos, qui se synchroniseraient avec les capteurs portés par un patient. Ceci lors des expériences pour avoir des données capteurs traitables et comprendre ce qu’il se passe en image lors des différentes phases des expériences. Nous avons ainsi préparé le travail à effectuer à partir de septembre jusqu’à janvier 2016, ce qui correspond à la deuxième phase.
En effet, la phase 1 est celle qui s’est déroulée de mars à mai 2015, et où des tests pré qualificatifs ont pu être déjà effectués. De ces premiers tests, des résultats de faisabilité ont pu être tirés. En effet, pour la solution basée sur un Raspberry pi, le planning s’est déroulé sans gros problème avec l’implantation des principales fonctions demandées concernant la caméra. Cependant, il a été noté pour la deuxième phase que des éléments devront être améliorés comme l’enregistrement des vidéos qui ne doit pas effacer d’anciennes vidéos déjà présentes sur l’appareil, à chaque allumage du Raspberry. De même, à l’aide de ces tests, l’ajout d’un écran LCD et la fabrication du boitier du produit final ont vu leur estimation de temps à la hausse pour la 2ème phase.
Ensuite, pour la deuxième solution qui est la commande d’une caméra par signal IR, ces tests pré qualificatifs ont aussi montré une étape compliquée à aborder qui est la réémission d’informations à la caméra type « go pro ». Donc pour la 2ème phase cette étape a été revue à la hausse concernant sa durée. De plus la fabrication du système d’accroche de la carte IR sur la caméra type « go pro » a vu lui aussi son temps alloué augmenter dans le planning.
Une fois tous ces problèmes résolus, et une fois les systèmes terminés, cela permettra aux clients d’avoir deux solutions clés en main et prêtes à l’emploi, ainsi qu’une version pouvant être reproduite facilement. Notre travail fut porté seulement sur cet aspect du projet, à savoir la synchronisation des capteurs et de la vidéo, car c’est le besoin le plus urgent des clients. Cependant une fois cette partie terminée, le projet pourra continuer et pourra être appelé à évoluer pour cette fois-ci, s’occuper de la partie récupérations des données des capteurs et de la vidéo afin qu’elle se fasse de façon automatique sur un ordinateur par exemple. En effet actuellement chaque capteur et caméra enregistre les données sur une carte SD qui lui est propre. C’est pourquoi ce projet peut évoluer et aider ces chercheurs dans leurs expériences qui ont pour but d’améliorer la vie de personnes touchées par des maladies handicapantes comme Parkinson.


Webographie

Dans cette partie se trouvent tous les sites internet consultés pendant la phase 1 du projet.

Wikipédia - http://fr.wikipedia.org/wiki/Raspberry_Pi
Inria - http://www.inria.fr/
Demar - http://www.lirmm.fr/demar/

(1) Instructables - http://www.instructables.com/id/Reverse-Engineering-RGB-LED-Bulb-with-IR-remote/step7/The-right-way/
(2) Raspberry pi - https://www.raspberrypi.org/resources/
(3) PiCamera? - http://picamera.readthedocs.org/
(4) GordonProject? - https://projects.drogon.net/raspberry-pi/wiringpi/
(5) Hardware-libre - http://hardware-libre.fr/


Documents

Fichier contenant plusieurs annexes du projet : Annexes de notre projet

Fichier ouvrable à l'aide du logiciel Logic de Saleae LLC pour analyse de la trame IR de début et fin d'enregistrement vidéo de la caméra fournie par le client : Fichier LogicData pour trame IR

Archives contenant les codes sources des programmes : code.zip

Archives contenant la C.A.O. : cao.zip

Synoptique_global_20150525231330_20150525231409.bmp (1.13 MB) axel BARRIEUX, 04/02/2021 10:16 AM

Patient_20150525232658_20150525232733.png (312 KB) axel BARRIEUX, 04/02/2021 10:17 AM

W.B.S_20150525232658_20150525232950.png (229 KB) axel BARRIEUX, 04/02/2021 10:25 AM

gantt_phase1v2_20150503214628_20150503214643.jpg (87.7 KB) axel BARRIEUX, 04/02/2021 10:27 AM

phase_2_1_20150525235247_20150526000302.png (124 KB) axel BARRIEUX, 04/02/2021 10:28 AM

phase_2_2_20150525235247_20150526000204.png (128 KB) axel BARRIEUX, 04/02/2021 10:29 AM

P15AB10_couts_projet_20150605195520_20150605195555.png (29.4 KB) axel BARRIEUX, 04/02/2021 10:30 AM

P15AB10_trame_oscillo_20150605210716_20150605210738.png (626 KB) axel BARRIEUX, 04/02/2021 10:31 AM

P15AB10_montage_reception_reemission_IR_20150605211325_20150605211619.png (503 KB) axel BARRIEUX, 04/02/2021 10:32 AM

P15AB10_schema_reception_reemission_IR_20150629014143_20150629015540.png (60.3 KB) axel BARRIEUX, 04/02/2021 10:33 AM

P15AB10_spectre_emission_telecommande_IR_20150605211325_20150605211718.png (94.6 KB) axel BARRIEUX, 04/02/2021 10:34 AM

RB1_20150525234059_20150525234546.jpg (33.7 KB) axel BARRIEUX, 04/02/2021 10:34 AM

RB2_20150525234059_20150525234531.jpg (23.1 KB) axel BARRIEUX, 04/02/2021 10:35 AM

Premiertest2_20150526010949_20150526011148.png (184 KB) axel BARRIEUX, 04/02/2021 10:35 AM

PrototypeRB_20150525235247_20150525235310.png (221 KB) axel BARRIEUX, 04/02/2021 10:36 AM

VideoTestRB_20150525234059_20150525234330.jpg (65.7 KB) axel BARRIEUX, 04/02/2021 10:39 AM

Annexes.pdf (941 KB) axel BARRIEUX, 04/02/2021 10:42 AM

Trame_REC.logicdata (6.35 KB) axel BARRIEUX, 04/02/2021 10:43 AM

code.zip (3.23 KB) axel BARRIEUX, 04/02/2021 10:43 AM