Polytech Projets Ge

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 :