Version du 14 mai 2018 à 16:58

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

Choix techniques : matériel et logiciel

Liste des tâches à effectuer

Calendrier prévisionnel

Réalisation du projet

Feuille d'heures

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.

Équation 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>

Et voici l'équivalent en visuel :

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 masse 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 fichiers 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 fichiers 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 256 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 cela 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 :

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

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.

• 

  Tensions PCB

2.3) Test du chargeur li-ion

J'ai laissé la batterie se décharger jusqu'à allumage de la led rouge témoignant d'une faible charge. J'ai branché une alimenantion 5V avant le chargeur de batterie li-ion et après quelques minutes, la led rouge s'était éteinte, témoignant du bon fonctionnement de la fonction de recharge.

Partie application

Partie Récupération du son

Nous avons couplé le son recueilli par la méthode RecordAudio avec le coefficient de vibration que l'utilisateur a sélectionné. De base, ce coefficient de vibration est de 50. Il a été plus compliqué que prévu de faire cela car nous n'avions pas assez assimilé le fonctionnement des Intent pour pourvoir réussir cela. Après pas mal de tentatives, nous avons réussi à faire passer la valeur du coefficient de vibration qui se trouvait dans l'activité réglage vibration à l'activité principale, mais seulement lorsque l'utilisateur appuie sur le bouton OK. S'il décide d'appuyer sur le bouton retour, ses changement ne sont pas enregistrés. Pour résoudre ce problème, il faudrait implémenter une méthode OnStop et la méthode OnPause (qui serait appelée lorsque l'on appuie sur le bouton retour), mais, au vu de ce qu'il nous reste à faire, nous préférons nous concentrer sur des problèmes plus importants et avons décidé de revenir là dessus s'il nous reste du temps plus tard. Malgré ce petit imprévu, nous avons néanmoins maintenant un son qui est capté par le micro et qui est ensuite traité et modulé suivant la valeur de l'intensité de vibration qu'a demandé l'utilisateur. Ce sera au final une valeur comprise entre 0 et 255 qui sera envoyée par bluetooth à la balle.

Partie Bluetooth

Mis à part le bluetooth, toute l'application est à peu près fonctionnelle, bien qu'il reste encore beaucoup de bugs à régler. Nous avons donc décidé d'attaquer la dernière grande étape de notre application : la gestion du Bluetooth ! Nous nous sommes documentés sur la façon dont le bluetooth se programmait. A noter que notre bluetooth n'est pas un bluetooth classique mais un BLE (pour bluetooth Low Energy). Nous avons choisi ce type de Bluetooth principalement car il consomme beaucoup moins qu'un bluetooth classique. L’inconvénient est qu'il y a peu d'informations ou de tutoriels sur la façon de programmer ce type de bluetooth. Après quelques temps de recherches, nous nous sommes décidés sur comment nous utiliserons la gestion du bluetooth. Notre module bluetooth sera utilisé comme serveur et notre smartphone ou tablette comme client. Pour l'instant, le PCB n'est pas encore fonctionnel, heureusement pendant qu'un des binômes continue de souder et de le debugger, l'autre peut travailler sur le bluetooth de l'application grâce au module bluetooth prêt à l'utilisation que nous avons acheté chez adafruit. Nous nous sommes inspirés du tutoriel d'Andrew Lunsford pour réaliser le bluetooth qui est extrêmement bien expliqué et que vous pourrez retrouver à l'adresse suivante : https://www.bignerdranch.com/blog/bluetooth-low-energy-part-1/ Seul problème, il utilise la technologie de l'Advertising (enfin 2010 environ^^) qui est assez récente, et le smartphone que nous utilisons pour développer notre application ne supporte pas l'Advertising. Deux solutions s'offrent alors à nous : acheter un nouveau smartphone Android ou changer la façon dont nous implémentons le bluetooth. N'ayant pas un budget illimité, nous avons décidé de trouver un autre moyen de programmer le bluetooth sans utiliser l'Advertising.

Pour résumer, il y a deux façons pour faire en sorte que deux appareils bluetooth low energy communiquent ensemble. Soit via le mode advertising, soit via le mode connecté. Avec le mode advertising, l'appareil émet des trames de façon régulière et tous les appareils peuvent capter ces trames et les lire. Le mode connecté quant à lui établi comme son nom l'indique une connexion entre les deux appareils et eux seuls peuvent alors communiquer ensemble. Pour notre utilisation, le mode connecté peut donc tout à fait fonctionner (nous étions au départ sur l'advertising car il consomme un petit peu moins d'énergie). Nous avons donc continué de tenter d'établir une connexion entre nos deux appareils et magie, vers la fin de la semaine, nous avons réussi à établir une connexion ! En cliquant sur le lien ci-dessous, vous accéderez à une vidéo montrant la connexion qui s'est établie.

vidéos montrant la connexion bluetooth entre le smartphone et le module bluetooth [[1]]

Attention, il ne faut pas prendre en compte les ronds verts et jaunes indiquant que la balle est connectée et qu'elle vibre car ceux-ci n'ont pas encore été programmés et ne sont donc pas corrects.

L'application est programmée pour se connecter automatiquement : elle recherche automatiquement tous les périphériques bluetooth qu'elle capte, puis quand elle trouve le périphérique bluetooth d'Adafruit (celui auquel nous voulons nous connecter), elle tente une connexion. C'est pour cela qu'au début de la vidéo, vous voyez s'afficher TV samsung 5 serie. Il semble que mon voisin possède une Télé connectée ! Bref mis à part ce détail, vous pouvez remarquer que le module bluetooth d'Adafruit est bien repéré puis que la connexion arrive à s'établir car le témoin lumineux bleu signalant qu'une connexion s'est établie s'allume.

Partie création de la balle

Maintenant que nous connaissons les dimensions de la carte électronique ainsi que des différents composants qui nous servirons à créer notre balle vibrante, nous pouvons commencer avons réfléchi sur comment nous allions créer la balle en elle même. En effet nous ne pouvons pas remettre à notre client ( le CAMSP ) simplement un logiciel et des circuits électrique mais il faut bien une balle. Ce premier prototype sera réalisé en imprimante 3D. Nous pensons ensuite envelopper de mousse le modèle 3D que nous aurons fabriqué pour lui donner une meilleur résistance au choc.

Nous devons donc créer une balle qui respectera les exigences suivantes :

• Avoir un diamètre de moins de 15cm pour que l'enfant ou le praticien puisse la manipuler avec aisance.
• Fixer la carte électronique et la batterie de manière à ce que ces dernières ne bouge pas lors des manipulations de la balle vibrante.
• Avoir des emplacements pour pouvoir poser des vibreurs ( 6 au total ).
• Avoir des trous pour pouvoir placer des LEDs et un interrupteur.

Nous avons réfléchi à comment nous pourrions fabriquer une balle répondant à tous ses critères et nous avons ensuite modéliser notre prototype sur le logiciel de CAO OnShape.

Après réflexion, nous avons décidé de faire deux parties pour la balle, nous assemblerons ensuite ces deux parties via un système de clips. La partie basse de la balle devra contenir le PCB, la bobine à induction ainsi que 3 vibreurs tandis que la partie haute aura la batterie et les trois dernier vibreurs.

Voici donc différentes vu du premier modèle de notre balle :

Vue de coté

Vue isométrique

Comme on peut le voir sur les images ci-dessus, la balle ne sera pas totalement ronde mais aura une partie plate. Nous avons prit cette décision pour que la balle puisse être rechargée par induction. En effet, la bobine à induction doit obligatoirement être posé sur une surface plane pour pouvoir fonctionner de manière optimale. De plus le fait d'avoir cette surface plane nous permettra de poser la balle et de la manipuler plus facilement.

La bobine sera donc déposé au fond de la balle est sera fixé avec une pointe de colle et du ruban adhésif pour que la bobine puisse bien plaquer contre le PLA de la boule. Les données constructeur nous indiquait que la portée d'une recharge par induction QI était de 4cm. une fois le matériel reçu nous aovns fait nos propres tests pour vérifier la porté. Il nous est apparu que au delà de 1cm, l'échange de tension n'avait plus lieu. Il est donc très important que la bobine plaque bien contre la balle pour que celle ci soit au plus près du chargeur lorsqu'on pose la balle sur la base. Nous avons mis une épaisseur de balle de 5mm. Nous avons également prévu des renfoncement pour pourvoir placer les vibreurs, de cette façons, nous pourrons les placer exactement à égal distance et nous aurons également une meilleur vibration.

Comme on peut le voir sur la figure ci-dessous, nous avons deux plaques rebords qui serviront à maintenir la carte électronique.

vue de dessus

La carte viendra se poser sur les rebord, et deux plaques viendront par dessus le PCB. ceci seront munies de tétons qui viendront s'enficher dans les trous prévu à cet effet. Ainsi la carte sera pris en tenaille et ne pourra plus bouger. Nous avons modéliser ce système de fixation sur le logiciel OnShape pour vérifier que toutes nos dimensions concordaient et que cela était viable :

modélisation du système de fixation du PCB

Notre modèle étant terminé nous avons pu l'enregistrer au format STL et l'imprimer sur la Witbox du fabricarium. Il devrait normalement être imprimé la semaine prochaine.

Semaine 11

Partie application

Après avoir réussi à connecter nos deux appareils bluetooth, il a fallu faire en sorte que le smartphone envoie des données au module. Pour cela nous avons commencé par initialiser la connexion. Pour faire cela, il nous fallait plusieurs données du module bluetooth dont le service UUID et le characteristic UUID que nous avons réussi à obtenir dans la datasheet du constructeur. Après pas mal de tests et de ligne de code, nous avons enfin pu envoyer des données et faire vibrer nos moteurs via bluetooth !

Partie création de la balle

photographie de notre premier prototype imprimé de balle On remrque bien le clips qui a cedé

coté prototype de la balle nous avons pu imprimer la partie basse au fabricarium. Cela a été très instructif car ça nous a permis de repérer ce qui fonctionnait mais également ce que ne fonctionnait pas avec notre premier modèle. La conception générale était bonne, mais nous avons eu deux gros problèmes :

• Entre le moment de la conception et de l'impression, les dimensions de la carte électronique avait changés et nous n'avions pas pensé à prendre cela en compte. Les rebords étaient donc placé trop bas et la carte électronique ne pouvait plus être fixée.
• Les clips qui devait servir à assembler la partie basse et la partie haute n'était pas du tout assez flexible, de plus il était bien trop petit et fragile. En conséquence, ce qui devait arriver arriver arriva et un des clip s'est cassé lors d'une manipulation.

Cela nous a fait comprendre que réaliser la fixation des deux partie de la balle garce à des clip était faisable mais nous devions changer notre type de PLA voir prendre une autre matière et réaliser de nombreux essais avant de trouver la bonne forme et les bonne dimension. Or nous avions encore beaucoup d'autres points sur lesquels nous devions travailler (réalisation de l'application, du PCB...) pour que nous nous attardions la dessus. Nous avons donc décidé de changer le système de fixation.

photographie de notre premier prototype imprimé de balle On remrque bien le clips qui a cedé

Nous n'utiliserons plus de clips mais des attaches qui viendront se loger dans des renfoncement qui se trouveront dans la partie supérieur de la balle. le renfoncement se rétrécira afin que l'attache finissent pas se bloquer. Pour faire cela nous sommes resté sur le design général du clips mais avons changer quelque peu son ergonomie afin qu'il puisse répondre aux nouvelles contrainte et surtout nous avons doublé son épaisseur pour le rendre bien plus résistant. Le croquis à gauche montre comment les attaches de la partie basse vienne s’emboîter dans les alcôves de la partie haute. Il y aura pour la balle 3 fois ce système d’accroche des deux parties de la balle.

Nous avons donc modélisé ces changements sur la partie basse puis avons nous sommes occupée de la partie haute que nous n'avions pas encore commencé. Il nous a fallu plus de temps que prévu pour faire la partie haute car celle-ci était beaucoup plus complexe que ce que nous devions faire initialement. En effet, il a fallu modéliser les creux pour les attaches ainsi que la fixation de la batterie. Voici donc ce que nous avons après modélisation :

vue de dessus de la partie haute de la balle

vue de dessus de la partie haute de la balle

vue isométrique de la partie haute de la balle

Comme sur la partie basse, on remarque les emplacements pour poser les vibreurs. Nous avons également placé 3 trous pour pouvoir mettre les LEDs du cahier des charges. Pour rappels ces LEDs devront s'allumer lorsque la balle sera connectée, vibrera ou encore sera en recharge. Nous avons fait un trou pour insérer un bouton ON/OFF qui nous semblait indispensable afin d'économiser de la batterie. Et justement, la batterie viendra se poser dans l'emplacement prévu à cet effet, et un couvercle viendra se fixer au dessus pour empécher la batterie de bouger ou de sortir de son emplacement. Le couvercle sera monté serré dans l'emplacement et il sera également muni de 4 ergos qui viendront se ficher dans les 4 petits trous afin de renforcer encore la fixation. Le couvercle à également été modélisé sur OnShape :

couvercle pour la fixation de la batterie

assemblage des parties de la balle pour vérifier que tout s’emboîtait correctement.

Nous avons donc modélisé tout de qu'il nous fallait pour faire notre balle. Mais les temps d'impression étant relativement long ( environ 8h pour la partie basse et 11h pour la partie haute) nous avons voulu être absolument sûr que tout fonctionnerait une fois imprimer. Heureusement le logiciel OnShape comme beaucoup de logiciel de CAO possède un mode assemblage qui nous permet de faire des assemblages entre plusieurs pièces et d'ajouter des contraintes etde vérifier les liaisons. Ainsi nous avons pu nous apercevoir que notre modélisation fonctionnait et nous avons également réalisé quelques ajustement notamment au niveau du jeu entre la pièce mâle et la pièce femelle qui était à notre gout trop faible. de plus, nous nous sommes aperçu que l'inclinaison des embout n'était pas bonne et donc qu'il y avait un contact entre la partie haute et les embouts de la partie basse. Nous avons donc modéliser une nouvelle fois les embouts pour leur donner une orientation incurvé qui à le même rayon de courbure que la balle. Ceci évite ainsi tout tout contact inopportun. Sur la photos de gauche, on remarque que nous avons également ajouté les logos de polytech et du CAMSP. Faire un peu d'esthétique à notre balle ne peut pas faire de mal.

Les imprimantes 3D du fabricarium étant très utilisé et non disponible avant au minimum une semaine, Mr Redon nous a proposé d'imprimer les parties haute et basse de la balle pour gagner du temps. Nous avons donc créé les fichiers STL et les avons donné à Mr Redon pour l'impression.

Partie électronique/informatique

Lors de cette séance, le but était de voir le bon fonctionnement ou non de l'atmega328p ainsi que des deux contrôleurs moteur, puis de comprendre le problème du module bluetooth.

1) L'Atmega328P et les controleurs moteur

Pour cela, il est nécessaire de graver le bootloader de l'atmega328p, en réalisant le câblage suivant :

• 

  Schéma upload bootloader

Une fois câblé, j'ai programmé le second arduino en tant que programmeur ISP (via le programme fourni en exemple dans l'arduino IDE). Après avoir fait les réglages indiquant que le processeur est un atmega328p fonctionnant en 5V, j'ai pu "graver la séquence d'initialisation" (le bootloader). Ceci s'est déroulé sans souci. Après une mise hors tension, j'ai pu souder mes résistance 0ohms (des fils) assurant le lien entre MOSI/MISO et le module bluetooth. Après cela, il m'est possible de téléverser des programmes arduino via les broches série RX/TX de l'atmega328p via un autre arduino (sans son atmega328p) ou un FTDI. Dans le 1er cas, le cablage a réaliser est le suivant :

• 

  Schéma upload programme

Pour faire un test relativement simple, j'ai uploadé un programme contrôlant les 3 sorties PWM de l'atmage328p afin de voir si des leds branchées en sortie des controleurs moteur diminuaient et augmentaient bien leur intensité (les contrôleurs n'ont bien sur aucun intérêt sur des leds, leur utilité vient avec les moteurs).

 #define motor1_2    3
 #define motor3_4    5
 #define motor5_6    6
 void setup() {
 }
 void loop() {
   for (int fadeValue = 0 ; fadeValue <= 255; fadeValue += 5) {
     analogWrite(motor1_2, fadeValue);
     analogWrite(motor3_4, fadeValue);
     analogWrite(motor5_6, fadeValue);
     delay(30);
   }
   for (int fadeValue = 255 ; fadeValue >= 0; fadeValue -= 5) {
     analogWrite(motor1_2, fadeValue);
     analogWrite(motor3_4, fadeValue);
     analogWrite(motor5_6, fadeValue);
     delay(30);
   }
 }

Ce test fut un succès, j'en déduis le bon fonctionnement de l'atmega328p ainsi que des deux contrôleurs moteur.

2) Le module bluetooth

Pour le moment, je n'ai pas eu le moindre signe de vie du module bluetooth. Aucune led ne s'allume, aucun périphérique bluetooth ne le détecte, rien. N'ayant pas fait le moindre pont lors des soudures, ayant vérifié et revérifié plusieurs fois les soudures, vérifié le 3.3V, vérifié que le convertisseur 5v vers 3.3V ne chauffe pas (ce qui laisse supposer qu'il n'y a pas de surintensité consommée par le module), j'ai l'intime conviction que le problème n'est pas matériel. Lors de mes recherches sur internet, je me suis rendu compte que ce module bluetooth est en réalité un petit processure ARM programmable, assez similaire au STM32. Ceci m'a fait réaliser deux choses :

1) Ce module à lui tout seul a les capacités de remplacer l'atmega328p car il possède des sorties PWM, un ADC (en cas d'évolution vers un micro embarqué) et des entrées et sorties digitales 3.3v. Or, étant donné que nous avons déjà un programme arduino fonctionnel, que je suis complètement novice dans le développement sur ces microcontroleurs, et que le temps commence à manquer, je décide de continuer comme prévu : une liaison série entre l'atmega328p et le module BT, et l'atmega328p gérant les leds et moteurs.

2) Certains (tous?) modules bluetooth MDBT40 sont livrés vierges. Je me penche donc sur la théorie selon laquelle notre module est bien vierge. Je cherche donc un moyen de programmer le module (ce qui n'était initialement pas prévu).

2.1) Le kit de développement

nRF51 DK

La première solution était l'achat d'un kit de développement nRF51 DK, prévu pour le module nRF51 qui équipe notre module bluetooth. Cette solution pose deux problèmes :

1) Notre module bluetooth est un module à souder, non pas à enficher dans un kit de développement, il aurait donc été nécessaire de tirer des cables jusqu'au module, risquant à nouveau les ponts et autres mauvaises soudures.

2) Nous ne possédons pas le kit, une acquisition aurait engendré des frais supplémentaires ainsi qu'un délai, ce que nous ne pouvons plus nous accorder.

2.2) La Black Magic Probe

Une autre solution était l'utilisation d'un STM32, avec le firmware Black Magic Probe. Cette méthode est décrite dans l'article suivant : https://devzone.nordicsemi.com/b/blog/posts/flashing-and-debugging-nrf5152-with-a-cheap-blackm

J'ai parlé de ce souci à Mr VANTROYS, ce dernier m'a autorisé à emprunter une carte Nucleo F401RE afin de réaliser l'opération. Or, lors de mes recherches, j'ai découvert qu'il existait une méthode bien plus simple, décrite dans le point suivant.

2.3) Programmation via SWD

Nucleo F401RE

La carte Nucleo F401RE possède un module ST-LINK/V2-1 permettant de programmer des microcontroleurs en SWD. Pour ce faire, je me suis référé au manuel. Sur le schéma de droite, nous pouvons voir le Nucleo, avec entouré en bleu le programmeur ST-LINK/V2-1, et entouré en rouge le connecteur CN4 sur lequel sera branché le module bluetooth ainsi que le port CN2, contenant à l'origine deux cavaliers, leur présence redirigeant le ST-LINK/V2-1 vers le STM32 du Nucleo, leur absence laissant la possibilité au ST-LINK/V2-1 de programmer ce qui est connecté sur le connecteur CN4.

Nous pouvons donc connecter la clock et la data du module bluetooth au ST-LINK et ainsi programmer. Passons maintenant à la partie logicielle.

2.3.1) OpenOCD

Les premières informations que j'ai pu trouver sont une programmation via le logiciel OpenOCD. La première étape est de lancer openocd via la commande suivante :

  openocd -f interface/stlink-v2-1.cfg -f target/nrf51.cfg

• 

  Lancement de OpenOCD

Cet écran est le premier signe de vie que j'ai eu du module bluetooth. Une fois cette commande lancée (terminal du haut), on peut lancer des commandes via telnet : Après avoir ouvert un nouveau terminal, on lance les commandes suivantes pour flasher un HEX : telnet localhost 4444

  init
  halt
  nrf51 mass_erase
  program PROGRAM_NAME.hex
  reset
  exit

Après plusieurs essais, j'ai enfin pu faire clignoter une led pour la première fois.

Le SDK fournit également des programmes gérant le bluetooth, mais je n'ai jamais réussi à faire fonctionner quoi que ce soit en rapport avec le bluetooth via une programmation avec OpenOCD. Malgré mes recherches dans lesquelles j'ai pu découvrir qu'afin de fonctionner, le bluetooth nécessite d'avoir un "softdevice" de programmé sur les premières cases mémoires, pour le programme utilisateur à la suite, rien n'y fait, je n'arrive pas à avoir quelque chose de fonctionnel.

2.3.2) Keil

La solution aux problèmes de bluetooth viendra avec le logiciel de programmation ARM Keil. Ce logiciel me permet de modifier les sources fournies dans le SDK, de les recompiler, et enfin de les programmer. Pour ce faire, il est nécessaire de configurer le ST-LINK dans Keil :

1) Dans les Options for target, onglet debug, sélectionner le ST-Link et cliquer sur Settings.

2) Sélectionner le ST-Link dans Debug Adapter.

3) Sésectionner le Port SW dans Target Com afin d'obtenir les bonnes fréquences.

4) Onglet Flash Download sélectionner le nRF51 afin d'obtenir les bonnes adresses mémoires.

• 

  Etape 1

• 

  Etapes 2 et 3

• 

  Etape 4

En cas de problème de compilation (certains fichiers non trouvés), il peut être nécessaire d'aller dans les options du target, onglet C/C++ et d'ajouter le path suivant :

  C:\Keil_v5\ARM\PACK\ARM\CMSIS\5.3.0\CMSIS\Include

Une fois keil configuré, j'ai pu compiler et téléverser l'exemple de programme UART bluetooth fourni dans le SDK, mais toujours pas de bluetooth. En revanche, l'exemple blinky (clignotement d'une led) fonctionnait bien aussi avec keil. Après de longues heures de recherche, j'ai finalement trouvé la solution sur un forum : le problème venait de l'horloge. En effet, j'avais lu (et vu sur le module d'Adafruit) que le nRF51 pouvait fonctionner correctement sans horloge externe. L'horloge interne avait donc été configurée, les réglages étaient bons, pour preuve le programme blinky faisait clignoter la led à la bonne fréquence.

En revanche, le softdevice, responsable de la communication bluetooth se devait d'être configuré aussi. En conséquences, dans la fonction ble_stack_init, les lignes suivantes devaient être présentes :

 nrf_clock_lf_cfg_t clock_lf_cfg;
 clock_lf_cfg.source = NRF_CLOCK_LF_SRC_RC;
 clock_lf_cfg.rc_ctiv = 16;
 clock_lf_cfg.rc_temp_ctiv = 2;
 clock_lf_cfg.xtal_accuracy = 0;
 
 // Initialize SoftDevice.
 SOFTDEVICE_HANDLER_APPSH_INIT(&clock_lf_cfg, true);

C'est seulement après cette correction que j'ai pu voir pour la première fois le module bluetooth depuis un appareil mobile.

Semaine 12

Partie création de la balle

Nous avons récupéré le vendredi l’impression 3D des parties hautes et basse de la balle vibrante. il y avait énormément de support sur la partie haute. cela était du au fait que le seul moyen d'imprimer la balle était de le faire avec la demi sphère tournée vers le haut. Il nous a fallu environ deux heures simplement pour enlever les supports. Nous avons en effet voulu prendre beaucoup de précaution afin d'être sur de ne pas endommager les parties de la balle. Surtout qu'il y avait des support au niveau des attaches et nous ne voulions surtout pas endommager l'un d'eux. Le fait de doubler l'épaisseur a considérablement augmenter leur résistance. En revanche, une chose assez étrange s'est produite. une des trois attaches s'est cassé des que nous l'avons touché, alors que les deux autres était bien plus résistant. Nous en avons déduit que cela devait provenir d'une erreur ou d'une fragilité lors de l'impression et avons donc décidé de le recoller plutôt que de revoir le design des attaches. La colle utilisé était très puissante mais nécessitait environ 100 heures de séchage. Nous devrons donc attendre la semaine prochaine pour pouvoir assembler les différentes parties de la balle.

Partie application

Nous avons passé la semaine à corrigé les bugs que nous pouvions trouver sur l'application et qui étaient plutôt nombreux. Il reste encore de nombreux bugs à régler, mais mis à part cela et le suivi des patients, tout ce que nous voulions faire sur l'application est opérationnel. Nous rappelons que nous n'avons eu aucune nouvelle du CAMSP malgré les mails de monsieur BOE, et que suite à ses directives nous n'avons pas pu programmé le mode suivi des patients de l'application car nous n'avions pas de données assez précise sur ce qu'il fallait faire.

Semaine 13

Partie création de la balle

La semaine dernière, L'impression s'est terminée et tout s'est passé comme prévu. la partie basse s'est imprimé avec les modifications que nous lui avions apporté et la partie haute n'as eu aucun souci d'impression. Nous avions un peu peur que les supports gênent ou que la balle ne s'imprime pas correctement mais il n'y a pas eu de souci. Une fois que l'attache a été recollé nous avons vu que cela tenait comme il faut. Nous avons donc enfin pu tester d'assembler les deux parties de la balle ainsi que de fixer les différentes pièces allant dans la balle :

1/ fixation de la batterie :

La batterie rentrait pile dans l'emplacement prévu à cet effet, le trou prévu pour faire passer les fils avaient la bonne dimension. Les choses se sont un peu corsés lorsque nous avons mis le couvercle de fixation. Les 4 ergos que nous avions prévu avaient un diamètre bien trop petit (3mm) et se sont cassé dès que nous avons tenté de les insérer dans les trous. Heureusement le couvercle se tenait même sans les ergos. Nous n'avons donc pas du faire de changement pour la partie fixation de la batterie et avons validé cette partie.

2/ fixation de la bobine à induction

Dans la première impression de la partie basse, nous avions mis une épaisseur de 5 mm en pensant que ce serait assez fin. Néanmoins, nous avions tord et la recharge fonctionnait mais par interruption. chaque petit mouvement stoppait la recharge. Nous avons donc décidé dans le deuxième modèle de réduire l'épaisseur à 3mm. Faire plus fin aurait été dangereux pour la solidité de l'ensemble nous espérions donc vraiment que la recharge fonctionnerait sans soucis sinon nous aurions eu à faire face à un sérieux problème. Heureusement pour nous, la recharge a été un succès. concernant la fixation de la bobine, nous avons simplement fixé du scotche pour bien appuyer la bobine au PLA. Nous pouvons donc valider la partie fixation de la bobine à induction.

3/ Fixation des 6 vibreurs

Les 6 vibreurs ont été très facile à poser. Il a suffit de les mettre dans les emplacements prévu à ces effets. il y avait déjà du double face intégré au vibreurs. Nous avons été assez content car nous avons passé un temps non négligeable à modéliser les trous pour les vibreurs. Mais en définitive, nous avons rattrapé partiellement ce temps dans la pose des vibreurs. Nous pouvons donc valider la partie fixation des vibreurs.

4/ Fixation de la carte électronique

pièce de fixation du PCB avec les embouts cassés

Pour rappel, la carte électronique devait être prise en étaux entre les deux rebords de la partie basse et les deux parties de fixation. Nous avons confronté au même problème qu'avec le couvercle de la batterie. Les embouts des parties supérieurs n'avaient un diamètre que de 5mm. Il était donc encore trop fragile et se sont cassé après quelques aller retour dans les trous. Nous étions donc face à un problème assez important car la fixation de la carte électronique est extrêmement important et nous ne pouvions pas imprimer de nouvelle pièce avec un diamètre plus important car nous n'avions pas la place. Il a donc fallu improviser et utiliser si nous pouvons nous permettre l'expression la méthode "système D". nous avons donc retiré complètement les embouts (pas de demi-mesure) et avons fait un trou eu milieu de la pièce. Nous avons ensuite fixé la pièce à la partie basse en insérant des vices. Ce système est peut-être rudimentaire et pas très élégant mais il a l’avantage de fonctionner. Toutefois pour ne pas abîmer le pseudo pas de vis, il ne faudra pas monter-démonter trop de fois cet ensemble. nous pouvons quand même valider la fixation de la carte électronique.

5/ Fixation de la partie haute avec la partie basse

C'est sans doute la partie qui nous a le plus stressé. En effet, cette fixation est la plus importante de la balle et nous avons utilisé un système de fixation nécessitant une modélisation assez compliqué. Pour pouvoir vérifier que tout fonctionnait correctement il a fallu encore enlever des supports qui se trouvait dans les renfoncements. Çà à été assez compliqué à enlever. Nous avons enfin pu tester. Et la fixation fut un succès ! Une petite vidéos vaux parfois mieux qu'un long discours alors vous trouverez une vidéo du montage des peux parties à l'ardresse suivante : https://www.youtube.com/watch?v=eKNJTRcCt5s

Semaine 14

Documents Rendus