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.

• 

  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 pour pouvoir échanger des données entre activités. 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éo 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 n'ont donc pour l'instant qu'une portée démonstrative.

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. Pour le debbugage et le compréhension de ce que nous faisons, nous avons fait afficher tous les périhpérique bluetooth que repère l'pplication avant de détecter celui d'adafruit. 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 ! 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.

Nous avons passé le reste de la semaine à tenté d'envoyer des données de l'application vers le smartphone, mais sans succès. Cela semble provenir du fait que nous ne paramétrons pas comme il faut la connexion après l'avoir établie.

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. Nous 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 électriques 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 meilleure résistance aux chocs.

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 bougent 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 ces 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 derniers vibreurs.

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

Vue de côté

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 pris cette décision pour que la balle puisse être rechargée par induction. En effet, la bobine à induction doit obligatoirement être posée 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ée au fond de la balle et sera fixée 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 indiquaient que la portée d'une recharge par induction QI était de 4cm. Une fois le matériel reçu nous avons fait nos propres tests pour vérifier la portée. 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 renfoncements pour pouvoir placer les vibreurs, de cette façon, nous pourrons les placer exactement à égale distance et nous aurons également une meilleure 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 rebords, et deux plaques viendront par dessus le PCB. Celles-ci seront munies de tétons qui viendront s'enficher dans les trous prévus à cet effet. Ainsi la carte sera prise en tenaille et ne pourra plus bouger. Nous avons modélisé 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

Nous avons continué à travaillé sur l'envoi des données de l'application vers la balle. Après beaucoup de recherches nous avons trouvé la bonne façon de paramétrer la connexion. 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. nous sélectionnions le mode de fonctionnement souhaité (rx, tx) puis il fallait envoyer ce paramétrage à la balle. Après pas mal de tests et de lignes de code, nous avons enfin pu envoyer des données et faire vibrer nos moteurs via bluetooth ! Vous pourrez retrouver toutes ces méthodes dans le code source de l'application qui se trouve dans les documents rendus.

schéma résumant le fonctionnement du Bluetooth dans l'application

Partie création de la balle

Photographie de notre premier prototype imprimé de la balle. On remarque bien le clips qui a cédé.

Côté 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 avaient changé et nous n'avions pas pensé à prendre cela en compte. Les rebords étaient donc placés trop bas et la carte électronique ne pouvait plus être fixée.
• Les clips qui devaient servir à assembler la partie basse et la partie haute n'étaient pas du tout assez flexibles, de plus ils étaient bien trop petits et fragiles. En conséquence, ce qui devait arriver arriva et un des clips s'est cassé lors d'une manipulation.

Cela nous a fait comprendre que réaliser la fixation des deux parties de la balle grâce à des clips é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 bonnes dimensions. 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 là-dessus. Nous avons donc décidé de changer le système de fixation.

Photographie de notre premier prototype imprimé de balle. On remarque bien le clips qui a cedé.

Nous n'utiliserons plus de clips mais des attaches qui viendront se loger dans des renfoncements qui se trouveront dans la partie supérieure de la balle. Le renfoncement se rétrécira afin que l'attache finisse par se bloquer. Pour faire cela nous sommes restés sur le design général du clips mais avons changé quelque peu son ergonomie afin qu'il puisse répondre aux nouvelles contraintes 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 viennent s’emboîter dans les alcôves de la partie haute. Il y aura pour la balle 3 fois ce système d’accroches des deux parties de la balle.

Nous avons donc modélisé ces changements sur la partie basse puis nous sommes occupés de la partie haute que nous n'avions pas encore commencée. 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 rappel 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 a é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 longs ( environ 8h pour la partie basse et 11h pour la partie haute) nous avons voulu être absolument sûrs que tout fonctionnerait une fois imprimé. Heureusement le logiciel OnShape comme beaucoup de logiciels de CAO possède un mode assemblage qui nous permet de faire des assemblages entre plusieurs pièces et d'ajouter des contraintes et de vérifier les liaisons. Ainsi nous avons pu nous apercevoir que notre modélisation fonctionnait et nous avons également réalisé quelques ajustements notamment au niveau du jeu entre la pièce mâle et la pièce femelle qui était à notre goût trop faible. De plus, nous nous sommes aperçus que l'inclinaison des embouts 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élisé une nouvelle fois les embouts pour leur donner une orientation incurvée qui a le même rayon de courbure que la balle. Ceci évite ainsi tout contact inopportun. Sur la photo de gauche, on remarque que nous avons également ajouté les logos de polytech et du CAMSP. Ajouter un peu d'esthétique à notre balle ne peut pas faire de mal.

Les imprimantes 3D du fabricarium étant très utilisées et non disponibles avant au minimum une semaine, Mr REDON nous a proposé d'imprimer les parties hautes et basses de la balle pour gagner du temps. Nous avons donc créé les fichiers STL et les avons donnés à 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 contrôleurs 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ésistances 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 contrôleurs moteur diminuaient et augmentaient bien leur intensité (les contrôleurs n'ont bien sûr 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 processeur 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 câbles 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.

Après avoir soudé des fils sur les ports de data et clock du module bluetooth, nous pouvons le connecter la clock et la data du 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 recherches, 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équence, 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

Mise à jour du code Arduino

Lors de nos premiers essais, nous avons pu nous rendre compte qu'il y avait un problème de délai avec nos commandes. En effet, jusqu'à maintemant, comme nous avons toujours voulu laissée la possibilité de contrôler chaque paire de moteurs individuellement, les commandes à envoyer étaient aXXX, bXXX et cXXX avec XXX une valeur comprise entre 0 et 255. Le problème étant qu'à un instant t nous devons contrôler les trois moteurs en même temps, or jusque là nous devons envoyer trois commandes distinctes, ce qui implique qu'entre l'envoi de la première commande et le traitement de la dernière s'est écoulé un temps non négligeable.

J'ai donc décidé d'optimiser ce temps en réduisant les trois commandes en une seule : aXXX, bXXX et cXXX devient aXXXbXXXcXXX en un seul message. Le fait de garder les lettres b et c est un choix. Grâce à ça, il est possible d'envoyer le message a85b74c96 par exemple sans avoir à rajouter les 0.

Enfin, afin d'avoir sur la balle une LED témoin de la vibration, je définis une variable LED sur le pin D2 qui s'allume au-delà d'une valeur minimale (valeur en dessous de laquelle les moteurs n'ont pas assez d'énergie pour se mettre en rotation du à leur inertie).

 #include <SoftwareSerial.h>
 #define LED         2
 #define motor1_2    3
 #define motor3_4    5
 #define motor5_6    6
 #define RXD_PIN     9    // Required for software serial!
 #define TXD_PIN     10   // Required for software serial!
 #define MIN         50
 SoftwareSerial mySerial(TXD_PIN, RXD_PIN);
 void setup()  
   {
   // Open serial communications and wait for port to open:
   Serial.begin(115200);
   pinMode(LED, OUTPUT);
   pinMode(motor1_2, OUTPUT);
   pinMode(motor3_4, OUTPUT);
   pinMode(motor5_6, OUTPUT);
   // set the data rate for the SoftwareSerial port
   mySerial.begin(115200);
 }
 void loop() // run over and over
 {
   int c=0, data=0, start=0, data_available=0, data1=0, data2=0, data3=0;
    while(1) {
    //acquisition de la data
    if ( mySerial.available() ) {
      c = mySerial.read();
      //bit de start
      if (c==97) {
        start=1;
        data=0;
      }
      //fin de la 1ere valeur, début de la 2eme
      else if (c==98 && start==1) {
        data1=data;
        data=0;
      }
      //fin de la 2eme valeur, début de la 3eme
      else if (c==99 && start==1) {
        data2=data;
        data=0;
      }
      //bits de data
      else if (c<=57 && c>=48 && start==1) {
        data=data*10+(c-48);
      }
      //bits de stop
      else if ((c==13 && start==1) || (c==10 && start==1) || (c==122 && start==1)) {
        data3=data;
        data=0;
        data_available=1;
        start=0;
      }
    }
    //écriture de la data sur la sortie PWM
    if (data_available==1) {
      analogWrite(motor1_2, data1);
      analogWrite(motor3_4, data2);
      analogWrite(motor5_6, data3);
      Serial.print("a=");
      Serial.println(data1);
      Serial.print("b=");
      Serial.println(data2);
      Serial.print("c=");
      Serial.println(data3);
      data_available=0;
      if (data1 > MIN || data2 > MIN || data3 > MIN) {
       digitalWrite(LED, HIGH);
       Serial.println("LED HIGH");
      }
      else {
       digitalWrite(LED, LOW);
       Serial.println("LED LOW");
      }
    } 
  }
 }

Partie création de la balle

Nous avons récupéré le vendredi l’impression 3D des parties hautes et basses de la balle vibrante. Il y avait énormément de supports sur la partie haute. Cela était dû 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écautions afin d'être sûrs de ne pas endommager les parties de la balle. Surtout qu'il y avait des supports au niveau des attaches et nous ne voulions surtout pas endommager l'un d'eux. Le fait de doubler l'épaisseur a considérablement augmenté leur résistance. En revanche, une chose assez étrange s'est produite. Une des trois attaches s'est cassée dès que nous l'avons touchée, alors que les deux autres étaient bien plus résistantes. 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 la recoller plutôt que de revoir le design des attaches. La colle utilisée é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 a corriger les bugs que nous pouvions trouver sur l'application et qui étaient plutôt nombreux. Il en reste encore à 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 Mr BOE, et que suite à ses directives nous n'avons pas pu programmer le mode suivi des patients de l'application car nous n'avions pas de données assez précises sur ce qu'il fallait faire.

Le bug d'Android 7

Le développement de l'application s'est fait sur un téléphone tournant sous Android 5.1 Lollipop (API 22) et à cette étape du projet l'application se connectait bien à la balle sans problème et restait connectée sans problème. Or, pour la suite du développement, nous nous sommes alliés afin d'avancer le développement et donc un nouveau téléphone a été utilisé pour le développement. Ce second téléphone tournait sous Android 7.1 Nougat (API 25), l'application se lançait correctement, se connectait, envoyait bien les messages en bluetooth, en revanche la connexion se coupait au bout de 30 secondes. J'ai alors pensé à une incompatibilité avec mon téléphone, un troisième téléphone est alors rentré en jeu : un Moto E sous Android 6.0.1 Marshmallow (API 23) : pas de déconnexion. J'en conclus donc qu'il n'y a pas de problème de compatibilité avec le Moto E. Après cela, j'ai installé Android 7.1 sur le Moto E : les déconnexions étaient de retour. Plus tard, J'ai pu essayer avec un Galaxy S7 Android 7.0 (API 24) : les déconnexions étaient bien là.

Conclusion : problème à partie de l'API 24. J'ai donc passé beaucoup de temps à chercher d'ou venait le souci depuis les logs :

 04-06 22:58:10.539 14713-14746/? W/bt_att: gatt_indication_confirmation_timeout disconnecting...
 04-06 22:58:10.540 14713-14746/? W/bt_btif: bta_gattc_conn_cback() - cif=3 connected=0 conn_id=3 reason=0x0016
 04-06 22:58:10.540 14713-14746/? W/bt_btif: bta_gattc_conn_cback() - cif=4 connected=0 conn_id=4 reason=0x0016
 04-06 22:58:10.541 14713-14746/? W/bt_btif: bta_gattc_conn_cback() - cif=5 connected=0 conn_id=5 reason=0x0016
 04-06 22:58:10.541 14713-14746/? W/bt_btif: bta_gattc_conn_cback() - cif=7 connected=0 conn_id=7 reason=0x0016
 04-06 22:58:10.543 23537-23550/com.camsp.thomas.myapplication D/BluetoothGattServer: onServerConnectionState() - status=0 serverIf=6 device=EC:72:B4:D7:7C:B0
 04-06 22:58:10.546 23537-23549/com.camsp.thomas.myapplication D/BluetoothGatt: onClientConnectionState() - status=22 clientIf=7 device=EC:72:B4:D7:7C:B0
 [ 04-06 22:58:10.546 23537:23549 D/         ]
 Disconnected from GATT server.

On a donc un souci de confirmation non renvoyée.

J'ai après regardé du coté du module bluetooth quelle était la raison de la déconnexion, malheureusement le code de déconnexion était le même que celui d'une déconnexion normale demandée par l'utilisateur. Pas d'erreur donc coté module bluetooth.

Après beaucoup d'heures d'essais, de recherches et de comparatif entre les logs d'un téléphone API<24 et API>=24, j'ai pu trouver une solution permettant de rendre l'application fonctionnelle :

 public void starteScan() {
   mBluetoothManager = (BluetoothManager) getSystemService(BLUETOOTH_SERVICE);
   mBluetoothAdapter = mBluetoothManager.getAdapter();
   GattServerCallback gattServerCallback = new GattServerCallback();
   mGattServer = mBluetoothManager.openGattServer(this, gattServerCallback);
   setupServer();
   List<ScanFilter> filters = new ArrayList<>();
   ScanFilter scanFilter = new ScanFilter.Builder()
 }

L'ajout du setupserver dans cette fonction permet d'envoyer la confirmation manquante et règle le problème. Je suis bien conscient que cette solution n'est pas propre et que même si le problème n'est plus apparent, il est toujours présent, et une vraie solution doit être trouvée. Malheureusement j'ai passé une semaine sur ce souci, et il est temps d'avancer.

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ée avec les modifications que nous lui avions apporté et la partie haute n'a 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ée 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 avait la bonne dimension. Les choses se sont un peu corsées 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és 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 dû 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 faciles à poser. Il a suffit de les mettre dans les emplacements prévus à ces effets. Il y avait déjà du double face intégré aux vibreurs. Nous avons été assez contents 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 été confrontés au même problème qu'avec le couvercle de la batterie. Les embouts des parties supérieures n'avaient un diamètre que de 5mm. Ils étaient donc encore trop fragiles et se sont cassés 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 importante 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 au milieu de la pièce. Nous avons ensuite fixé la pièce à la partie basse en insérant des vis. 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ée. Pour pouvoir vérifier que tout fonctionnait correctement il a fallu encore enlever des supports qui se trouvaient dans les renfoncements. Cela a été assez compliqué à enlever. Nous avons enfin pu tester. Et la fixation fut un succès ! Une petite vidéo vaut parfois mieux qu'un long discours alors vous trouverez des images du montage des peux parties à l'ardresse suivante : https://www.youtube.com/watch?v=eKNJTRcCt5s

Semaine 14

Lors de cette dernière semaine, nous avons pu apporter les toutes dernières modifications autant au code de l'application Android, qu'à celui du module bluetooth. Enfin, nous avons pu passer à l'assemblage de la balle, soudure des moteurs, des leds, etc.

1) Réparation du bloc boost converter

Pendant notre travail sur le PCB, nous avons eu un souci avec le boost converter (qui était en fonctionnement). Lors du déplacement de la carte, un doigt a touché le TPS61090, et la carte s'est directement arrêtée de fonctionner. Des mesures ont montré que ce dernier ne délivrait plus que plus ou moins 3V, et qu'il chauffait énormément, ainsi que la bobine juste à côté. J'en ai déduit que, comme je n'étais pas relié à la terre à ce moment-là, une décharge d'électricité statique avait endommagé le composant. Heureusement, nous avions un TPS61090 d'avance, de ce fait avec l'aide de Mr FLAMEN nous avons pu désouder le module défectueux à l'air chaud, afin de souder le nouveau. Une fois fait, tout était rentré dans l'ordre.

• 

  Footprint après avoir dé-soudé le composant

2) Mise à jour du code MDBT40

Le code du module bluetooth nécessitait un peu de nettoyage. En effet, pour résoudre le bug d'Android 7, beaucoup de printf ont été ajoutés afin d'être visibles sur la broche TX du module, le souci étant que cette même broche envoie les commandes de vibration venant du périphérique Android. Ces messages étaient donc une potentielle source de problèmes, inutile dans le cas d'un produit fonctionnel.

Enfin, le CDCH préconise une led en façade attestant de la bonne connexion bluetooth. Jusque-là le programme fonctionnait avec une led clignotante en cas de non connexion et éteinte le cas échéant. J'ai donc déclaré une nouvelle led LED_EXT sur le gpio 18 (déjà broché sur le PCB à un header) :

Ceci se fait dans le fichier pca10028.h :

 #define LED_EXT        19
 #define LEDS_LIST { LED_1, LED_2, LED_3, LED_4, LED_EXT }
 #define LEDS_NUMBER    5

Je me suis ensuite servi des événements dans le main.c lors de la connexion et déconnexion pour changer l'état de ma led :

 case BLE_GAP_EVT_CONNECTED:
   IS_CONNECTED = 1;
   bsp_board_led_off(4);
   err_code = bsp_indication_set(BSP_INDICATE_CONNECTED);
   APP_ERROR_CHECK(err_code);
   m_conn_handle = p_ble_evt->evt.gap_evt.conn_handle;
   break; // BLE_GAP_EVT_CONNECTED

 case BLE_GAP_EVT_DISCONNECTED:
   IS_CONNECTED = 0;
   bsp_board_led_on(4);
   err_code = bsp_indication_set(BSP_INDICATE_IDLE);
   APP_ERROR_CHECK(err_code);
   m_conn_handle = BLE_CONN_HANDLE_INVALID;
   break; // BLE_GAP_EVT_DISCONNECTED

Remarques : 1) bsp_board_led_on(4); éteint la led et bsp_board_led_ff(4); l'allume. 2) L'indice 4 représente la position du GPIO à contrôler dans LEDS_LIST.

3) Mise à jour de l'application

i) Débuggage de l'application

Nous avons repris l'application et avons continué à corriger des bugs qui persistaient. Par exemple l'échange de la valeur du coefficient de vibration de l'activité réglage vibration vers l’activité principale ne fonctionnait pas de manière optimale. Il fallait effectuer le réglage de la vibration avant d'avoir connectée la balle et une fois celle-ci connectée, nous ne pouvions plus changer le coefficient de vibration (un bug fermait l'application lorsque nous essayions). Nous avons encore travaillé sur la compréhension des intents, de la méthode startActivity (métohde qui sert à ouvrir une application) et de comment s'affichaient les images les unes par rapport aux autres. Après plusieurs recherches, nous avons compris notre erreur :

Les activités sont organisées en système de pile. Lorsque l'utilisateur navigue dans une activité (appelée A), celle-ci se trouve au dessus de la pile. Avec la méthode startActivity, nous pouvons appeler une autre activité qui viendra se placer au-dessus de la pile et c'est celle-ci qui sera affichée. Par exemple startActivity(B) placera l'activité B en haut de la pile, et c'est celle-ci qui sera affichée à l'utilisateur. Pour revenir à l'activité A, il suffit de fermer l'activité B via la méthode finish, celle-ci se retirera de la pile, et ce sera l'activité A qui se retrouvera en haut de la pile et donc qui sera affichée.

Or, quand nous avons créé la liaison entre les deux activités, nous n'avions pas compris ce mode de fonctionnement, nous pensions que pour retourner dans l'activité A il ne fallait pas appeler la méthode finish mais la méthode startActivity(A). Donc plutôt que de retirer l’activité B de la pile, nous avons créé une nouvelle activité A' qui se plaçait au-dessus de la pile. Plutôt qu'une activité qui était présente sur la pile, nous en avions 3. Ce qui implique que 3 activités lançaient leurs méthodes au lieu d'une. Cela était également à l'origine de nombreux autres bugs dont nous n'avions jusque-là pas trouvé la cause. Nous l'avons donc résolu très simplement en appelant la méthode finish plutôt que la méthode startActivity. Bien que la solution de ce problème semble assez évidente, nous avons mis beaucoup de temps avant de comprendre le fonctionnement de tout ce qui est énoncé plus haut.

ii) Optimisation du traitement du son

Nous avons également changé la formule qui permettait en fonction de l'intensité sonore et du niveau de vibration choisi par l'utilisateur d'obtenir une valeur comprise entre 0 et 255 qui serait envoyé par bluetooth à la balle (0 signifie pas de vibration et 255 vibration maximale). Jusque maintenant le niveau de vibration choisi par l'utilisateur n'était qu'un coefficient ajouté à la formule. Ce que signifiait que même avec un coefficient très faible, si l'intensité sonore était suffisamment importante, une vibration maximale pouvait être atteinte. Mais nous n'arrivions pas à régler correctement cette vibration : bien souvent, la balle vibrait à son maximum, et il n'était pas possible de garder une vibration d'intensité modéré pendant un long moment, en effet l'intensité sonore n'est jamais exactement la même.

Nous avons donc totalement changé la formule. Maintenant, lorsque le coefficient de vibration change le niveau maximale de vibration que peut atteindre la balle. Après plusieurs teste, nous nous sommes aperçu que nous obtenions un niveau de vibration qui était beaucoup plus table et que la balle était maintenant beaucoup plus simple d'utilisation. Nous avons donc dévidé de garder cette formule.

Voici les courbes des deux formules :

nouvelle formule

Ancienne formule

chaque courbe correspond à un certain coefficient de vibration choisi par l'utilisateur. On a en abscisse l'intensité sonore recueilli et en ordonnée la valeur comprise entre 0 et 255 envoyé à la balle.

4) Montage de la balle

La balle a été conçue afin de garantir une facilité de démontage/remontage dans le but de faciliter le développement futur de la balle. Pour ce faire, nous avons fait le choix de conserver sur la carte les headers et de souder sur tous les périphériques des connecteurs Dupont femelle. De plus, certains fils soudés sur la carte n'ont pas été coupés, c'est le cas :

• Des fils sur les broches D11 et D12 de l'arduino (afin de pouvoir le programmer avec un Arduino en ISP)

• Des fils sur les GPIO configurés en RX et TX du module bluetooth (afin de pouvoir visualiser les communications entre le module bluetooth et l'arduino)

• Des fils sur les broches data et clock du module bluetooth (afin de pouvoir programmer le module en SWD)

Dans une future version du PCB, ces fils devraient être remplacés par des headers.

Nous avons donc soudé sur les connecteurs Dupont les 3 leds, les 6 moteurs, l'interrupteur (directement sur la masse de la batterie), le + de la batterie, et la bobine de recharge sans fil.

Comme on peut le voir sur les photos ci dessus, les câbles connectés à un moteur ont été rassemblés avec une gaine thermorétractable, dans un souci de clarté lors des branchements. Idem pour les câbles connectés aux leds et à la batterie. De plus, leur longueur est suffisamment longue pour pouvoir poser les deux demi sphères sur une table sans rien débrancher, mais également assez courte pour ne pas venir se prendre dans les fixations lors de la fermeture.

Documents rendus

Code de l'Atmega328P : Media:328p Program.zip

Code du nRF51 : Media:NRF51 Program.zip

Sources Altium du PCB : Media:Altuim PCB.zip

Modélisation de la partie haute, de la partie basse et des composants de fixation: Media:STLballe.zip

Remarque : notre code source contenant des fichiers java.class, nous n'avons pas pu l'uploader sur les serveurs du wiki.

Code source de l'application : https://drive.google.com/file/d/1x1Mov-sWI5KlrLY7X2OTeVtmIZ0gc3yd/view?usp=sharing

Git du projet : https://archives.plil.fr/tcattela/CAMSP

Rapport de projet : Media:Rapport p15.pdf

Cahier des charges : Media:Cahier des charges p15.pdf