Thetweekproject - Historique des versions

Rex le 15 juin 2015 à 15:45

2015-06-15T15:45:21Z

Tvantroy : /* Matériel disponible */

2015-05-18T15:11:57Z

‎Matériel disponible

Rex : /* La programmation des différents éléments */

2015-05-12T20:26:16Z

‎La programmation des différents éléments

Jwasilew : /* La programmation des différents éléments */

2015-05-11T06:30:41Z

‎La programmation des différents éléments

Jwasilew : /* La programmation des différents éléments */

2015-05-11T06:29:58Z

‎La programmation des différents éléments

Jwasilew : /* Conclusion */

2015-05-11T06:09:19Z

‎Conclusion

Pletouse : /* Machine à café */ Corrections générales, compétion des éléments restants et ajout du lien de la vidéo de présentation

2015-05-10T21:33:32Z

‎Machine à café : Corrections générales, compétion des éléments restants et ajout du lien de la vidéo de présentation

Voir les modifications

Pletouse : /* Détermination du plan de régulation */ Recadrage de l'image

2015-05-10T20:34:37Z

‎Détermination du plan de régulation : Recadrage de l'image

Pletouse : /* Détermination du plan de régulation */ Ajout explications régulation + résultats

2015-05-10T20:29:24Z

‎Détermination du plan de régulation : Ajout explications régulation + résultats

Jwasilew : /* L'interface utilisateur finale */

2015-05-08T15:01:37Z

‎L'interface utilisateur finale

← Version précédente		Version du 15 juin 2015 à 15:45
Ligne 1 :		Ligne 1 :
		+	<include nopre noesc src="/home/pedago/pimasc/include/video-MachineCafe-iframe.html" />
		+	__TOC__
		+	<br style="clear: both;"/>
	=Machine à café=		=Machine à café=
	==Présentation du projet==		==Présentation du projet==

@@ Ligne 67 : / Ligne 67 : @@
 *Matériel électro-informatique
-**Arduino Uno [<span style="color: green;">fourni le 26/1/2015</span>]
+**Arduino Uno [<span style="color: green;">fourni le 26/1/2015</span>][<span style="color: green;">Récupéré le 18/05/2015</span>]
-**Arduino Léonardo [<span style="color: green;">fourni le 5/2/2015</span>]
+**Arduino Léonardo [<span style="color: green;">fourni le 5/2/2015</span>][<span style="color: green;">Récupéré le 18/05/2015</span>]
-**RaspberryPi [http://www.adafruit.com/products/998] [<span style="color: green;">fourni le 28/1/2015</span>]
+**RaspberryPi [http://www.adafruit.com/products/998] [<span style="color: green;">fourni le 28/1/2015</span>][<span style="color: green;">Récupéré le 18/05/2015</span>]
-**Carte SD 16G [<span style="color: green;">fournie le 29/1/2015</span>]
+**Carte SD 16G [<span style="color: green;">fournie le 29/1/2015</span>][<span style="color: green;">Récupéré le 18/05/2015</span>]
 **Capteur de température [http://fr.rs-online.com/web/p/capteurs-de-temperature-et-humidite/0264147/] [<span style="color: green;">fourni le 4/2/2015</span>]
 **Thermocouple [http://fr.rs-online.com/web/p/thermocouples/6212287/] [<span style="color: green;">fourni le 4/2/2015</span>]
-**Lecteur NFC [http://www.adafruit.com/product/364] [<span style="color: green;">fourni le 4/2/2015</span>]
+**Lecteur NFC [http://www.adafruit.com/product/364] [<span style="color: green;">fourni le 4/2/2015</span>][<span style="color: green;">Récupéré le 18/05/2015</span>]
-**Ecran tactile [http://www.gotronic.fr/art-afficheur-tactile-usb-2-8-dfr0275-21547.htm] [fourni le 18/03/2015]
+**Ecran tactile [http://www.gotronic.fr/art-afficheur-tactile-usb-2-8-dfr0275-21547.htm] [fourni le 18/03/2015][<span style="color: green;">Récupéré le 18/05/2015</span>]
 *Matériel électronique de puissance

@@ Ligne 394 : / Ligne 394 : @@
 ! GitLab
 |-
-! Shiled Arduino NFC
+! Shield Arduino NFC
 | [https://github.com/henyxia/tweekd_nfc]
 | [https://archives.plil.fr/henyxia/tweekd_nfc]

@@ Ligne 411 : / Ligne 411 : @@
 |-
 ! Utilitaire de conversion BMP vers RGB565
-| [https://github.com/henyxia/tweekd]
+| [https://github.com/henyxia/bmp2rgb565]
 | [https://archives.plil.fr/henyxia/bmp2rgb565]
 |-
 ! Utilitaire de conversion BMP vers MAP
-| [https://github.com/henyxia/tweekd]
+| [https://github.com/henyxia/bmp2map]
 | [https://archives.plil.fr/henyxia/bmp2map]
 |}

@@ Ligne 387 : / Ligne 387 : @@
 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 [http://www.github.com GitHub], et les liens vers les différents programmes sont les suivants
+Le code source du projet est disponible sur [http://www.github.com GitHub] et sur [https://archives.plil.fr/ le GitLab de PolytechLille], et les liens vers les différents programmes sont les suivants
 {| class="wikitable"
 |-
+!
-! Lien
+! GitHub
 |-
 ! Shiled Arduino NFC
 | [https://github.com/henyxia/tweekd_nfc]
 |-
 ! Shield Arduino de puissance
 | [https://github.com/henyxia/tweekd_hvc]
 |-
-! Interface en ligne de commande
+! Interface graphique intermédiaire
 | [https://github.com/henyxia/tweekd]
 |}
 ====Le Shield Arduino NFC====

@@ Ligne 441 : / Ligne 441 : @@
 Nous nous sommes donc penché sur l'utilisation de l'interface tactile de l'écran. C'est une lecture USB par interruption qui nous donne si l'écran est actuellement pressé, et si oui où la pression est effectuée. Donc, pour permettre au programme de comprendre quelle fonction appeler lors d'un appui sur l'écran, nous avons créé un autre format de fichier. Celui ci, aussi issu du BMP, est une liste de pixel en nuance de gris. Donc, chaque pixel est représenté par une valeur comprise entre 0 et 255. En fonction de la valeur, le programme principal appelle la fonction en conséquence. De façon analogue à la conversion de BMP et RGB565, nous avons créé un programme permettant de convertir les BMP en suite de bytes correspondant aux pixels. Ce programme ce trouve à [https://github.com/henyxia/bmp2map l'adresse suivante].
-==Conclusion==
+==Fin du projet==
 ===Vidéo de présentation===
 Nous pensons enregistrer la vidéo pendant les vacances à l'aide d'une caméra professionnelle.
 La vidéo du projet est disponible à [https://www.youtube.com/watch?v=GXPjxfLEy3o cette adresse].

@@ Ligne 305 : / Ligne 305 : @@
 '''Choix de la régulation :'''
 Ici ne possèdant pas de commande réglable, nous ne pouvons pas choisir une régulation continue de type PID ou prédicteur de Smith, car on commande le thermoblock via un relais. Une commande MLI n'est pas envisageable dans notre cas, à cause du faible "pouvoir de commutation" des contacteurs de puissance que nous avons récupéré. Une simple régulation Tout ou Rien type thermostat ne serait pas suffisante, car ceci engendrerait des dépassements et des oscillations fortes autour de la température de consigne compte tenu du rapport Temps caractéristique sur Temps de retard du système <math>\frac{\tau}{T_{r}} \approx 1,66</math>. Nous nous situons donc dans le cas "Régulation par Boucles multiples" d'après la méthode de Broïda.
 Dans notre cas d'utilisation, un algorithme par boucles multiples, basé sur des commandes Tout ou Rien, est possible et peut satisfaire au cahier des charges. En effet, la consigne ne change pas d'ordre de grandeur : il faudra toujours chauffer l'eau dans un intervalle compris entre 88°C et 92°C. On propose alors l'algorithme suivant :
@@ Ligne 316 : / Ligne 316 : @@
 Un avantage de la chauffe palier par palier permet d'attendre que la chaleur s'établisse uniformément dans le thermoblock. Ceci permet de limiter les problèmes d'inerties thermiques, y compris celui de notre capteur (sans mettre ces paliers d'attente, ce que l'on observerait en température ne serait pas nécessairement la température au coeur du thermoblock).
 '''Résultats de la régulation'''
-[[Fichier:Mode_Auto.png|400px|thumb|right|Evolution de la température du chauffe eau avec la régulation]]
+On constate sur le graphique à droite les 3 étapes de chauffe : les étapes 1 et 2 s'effectuant ici entre 0s et environ 80s puis l'étape de maintien après cette date. La température évolue ainsi de façon presque linéaire pendant les étapes 1 et 2, puis reste dans la plage 88°C-92°C.
-On constate sur le graphique à droite que les 3 étapes de chauffe : les étapes 1 et 2 s'effectuant ici entre 0s et environ 80s puis l'étape de maintien après cette date. La température évolue ainsi de façon presque linéaire pendant les étapes 1 et 2, puis reste dans la plage 88°C-92°C. A t=140s, la pompe est commandée dans cette exemple afin de pouvoir visualiser le maintien en température lorsque l'eau circule. On remarque donc que cette régulation valide les 2 premiers critères du cahier des charges (chauffer l'eau dans la plage et pas de dépassement de cette plage). Cependant, le temps de réponse avant de pouvoir élaborer un café est un peu plus long (environ 80s).
+On remarque donc que cette régulation valide les 2 premiers critères du cahier des charges (chauffer l'eau dans la plage et pas de dépassement de cette plage). Cependant, le temps de réponse avant de pouvoir élaborer un café est un peu plus long (environ 80s).
 ===Réalisation de la carte électronique===

@@ Ligne 307 : / Ligne 307 : @@
 Ici ne possèdant pas de commande réglable, nous ne pouvons pas choisir une régulation continue de type PID ou prédicteur de Smith, car on commande le thermoblock via un relais. Une commande MLI n'est pas envisageable dans notre cas, à cause du faible "pouvoir de commutation" des contacteurs de puissance que nous avons récupéré. Une simple régulation Tout ou Rien type thermostat ne serait pas suffisante, car ceci engendrerait des dépassements et des oscillations fortes autour de la température de consigne compte tenu du rapport Temps caractéristique sur Temps de retard du système <math>\frac{\tau}{T_{r}} \approx 1,66</math>. Nous nous situons donc dans le cas "Régulation par Boucles multiples" d'après la méthode de Broïda.
-Un algorithme basé sur des alimentations Tout ou Rien est suffisant ici. En effet, la consigne ne change pas d'ordre de grandeur : il faudra toujours chauffer l'eau dans un intervalle compris entre 88°C et 92°C. On propose alors l'algorithme suivant :
+[[Fichier:Grafcet_AutoHeat.JPG‎|400px|thumb|right|Grafcet illustrant le principe de l'algorithme de régulation de la température]]
-''insérer image grafcet''
+Dans notre cas d'utilisation, un algorithme par boucles multiples, basé sur des commandes Tout ou Rien, est possible et peut satisfaire au cahier des charges. En effet, la consigne ne change pas d'ordre de grandeur : il faudra toujours chauffer l'eau dans un intervalle compris entre 88°C et 92°C. On propose alors l'algorithme suivant :
 Principe :
-Avantage : chauffer palier par palier permet d'attendre que la chaleur s'établisse uniformément dans le thermoblock. Ceci permet de limiter très fortement le problème d'inertie thermique de notre capteur (sans mettre ces paliers d'attente, ce que l'on observerait en température ne serait pas nécessairement la température au coeur du thermoblock)
+Un avantage de la chauffe palier par palier permet d'attendre que la chaleur s'établisse uniformément dans le thermoblock. Ceci permet de limiter les problèmes d'inerties thermiques, y compris celui de notre capteur (sans mettre ces paliers d'attente, ce que l'on observerait en température ne serait pas nécessairement la température au coeur du thermoblock).
 ===Réalisation de la carte électronique===

@@ Ligne 424 : / Ligne 424 : @@
 Pour l'interface utilisateur finale, nous nous reposons sur un module d'affichage [http://www.robopeak.com/docs/doku.php?id=product-rpusbdisp 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.
-[[Fichier:RPUSBDisp1.jpg|200px|thumb|right|Premier BMP affiché avec succès sur l'écran]] 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.
+[[Fichier:RPUSBDisp1.jpg|200px|thumb|right|Premier BMP affiché avec succès sur l'écran]] 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 compressé 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.
 Après de longues recherches, nous nous sommes rendus compte qu'il n'était pas possible de réaliser une interface temps réel avec cet écran si l'on utilisait la librairie X11. En effet, celle ne communique pas assez rapidement avec l'écran (les recordes d'écriture étant de ~17 secondes par images avec X11). Le constructeur préconise en fait une utilisation à travers une interface USB. Cette interface, décrite dans ce [http://www.robopeak.com/data/doc/rpusbdisp/RPUD03-rpusbdisp_interface_protocol-enUS.1.0.pdf manuel] nous oblige à réécrire notre interface homme machine.
 ==Conclusion==
 ===Vidéo de présentation===
 Nous pensons enregistrer la vidéo pendant les vacances à l'aide d'une caméra professionnelle.