Biere connectee

De fablab
Aller à : navigation, rechercher

Description du sujet

Objectifs

Ce projet consiste à créer un verre de bière connecté permettant de voir sur une application si un client a besoin d'aide ou a bientôt fini son verre afin d'optimiser le service et de limiter les déplacements des clients dans le bar.

La conception de ce projet (application, matériel physique) a pas mal changé au fil des séances, et ce pour des raisons d'impossibilités techniques ou par manque de matériel (trop spécifiques pour être facilement accessibles).

Équipe

  • Léa Barrau
  • Léopold Favre
  • Yanis Garcin
  • Louise Lallemand

Problématique

Après les nombreux confinements provoqués par la crise du coronavirus, le nombre de personnes dans les bars a fortement augmenté. Cet essor pose deux problèmes majeurs pour les établissements : comment gérer un très haut nombre de commandes et comment faire pour qu'il y ait le moins de contact possible entre les clients pour éviter la propagation du virus.

Pour répondre à ce problème, nous avons décidé de mettre au point un verre connecté. Ce dernier a deux fonctionnalités principales : signaler si un verre est bientôt vide (défini comme l'état ORANGE) et signaler si un client a un problème (défini comme l'état ROUGE). L'état ORANGE se déclenche lorsque le verre atteint un certain niveau défini comme critique tandis que l'état ROUGE est déclenché lorsque le client appuie sur le bouton sur le socle de son verre. Cela permet, d'une part, de prévoir les commandes à venir en demandant aux personnes dans l'état ORANGE s'ils veulent être resservis et d'autre part, d'aller voir un client dans l'état ROUGE pour régler son problème, le tout sans que les personnes n'aient besoin de se déplacer.

Conception

Au moment où l'équipe a décidé du sujet, en l'occurrence du verre connecté, nous avons établi un premier cahier des charges au travers d'un diagramme "bête à corne", ainsi qu'un diagramme "pieuvre" ou "graphe des interactions".


Diagrammebac.png
Diagramme "Bête à Corne" du projet


Ce diagramme définit notre besoin, en l'occurrence aider du personnel de bar/restaurant à gérer les commandes plus facilement grâce au verre connecté.


Pieuvre.png
Diagramme "Pieuvre" du projet
  • FP1: Indiquer le niveau de contenance d'un verre aux serveurs.
  • FP2: Prévenir les serveurs que les client(e)s ont besoin d'un service.
  • FC1: Être étanche.
  • FC2: S'adapter à tous les verres (dans la mesure du possible).
  • FC3: Ne pas coûter trop cher (<20€).
  • FC4: Être identifiable.
  • FC5: Être fixe.
  • FC6: Avoir une autonomie considérée comme satisfaisante (le temps d'une soirée ≈ 5h).
  • FC7: Ne pas être trop lourd/trop petit.
  • FC8: Être simple et rapide à utiliser, configurer et maintenir.
  • FC9: Ne pas rajouter trop de travail (doit rester rentable).


Ces deux diagrammes constituent le cahier des charges initial que nous avons formé, nous avions là l'esquisse de l'analyse de nos besoins.

Initialement, nous ne savions pas comment la détection de la quantité dans le verre serait faite. Nous avons immédiatement pensé à un capteur optique, mais cela rajoutait beaucoup de contraintes (calibrage, verre transparent, contenu pas trop opaque...). Nous avons donc opté pour une plaque de pression reliée à un potentiomètre (fourni par le FabLab, qui l'a reçu d'un ancien étudiant les ayant fabriquées lui-même). L'avantage principal de ces plaques est qu'elles ne prennent pas beaucoup de place, ce qui est confortant au niveau du cahier des charges que nous nous étions fixé.

Scénario d'utilisation

Diagramme de séquence et explication

Les diagrammes ci-dessous décrivent la suite chronologique des différents états d'un verre.

Le verre est vide et doit être configuré

Piwo diag seq 1.png

Ici, le verre n'est pas encore configuré, c'est-à-dire qu'il n'a encore jamais été utilisé. Pour que le verre soit utilisable par la suite, il doit être reconnu par le socle et l'application. Pour cela, le serveur pose le verre sur le socle qui va directement se déclarer au système en remplissant les infos qui le concernent et en demandant au serveur de valider. Le verre est alors connu du système et peut être utilisé.

Le verre est enregistré et va être servi

Piwo diag seq 2.png

Ici, le verre va être utilisé pour le service. Pour cela, le serveur choisi sur l'application la table concernée pour cette commande et pose les verres en question un à un sur le socle. Le système ajoute les nouveaux verres à la table concernée et le serveur peut les servir.

Le verre est sur une table et il y a un problème, le client appuie sur le bouton (état rouge)

Piwo diag seq 3.png

Dans le cas d'un problème, le client peut appuyer sur le bouton se trouvant sur le socle de son verre pour appeler un serveur. Lorsque cela est fait, l'application signale avec un code couleur qu'il y a un problème sur la table en question. Une fois que le serveur est allé voir cette table, il consulte son application pour déclarer que le problème est réglé. Pour cela, il sélectionne le verre sur l'application et signale si ce dernier a été repris (suppression du verre dans la liste des verres de la table) ou si le problème a simplement été résolu (passage de l'état ROUGE à VERT dans la base de données et dans l'application).

Le verre est servi et bientôt vide (état orange/gris)

Piwo diag seq 4.png

Lorsqu'un verre est mis en service il envoie son poids de manière régulière au serveur. Lorsque le poids atteint un poids défini comme étant critique (le verre est bientôt vide), le serveur change l'état du verre dans la base de données (passage de l'état VERT à l'état ORANGE). Dans ce cas, l'application signale par un code couleur ce changement au serveur qui peut aller voir directement la table concernée. Deux cas se distinguent par la suite :

  • Premier cas : le client veut se resservir : le serveur signale que le verre a été repris. Le verre est alors supprimé de l'application ; il n'est plus en service. Le serveur ressert un verre au client en réitérant l'étape de service vue au-dessus.
  • Deuxième cas : le client ne veut plus se resservir : le serveur signale que le client finit simplement son verre. Le verre passe alors dans l'état GRIS sur l'application et la base de données. Le serveur pourra, par la suite, le sélectionner pour signaler que le verre est fini et qu'il a été retiré.

Diagramme de séquence final

À cause des problèmes techniques rencontrés lors de la réalisation de l'objet, certains éléments des diagrammes de séquence dessinés lors de la conception ont dû être supprimés ou modifiés. Voici le diagramme de séquence du produit fini :


Diagseqpiwo.png


Les couleurs dans la séquence temporelle du Piwo correspondent à un état, qui est systématiquement communiqué à la base de données à chaque changement. De plus, la couleur correspondante est affichée par la LED de couleur située sur le Piwo. Enfin, lorsque le Piwo est dans l'état "orange" ou "vert", l'objet envoie régulièrement la dernière mesure de remplissage non inférieure au poids du verre vide à la base de données.



Vidéo de démonstration

La vidéo de démonstration de notre projet est disponible sur le lien suivant: [[1]]

Technologies utilisées

Piwo-schema.png

Matériel utilisé

  • (1) Carte programmable NodeMCU Devkit 1.0 (ESP8266)
  • (1) Breadboard
  • (1) Module "Balance" pour carte programmable, fait maison par un ancien usager du FabLab
  • (1) Module bouton pour Arduino
  • (1) Module LED RGB pour Arduino
  • (4) Petits fils M/M
  • Un pc pour la machine serveur
  • Un smartphone Android (émulé)

La carte programmable

Cette carte programmable a été choisie puisqu'elle est équipée d'une puce Wifi. En effet, notre objet est supposé fonctionner dans le réseau Wifi du bar auquel est connecté la machine serveur, les Piwos et les smartphones équipés de l'application.

Cette carte programmable a un fonctionnement similaire aux cartes Arduino, et avec ses drivers sont fournis les bibliothèques permettant de se connecter au réseau Wifi et d'y communiquer via des requêtes HTTP. Nous avons donc programmé la carte en C/C++.

Le serveur

La machine serveur est une classique combinaison Apache HTTP / MariaDB, facile à installer et configurer sous Linux (surtout si la base de données est hébergée localement), et plutôt fiable. Le serveur Apache a également été équipé des extensions nécessaires pour le PHP.

Ce serveur est donc doté de deux types d' APIs, codées en PHP :

  • Les APIs dédiées à l'objet connecté
  • Les APIs dédiées à l'application mobile

Celles-ci modifient et consultent la base de données à chaque requête, base de données qui stocke l'état que chaque Piwo lui envoie régulièrement en fonctionnement normal.

Les signaux

Pour déclencher des évènements au niveau de l'objet, l'entrée de chaque Piwo dans la base de données possède une entrée "sig", une API accessible via l'application.

L'application mobile

L'application mobile est une application crée sous Android Studio.

Budget

Temps de travail

Pour la réalisation du projet, on peut compter environ 20 heures de travail par personne, soit 80 heures de travail au total. En prenant un salaire de 15€ de l'heure, cela donne un projet coûtant 1200€ en temps de travail.

Matériel

Le budget matériel est plus difficile à estimer. Nous avons essayé de nous baser sur 3 éléments principaux pour définir un prix :

  • La carte programmable : peut être achetée en lot de 25 pour 95€99 soit 3€84 pièce environ ;
  • La LED RGB programmable : nous en avons trouvé pour 3€80, mais on pourrait imaginer qu'en achetant en gros pour faire toutes les bases nécessaires à la mise en place du projet dans un bar, il serait possible de diminuer ce coût ;
  • La balance : la balance que nous utilisons n'est pas assez précise pour ce projet et nous n'en connaissons pas le coût. C'est pourquoi nous nous basons plutôt sur cette balance ARCELI HX711 ADC qui n'était pas disponible au FabLab, mais qui devrait permettre de réaliser un meilleur socle que notre prototype. Cette balance est à 7€99 l'unité, mais comme pour les LEDs, il serait probablement possible de diminuer le coût en achetant en gros.

Rien qu'avec ces trois éléments principaux, on arrive à une estimation d'environ 16€ par socle.

Bilan et pistes d'améliorations

Bilan

Durant ce projet nous avons dû sans cesse évoluer et réfléchir à de nouvelles solutions. Comme il est possible de le voir dans les parties précédentes, le projet a changé mais notre idée de base est restée la même et a pu finalement être réalisée. En effet, à l'issue de ce semestre nous sommes en possession d'un système qui est capable de faire des mesures de pression sur un objet (dans notre cas, un verre), d'une application complète et d'un serveur qui fait le lien entre ces deux éléments.

Pistes d'améliorations

Bien que nous ayons à la fin de ce projet un objet connecté qui correspond à notre cahier des charges, différents points sont à améliorer :

  • L'application est à améliorer. En effet, pour les besoins du projet, différentes parties de l'application n'ont pas été développées pleinement. Par exemple, les parties dans l'application concernant les tables, les types de verres, les connexions ou autre fonctionnalités annexes font des appels à une base de données SQLite en local. Pour avoir une application permettant une utilisation dans la vie courante il faudrait connecter chaque partie faisant appel à la base de données SQLite à la base de données MySQL du serveur.
  • La synchronisation entre le système du verre et l'application est à améliorer. En effet, le serveur récupère le signal du verre toutes les x secondes, l'enregistre puis le modifie dans la base de données. Pendant ce temps, l'application peut changer l'état d'un verre et donc son signal. On arrive alors à une contradiction entre l'état de la LED et la représentation sur l'application. Pour contrer cela, nous avons pour le moment mis un temps d'attente lors de l'appel de l'application à la base de données et, en cas de contradiction avec la LED, un bouton refresh est disponible pour refaire un appel à la base de données. Pour la suite, il faudrait trouver un meilleur compromis entre l'attente de l'information et l'attente de l'utilisateur.
  • Par manque de temps et d'accès au FabLab, il n'a pas été possible de faire un socle qui pourrait s'insérer directement à la base d'un verre afin d'y placer notre système.
  • L'utilisation de la Raspberry comme serveur, et comme borne d'accès WiFi (de cette manière, les téléphones connectés au serveur ont accès aux données en LAN, donc impact énergétique et performances optimisées), mais pour la même raison que le précédent point, finaliser cette partie a été impossible par manque d'accès au matériel.