Version actuelle datée du 15 juin 2018 à 21:40

Présentation générale

Description

Notre objectif est le suivant :

L'institut CAMSP Montfort s'occupe d'enfants sourds ou malentendants. La plupart de ces enfants sont équipés de systèmes de prothèses auditives. Or, il reste certains enfants qui ne peuvent pas être appareillés. Ainsi, l'institut a eu l'idée d'équiper les enfants d'un objet vibratoire qui soit connecté au son que ferait le praticien : cela permettrait notamment à l'enfant de :

• prendre conscience du monde sonore, auquel ils n’ont pas accès du fait de leur handicap
• développer une fonction d’alerte
• renforcer les informations sonores apportées par leur appareillage
• compléter les informations visuelles

Or pour l'instant, il n'existe aucun dispositif de la sorte sur le marché (car trop peu d'enfants concernés). Nous allons donc créer ce dispositif qui sera mis en open source.

Objectifs

Notre travail consistera donc à créer un dispositif vibrant réagissant au son que produira le praticien. Ce dispositif devra :

• être facile à prendre en main ou à déplacer sur le corps de l'enfant (une balle)
• pouvoir avoir différentes intensités de vibrations (proportionnelles à l'intensité de la voix )
• être relié à un micro pour capter le son du praticien
• être équipé d'une application Android permettant de gérer :
  • une base de données assurant le suivi médical des enfants
  • régler la plage de vibration souhaitée (suivant la sensibilité de l'enfant)
  • pouvoir faire vibrer la balle manuellement

Analyse du projet

Positionnement par rapport à l'existant

Un prototype permettant d'affiner le cahier des charges de l'institut a déjà été conçu durant un projet IMA5. Celui-ci a déjà notamment réalisé un prototype à partir d'Atmega 328p, d'un bracelet vibrant relié et un micro avec un boitier en imprimerie 3D. Tous deux étaient reliés par un fil. Le bracelet vibrait effectivement suivant l'intensité sonore, mais n'avait pas plusieurs niveaux de vibrations possibles. Par ailleurs, la liaison entre le bracelet et le micro n'était que filaire. Une application Android gérant le suivi des patients a également été développée, mais il était impossible de gérer l'intensité de la vibration via l'application ou de déclancher une vibration par appui sur un bouton.

Analyse du premier concurrent

Nous n'avons actuellement aucun concurrent direct (personne tentant de réaliser un dispositif similaire au nôtre). Néanmoins, nous avons certains concurrents indirects. Par exemple, une université au Colorado ayant créé une oreillette équipée d'un micro qui est capable de capter les sons et le retransmet via bluetooth à un petit dispositif placé sous la langue. Celui-ci transforme le son initial en motif et l'envoie sous forme de signaux électriques. En revanche, il faut un certain temps d'adaptation avant que ce dispositif puisse fonctionner et il n'est pas forcement adapté pour tout le monde.

Analyse du second concurrent

Notre second concurrent est une brosse à dents électrique. Le principe de faire vibrer un objet pour signifier aux enfants qu'une personne veut leur parler a déjà été expérimenté grâce à une brosse à dents électrique positionnée sur le corps de l'enfant. Or, ce procédé est très limité :

• un seul type de vibration
• présence obligatoire du praticien juste à coté de l'enfant pour déclencher la vibration
• pas de convivialité apportée par la forme de l'objet
• impossibilité d'automatiser le déclenchement de vibration en fonction du son émis par le praticien.

Scénario d'usage du produit ou du concept envisagé

Tim est un jeune enfant de 2 ans. Malheureusement, il a très vite été diagnostiqué malentendant, et son état médical ne lui permet pas de porter un implant pouvant lui redonner la possibilité d'entendre quelques sons.

Dans le but d'apprendre à vivre dans le monde qui l'entoure avec son handicap, et ce dans les meilleures conditions, ses parents le conduisent régulièrement au CAMSP MONTFORT, un service social classifié Centre d'action médico-sociale précoce (CAMSP). Dans cet institut, Tim utilise à raison d'une dizaine de minutes par jour une petite balle vibrante. Cette balle a pour intérêt d'aider Tim à comprendre qu'il y a un lien entre des lèvres qui bougent, et la volonté de transmettre un message. Pour ce faire, cette balle émet une vibration proportionnelle à l'intensité de la voix du praticien. De cette manière, la balle devient une sorte de signal mobilisant l'attention de Tim.

Tom est un ami de Tim. Alors que ce dernier sent très bien les vibrations en tenant la balle dans le creux de sa main, Tom a plus de mal à les percevoir. En effet, il est moins sensible que Tim. Heureusement, Sophie, la praticienne s'occupant d'eux, peut modifier l'intensité des vibrations grâce à une application installée sur son smartphone Android, directement connecté à la balle. Avec cette application, elle gère également des fiches propres à chaque enfant dans lesquelles elle note leur évolution grâce à la balle. A la fin de la journée, grâce à la certification waterproof, Sophie peut plonger la balle sous l'eau pour la nettoyer et la reposer sur un socle qui rechargera la balle pour qu'elle puisse la réutiliser le lendemain durant toute la journée.

Réponse à la question difficile

Quel sera le système de rechargement

Nous optons pour le moment pour un système de rechargement par induction. Ce mode de rechargement a les mêmes caractéristiques qu'un chargement classique par câble, et il en offre l’avantage de ne pas devoir placer un port USB sur la surface de la balle. Ainsi nous pourrons plus facilement assurer son étanchéité.

Quelle devra être l'autonomie de la batterie

Selon notre scénario d'usage, la balle vibrante sera utilisée toute la journée par le praticien, soit 10h sans interruption, et rechargée durant la nuit. Nous disposerons donc une batterie à l'intérieur de la balle. Celle-ci devra fournir de l'énergie à la fois à notre module de contrôle mais aussi au moteur qui actionnera un excentrique permettant à la balle de vibrer.

Préparation du projet

Cahier des charges

Le cahier des charges est disponible dans la rubrique documents rendus

Choix techniques : matériel et logiciel

Liste des tâches à effectuer

Nous pouvons résumé 3 principales tâches à effectuer :

• Création de la carte électronique
• Création de l'application
• Création de la balle en impression 3D

Calendrier prévisionnel

Réalisation du projet

Feuille d'heures

Les heures marquées sont indiquées à titre indicatif. En effet, tout au long du projet, nous avons travaillé afin de faire en sorte que notre balle soit fonctionnelle dans le temps imparti. Nous avons en conséquence travaillé non pas à l'heure mais à la tache et n'avons pas (peut-être à tord) fait un décompte précis du nombre d'heures passées à la réalisation du projet.

Premier prototype

Voici à quoi ressemblera notre premier prototype :

Le diamètre extérieur de la balle sera de 14cm.

Le revêtement extérieur ne sera pas celui-ci. Nous avons également commencé à modéliser l'application qui ressemblera à cela :

Prologue

Semaine 1

Durant cette semaine, nous nous sommes fait un aperçu global du circuit que nous allions utiliser. Le schéma était le suivant :

• Une batterie fournit la tension d'alimentation nécessaire.
• Cette batterie est rechargée par un bloc de charge prenant sa source sur une bobine à induction.
• La tension de la batterie diminuant lors de la décharge, sera stabilisée à 5v par un boost converter.
• Un Atmega328PB, relié à deux contrôleurs moteur, trois leds et un module bluetooth gérera les commandes.
• Le module bluetooth assurera la connectivité avec le téléphone/tablette Android.
• Les contrôleurs moteur convertissent le signal PWM provenant de l'Atmega328p en variation de tension.
• Les contrôleurs moteur entraînent des vibreurs disposés sur la surface de la balle.

Schéma de fonctionnement

Semaine 2

Nous nous sommes penchés plus sur le cahier des charges, et avons passé la semaine à définir comment serait notre balle vibrante. Il en est ressorti que :

• La balle sera réalisée via imprimante 3D. Nous devrons ensuite recouvrir cette balle de mousse puis, d'un matériau qui soit adapté au touché de l'enfant. Nous attendons une réponse du CAMSP pour pouvoir définir la texture finale. L’avantage de créer une base en imprimante 3D est que nous pouvons créer la balle de la façon dont nous le voulons, ainsi, nous disposerons à l'intérieur de la balle d'un support pour tenir la batterie et la carte électronique.
• Concernant la carte électronique, il a fallu déterminer quels composants nous allions placer. En effet notre carte électronique sera donc composée :
  • D'un Atmega 328p pour pouvoir stocker notre programme.
  • D'un module Bluetooth LE pour pouvoir avoir une connexion sans fil entre la balle et la tablette, et ce avec une grande efficacité énergétique. Les flux de données transmis entre le terminal Android et la balle étant faibles, nous pouvons nous contenter des débits offerts par le bluetooth 4 Low Energy.
  • D'une batterie Li-on pour pouvoir alimenter l'Arduino et les vibreurs. Nous avons choisi une batterie de type Li-on car elle a un bon rapport poids/énergie. De plus, pour des raisons de sécurité (balle manipulée par des enfants) nous n'avons pas voulu utiliser de batterie Li-Po que nous considérions trop instables (risques d'explosion).
  • Pour recharger la batterie, nous avons décidé de mettre une bobine à induction dans la balle. L’avantage de ce mode de recharge est qu'il se fait entièrement sans fil. Cela permettra un nettoyage facile de la balle, et aucun port USB apparent. De plus, après plusieurs recherches, nous avons décidé d'utiliser une bobine à la norme QI car la portée est très grande (environ 4cm) et étant donné que nous allons remettre des épaisseurs de mousse sur la balle pour la protéger en cas de choc, il faut que la distance de recharge puisse être assez grande.
  • Des LEDs pour indiquer les différents états de la balle.

Nous avons également modélisé le premier prototype de notre balle vibrante pour que le CAMSP nous confirme que ce que nous faisons est bien en adéquation avec leurs attentes.

Semaine 3

Durant cette semaine, les derniers choix de matériel ont été faits.

Charge de la batterie

Chargeur de batterie Li-Ion

La batterie utilisée étant de type Lithium-Ion, cette dernière nécessite un chargeur afin d'assurer le cycle de charge et de décharge. La charge est assurée selon les étapes suivantes :

• Courant maximum constant et tension minimale (3.2v) au début de la charge
• Augmentation de la tension jusqu'à la tension maximale de charge (5v)
• Abaissement du courant de charge jusqu'à 0A

Le chargeur MCP73831T (U1) permet d'assurer ce cycle tout en pouvant être supervisé par des leds :

• Une led orange (D2) témoignant de la charge en cours
• Une led verte (D1) témoignant d'une charge complétée

La tension d'entrée est également découplée (C1).

Boost de la tension

Boost-Converter

Le module choisi pour maintenir la tension à 5v est le TPS61090. La tension de sortie de ce module dépend de la valeur des résistances R8, R9, R3, R7. Elles sont calculées selon les équations suivantes fournies dans la datasheet :

Équation 1:

Avec R7 = 200kΩ, Vfb = 500mV d'après la datasheet. Vo, la tension de sortie souhaitée est de 5V.

Après calcul, R3=1.8MΩ.

Équation 2:

Ici, R9 = 340kΩ, Vlb = 500mV toujours d'après la datasheet. Vbat est la tension minimale de la batterie à partir de laquelle l'indication de batterie faible se déclenche. Cette tension est selon la datasheet de la batterie de 2.75V, mais nous préférons éviter tout risque : en cas de non utilisation de la batterie pendant une longue période, la batterie continue de se décharger à cause de courants de fuite. Si la tension de la batterie passe sous les 2.75V, elle deviendra inutilisable, c'est pourquoi nous minimalisons les risques en fixant la tension de batterie faible Vbat = 3.2V.

Après calcul, R8 = 1.8V.

Équations 3 & 4:

Le boost converter nécessite un "boost inductor" afin de stocker l'énergie durant la conversion. Afin de pouvoir déterminer la valeur de cette inductance (L1), il est nécessaire d'estimer le courant moyen Il traversant l'inductance :

On fixe ici Iout à 500mA, ceci donnera une charge plus lente, mais la balle ne chargeant que durant la nuit, le temps de charge n'est pas un problème, de plus ceci prolongera la durée de vie de la batterie. Concernant Vbat, on se place dans un cas très défavorable, avec une batterie extrêmement déchargée à Vbat = 1.8V. La tension de sortie désirée reste Vout=5V.

Après calcul, Il = 1.750A.

Avec ces données, nous pouvons maintenant dimensionner L1 :

Avec ΔIl = 0.2 * Il, f = 600kHz.

Après calcul, on trouve une inductance Il = 5.5uH au minimum.

Les capacités en entrée, C2 et C3, sont des capacités servant à améliorer le comportement transitoire du montage, et sont conseillées respectivement à 10uf et 0.1uf d'après la datasheet.

La capacité C5 en sortie sert à limiter le ripple (résidus de variation de tension), elle est conseillée à 100uF pour une sortie de 5V.

Enfin, la présence de leds informent des états du circuit :

• Une led bleue (D3) branchée sur la sortie 5V confirme la présence de 5V.
• Une led rouge (D4) alimentée par un transistor (Q1), commandée par la tension Lbo indique une batterie faible.

Gestion du bluetooth

Convertisseur 3.3v

Le module bluetooth choisi fonctionne en 3.3v, or la seule tension d'alimentation présente est 5V, il faut donc un convertisseur 5v vers 3.3v. Nous nous sommes orientés vers un montage avec le MIC5225-3.3 (U5). Des capacités de découplage (C7 et C8) sont également ajoutées ainsi qu'une diode Schottky afin de protéger le circuit.

Les choix étant faits, l'étape suivante était la conception du PCB ainsi que de ses composants. Initialement, pour une question pratique, les composants choisis étaient de taille 1206. Mais rapidement nous nous sommes rendu compte que les composants, de par leur nombre, prendraient trop de place sur le PCB et ne nous permettraient pas de le compacter comme souhaité. Nous nous sommes alors orientés vers des tailles 0603.

Schéma de fonctionnement

Avec les informations précédentes, on établit le schéma suivant :

Schéma complet

Semaine 4

Nous nous sommes penchés plus en détails sur la création de l'application. Pour créer l'application mobile, nous avons décidé d'utiliser le langage Java. En effet, nous devons créer une application Android et après plusieurs recherches, il nous est apparu que le langage Java avec l'aide D'Android Studios était le plus adapté. Nous aurions pu utiliser d'autres IDE (appInventor; inDesign CS6). Celles-ci sont plus faciles à prendre en main, mais offrent beaucoup moins de possibilités. Seul petit problème, nous n'avons, pour l'instant, que des bases assez faibles en langage Java. Une grande partie de la semaine a donc été consacrée à l'apprentissage de ce langage.

Nous sommes ensuite passés à une phase de modélisation des composants sous altium. Certaines footprints étaient déjà disponibles, d'autres non tel que le moduble bluetooth MDBT40 :

Empreinte du module Bluetooth

Premier placement

Durant cette semaine s'est déroulée une longue session de rootage, un premier placement des composants a pu être proposé. Cependant, certains problèmes ont pu être relevés :

• La largeur des pistes par défaut à 0.6mm n'est pas adaptée, en effet, les pads les plus étroits sont ceux du booster de tension avec 0.35mm.
• La face inférieure du booster de tension n'est pas reliée à la masse alors qu'elle le devrait selon sa datasheet afin de dissiper la chaleur. Cela implique également que les pistes ne peuvent pas passer sous ce composant (sur la face supérieure).
• Le placement du module bluetooth n'est pas correct, il doit être idéalement placé en bordure du PCB afin que les interférences ne soient pas un problème. De plus, il est préconisé dans la datasheet de ne pas faire passer de pistes sous ce module (toujours sur la face supérieure). Afin de pouvoir faire passer des pistes sous le module (face inférieure), une masse doit être présente sous le composant en face supérieure. Enfin, le côté de l'antenne côté PCB (ici le côté gauche), doit être espacé de 1 centimètre du reste des composants/pistes.
• Les angles aigus doivent être supprimés afin d'éviter de générer du bruit.
• Le placement des composants doit être revu afin de réduire au maximum la taille du PCB.
• Le placement de composants doit être fidèle à celui préconisé dans les datasheet, surtout au niveau des composants fonctionnant à hautes fréquences (le booster de tension, qui fonctionne en PWM à 600kHz).

Semaine 5

Pour la partie application :

• Nous avons continué à nous former sur le langage Java. En fin de semaine, nous avons téléchargé l'application Andoid Studios et avons commencé à nous familiariser avec la programmation pour la création d'applications (notamment via le tutoriel d'Openclassroom), en suivant le tutoriel. Nous avons notamment pu créer notre première application. Celle-ci consistait à créer une page assez simple où l'on rentre son poids et sa taille et l'application retourne l'IMC. Ce n'est pas quelque chose de très sophistiqué mais ça a l’avantage de mettre en pratique tout ce que nous avons vu jusque-là, que ce soit du Java pour gérer tous les calculs ou le XML pour le design.

Pour la partie PCB : les placements de composants ont été revus afin de corriger les erreurs de la semaine précédente.

Cette version de PCB sera très proche de celle gravée lors de la réception des composants.

Semaine 6

Partie application

Nous n'avons pas encore totalement fini le tutoriel pour se former à la création d'application, mais nous pensons en savoir suffisamment pour pouvoir commencer à designer notre propre application, alors nous nous lançons enfin dans la création de notre application ! La première partie consiste à créer le design général. Comme nous l'avons vu dans le cahier des charges, il faudra une page principale qui servira de menu. Dans cette page nous pourrons voir si la connexion a eu lieu ou si la balle vibre. Nous pourrons également activer ou désactiver la vibration ainsi qu'accéder au niveau de vibration et à la base de données pour le suivi des patients. Nous avons donc commencé à créer cette page. Pour l'instant nous ne faisons que du développement front-end. Nous n'utilisons donc pas le Java (un peu déçus d'avoir passé plusieurs semaines à l'apprendre sans encore l'utiliser) mais simplement le XML qui est un langage de description et de balisage. Pour ce faire nous utilisons des Layout afin de placer les composants dans l'espace. Le plus grand intérêt des Layouts et qu'en les utilisant nos widgets garderont des places similaires peu importe les dimensions de l'écran. Etant donné que le CAMSP ne nous a toujours pas indiqué quelle sera la tablette sur laquelle l'application sera utilisée, et pour des raisons d'adaptabilité sur tous les appareils, il est donc indispensable d'utiliser des Layouts. Vu le design général que nous voulions donner à notre application, nous avons décidé d'utiliser les gravitiy Layouts qui nous permettent de placer les widgets par rapports aux autres.

Semaine 7

Partie bluetooth

Bluefruit LE

Les premières commandes ont été livrées, nous avons alors pu commencer à travailler sur le module bluetooth de Adafruit (Bluefruit LE) que nous avions commandé afin de pouvoir commencer le développement de l'application android avant d'avoir une version finale du PCB.

Cette carte est basée sur le MDBT40, une carte de développement elle-même basée sur la famillede puces nRF51 de Nordic Semiconductor. Cette carte de développement permet donc une connectivité bluetooth 4.2 BLE. Cette dernière fonctionnant avec des tensions de 3V, Adafruit n'a fait qu'abaisser la tension de 5V délivrée par un Arduino à 3V grâce à un convertisseur MIC5225-3.3 que nous réutiliserons dans notre PCB. De plus, afin de protéger les IO de la puce du 5V provenant de l'arduino, des diodes sont placées afin d'abaisser la tension à 3V.

Le but ici est d'initialiser une communication série entre l'arduino et le module bluetooth. Ce module possède un mode UART, lui permettant de se connecter à un téléphone Android et de recevoir et envoyer des trames série. Adafruit fournit des exemples de programmes arduino, avec une librairie spécialement faite pour le module, et même une application android permettant de tester la communication.

Le but ici étant de développer notre propre application, il nous a semblé indispensable de se séparer le plus possible des sources et lourdes appendices de Adafruit. La première étape a donc été de remplacer l'application conseillée par adafruit par une application plus générique : Serial Bluetooth Terminal, cette dernière permettant le strict minimum : la communication série en bluetooth. L'application est disponible à cette adresse sur le playstore : https://play.google.com/store/apps/details?id=de.kai_morich.serial_bluetooth_terminal&hl=fr

Nous avons ensuite entrepris de modifier le code de Adafruit afin de pouvoir contrôler indépendamment les 3 sorties analogiques. Pour cela, la convention adoptée pour la trame est la suivante :

  -Un bit de start sera modélisé par la lettre a, b ou c afin de contrôler respectivement les sorties 1, 2 et 3.
  -Au plus 3 chiffres formant un nombre compris entre 0 et 255 (pas du PWM de l'atmega328p).
  -Un bit de stop (envoyé automatiquement par l'application).

Le code proposé est le suivant :

 while(1) {
   //acquisition de la data
   if ( ble.available() ) {
     c = ble.read();
     //bit de start
     if (c==97) {
       start1=1;
       data=0;
     }
     else if (c==98) {
       start2=1;
       data=0;
     }
     else if (c==99) {
       start3=1;
       data=0;
     }
     //bits de data
     else if (c<=57 && c>=48 && start1==1) {
       data=data*10+(c-48);
     }
     else if (c<=57 && c>=48 && start2==1) {
       data=data*10+(c-48);
     }
     else if (c<=57 && c>=48 && start3==1) {
       data=data*10+(c-48);
     }
     //bits de stop
     if ((c==13 && start1==1) || (c==10 && start1==1)) {
       data_available1=1;
       start1=0;
     }
     else if ((c==13 && start2==1) || (c==10 && start2==1)) {
       data_available2=1;
       start2=0;
     }
     else if ((c==13 && start3==1) || (c==10 && start3==1)) {
       data_available3=1;
       start3=0;
     }
   }
   //écriture de la data sur la sortie PWM
   if (data_available1==1) {
     analogWrite(motor1_2, data);
     data_available1=0;
   }
   if (data_available2==1) {
     analogWrite(motor3_4, data);
     data_available2=0;
   }
   if (data_available3==1) {
     analogWrite(motor5_6, data);
     data_available1=0;
   }
 }

Partie application

Nous avons continuer à travailler sur la partie front-end de notre application. Après beaucoup de tentatives, il nous est apparu qu'il ne serait pas possible de réussir à avoir un design qui ne fasse pas amateur en utilisant des gravitiy layout. En effet, même après beaucoup de tentatives, l'activité principale restait extrêmement brouillon. Nous avons donc décidé de changer de stratégie et d’utiliser des Linear Layout imbriqués les uns dans les autres. Il y avait également d'autres soucis, les boutons pour pouvoir accéder aux réglages de la vibration ou au suivi patient étaient bien trop grossiers. C'étaient de simples rectangles très bruts. Il fallait donc les changer. Après beaucoup de recherches, il est apparu que le seul moyen de changer l'aspect des boutons était de redéfinir le design en XML. J'ai donc redirigé le background des boutons que je voulais redessiner vers un petit fichier XML qui change la forme du bouton.

Voici le code XML servant pour créer le design de l'application :

 <?xml version="1.0" encoding="utf-8"?>
 <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
 android:layout_width="fill_parent"
 android:layout_height="fill_parent"
 android:background = "#F0F0F0"
 android:orientation ="horizontal"
   android:baselineAligned="false">
   <LinearLayout
       android:layout_width="wrap_content"
       android:layout_height="match_parent"
       android:orientation="vertical"
       android:layout_weight="1"
       >
       <LinearLayout
           android:layout_width="match_parent"
           android:layout_height="wrap_content"
           android:orientation="horizontal"
           android:layout_weight="1">
           <ImageView
               android:id="@+id/voyantConnecte"
               android:layout_width="70dip"
               android:layout_height="70dip"
               android:src="@drawable/button_green"
               android:layout_weight="1"
               android:layout_gravity="center"
               android:layout_marginLeft="10dip"
               />
           <TextView
               android:id="@+id/texteconnection"
               android:layout_width="wrap_content"
               android:layout_height="wrap_content"
               android:text="@string/balle_connecte"
               android:textSize="25dip"
               android:textColor="#A090A0"
               android:layout_weight="7"
               android:layout_gravity="center"
               android:gravity="center"
               android:fontFamily="serif"
               />
       </LinearLayout>
       <LinearLayout
           android:layout_width="match_parent"
           android:layout_height="wrap_content"
           android:orientation="horizontal"
           android:layout_weight="1"
           >
           <ImageView
               android:id="@+id/voyantVibration"
               android:layout_width="70dp"
               android:layout_height="70dp"
               android:src="@drawable/button_red"
               android:layout_marginLeft="10dip"
               android:layout_gravity="center"
               android:layout_weight="1"
               />
           <TextView
               android:id="@+id/textevibration"
               android:layout_width="300dip"
               android:layout_height="wrap_content"
               android:text="@string/vibration_NON_OK"
               android:textSize="25dip"
               android:layout_gravity="center"
               android:textColor="#B070B0"
               android:layout_weight="7"
               android:gravity="center"
               android:fontFamily="serif"
               />
       </LinearLayout>
           <Button
               android:id="@+id/activVibration"
               android:layout_width="match_parent"
               android:layout_height="wrap_content"
               android:layout_weight="1"
               android:text="@string/marcheArret"
               android:layout_margin="20dip"
               android:background="@drawable/fond_arret"/>
       <TextView
           android:id="@+id/intensiteSon"
           android:layout_width="match_parent"
           android:layout_height="wrap_content"
           android:textSize="15dip"
           android:text="59"
           android:gravity="center"
           android:layout_marginBottom="5dip"
           />
   </LinearLayout>
<LinearLayout
    android:layout_width="wrap_content"
    android:layout_height="match_parent"
    android:orientation="vertical"
    android:layout_weight="3">
   <Button
       android:id="@+id/reglerVibration"
       android:layout_width="match_parent"
       android:layout_height="wrap_content"
       android:layout_marginTop="25dip"
       android:layout_marginLeft="35dp"
       android:layout_marginRight="30dp"
       android:text="@string/regler_la_vibration"
       android:textColor="#f0f0f0"
       android:textSize="20dip"
       android:background="@drawable/bordure"
       android:layout_weight="1"
       />
   <Button
       android:id="@+id/suiviPatient"
       android:layout_width="match_parent"
       android:layout_height="wrap_content"
       android:layout_marginLeft="35dp"
       android:layout_marginRight="30dp"
       android:layout_marginBottom="30dip"
       android:text="@string/suivi_patient"
       android:textColor="#f0f0f0"
       android:textSize="20dip"
       android:background="@drawable/bordure"
       android:layout_marginTop="35dip"
       android:layout_weight="1"/>
</LinearLayout>
</LinearLayout>

Ceci n'est pas très digestif, l'équivalent en visuel sera plus parlant :

Page principale de l'application

Semaine 8

Partie PCB

Les dernières modifications avant gravure ont été apportées :

• L'épaisseur des pistes régulières (ne véhiculant pas de tension d'alimentation) a été grossie à 0.4mm.
• L'épaisseur des pistes véhiculant des tensions d'alimentation a été grossie à 0.6mm
• Dans un souci d'évolutivité, un maximum de pins de l'atmega328p ont été brochés à des connecteurs (pins analogiques et digitaux).
• Afin d'éviter les soucis lors de la gravure du bootloader de l'atmega328p, deux résistances de 0ohms à souder après la gravure ont été rajoutées sur les broches MOSI et MISO, cette opération n'étant pas nécessaire pour SCK, cette dernière n'étant pas connectée.
• Une led du module bluetooth a été remplacée par un connecteur, permettant de brancher une LED qui sera montée à la surface de la balle, ceci permettant de donner un feedback à l’utilisateur quant à l'état de la connexion entre la balle et l'appareil android.
• Des vias ont été rajoutés surtout au niveau du boost converter (ce dernier fonctionnant à une haute fréquence) afin de garantir une bonne asse sur toute la surface du PCB.
• Le routage a été optimisé au niveau du second contrôleur moteur afin de raccourcir au maximum la longueur des pistes.

Partie application

Après avoir réalisé la partie visuelle de la page principale nous avons également réalisé la partie visuelle de l'activité réglages vibration avec également des Linear Layout. Il ne serait pas utile d'afficher le code XML car celui-ci est assez similaire à celui de la page principale, mais voici à quoi ressemble l'activité :

Activité de réglage de la vibration. On peut obtenir une vibration avec une échelle allant de 1 à 100.

Comme vu sur l'image, pour l'activité suivi - patient, il est possible de moduler le niveau de vibration et de tester la vibration minimale et maximale

Connection des widgets du fichier XML au fichier java

obtenue avec cette configuration. Nous avons pensé que cela serait très utile au praticien pour savoir quelle vibration il fallait utiliser avec le patient. Nous rappelons que pour l'instant tout cela n'est que du design et si l'on appuie sur ces boutons rien ne se passe.

Pour l'activité suivi patient, en accord avec Mr BOE, nous n'avons encore rien fait car nous attendons plus d'informations du CAMSP concernant ce que nous devons mettre comme informations.

Une fois la partie front-end faite dans les grandes lignes, nous pouvions maintenant attaquer la partie Java (pas trop tôt !). De même que pour le XML, nous aurons un fichier .java pour chacune de nos activités ou de nos pages). Nous aurons donc pour l'instant un fichier Java pour l'activité principale, un fichier pour l'activité réglage vibration.

Pour chaque fichier Java, il faut le connecter avec le fichier XML correspondant. Pour ce faire, nous avons créé statiquement tous les widgets puis les avons associés aux widgets des fichiers XML avec la fonction findViewById dans la méthode OnCreate (c'est la méthode qui est appelée lors de la création de l'activité) .

Connection des widgets du fichier XML au fichier java

Une des autres choses très importantes à faire est de relier les activités entre elles. C'est à dire faire en sorte que lorsque l'on appuie sur le bouton réglage vibration ou suivi patient il y ait l'activité correspondante qui se lance ainsi que la page correspondante qui s'affiche. Pour faire cela, nous avons utilisé des intents. Un Objet Intent nous permet de relier deux activités entre elles, pour pouvoir échanger des données ou passer de l'une à l'autre. Nous créons une classe anonyme pour gérer l'appui sur un des boutons qui nous fait changer d'activité, et dans cette classe nous créons un Intent nous permettant de lier l'activité principale et celle vers laquelle nous voulons aller, puis via la méthode startActivity, nous lançons l'activité reliée par l'Intent à notre activité principale.

Le reste de la semaine a été consacré à des recherches pour l'utilisation du Micro dans une application Android. En effet, le son sera capté par le micro du téléphone. Si le CAMSP décide que le micro devra se trouver vers le patient et non pas vers le praticien, nous utiliserons un micro bluetooth.

Semaine 9

Partie PCB

Lors de cette semaine, nous avons pu lancer la gravure de notre PCB après une dernière vérification par Mr BOE et Mr FLAMEN. La gravure s'est correctement déroulée, une inspection à la loupe du PCB n'a révélé aucun défaut. Le PCB est donc prêt pour la soudure. Nous avons donc récupéré les derniers composants (surtout les CMS). Malheureusement le peu d'expérience que j'ai ne me permettait pas de souder tous les composants en moins de 4 heures (affirmation confirmée par Mr FLAMEN et vérifiée lors de la phase de soudure). En effet, un passage au four était désiré, tous les composants se devaient d'être placés avant le passage. La soudure se fera donc la semaine suivante.

Photos de la gravure :

• 

  Carte en fin de gravure

• 

  Résultat final

Reste de la semaine : travail sur l'appli android.

Partie application

Nous avons continué à effectuer des recherches sur l'audio et savons maintenant comment nous allons procéder pour récupérer l'intensité du son sur le microphone. Nous allons créer :

• Une méthode RecordAudio qui va activer le microPhone et récupérer des données audio.
• Un timer qui activera tous les dixièmes de seconde une méthode qui viendra récupérer les données recueillies par la méthode RecordAudio et qui l'enverra ensuite par bluetooth à la balle. Pour le moment, étant donné que le bluetooth n'est pas encore programmé, nous nous contenterons d'afficher toutes les 100ms une valeur comprise entre 0 et 255 correspondant à l'intensité sonore recueillie.

Nous avons donc passé une grande partie de la semaine à coder ceci, et vers la fin de la semaine, nous avons commencé à avoir des résultats satisfaisants. La méthode RecordAudio ainsi que le Timer s'active lorsque l'utilisateur appuie sur le bouton acitvierVibration de l'activité principale. Pour ne pas ralentir l'application ou créer de Bug, il a fallu créer un nouveau Thread dans lequel lancer l'application RecordAudio. Nous avons passé un certain temps avant d'enfin pouvoir réussir à utiliser les threads dans notre application. Mais une fois ceci assimilé, il ne restait plus qu'à initialiser un timer et nous avions notre audio qui fonctionnait ! Créer un timer n'était pas une chose très complexe car un grand nombre de tutoriels existait sur internet, mais il est peut-être intéressant de voir à quoi ressemble l'application RecordAudio qui capte le son.

Programmation de la méthode permettant de capter l'audio dans un nouveau thread

Voici une représentation très schématique reprenant les grandes étapes du fonctionnement de l'audio et de la conversion de l'intensité sonore capté en une valeur comprise entre 0 et 255 envoyé à la balle :

fonctionnement de l'audio et de la conversion de l'intensité sonore capté en une valeur comprise entre 0 et 255 envoyé à la balle

Semaine 10

Partie PCB

1) Partie soudure

Package 16-QFN (4x4)

Lors de cette semaine, nous avons soudé les composants en trois étapes :

1.1) Soudure des CMS

La première étape est le dégraissage du PCB (à l'aide d'une gomme par exemple) afin d'assurer de bonnes soudures et pas des "collages". On dépose ensuite la pâte à braser sur les points de contact. Enfin les composants peuvent être posés directement sur la pâte. Cette étape n'est pas d'une grande difficulté, excepté pour le boost converter (TPS61090) qui a un package 16-QFN (4x4), c'est à dire avec les contacts situés sous le composant, empêchant de voir si oui ou non des ponts se sont formés lors de la soudure. Une fois les composants placés, la carte peut être passée au four. Le résultat est dans ce cas très satisfaisant, aucune anomalie n'est détectée visuellement (pas de pont, de soudure craquelée ou de mauvaise soudure), et les tests au multimètre (continuité entre autre) n'ont pas révélé d'anomalie au niveau de toute la partie recharge, boost de tension, conversion 5v - 3.3v. En revanche, un souci est détecté au niveau du quartz qui est en court-circuit avec la masse.

PCB en sortie de four

L'origine du court-circuit du quartz est dû à une mauvaise lecture de la datasheet du composant.

Extrait de la datasheet du quartz

En effet, le rootage a été fait en pensant que les pins 2-3 et 1-4 étaient liés. Or, comme nous le montre la datasheet, 2 et 4 sont à la masse. Le quartz a donc été extrait de son emplacement grâce à la station à air chaud, le PCB modifié, et le quartz resoudé, avec succès et sans problème cette fois.

1.2) Soudure du module bluetooth

Nous avons fait le choix de ne pas passer le module bluetooth au four. En effet, même si les températures max notées dans la datasheet du module étaient inférieures à celle du four, Mr FLAMEN nous a déconseillé par expérience de le passer au four. En effet, il serait risqué pour le composant de l'exposer à de trop hautes températures. La soudure s'est donc faite à la pâte à braser, au fer à souder, mais aussi avec un fil d'étain. Les premières étapes sont les mêmes que précédemment avec les CMS : dépôt de la pâte à braser sur les pistes, placement du composant, et fonte de la pâte avec le fer à souder cette fois-ci. Mon erreur aura été de fondre un côté sans appuyer sur le composant, le résultat étant que ce dernier s'est mis en porte à faux sur l'autre côté. Afin de régler le souci, j'ai rajouté de l'étain sur les pistes dont le contact n'était pas bon.

• 

  PCB avec module bluetooth soudé

1.3) Soudure des traversants et des vias

Les seuls composants traversants que nous avons sont juste des headers sur lesquels nous viendrons repiquer des fils qui serviront pour de la programmation, du débuggage, de l'évolution, ou tout simplement pour relier les LEDS, moteurs, et alimentations de la balle. Cette phase du projet est simple mais relativement longue. Pour les connecteurs, même pour une simple masse j'ai pris soin de bien faire la connexion entre les deux faces de la carte. Certains câbles temporaires ont également été soudés, tels que ceux servant uniquement à graver le bootloader de l'atmega328p, et un câble gris permettant de mesurer le 3.3v. Ces câbles pourront être coupés une fois leur tâche remplie.

• 

  PCB entièrement soudé

2) Partie debugging

Le PCB étant maintenant entièrement soudé, il peut être mis sous tension pour la première fois. Pour ce faire, je procède par étapes.

2.1) Test de la partie Arduino/Bluetooth

J'injecte du 5V provenant d'une alimentation secteur après la partie de gestion de batterie (je saute donc le chargeur et le boost-converter) : pas de chauffe anormale d'aucun composant, mais le 3.3V est absent, je n'ai qu'une tension résiduelle de quelques mV. Je me penche donc sur le composant ayant pour fonction d'abaisser le 5V en 3.3V (le MIC5225). Ce dernier reçoit bien les 5V, mais ne sort que quelques mV. Je me suis par la suite rendu compte que j'avais fait une erreur lors de la commande : j'ai commandé un MIC5225 et pas un MIC5225-3.3YM5. La datasheet (commune à ces deux composants) nous apprend que le MIC5225-3.3YM5 sort toujours du 3.3V, alors que la tension en sortie du MIC5225 dépend de deux résistances R1 et R2 supplémentaires représentées sur le schéma ci dessous (extrait de la datasheet) :

• 

  Schéma MIC5225

Cette erreur ayant été découverte dans la nuit de vendredi à samedi, je n'avais pas toutes les valeurs de résistances à disposition. J'ai donc soudé un fil sur la broche 4 du MIC5225, repris le fil du 3.3V et une masse, et avec une breadboard, une résistance fixée, un potentiomètre et cette formule : Vout = Vref(1+(R1/R2)), avec Vref = 1.24V, j'ai pu obtenir un 3.3V correct.

Le problème suivant étant que le module bluetooth ne donnait aucun signe de vie : pas de led, et non détecté par les téléphones. J'ai mis ce problème de côté et ai continué à tester les autres fonctions.

2.2) Test du boost converter

J'ai ensuite injecté du 5V avant le boost converter, toujours avec une alimentation secteur pour ne pas endommager la batterie en cas de souci. Aucun souci, avec une batterie à 3.7V, le boost converter sort un 5V stable, et le 3.3V est aussi stable comme on peut le voir sur la photo ci dessous.