IMA4 2016/2017 P14 : Différence entre versions
(→Module bluetooth utilisé) |
(→PCB du pénis) |
||
Ligne 354 : | Ligne 354 : | ||
Le premier PCB imprimé et soudé est celui du pénis. Une première carte avait été imprimé regroupant sur cette dernière : un support pour l'arduino, un accéléromètre, un module bluetooth. | Le premier PCB imprimé et soudé est celui du pénis. Une première carte avait été imprimé regroupant sur cette dernière : un support pour l'arduino, un accéléromètre, un module bluetooth. | ||
− | + | [[Fichier:PCB_penis_VB.png|400px|thumb|center|PCB v1.0]] | |
+ | |||
Nous avons expérimentés des problèmes dûs aux dimensions de l'accéléromètre, l'utilisation d'un boîtier CMS de type TDFN10 2x2 était optimiste pour la réalisation du projet, compte tenu du matériel à disposition. | Nous avons expérimentés des problèmes dûs aux dimensions de l'accéléromètre, l'utilisation d'un boîtier CMS de type TDFN10 2x2 était optimiste pour la réalisation du projet, compte tenu du matériel à disposition. | ||
Ligne 360 : | Ligne 361 : | ||
C'est pourquoi une seconde carte a été gravée, cette fois sans l'accéléromètre. | C'est pourquoi une seconde carte a été gravée, cette fois sans l'accéléromètre. | ||
− | + | [[Fichier:PCB_penis_VF.png|400px|thumb|left|PCB v2.0]] [[Fichier:PCB_VF.png|400px|thumb|right|PCB v2.0 schema]] | |
Ce prototype est sensé embarquer un capteur de température que nous avons décidé de mettre sur un PCB à part. Cette carte avait pour but d'être coulé dans le silicone, afin de mesurer la température au plus près de la zone intéressée. | Ce prototype est sensé embarquer un capteur de température que nous avons décidé de mettre sur un PCB à part. Cette carte avait pour but d'être coulé dans le silicone, afin de mesurer la température au plus près de la zone intéressée. | ||
− | + | ||
+ | [[Fichier:TEMPERATURE_PCB_VF.png|400px|thumb|left|PCB temperature]] [[Fichier:TEMPERATURE_VF.png|400px|thumb|right|PCB temperature schema]] | ||
====PCB du vagin==== | ====PCB du vagin==== |
Version du 9 mai 2017 à 16:21
Sommaire
Projet IMA4 : Sex-toy connecté
Présentation du projet
L'objectif de ce projet est de développer un système d'échange entre deux partenaires distants afin de rendre plus facile la vie de couple à distance.
Pour ce faire, le dispositif sera constitué de deux sextoys connectés (un par appareil génital désiré) à leur téléphone portable respectif. Une application mobile permettra aux utilisateurs de s'échanger des données de manière sécurisé, ceci au travers d'un serveur embarqué dans le téléphone portable.
Les données échangées pourront être l'accélération ou la température. Elles seront traitées et transmises au sextoy qui adaptera sa vitesse, son retour vibratoire ou sa position en conséquence.
Les sextoys pourraient être composés de :
- Pour l'appareil masculin (dédié à la femme) :
- un servomoteur ;
- un vibreur ;
- une sonde de température ;
- un accéléromètre.
- Pour l'appareil féminin (dédié à l'homme) :
- 4 servomoteurs (dans le but de "masser" en déplaçant le silicone);
- des vibreurs ;
- un accéléromètre.
- Pour les deux appareils :
- un micro-contrôleur (Arduino mini) ;
- un module de transmission / réception bluetooth afin de se connecter au téléphone ;
- du silicone.
- L'application mobile devra :
- mettre en place une communication cryptée à travers un serveur (embarqué ou bien intermédiaire ?) ;
- effectuer un échange de données en bluetooth avec le sextoy connecté.
- L'application mobile pourra :
- utiliser la vidéo-conférence ;
- enregistrer les meilleurs moments et enventuellement pouvoir les partager ;
- effectuer une recherche de partenaire aléatoire.
- S'il nous reste du temps, il peut être envisageable de :
- mettre en place un réseau social interne à Polytech.
Liste des tâches
- Conception de l'appareil masculin (Cédric)
- mettre en place le bus I2C avec les différents capteurs ;
- création d'un PCB au format gerber ;
- création d'un prototype.
- Conception de l'appareil féminin (Cédric)
- mettre en place le bus I2C ;
- traitement des données afin d'en déduire la position et l'entrain de l'utilisateur ;
- création d'un PCB ;
- création d'un prototype.
- Communication bluetooth (Cédric)
- étudier l'émission/réception vue de l'arduino ;
- étudier l'émission/réception vue du téléphone ;
- mise en place du protocole ;
- test de portée.
- Développement mobile (Thomas)
- déterminer la meilleure approche : utilisation d'un serveur intermédiaire ou bien mise en place d'un "client-serveur" dans l'application mobile ;
- mettre en place le choix retenu ;
- tester dans un premier temps une transmission de texte ;
- programmer le traitement de données reçues par bluetooth ;
- rajouter un côté esthétique à l'application.
Feuille d'heures
Tâche | Prélude | Heures S1 | Heures S2 | Heures S3 | Heures S4 | Heures vacances | Heures S5 | Heures S6 | Heures S7 | Heures S8 | Heures S9 | Heures S10 | Heures vacances | Total |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Définition cahier des charges | 2H | 2H | 1H | |||||||||||
Dimensionnement et établissement de la liste de matériel | 3H | 4H | 4H | |||||||||||
Établissement de la liste et de la répartition des tâches | 1H | |||||||||||||
Appareil masculin : programmation | 1H | 2H | ||||||||||||
Appareil masculin : étude des datasheets | 1H | 1H | 4H | 1H | ||||||||||
Appareil masculin : PCB | 4H | 4H | 6H | 10H | ||||||||||
Appareil masculin : 3D | ||||||||||||||
Conception de l'appareil féminin | 2H | 1H | ||||||||||||
Liaison bluetooth (embarqué) | 3H | 1H | ||||||||||||
Liaison bluetooth (téléphone) | ||||||||||||||
Recherche et discussion autour de la meilleure approche de communication | 2H | 2H | ||||||||||||
Synchronisation temporelle des téléphones (par sms) | 2H | 4H | 4H | 4H | 4H | |||||||||
Transmission de paquets UDP | 4H | 4H | 4H | |||||||||||
Streaming video(UDP) | 4H | 4H | ||||||||||||
Application et bases de données | 4H | 4H |
Conception des sextoys
Introduction
Choix du silicone, rencontre avec Mario Sanz
Le projet nécessite l'utilisation d'une matière souple et non irritante, c'est pourquoi nous avons choisi de nous tourner vers l'utilisation du silicone. Afin de choisir au mieux le produit correspondant à nos besoins, nous avons rencontré Mario Sanz, ingénieur à l'INRIA, qui travail régulièrement avec du silicone.
Ce dernier nous a expliqué les différents points importants sur lesquels nous baser afin de choisir au mieux un produit en accord avec le projet. Ne serait-ce que pour le choix de la dureté, il existe une échelle propre au silicone ("Shore hardness scale"), nous pensions au départ rechercher un silicone le plus mou possible, cependant, il faut savoir que le plus le silicone est mou, plus il a tendance à être "collant". Finalement, après discutions, un shore de 40A (correspondant à la dureté d'une gomme) suffisamment mince fera l'affaire pour la conception des prototypes.
Il nous a également expliqué que le silicone peut être travaillé à l'aide d'additifs et sous cloche à vide afin d'améliorer le moulage, l'absence de "bulles" sur la surface de la pièce et la souplesse. Nous pouvons cependant travailler sans tout cela car il n'est pas spécialement important, pour notre projet, de rechercher des propriétés physiques homogènes dans tout le sextoy.
Pour ce qui est de la création de moules, nous pourrons les effectuer via imprimante 3D. Il existe un bon nombre de tutoriels sur internet pour s'y référer en cas de soucis.
Impression 3D
Pour la création d'objets en 3D, de nombreux outils sont disponibles. Nous avons décidé d'utiliser Tinkercad, un outil qui s'intègre directement au navigateur internet utilisé.
L'avantage d'un tel outil est sa grande communauté qui permet un accès simple et rapide à une multitudes de projets dont on pourrait s'inspirer pour générer nos pièces.
Création des moules
A l'aide d'une imprimante 3D, nous pouvons concevoir des moules afin de créer des pièces en silicone. Il s'agit de la manière la plus rapide et accessible pour notre projet.
Cette méthode comporte des désavantages, dont le principal est la présence d'imperfection et de non homogénéité dans les pièces réalisées. Ceci n'a pas de grande importance dans la mesure où nous souhaitons du qualitatif.
Création d'un prototype
Pénis
Afin de visualiser qualitativement la forme et le passage des câbles, un prototype imprimé au Fabricarium de Polytech Lille a été réalisé.
Ce prototype se divise en 3 pièces : un boîtier (pour y loger le PCB), un cylindre (afin de reproduire la forme désirée) et un "tête" qui devait à l'origine être un moule en silicone (pour y loger le PCB du capteur de température).
Image 3D
Conception des PCB
Afin de diminuer un maximum la taille des cartes electroniques, nous utilisons principalement des composants CMS.
La conception des cartes peut-être effectué à l'aide de logicels de CAO tels qu'Altium ou Eagle. Dans notre cas, nous avons utilisé Eagle.
Ce travail consiste à créer une librairie regroupant l'intégralité des composants nécessaires et, ensuite, de créer un schéma du circuit. Une fois le schéma terminé, il ne restera plus qu'à faire le routage et exporter les fichiers au format "Gerber".
Pour ce projet, nous aurons besoin de deux cartes, une par prototype. Chaque carte embarquera des composants similaires, c'est pourquoi nous nous contenterons d'abord d'un seul PCB pour effectuer des tests. Si ces derniers sont concluants, nous pourrons graver le second.
PCB du pénis
Le premier PCB imprimé et soudé est celui du pénis. Une première carte avait été imprimé regroupant sur cette dernière : un support pour l'arduino, un accéléromètre, un module bluetooth.
Nous avons expérimentés des problèmes dûs aux dimensions de l'accéléromètre, l'utilisation d'un boîtier CMS de type TDFN10 2x2 était optimiste pour la réalisation du projet, compte tenu du matériel à disposition.
C'est pourquoi une seconde carte a été gravée, cette fois sans l'accéléromètre.
Ce prototype est sensé embarquer un capteur de température que nous avons décidé de mettre sur un PCB à part. Cette carte avait pour but d'être coulé dans le silicone, afin de mesurer la température au plus près de la zone intéressée.
PCB du vagin
Compte tenu des soucis rencontrés avec l'accéléromètre, la carte sera gravée afin de pouvoir y plugger un accéléromètre analogique en traversant. Le but étant d'avoir un prototype fonctionnel d'ici la fin du projet.
Nous avons également eu des problèmes avec le module bluetooth utilisé, ce dernier ne pouvant être reconfiguré manuellement par minicom, nous utiliserons le bluetooth HC-05 utilisé pour les essais de code. De même que pour l'accéléromètre, nous prévoirons un endroit pour le plugger sur la carte.
image PCB vagin
Reste à graver le PCB du vagin
Gestion des capteurs et servomoteurs
Introduction
Utilisation des capteurs par IIC
Controle des servomoteurs
Un servomoteur se contrôle à l'aide d'un signal PWM (Pulse Width Modulation). Ce signal consiste à modifier la largeur de l'impulsion en fonction de la consigne désirée.
Notre première manière de procéder consister à générer la PWM nous même à l'aide du vecteur d'interruption d'un TIMER. La méthode consistait à compter de 0 à 255 en permanence. Lorsque le compteur était inférieur à la consigne, on passait une sortie à l'état haut, sinon elle restait à l'état bas.
Cette méthode simulait plutôt bien le signal PWM et avait pour avantage d'être utilisable pour n'importe quelle de l'arduino. Cependant, cette méthode a le gros désavantage d'être sensible à l'utilisation d'autres interruptions, rendant le TIMER imprécis.
Or, notre projet utilisera d'autres procédures d'interruption. Nous avons donc décidé d'utiliser une méthode plus simple mais nous restreignant sur le choix de nos sorties.
En effet, un atmega possède des registres que l'on peut configurer pour générer des signaux PWM sur des broches spécifiques.
Ainsi, en configurant le registre TCCR0A à 0x81 et TCCR0B à 0x05, on se place en mode PWM non inversée à fréquence élevée. Ceci veut dire que pour une valeur d'OCR0A donné, la largeur d'impulsion haute sera proportionnelle à OCR0A.
Ainsi, nous pouvons donc contrôler le moteur simplement en changeant la consigne d'OCR0A.
Tests
Dans un premier lieu, les moteurs servomoteurs ne recevaient pas les consignes. Nous pensions que le fait que la PWM soit en 3V3 était l'origine du problème. Nous avons donc fait le montage à l'aide d'un transistor NPN monté en saturé. Le problème n'a pas été résolu.
Finalement, le soucis viendrait du fait que les tests étaient effectués avec des valeurs du registre OCR0A à 0 (pwm nulle). Nous n'aurons donc pas besoin d'un montage à transistor pour le PCB.
Le but des servomoteurs est d'effectuer un semblant de massage, nous allons donc modifier le code afin d'effectuer la tâche de manière périodique via l'utilisation d'un TIMER.
Gestion de la communication bluetooth
Introduction
Dans le cadre de notre projet, la communication entre le sextoy et le téléphone se fera à faible portée. C'est pourquoi nous avons considéré comme intéressante l'utilisation de la technologie bluetooth.
La première partie consiste à coder une librairie au niveau de l'arduino. Cette librairie, codée en C, consiste simplement en une lecture / écriture via les broches RX/TX de l'arduino et du module bluetooth.
La seconde partie conssite à coder la partie application mobile qui communiquera avec la arduino.
Une fois que cette transmission sera mise en place, il ne reste plus qu'à expliciter le protocole des paquets transmis.
Arduino
Afin de communiquer à travers le module bluetooth, il faut relier la broche RX de l'arduino à celle TX du module bluetooth et inversement. Pour tester nos codes, nous avons utilisé un module bluetooth HC-06 et l'application Bluetooth Terminal.
Dans la mesure où l'arduino devra traiter l'arrivée asynchrone de messages tout en effectuant le traitement des capteurs, il est intéressant d'effectuer des lectures à l'aide d'interruptions. Pour cela, nous utilisons le vecteur d'interruption USART_RXC_vect qui déclenchera la fonction de lecture d'un paquet à chaque fois qu'un message est reçu.
Actuellement, la librarie est fonctionnelle, il ne reste plus qu'à faire l'utilisation par interruption.
Application mobile
Protocole de transmission
Module bluetooth utilisé
Le module bluetooth embarqué sur le PCB est un module reprogrammable. Ainsi il était nécessaire de connaître la configuration par défaut du composant, dans le but de savoir s'il fallait ou non prévoir un pcb de reconfiguration.
Le CYBLE-012012 est configuré par défaut avec le firmware "EZ-Serial BLE Firmware". La configuration par défaut de ce firmware est la suivante :
- 115200 baud, 8bits de donnée, pas de bit de parité, 1bit de stop
- "UART flow control" désactivé
- firmware activé en mode "auto-start", qui correspond à une recherche automatique de connection bluetooth et de redirection RX-TX en cas de connection
Ces informations sont importantes car, si elles sont vraiment respectées, nous n'auront pas à créer notre propre kit de développement, ce qui est un gain de temps considérable.
Qui plus est, l'utilisation d'une fonction "auto-start" est en adéquation avec le module bluetooth HC-05 utilisé pour les tests. Nous pouvons donc commencer la programmation mobile du bluetooth en parallèle de l'impression des pcb. Et, dans le cas où les pcb seraient disfonctionnels, nous pourront quand meme envisager un prototype sur breadboard.
Test
Après avoir alimenté la carte, nous n'avons pas pu nous connecter au module bluetooth, ce dernier n'étant même pas visible dans les appareils alentours.
Nous avons alors vérifié si la carte était correctement alimentée. Pour ce faire, nous avons mesuré différents points de tensions sensé être mis par défaut en PULL-DOWN ou PULL-UP à des niveaux de tensions d'1.7V. Ces niveaux étaient respectés. Le problème n'est donc pas d'ordre électronique.
Par la suite, nous avons voulu vérifier la communication du module. Ce dernier, en déclenchant l'auto start est sensé émettre (en suivant le protocole UART rappelé précédemment) un message START. Nous avons donc inspecté ceci en utilisant minicom. En effet, minicom reçoit un message, mais ne sait pas le déchiffré. Qui plus est, impossible d'envoyer un message au module afin de le reprogrammer (de manière similaire à un XBee).
Devant ces soucis, nous décidons donc d'abandonner ce module bluetooth et de poursuivre avec celui utilisé pour les essais de programmation, le HC-05.
Conception de l'application Android
Envoie et réception de SMS
Afin de ne pas utiliser de serveur, les deux appareils Android doivent synchroniser l'envoi de paquet UDP, pour cela nous avons voulu utiliser des SMS. Les SMS permettent d'envoyer des informations, comme les adresses IP, les ports utilisés, l'heure à laquelle les deux téléphones vont envoyer leur premier paquet UDP.
Dans un premier temps nous avons créer une application pour envoyer les SMS:
L'application était très simple, l'envoi de SMS se faisait en deux lignes
// initialisation d'une variable sms gérant les sms SmsManager sms = SmsManager.getDefault() ; // envoie un sms comportant le texte de la variable message de type String au numéro contenu dans la variable num de type String sms.sendTextMessage(num, null, message, null, null);
Dans un deuxième temps il fallait recevoir un SMS, ou plutôt savoir qu'un nouvel SMS avait été reçu :
Pour cela il fallait utiliser un thread qui était appelé par interruption avec la réception d'un SMS comme vecteur d’interruption. Ce thread effectuait ce qui était demandé dans sa fonction onReceive(), comme par exemple lire les informations contenues dans le SMS:
public class IncomingSms extends BroadcastReceiver { final SmsManager sms = SmsManager.getDefault(); public void onReceive(Context context, Intent intent) { //Ce qui doit etre fait lors de la reception de SMS } }
Malheureusement ce programme ne marchait pas pendant des semaines, malgré de nombreuses modifications et de nombreux essais. Et le problème semblait être ma carte SIM, car en changeant de SIM, tous les programmes contenant ce code fonctionnaient parfaitement.
Protocole UDP
Afin d'effectuer un échange de données entre les deux sextoys, mais aussi pour effectuer une vidéo-conférence, nous avons choisi d'utiliser le protocole UDP.
Une première application permettait de tester l'envoi de paquet UDP, pour cela un serveur UDP a été utiliser sur un PC. Le serveur attendait un message et l'affichait quand il le recevait.
Une fois que tout fonctionnait comme il le fallait, nous avons pu créer une application qui comportait l'envoi et la réception de paquet. En mettant l'application sur deux téléphones on pouvait tester si tout fonctionnait. Les tests ont seulement été effectué sur un réseau local, on ne sait pas pour le moment si des box internet pourraient empêcher la transmission. L'application est composé de un thread d'écoute, un thread d'envoi et d'un thread principal gérant l'affichage et appelant le thread d'envoi lorsque que le bouton de l'application est appuyé.
Application principale
Afin d'être ergonomique,l'application doit pouvoir enregistrer des contacts, des réglages et avoir un menu principal intuitif.