Thetweekproject

Machine à café

Présentation du projet

Cahier des charges

SA

• Broyage des grains déjà torréfiés
  • Régulation d’un moteur en vitesse avec charge variable
  • Réutilisation des éléments d’une cafetière existante (carte électronique hors d’usage)
    • Étalonnage du débitmètre
    • Analyse du chauffe-eau
    • Calibration de la pompe à eau
  • Propulsion de l’eau chauffée
    • Régulation d’une pompe à eau en pression et en débit
    • Régulation du chauffe-eau en température
  • Modélisation des éléments du système

SC

• Création d’une interface homme-machine
  • Installation d’un RaspberryPi avec un écran tactile
    • Gestion des stocks de café, d’eau et de gobelets
    • Gestion des différents éléments (pompe, compresseur, chauffe eau, …)
  • Réalisation d’une interface graphique permettant de :
• Moudre le café
• Sélectionner la quantité d’eau à distribuer (café court ou long)
• Sélectionner un café parmi une présélection de café
  • Création d’une application Web et Smartphone
    • Possibilité de noter son café
    • Possibilité de retenir un choix de café particulier
• Création de profils créés à partir de la carte étudiante
  • Lecture d’information en NFC sur la carte étudiante
  • Création d’une base de données basée sur ces profils
    • Proposition des cafés à partir de ceux les plus commandés et/ou mieux notés
    • Possibilité de retenir certains choix et de les recommander

Commun

• Création d’une carte permettant la commande des différents éléments de la machine à café (pompe, chauffe-eau, et d’autres sorties)
• Création d’une carte permettant de faire l’acquisition des différents capteurs (comme le débitmètre)

Liste des tâches

• Caractériser le débitmètre
• Caractériser le chauffe-eau
• Caractériser la pompe
• Détermination du schéma de fonctionnement et éventuels correctifs de régulation
• Réalisation de la carte électronique de commande
• Programmation de l'Arduino pour commander la carte
• Programmation du RaspberryPi pour l'interface tactile et la lecture NFC
  • Estimation temps de réponse (temps de transfert à l'Arduino négligeable ?)
• Gestion automatique du café
  • Dimensionnement capsule et du dispositif de broyage
  • Création d'un système dispenseur de gobelets
    • Design d'engrenages pour les gobelets
• Plus de fonctionnalités si temps restant
  • Recharge par le Net
  • Poison pour diabétique
  • Interface beaucoup travaillée
  • Packaging pratique

Matériel disponible

• Machine à café Nespresso défectueuse en morceaux [fournie en 2014]
  • Un débitmètre
  • Une pompe à eau
  • Un chauffe-eau
  • Tubes
  • Carte électronique (très sûrement défectueuse)
  • Mécanisme d'infusion de capsules de café
  • Réservoir d'eau avec valve anti-retour

• Matériel électro-informatique
  • Arduino Uno [fourni le 26/1/2015]
  • Arduino Léonardo [fourni le 5/2/2015]
  • RaspberryPi [1] [fourni le 28/1/2015]
  • Carte SD 16G [fournie le 29/1/2015]
  • Capteur de température [2] [fourni le 4/2/2015]
  • Thermocouple [3] [fourni le 4/2/2015]
  • Lecteur NFC [4] [fourni le 4/2/2015]
  • Ecran tactile [5] [fourni le 18/03/2015]

• Matériel électronique de puissance
  • Contacteurs de puissance (max 32A, 400V) (x2)
  • Coffrets d'isolation électrique (x2) (achetés le 09/02/2015)
  • Cables électriques (section 2,5 mm2) (achetés le 09/02/2015)
  • Boitier interrupteur (achetés le 09/02/2015)

Matériel manquant

• Broyeur de café [6]

Répartition du travail

Titre

	Lundi 14-16h	Mercredi 14-18h	Jeudi 10-12h
Semaine 5	26/01 - Organisation et répartition du projet	28/01 - Caractériser le débitmètre et gérer les pièces manquantes	29/01 - Caractériser le chauffe eau et la pompe
Semaine 6	02/02 - Détermination du schéma de fonctionnement et du plan de régulation	04/02 - Réalisation de la carte électronique	05/02 - Réalisation de la carte électronique
Semaine 7	09/02 - Réalisation de la carte électronique	11/02 - Réalisation de la carte électronique	12/02 - Réalisation de la carte électronique
Semaine 8	16/02 - Gestion automatique du café	18/02 - Gestion automatique du café	19/02 - Gestion automatique du café
Semaine 9	23/02 - Gestion automatique du café	25/02 - Gestion automatique du café	26/02 - Gestion automatique du café
Semaine 11	09/03 - Gestion automatique du café	11/03 - Gestion automatique du café	12/03 - Gestion automatique du café
Semaine 12	16/03 - Gestion automatique du café	18/03 - Gestion automatique du café	19/03 - Gestion automatique du café
Semaine 13	23/03 - Gestion automatique du café	25/03 - Gestion automatique du café	26/03 - Gestion automatique du café
Semaine 14	30/03 - Gestion automatique du café	01/04 - Gestion automatique du café	02/04 - Gestion automatique du café
Semaine 15	Férié	08/04 - Gestion automatique du café	09/04 - Gestion automatique du café
Semaine 16	13/04 - Gestion automatique du café	15/04 - Gestion automatique du café	16/04 - Gestion automatique du café
Semaine 17	20/04 - Gestion automatique du café	22/04 - Gestion automatique du café	23/04 - Gestion automatique du café

En somme, les prévisions pour les différentes parties sont de:

• 8 H pour la prise en main du matériel actuel
• 14 H pour la réalisation de la carte électronique de commande
• 70 H pour la gestion automatique du café

Etude préalable

Caractérisation du débitmètre

Lors de la première séance "pratique", nous avons étudié le comportement du débitmètre.

Après recherches, nous avons appris qu'il en existe deux types. Le premier type est assimilable à une résistance variable dont la valeur dépend du débit. Le deuxième type se comporte comme un type tout ou rien qui effectue un contact entre deux des pins lorsque l'ailette interne fait un tour. Le débit est donc déduit par la fréquence des impulsions que délivre le débitmètre.

Notre débitmètre est un composant crée par Digmesa, dont la fiche constructeur est disponible ici. Il s'agit d'un débitmètre à turbine, du deuxième type.

Le montage à droite permet de récupérer les impulsions du débitmètre sous forme TTL.

Schéma du montage permettant de récupérer les impulsions du débitmètre

Le volume d'eau mesuré s'exprime alors sous cette forme : $V = n * \frac{1}{Kdeb}$ avec n le nombre d'impulsions, V le volume en L et Kdeb la constante fournie dans la doc constructeur Kdeb = 1925 impulsions/L.

Le débit n'est pas une grandeur mesurée directement avec notre débitmètre, mais elle est déduite en choisissant un temps $\Delta t$ suffisamment court pour considérer le débit "instantané". L'expression du débit "pseudo-instantané" est alors la suivante : $\frac{\Delta V}{\Delta t} = \frac{1}{Kdeb} * \frac{\Delta n}{\Delta t}$ avec $\Delta n$ la variation du nombre d'impulsion pendant le $\Delta t$.

Obtenir le débit est ici utile car, d'après les informations collectées, le temps d'extraction du café doit être contrôlé (entre 20s à 25s) et le café doit être de 5cl pour un ristretto et de 12cl pour un lungo.

Il est important de noter aussi que ce capteur a une influence sur la pression : en effet, il peut induire une perte de pression (au maximum) de 0,43 bar.

Réalisation interface commande - puissance

Afin de pouvoir séparer circuit de commande et alimentation de puissance, nous utiliserons un optocoupleur et des contacteurs pour l'alimentation de la pompe et du chauffe-eau (tout deux alimentés en 230V alternatif 50 Hz). L'optocoupleur est utilisé afin de bénéficier d'une isolation galvanique entre les deux parties, pour plus de sécurité.

La commande d'alimentation est envoyée par l'Arduino à l'optocoupleur. L'optocoupleur commande alors le contacteur (relais de puissance), ce qui alimente l'élément choisi.

L'optocoupleur utilisé est sous forme de circuit "prêt à utiliser" (ET-OPTO AC-OUT 4 dont la fiche constructeur est disponible ici) qui dispose de quatre optocoupleurs isolés. Nous en utiliserons un pour commander la pompe (OCT0) et un deuxième pour commander le chauffe-eau (OCT1). L'objectif d'une des séances a été d'établir ce dispositif d'alimentation, de comprendre le fonctionnement de l'optocoupleur dont nous disposons et de mapper les optocoupleurs aux sorties de l'Arduino.

Par la suite, nous avons été contraint de changer de type de commande. En effet, la carte d'octocoupleurs permettait la commande mais n'était pas capable de couper le contacteur. Cela est du au principe même du fonctionnement du contacteur. En effet,le contacteur est composé d'une bobine (entre A1 et A2) qui vient attirer un bloc aimanté de façon à créer un contact entre les six broches de puissance (connecteurs 1 à 6). Le problème était que cette bobine demandait un courant trop important que l'octocoupleur gérait mal en rendant impossible la coupure de la bobine.

Pour palier à ce problème, nous avons choisi d'utiliser une carte de commande d'octocoupleurs commandant des relais (ET-OPTO RELAY4, dont la fiche constructeur est disponible ici). Après vérification à l'aide de la documentation technique des relais, nous avons constaté que ceux-ci sont bien capable de couper la commande des contacteurs.

Fabrication d'un Shield Arduino

Nous avons donc été amené à créer un shield Arduino avec une carte de prototypage rapide qui réalise les fonctions suivantes :

• intégrer un connecteur 10 broches compatible pour :
  • relier la sortie digitale IO 2 à l'optocoupleur OCT0 qui commandera l'alimentation de la Pompe
  • relier la sortie digitale IO 3 à l'optocoupleur OCT1 qui commandera l'alimentation du Chauffe eau
• intégrer le circuit de récupération des impulsions du débitmètre TTL et échantillonner ce signal sur l'entrée digitale IO8
• disposer d'une fonction "Boutons Arrêt d'urgence" pour la pompe et le chauffe eau.

Le principe de fonctionnement des "Arrets d'urgence" est le suivant :

Caractérisation de la pompe

La pompe récupérée est un composant fabriqué par Invensys, dont la fiche constructeur est disponible à cette adresse. Il s'agit d'une pompe à piston qui permet de délivrer une pression allant jusqu'à 19 bar au maximum. Cette pression est fonction du débit en sortie de la pompe, selon la caractéristique à droite.

Caractéristique Pression/Débit de la pompe

Elle se commande en "tout ou rien" et est alimentée en 230 V alternatif 50Hz. Le paramètre permettant de fixer le point de fonctionnement sur le graphique précédent est la section du tuyau en sortie. Nous n'avons pas la main sur ce paramètre étant donné que nous possédons déjà le système de tuyaux avec les embouts adaptés (section à mesurer : S = ? mm²). En revanche, nous la commanderons en décidant du temps d'allumage. Il s'agit maintenant de déterminer à quels moments et combien de temps il faut alimenter la pompe, sachant qu'il faut que l'extraction dure entre 20s et 25s et que le chauffe eau induit un retard à déterminer.

Séance pratique :

Lors d'une séance de manipulation de la pompe, nous l'avons commandé au moyen de l'Arduino pendant plusieurs durées pré-établies (2s, 5s et 10s) afin de déterminer si elle possède un régime transitoire négligeable. Nous avons ensuite relevé le volume d'eau qu'elle avait délivré grâce à une éprouvette graduée. Plusieurs séries de mesures ont été effectuées à chaque fois. Lors de cette manip, le tuyau de sortie n'était pas connecté au chauffe-eau afin que la mesure ne soit pas influencée, il donnait directement dans l'éprouvette. Cette manipulation nous a également permis de tester notre débitmètre et notre manière d'échantillonner le signal qu'il nous fournit, en comparant le volume déduit par celui ci et le volume réel relevé avec l'éprouvette. (insérer photos et résultats sous forme tabloïdale ici)

Ainsi, nous avons déterminé que quelque soit le temps d'allumage (pour une durée supérieure à 2s), la pompe fournit un débit constant de 5,2 mL/s = 0,312 cc/min.

Étalonnage du capteur de température du chauffe-eau

Afin de réguler le chauffe eau en température, nous avons besoin de connaître le fonctionnement du capteur de température intégré sur celui ci. Il s'agit en fait d'une thermistance (résistance variable dont la valeur de la résistance dépend de la température), ici à coefficient de température négatif (CTN).

Il n'y a visiblement pas de référence constructeur dessus. Nous avons donc décidé d'effectuer un étalonnage de celle ci. Il existe un dispositif en salle électronique comportant des capteurs de températures déjà étalonnés disposés sur une plaque qui peut être chauffée par un chauffage électrique. Nous avons "collé" avec de la pâte thermique notre thermistance sur cette plaque et effectué un relevé de la résistance en fonction de la température indiquée par les capteurs déjà présents. Le problème est que le chauffage ne pouvait pas être régulé, il continue de chauffer tant qu'on l'alimente. N'ayant donc pas de valeur de température stabilisée, à cause de l'inertie thermique, les valeurs de résistances relevées sont complètement non significatives. Cette manipulation aura tout de même soulevé un point à prendre en compte : le capteur de température étant en métal, il faudra déterminer l'inertie qu'il induit dans la mesure et si celle ci est négligeable, sinon, comment faire avec.

Le soucis pour une approximation linéaire est que la plage de température est trop importante. En effet, la température de l'eau pour le café doit être entre 88°C et 90°C, mais on doit aussi pouvoir utiliser le capteur à une température de 65°C pour prévoir un mode "économie d'énergie", lorsque la machine n'est pas utilisée pendant 10min par exemple. Après recherches, la loi d'évolution de la résistance en fonction de la température est de la forme : ${1 \over {T}} = A + B \ln(R_{Th}) + C (\ln(R_{Th}))^3 \,$

Autre idée : simplement l'étalonner la thermistance au moyen d'un bain d'eau que l'on peut chauffer et d'une sonde de température précise.

Après relevé de l'évolution de la résistance en fonction de la température au moyen du bain marie, nous avons constaté et vérifié que notre sonde de température se comporte comme une sonde standardisée PT100. Nous avons trouvé une fiche constructeur de ces sondes standardisées qui vérifie les caractéristiques de notre capteur (lien). Sur la plage de température que nous avons besoin d'utiliser (25°C - 105°C), nous pouvons négliger le terme en ln^3, ainsi l'équation régissant la résistance en fonction de la température peut s'exprimer ainsi : ${R_{Th}}={R_0} \times\exp\left(\beta\times\left({1 \over {T}} - {1 \over {T_0}}\right)\right) \,$ avec ${R_0}$ = 100 kOhm la résistance de référence à $T_0$= 25°C, $\beta$ = 4334 Kelvin le coefficient fourni par le constructeur pour l'approximation sur la plage 25°C-100°C.

Ainsi, la représentation des données pour récupérer la température est la suivante : au moyen d'un pont diviseur (insérer image), nous récupérons une tension sur l'Arduino image de la résistance et donc de la température avec la relation ci-dessus. Nous ne pouvons pas inclure dans le code directement un calcul avec la fonction exponentielle, cela prendrait , entre autres, trop de temps de calcul et ne serait pas optimisé étant donné que l'on connait la résolution du CAN de l'Arduino. Pour cela, nous passons par un tableau de conversion sur 256 valeurs calculé au moyen de cette feuille de calcul. Voici un schéma de principe :

Coté Arduino : Tension aux bornes de Rth(V) ---CAN---> Valeur sur 10 bits ---TableauDeConversion---> Valeur sur 8 bits

La Raspberry (ou le PC) récupère ensuite cette valeur sur 8 bits et en déduit la température avec la connaissance du "pas" entre 2 températures : $Pas = {(105-25)\over 255}$

Coté Raspberry : Valeur sur 8 bits --->  25 + (Valeur * Pas)  ---> Température en °C

Cette méthode permet d'alléger le temps de traitement sur l'Arduino et surtout de ne pas perdre en précision et résolution à cause de la transmission de l'information "température", qui s'effectue sur 8 bits.

Déroulement du projet

La programmation des différents éléments

Pour la partie programmation, le défi résidait dans le fait de faire communiquer tout les éléments à l'aide d'un seul programme. Pour cela, nous avons subdivisé les fonctions principales dans différents modules. Ceci nous permettait entre autre de minimiser le nombre d'éléments reliés à la partie "puissance" du projet (détaillé plus loin)

Le code source du projet est disponible sur GitHub, et les liens vers les différents programmes sont les suivants

	Lien
Shiled Arduino NFC	[7]
Shield Arduino de puissance	[8]
Interface en ligne de commande	[9]
Interface graphique finale	En attente du matériel

Le Shield Arduino NFC

L'objectif de l'utilisation du Shield NFC est de permettre à un utilisateur de payer un café, et donc de s'identifier sur la machine, à l'aide de carte Lille 1. Pour cela, nous nous sommes premièrement orientés sur l'utilisation de l'IDE Arduino et de la librairie dédiée au PN532. Puis, nous avons décidé de passer à un langage C pour avoir une meilleure visibilité sur les registres. Par conséquent, nous avons utilisé le compilateur avr-g++ pour compiler le projet. Il nous a donc était nécessaire de transposer une partie des fichiers C et C++ pour les rendre utilisables avec notre programme C.

La communication se fait par système de questions-réponses. Le serveur sur la Raspberry envoie une demande de données, et l'Arduino répond en conséquence. La seule difficulté a résidé dans la problématique des données à envoyer pour l'identification. Les cartes de Lille 1 sont des cartes NFC Mifare Classic 1K. Elles sont composées de 16 secteurs de 4 fois 16 bytes. Le secteur qui nous intéresse est le douzième secteur, qui est encodé en utilisant les clés NFC publiques (donc accessible par tout le monde). Les clés publiques en question sont :

	Clé
A	A0A1A2A3A4A5
B	B0B1B2B3B4B5

Ce douzième secteur contient, pour les carte étudiantes, l'INE, suivi du numéro étudiant (sur 8 chiffres), suivi du prénom, suivi d'un point puis du nom. Nous avons d'abord envisagé d'utiliser le nom et le prénom, cependant cela posait le problème des personnes avec le même patronymes. De plus, il arrivait que le nom de l'étudiant soit tronqué pour rester dans l'espace alloué au secteur 12. Par conséquent, nous utilisons le numéro d'étudiant, qui est toujours au même endroit sur le secteur. Le logiciel compare alors ce numéro à une liste d'étudiant.

Par soucis de sécurité, nous n'avons pas de liste donnant une correspondance directe entre un numéro d'étudiant et son nom. En effet, la liste utilisée est un enchaînement de nom et de numéro étudiant encodé avec l'algorithme MD5. Pour récupérer le nom, il nous suffit alors de comparer le numéro étudiant que nous récupérons (que nous encodons en MD5) avec la liste. Ceci nous assure une confidentialité relative, dépendante directement de la robustesse de la non réversibilité du MD5.

Une fois la reconnaissance des cartes étudiantes terminées, nous avons essayé de d'inclure les cartes Lille 1 dédiées au personnel. La première question que nous nous sommes posée est comment pouvons nous faire la différence, au niveau du lecteur, entre une carte étudiante et une carte du personnel. Nous avons remarqué que les cartes du personnel comporte, sur leur douzième secteur, deux fois le numéro de personnel (sur 6 chiffres). La répétition du numéro de personnel se situe à l'endroit où se situe le nom de l'étudiant sur la carte de l'étudiant. Le test est donc assez facile à réaliser. L'autre problème est : comment lié un numéro de personnel à un nom ? Nous n'avons pas encore résolu ce problème car cette table de liaison n'est pas accessible à PolytechLille. Éventuellement, si nous arrivons à accomplir tous les objectifs du projet, nous envisagerons de contacter les responsables de Lille 1 pour obtenir cette table de correspondance.

L'interface utilisateur finale

Pour l'interface utilisateur finale, nous nous reposons sur un module d'affichage RPUSBDisp de la société RoboPeak. Avant de se lancer dans la phase de programmation de l'interface, il nous a d'abord fallut rendre utilisable l'écran par le RaspberryPi. Pour cela, il a fallut créer un module chargeable par le noyau Linux. Une fois ce module créé, nous nous sommes rendu compte le noyau Linux que nous utilisions (celui fournis avec Raspbian) ne contenait pas les symboles nécessaires au chargement du module. Nous avons alors recompilé le noyau Linux avec les symboles manquants. La compilation s'est avérée assez compliquée car pour éviter de faire de la cross compilation (ce qui aurait surement augmenter le taux d'échec de compilation) nous avons compilé le noyau directement à partir de la RaspberryPi ce qui, malgré son overclooking, était très long (une compilation prenait approximativement une nuit complète). Après quatre tentatives, nous avons réussi à obtenir un noyau fonctionnel.

Une fois l'écran utilisable, nous nous sommes lancés dans le développement de l'interface. Nous avons choisi, dans une optique de performance, de n'utiliser que la librairie X11. Le premier objectif était de réussir à afficher une image sur l'écran. Le format d'image utilisé était le BMP car il n'est pas compréssé et peut être lu sans autres calculs. Après de petits cafouillages (liés au fait que le BMP représente une couleur de 0 à 255 et X11 de 0 à 65535) nous avons réussi à faire afficher notre première image. Cependant, le point négatif est que l'image est affichée en une trentaine de secondes. Nous sommes donc en train de travailler sur un moyen de faire afficher des images plus rapidement.