IMA4 2016/2017 P14

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 et Thomas)

• é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 et après	Total
Définition cahier des charges	2H	2H	1H											5H
Dimensionnement et établissement de la liste de matériel		3H	4H		4H									11H
Établissement de la liste et de la répartition des tâches	1H													1H
Appareil masculin : programmation					1H	2H							14H	17H
Appareil masculin & féminin : étude des datasheets				1H	1H		4H					1H		7H
Appareil masculin : PCB										4H	4H	6H	30H	44H
Appareil masculin : 3D													6H	6H
Appareil féminin : programmation													24H	24H
Appareil féminin : PCB						2H	1H						4H	7H
Appareil féminin : 3D														0H
Liaison bluetooth (embarqué)				3H	1H								8H	12H
Liaison bluetooth (téléphone)													10H	10H
Recherche et discussion autour de la meilleure approche de communication	2H	2H												4H
Synchronisation temporelle des téléphones (par sms)		2H	4H	6H	8H	8H								28H
Transmission de paquets UDP							8H	6H	6H				10H	30H
Streaming video(UDP)										4H	4H			8H
Application et bases de données												8H	40H	48H
Total														262H

Conception des sextoys

Introduction

La conception de sextoys doit respecter différents règles, notamment sanitaires. C'est pourquoi nous nous sommes intéressés à l'utilisation de silicone pour ce projet. Nous avons notamment rencontré un ingénieur compétant dans ce domaine afin de nous aiguiller sur cette éventuelle conception.

La conception passera également par une conception 3D que nous effectuerons à l'aide d'imprimantes 3D au fabricarium de Polytech Lille.

Enfin, les prototypes seront embarqués de cartes électroniques (aussi appelés PCB) que nous constituerons.

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 une "tête" qui devait à l'origine être un moule en silicone (pour y loger le PCB du capteur de température).

Prototype 3D pénis

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.

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.

C'est pourquoi une seconde carte a été gravée, cette fois sans l'accéléromètre.

PCB v2.0

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.

PCB temperature

PCB temperature schema

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.

PCB vagin

PCB vagin schema

Conclusion

Dans cette partie du projet, tous les PCB ont été soudés, pour certains même plusieurs fois. Nous avons eu des soucis avec certains composants, nous imposant de perdre du temps sur des tests plus poussés que la simple vérification de court circuit et soudures correctes. Finalement, nous avons dû re-designer les cartes et faire autrement que prévu initialement. Ainsi, nous avons appris qu'en se lançant dans un projet, il ne suffit pas de prévoir un seul plan, mais il faut également une solution de secours, ce qui nous aurait économisé un temps précieux.

Nous avons également pu apprendre à utiliser l'imprimante 3D du fabricarium en imprimant un des deux prototypes. Malheureusement, nous n'avons pas eu le temps de mettre à profit les conseils de Mario Sanz sur le silicone.

Gestion des composants

Introduction

Notre projet implique l'utilisation de capteurs, de servomoteurs et de buzzers, constituant chacun une partie de la programmation embarquée.

Pour cette programmation, nous avons décidé d'utiliser AVR-gcc et ainsi coder les arduinos en C.

Les capteurs utilisés utilisent un protocole de communication IIC (ou I²C, I2C), ce protocole de multiples avantages que nous expliciterons par la suite. Cependant, comme un des capteurs (l'accéléromètre) prévus initialement nous a causé beaucoup de soucis, nous expliciterons également la mesure à l'aide de capteurs analogiques. Ces différents capteurs nous permettront de mesurer l'excitation d'un utilisateur.

Une fois l'excitation mesurée, il faut induire une réponse "physique". Pour ce faire, nous utilisons d'une part des servomoteurs dans le but de produire une sensation de massage.

D'autre part, nous utilisons également des buzzers.

Veuillez noter que le code ne sera pas détaillé dans le wiki, vous pouvez vous référer au dépôt git contenant les différents codes.

Utilisation des capteurs

Capteurs par IIC

Le choix de l'IIC n'était pas anodin. L'IIC permet, pour un bus de seulement deux fils (SDA et SCL), d'utiliser un nombre important de capteurs. Ainsi, si nous décidions au cours du projet de rajouter tel ou tel capteurs, nous n'avions qu'à les greffer à ce bus IIC.

Tout d’abord, nous devons initialiser le bus IIC de l’arduino. Pour ce faire, il suffit de préciser la fréquence désirée, ici 400KHz, dans les registres TWSR (prescaler) et TWBR. (fréquence désirée suivant la fonction TWBR = (Fcpu - 16 Fscl ) / (2 Fscl Prescaler) ) avant de lancer l'utilisation IIC via le bit TWIE.

Comme il peut y avoir potentiellement plusieurs capteurs sur ce bus, il faut respecter un certain protocole afin de récupérer la valeur du capteur de température. Attardons nous sur la lecture d’une valeur sur le capteur de température. Il faut :

• Lancer un message de start
• Envoyer l’adresse du capteur de température (0x98 dans notre cas)
• Envoyer l’adresse du registre qui nous intéresse (0x00 pour celui contenant la température), ceci placera le pointeur de registre du capteur sur cette adresse
• Restart la communication pour laisser la main au capteur
• Envoyer l’adresse du capteur en ajoutant 1 (Ceci permet de stipuler que nous désirons lire la valeur pointée)
• Lire la partie haute de la température
• Lire la partie basse de la température
• Envoyer un message de stop

Chaque action correspond à l'utilisation d'une fonction de la librairie IIC codée. (cf déport git) Et après chaque action, nous devons vérifier le status du bus dans le registre TWSR. Ce "status" nous donnera des indications sur le bon déroulement de la communication, à savoir la réception d'ACK (équivalent d'accusé de réception) ou confirmation d'envoie de start, restart, etc.

Test

Le test de la librairie iic s'est fait directement lorsque la carte du capteur de température a été soudée. Pour ce faire, nous utilisons une compilation en mode "DEBUG" (make debug upload) qui nous permettait de lire la valeur des "status" avec minicom. Après différents tests, nous avons finalement réussi à faire fonctionner le capteur de température en IIC, ce dernier nous renvoyait bel et bien une valeur de température précise à 0.5degrés près, vérifié à l'aidé d'un autre capteur de température.

Il est néanmoins regrettable que ce capteur ne sera pas utilisable dans les prototypes finaux dans la mesure où il est greffé à une carte dont le module bluetooth n'est pas utilisable.

Capteurs analogique

Comme dit précédemment, nous avons abandonné l'utilisation de l’accéléromètre IIC prévu initialement dans le vagin car nous n'avons pas réussi à le souder sur les cartes du pénis. Nous avons donc utilisé ce qui était à notre disposition à savoir un capteur analogique.

La mesure analogique sous AVR se fait simplement via l'utilisation de la fonction ad_sample(numéro de la broche analogique lue). Elle renvoie directement une valeur entre 0 et 255 correspondant à une conversion analogique-numérique de la tension sur la broche lue du capteur.

Test

Nous avions déjà utilisé ce genre de fonctionnalité dans le projet de système et réseau, donc comme attendu, les tests étaient réussis.

Contrôle 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.

La génération de PWM via microcontrôleur se fait à l'aide de TIMERS. Il faut savoir qu'il existe une priorité dans les interruptions, pour un TIMER_X donné, plus le X est proche de 0, plus l'interruption sera prioritaire. Nos signaux PWM se doivent d'être le plus en accord avec nos consignes, c'est pourquoi nous avons choisi d'utiliser les TIMER les plus prioritaires pour les générer. (TIMER0 et TIMER1)

PWM sur un seul servomoteur

Notre première manière de procéder consistait à 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. En résumé, cette configuration nous permet de faire varier les signaux PWM en introduisant une consigne dans le registre OCR0A.

Ainsi, nous pouvons donc contrôler le moteur simplement en changeant la consigne dans 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 d'un ensemble de servomoteurs

Dans le vagin, nous utilisons 4 servomoteurs afin de masser l'utilisateur. Nous avons trouvé intéressant de diviser ces moteurs en deux couples afin d'intensifier ou non ce massage en fonction des seuils d'excitation détectés par les capteurs.

Pour ce faire, nous aurons besoin de deux signaux PWM différents, donc de l'utilisation de deux timers configurés en PWM.

Comme dit en introduction de cette section, nous nous imposons l'utilisation du TIMER1 pour cette deuxième PWM. Il existe une différence dans la configuration de cette dernière dans la mesure où le signal peut recevoir des consignes allant de 8 à 16bits en fonction de la configuration. Afin de simplifier les choses, nous avons configuré cette dernière sur 8bits pour lui envoyer les mêmes consignes que pour le TIMER0.

Tests

Avant tout, nous devions vérifier que la consigne avait une intensité suffisante pour être envoyée sur deux servomoteurs en même temps. Ce qui était le cas.

Ensuite, nous avons testés des changements de consignes plus ou moins rapides afin de déterminer ce qui répondrait le mieux à nos attentes.

Les tests concluants, nous pouvions passer à la suite.

Utilisation des buzzers

En fonction du niveau d'excitation, nous ferons vibrer un ou deux buzzers. Pour ce faire, nous avons fait le choix de souder leur broche GND au GND de nos cartes et ainsi souder leur potentiel VCC à une broche de l'arduino. Ainsi, si nous plaçons la broche à l'état bas, le tension dans le buzzer est nulle et si nous passons la broche à l'état haut, la tension aux bornes du buzzers devient 3.3V et il vibre.

Pour ce faire, nous utilisons simplement deux broches, ici PXX et PXX, que nous avons initialisés en tant que sorties en mettant à un leur bit correspondant dans le registre DDRX. Ainsi, il ne reste plus qu'à commander la valeur haute ou basse de ces broches en mettant à 1 ou 0 leur bit dans le registre PORTX.

Tests

Ceci a été testé sur breadboard et était fonctionnel. Cependant, une chose à quoi nous n'avions pas pensé était que lorsque nous les avons soudés sur le PCB, nous aurions dû utiliser des câbles plus épais, car comme nous n'avions pas de prototype sur quoi coller les buzzers, l'un des buzzers s'est arraché de la carte en vibrant.

TIMER2

Maintenant que nous avons chaque partie pouvant fonctionner indépendamment, nous avons choisi d'utiliser le dernier TIMER à disposition afin de rendre l'intégralité du programme basé sur les interruptions et ainsi s'assurer que les priorités désirées soient respectées.

Ce TIMER nous servira donc à :

• Effectuer des mesures régulières des capteurs
• Changer les consignes PWM quand il le faut

Nous avons fait en sorte que ce TIMER provoque une interruption le plus lentement possible (à savoir toutes les 32ms environ), afin de ne pas surcharger le contrôleur inutilement. En effet, la mesure des capteurs n'a pas besoin d'être faite de manière intensive.

Test

Au cours des tests, nous nous sommes rendu compte que la mesure d'excitation avec l'accéléromètre ne pouvait être fait que sur une seule mesure du capteur. Ainsi, nous avons décidé de moyenner les valeurs sur 20mesures et calculons ce qui se rapproche de la dérivée des valeurs de l'accéléromètre sur une période donnée.

Ainsi, nous mesurons réellement l'entrain de l'utilisateur sur une période de temps significative et non pas à un instant donné.

Résumé

Conclusion

Cette partie du projet a été finalisée. Nous avons réussi à utiliser toutes les fonctionnalités "embarquées" de notre projet.

proto pénis

Prototype final du pénis.

proto vagin

Ensemble des dispositifs électroniques du vagin, résumant les fonctionnalités possibles de notre cahier des charges.

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-05 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 à chaque fois qu'un message est reçu.

Une fois le niveau d'excitation lu, nous pouvons utiliser la fonction "lovometre()" qui activera ou désactivera tel ou tel dispositif en fonction du niveau reçu. En réponse à cette lecture, pour confirmer notre réception, nous envoyons le niveau d'excitation actuel de l'utilisateur.

Test

A l'aide de Bluetooth Terminal, nous avons pu effectuer un test sans l'application mobile de notre projet. Ayant fait ces tests avant la partie "gestion des composants", nous nous sommes juste assurés du bon fonctionnement de la communication en effectuant un echo à chaque réception.

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.

Téléphone

Pour gérer la communication entre le téléphone et un sextoys, il faut utiliser une communication Bluetooth.

Dans un premier temps il faut se connecter avec l'appareil:

new ConnectBT().execute();

Avec ConnectBT une classe trouvée sur internet.

Ensuite il faut communiquer :

Pour envoyer un message on utilise:

btSocket.getOutputStream().write(message);

Avec btSocket un socket Bluetooth ayant été connecté avec le sextoy dans la classe ConnectBT.

Ensuite il faut recevoir :

btSocket.getInputStream().read(mmBuffer);

Avec mmBuffer qui contient le message reçu.

Mais contrairement à la réception UDP, la réception Bluetooth n'est pas bloquante, ainsi on peut recevoir des messages nuls.

Protocole de transmission

Pour éviter que l'application ne reçoit de message vide, nous avons choisi que le sextoy réponde juste après avoir reçu un paquet.

Ainsi l'application à juste a envoyer un paquet Bluetooth et juste après à chercher à lire le message reçu, pour que tout fonctionne comme prévue

Conclusion

Cette partie du projet a été finalisée. Ceci était un point clé du projet car elle permet l'interaction entre le téléphone et la partie physique du projet. Il est néanmoins regrettable de ne pas avoir pu avoir un module bluetooth viable sur chaque prototype.

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 utilisateurs, et essayer de faire 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é utilisé sur un PC. Le serveur attendait un message et l'affichait quand il le recevait.

Pour envoyer un paquet nous utilisons :

DatagramSocket ds = null;
ds = new DatagramSocket(PortA);
DatagramPacket dp;
InetAddress local = InetAddress.getByName(AdrIp);
dp = new DatagramPacket(message.getBytes(),message.length(),local,PortA );
ds.setBroadcast(true);
ds.send(dp);

Ce code crée un paquet qui comporte l’adresse et le port du destinataire, mais surtout les données à envoyer. Ce paquet est ensuite envoyer grâce à un socket.

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. Pour la réception nous utilisons :

dsocket.receive(packet);
buff = packet.getData();

Pour récupérer les données du paquet dans la variable buff, il suffit ensuite de créer une boucle pour recevoir plusieurs messages. La fonction de réception étant bloquante, il a été préférable de l'effectuer dans un thread.

L'application est donc 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é. Voici une image de l'application, les champs d’adresseIp et de port du destinataire sont à remplir avant d'envoyer un paquet UDP. Et le port d'écoute est défini dans le code de cette application, ce qui n'est pas très pratique, mais suffisant pour les tests.

Le TextView est mis à jour à chaque que le bouton envoyer est appuyé, en prenant comme valeur celle d'un registre comprenant la valeurs du dernier paquet UDP reçu.

Application principale

Afin d'être ergonomique,l'application doit pouvoir enregistrer des contacts, pour plus facilement communiquer avec eux. Nous avons choisi de ne pas utiliser les contacts du téléphone, pour pouvoir avoir des contacts "confidentiels" qui ne seront que dans la base de donnée de l'application.

Il fallait donc créer une base de donnée, nous avons donc utilisé SQLite car cette bibliothèque est utilisée par Android comme base de données embarquée. La base ne comporte qu'une seule table, avec seulement les pseudos et les numéros de téléphone.

Une fois la base crée, pour interagir avec, nous avons coder des activités:

- Ajout de contact:

Il faut entrer dans les champs de textes les informations pour la base de données,puis appuyer sur le bouton "Ajouter" pour créer un nouveau contact dans la base de donnée.

-Fiche de Contact:

Affiche le pseudo et le numéro de téléphone dans les "TextView", et permet de : supprimer le contact en cliquant sur la croix, envoyer un SMS en cliquant sur l'icone "Message", mais aussi commencer une communication UDP en cliquant sur le téléphone.

-Liste de contact :

Affiche la liste de contacts, en cliquant sur un des contacts on arrive sur la page Fiche de Contact, et en cliquant sur le plus on arrive sur la page Ajout de Contact.

Ensuite il faut ajouter la gestion de communication:

-Les SMS :

Il faut remplir les champs de texte et appuyer sur SMS pour envoyer un message du type

Message

"Address Ip :" Addresse Ip

"Port :" Port

Avec Message,Addresse Ip, et Port les champs à remplir, "Addresse Ip :" et "Port :" deux chaines de caractères.

-Protocole UDP :

Quatre champs sont à remplir, cliquer sur Envoyer pour passez à l'activité de gestion Bluetooth.

Les champs sont:

-L'addresse Ip

-Le port destination

-Le port source

-L'heure qui n'est pas utilisée, qui devait servir pour la synchronisation.

Les valeurs des champs sont conservés pour la communication UDP à venir.

-Gestion Bluetooth :

En cliquant sur "Paired Devices", l'application affichera la liste des appareils appairés.

Puis en cliquant un des appareils, l'application essayera de connecter avec, tout en lançant l'activité UDP avec Bluetooth.

Si l'on souhaite ne pas utiliser de périphérique Bluetooth, il suffit de cliquer sur le bouton moins en haut à droite.

L'activité UDP sans Bluetooth se lancera.

-Communication UDP avec Bluetooth:

Pour lancer la communication UDP, appuyer sur le bouton Off ,il passera en mode On.

Si vous cliquez sur le bouton On il passera en mode Off, et coupera la communication UDP.

Le bouton envoyer, permet de forcer l'envoi d'un paquet UDP.

Et le bouton croix coupe toutes les communications(UDP et Bluetooth), et retourne à la page précédente.

Lorsque l'application reçoit un paquet UDP, un message est envoyé via Bluetooth au sextoys.

Celui-ci répond automatiquement en envoyant une valeur moyennée des ses capteurs, cette valeur est récupérée et mise dans un registre.

En parallèle, toutes les secondes un paquet UDP est envoyé et les données envoyés sont celle du registre.

-Communication UDP sans Bluetooth.

Le bouton On/Off est utilisé comme dans l'activité "Communication UDP avec Bluetooth"

Les boutons de niveaux, mettent une valeur dans un même registre.

Chaque boutons correspond à une valeur, qui correspondent avec un niveau d'excitation du sextoys.

Ainsi toutes les secondes, un paquet UDP est envoyé avec comme donnée la valeur du registre.

Lorsqu'un paquet UDP est reçu, la donnée reçue est mise dans un registre qui détermine l’affichage du "TextView" en bas à droite.

Ce TextView est mis à jours en même temps qu'un paquet UDP est envoyé.

Streaming vidéo

Nous nous sommes attardés sur le streaming vidéo avant d'avoir fait l'application principale et le gestion du Bluetooth. Nous avions trouvé un code sur Github, qui permettait de streamer la vidéo du téléphone sur un pc. Il aurait fallut adapter ce code pour streamer entre deux téléphones. Mais la recherche du code avait pris trop de temps, et il restait encore trop de chose importante à faire avant de pouvoir continuer cette partie. C'est pourquoi il n'y a pas de Streaming vidéo dans l'application finale.

Conclusion

Il reste beaucoup de travail, on ne sait pas si l'application fonctionne avec les boxs, il faudrait améliorer l'ergonomie pour l'utilisateur( par exemple l'application pourrait récupérer elle-même l'addresse Ip pour l'envoyer par SMS), et le streaming vidéo aurait été vraiment intéressant.

Mais l'application arrive tout de même à communiquer avec les sextoys, mais aussi avec un deuxième téléphone en même temps. La connexion avec un sextoy est simple, on peut simuler les relevés des capteurs si on désire ne pas utiliser de sextoys, on peut facilement agencer sa liste de contact et interagir avec. Ce qui est déjà une très bonne base.

Rapport et codes

Rapport : Fichier:CR sextoy connecte.pdf

Codes