Sous bock connecté
Cahier des charges
Présentation générale du projet
Contexte
Dans le cadre du module transversal Internet des Objets (IOT), nous avons choisi de réaliser un dessous de verre connecté. En effet, ces technologies sont très en vogue d'un point de vue commercial. De plus, cet élément peut être un plus pour notre projet de fin d'étude (PFE) puiqu'il s'agit de réaliser une table de bar connectée.
Objectif du projet
L'objectif du projet est de concevoir le dessous de verre afin d'avoir un produit fini et de démonstration. Nous allons donc commencer par établir le cahier des charges, puis réaliser la partie logiciel et enfin hardware.
Description du projet
L'idée est d'avoir un support pour les verres afin d'avoir un moyen de protéger la table que l'on doit réaliser pour notre PFE. De plus, il est intéressant de rendre cet objet connecté pour intéragir avec la table. Ses principales fonctionnalités seront de détecter la présence d'un verre, de réaliser un contrôle de la température du verre et de la température ambiante, d'avoir un retour visuel de la température via des LEDs RGB, enfin nous souhaitons faire une détection et une lecture de tag NFC qui sera placé sous le verre afin de transmettre des informations sur la boisson(son nom, sa température idéale de dégustation ...)
Par la suite on pourrait envisager une application mobile qui donnerait toute sortes d'informations, comme un historique des boissons consommés, des alertes de temperatures lorsque la boisson ce réchauffe ou refroidie, des statistiques sur le temps mis à consommer la boisson, ou la durée passé avec le verre en main ...
Choix techniques : matériel et logiciel
- LEDs RGB NeoPixel
- SmartEveryThing FOX V2 qui embarque déjà le module BLE, le lecteur NFC et un premier capteur de température.
Nous souhaitons réaliser le dessous de verre en plexi avec un miroir gravé au Fabricarium sur le dessus qui aura l'avantage d'être facilement nettoyable.
Nous avons une contrainte de taille que nous avons fixé à 10x10cm dans l'idéal.
Étapes du projet
- Dans un premier temps, nous allons réaliser un choix matériel et logiciel.
- Puis nous allons réaliser quelques tests pour son bon fonctionnement pour la réalisation du projet.
- Réalisation de la partie logicielle
- Réalisation de la partie mécanique/hardware
- Test
Suivi de l'avancement du Projet
Séance 1 (13/01/2016)
- Réalisation du cahier des charges.
- Choix matériel : SmartEveryThing FOX V2 pour la carte du microP qui a l'avantage d'embarquer le module BLE et le lecteur NFC et même un capteur de température.
- Choix logiciel : pour un gain de temps sur ce genre de petit projet, nous avons opté pour l'IDE arduino.
- problème : le smarteverything a juste un émulateur de tag et pas de lecteur
- lecteur de chez Seeed Studio fonctionne sous 5V et le RFDuino sous 3V donc pas possible
- donc on part sur un RFDuino RFD22102 + un Shield NFC de DFRobot DFR0231
- on ne peut utiliser ce shield NFC car il communique en série et il n'y en a qu'une sur le RFDuino (du moins pour effectuer les test et la programmation)
On obtient donc :
- Materiel :
- Rfduino
- Bouton pour détecter la presence d'un verre
- 2 capteurs de temperature TMP36 (et donc pouvoir comparer la temperature d'ambience et celle du verre)
- Shield DFR0231 de DFRobot pour la lecture du NFC, il faudra tester le code sur un arduino MEGA ou due avant de le mettre sur le RFduino
- Anneau de 24 leds neopixels par adafruit, afin d'avoir un retour visuel sur l'etat du sous bock
- Batterie externe Samsung, qui permettra l'alimentation du Rfduino et des composant, en branchant son shield USB directement sur la batterie.
- Logiciel :
- L'IDE arduino, comme indiqué précédemment permettra un développement rapide ainsi qu'une gestion plus aisé des communications BLE, du module NFC, ainsi que des leds.
- L'application android sera minimaliste et permettra uniquement la connexion puis la visualisation des données provenant du sous bock. Néamoins, on pourrait envisager avec plus de temps des graphiques pour suivre l'évolution des temperatures, des alertes lorsque la boisson se réchauffe ou refroidis, le temps mis pour terminer la boisson, les boissons les plus conssomées, le nombre de boissons consommés dans la semaine ou le mois et bien d'autres choses.
La suite de cette séance a été consacré à la prise en main du RFduino, ainsi qu'au test de communication BLE avec un telephone android. En effet, il n'existe pas d'application de test ou d'exemple disponible sur le site officiel ou sur le github du fabricant. Plusieurs tutos on été testé, et après de longues recherches infructueuse nous avons fini par trouver un projet à compiler sous androidStudio utilisable. Des solutions à base de projet eclipse ou de AppInventor n'ont pas fonctionné car elles ne supportent pas le BLE. L'application suivante https://github.com/donaldhwong/rfduino permet donc la connexion puis la visualisation de caractères ascii envoyés par le RFduino (ainsi que l'envoi vers le duino, mais ce n'est pas pertinent ici).
Séance 2 (13/01/2016)
Lors de cette séance nous avons cherché à controller le fonctionnement des leds avec le RFduino. En effet, malgrès l'utilisation de l'IDE, la librairie prévu pour les cartes arduino ne peut se compiler pour le RRFduino. Nous avons donc trouvé et adapté des fonctions ajoutables dans notre code et qui permettront d'envoyer les données de commande une a une aux leds. Ces fonctions remplissent donc un tableau ajusté au nombre de led*3 canaux de couleurs puis envois toutes les données sur le GPIO indiqué. Ces fonctionnalités sont donc implémentés dans les 2 fonctions suivantes :
void setPixelColor(int pixel, byte red, byte green, byte blue) void showStrip()
Nous avons aussi réussi a récuperer la temperatures des capteurs, avec les commandes suivantes :
int sensorValueExt = analogRead(PinTempExt); float outputValueExt = (((float)(sensorValueExt))*3300.0)/1023.0; float outputTempExt = ( (float) outputValueExt - 500.0) /10.0;
Il y'a donc la recuperation de la valeur analogique, puis conversion en millivolts puis en degrés C.
Enfin nous avons testé le fonctionnent du lecteur NFC, en exécutant le code present sur le wiki du constructeur sur un arduino DUE, possédant donc deux ports séries. (http://www.dfrobot.com/wiki/index.php/NFC_Module_for_Arduino_(SKU:DFR0231) ) Celui ci fonctionne et va donc permettre la creation d'une fonction qui associe au numéro d'un tag le nom d'une boisson et le retourne. Cette fonction pourra par la suite être implémenté dans le RFduino monopolisant son port série. (L'utilisation d'un virtual serial a aussi été envisagé mais ne semble ici aussi pas compatible avec le RFduino)
Séance 3 (14/01/2016)
Lors de cette séance nous avons essayé d'assembler les différentes pieces logicielles validés individuellement pour l'arduino. Malheureusement, lors de nos tests l'activation des fonctions bluetooth sur le RFduino entraînaient des ralentissement et des bugs sur l'actualisation des leds. Après de longues recherches, nous avons trouvé une solution dans le manuel de programmation BLE fourni par rfduino. En effet, on ne peut anticiper le moment ou le BLE va communiquer (advertisement par exemple) et lorsqu'il y'a emission, les instructions en cours sont arrêtées. Cela pose donc évidemment problème lorsque l'émissions des donnés destinés aux leds est effectué. Le document propose donc de placer la fonction suivante avant d'effectuer du code sensible au timing
while (RFduinoBLE.radioActive) ;
En placant cette instruction au début de la fonction showStrip(), nous n'avons plus constaté de soucis. Une augmentation de la valeur de RFduinoBLE.advertisementInterval permet aussi de laisser plus de temps à nos instructions.
Nous nous sommes aussi attaqué a un autre aspect de ce projet, la réalisation de la maquette. Nous solutions avoir un sous bock rond, avec un disque central mobile permettant de recevoir le verre et de s'enfoncer sous son poids afin d'actionner le bouton. L’épaisseur et nécessairement assez importante pour ce premier prototype, et ce en grande partie a cause de la taille imposante de notre batterie. Mais il serait par la suite envisageable de la réduire avec une batterie de telephone portable par exemple, et/ou un module de recharge Qi (sans fil) L'idée de base était de réaliser le prototype dans du plexiglas, principalement pour l'aspect esthétique ainsi que pour la qualité de la surface après découpe. En effet cela permettrait d'assurer une bonne liaison entre le disque qui s’enfonce pour recevoir le verre et l'autre. Nous avons donc préparé des dessins vectoriels du socle, d'anneaux extérieurs à empiler afin de parvenir a la bonne hauteur ainsi que le dessus. Le fabricarium ne disposant de plexiglas, nous avons décidé d'adapter nos dessins de découpe pour un modèle en carton. Le prototypage sera alors plus rapide et moins coûteux. Nous avons donc remplacé les anneaux extérieurs par un rectangle a replier, permettant d'atteindre directement la bonne hauteur. Le dessus a aussi été séparé en plusieurs couches, pour remplacer les gravures en profondeur permettant d’intégrer les leds, le bouton et le capteur de temperature par des découpes. Les fichiers utilisés sont disponibles ici. Fichier:Model Laser SousBock.zip
Séance 4 (
Le code de lecture Nfc n'ayant pas encore fonctionné sur le RFduino, nous avons essayé de le porter. Malheureusement celui ci n'a pas fonctionné comme c’était le cas avec l'arduino DUE, en effet le RFduino n'est pas supposé être capable de dépasser 9600 bauds avec une communication BLE. Or le module NFC DFrobot envois les données à la vitesse de 115200 bauds. Nous avons tout de même réussi après de nombreux tests et recherches, en ajoutant une ligne permettant de passer outre la limite de 9600 puis en réduisant la fréquence des advertisements bluetooth afin de gagner en temps.
overide_uart_limit = true; RFduino.BLEadvertisementInterval=1000;
Avec ces ajouts, nous avons réussi à extraire les donnés d'un tag, et les envoyer via BLE. Enfin problème USB
Cependant lors de la fusion de ce programme, avec la version complete, le programme ce bloque dans un état et ne réagi plus à rien. La liaison serie etant paralysé pour le shield NFC, malgrès de nombreux tests nous n'avons pas pu débloquer la situation.
La suite de la séance à été consacré à la finalisation de la maquette et la réalisation de la planche A3