Réflecteur solaire automatisé

Projet réflecteur solaire automatisé

 

LUCAS Miguel                        KIEFFER Maxime                      NESTELHUT Alexandre

 

 

SOMMAIRE

 

     I.Préparation

              Contexte et principe

              Choix des techniques et du matériel

              Montage du réflecteur

              Recherche des coordonnées solaires

 

     II.Création du support

            Pied et rotation

             Cadre et pivotement

             Montage final (à compléter)

 

     III.Programmation

             Branchements et configuration

             Tests des servomoteurs avec des valeurs données

             Amélioration à l’aide de la carte SD

             Modifications complémentaires

 

     IV.Conclusion et remerciements

 

 

 I.Préparation

 

 1.Contexte et principe

Dans le cadre d’étude et réalisation du troisième semestre du DUT GEII (Génie Électrique et Informatique Industrielle), un projet nous a été confié par notre professeur référent, M. OULD ABDESLAM Djafar, consistant à étudier la mise en place d’un réflecteur solaire et ainsi dans un deuxième temps le réaliser dans le but de faire converger les rayons du soleil vers un point donné (par exemple une maison pour pouvoir chauffer celle-ci) d’une manière autonome.Ce type de réflecteur n’étant pas commercialisé en France, la conception et la programmation se créera de toutes pièces par notre groupe, et pourra aboutir à une présentation pour des entreprises intéressées et ainsi effectuer une potentielle mise sur le marché.

 

 

 

 

Ce réflecteur est composé d’une base solide afin de maintenir la structure stable en cas d’intempéries ou de temps indésirable. Sur celui-ci seront situés un servomoteur et un moteur pas à pas contrôlés par une carte Arduino permettant d’effectuer les rotations nécessaires, à savoir une horizontalement et l’autre verticalement pour que le miroir fixé à la structure puisse se mouvoir dans plusieurs positions et angles possible nécessaires à réflexion des rayons du soleil, ceux-ci devant incider sur un point précis, en l’occurrence ici les fenêtres du bâtiment afin de le chauffer ou d’améliorer sa luminosité de manière écologique.

 

 

2.Choix des techniques et du matériel

 

Nous avons utilisé un moteur pas à pas pour sa rotation continue permettant de faire plusieurs tours pour descendre et remonter le panneau, et inversement le servomoteur qui reste bloqué à son dernier angle lorsque l’on coupe l’alimentation pour pouvoir tourner et rester dans l’orientation voulue.

 

Nous avons utilisé une carte Arduino Uno étant donné que cette dernière est pratique dû à sa simplicité de fonctionnement et sa faible consommation. Pour alimenter le servomoteur ainsi que la carte Arduino, nous avons choisis un adaptateur USB 4 ports étant donné que la puissance délivrée par l’Arduino n’est pas suffisante pour le servomoteur. Une alimentation externe plus puissante est prévue pour le moteur pas à pas.

 

 

3.Montage du réflecteur solaire

 

 

Lors du montage, nous avons constaté que la fixation de base du panneau risquait de subir les aléas de la météo et ainsi fragiliser le réflecteur. Pour régler ce souci, nous avons eu l’idée de renforcer la structure avec des plaques reliées aux coins supérieurs et ainsi de remplacer l’ancien support.

 

 

 

4.Recherches pour les coordonnées solaires

 

Afin de réaliser notre projet, nous avons dû faire des recherches concernant les positions et trajectoires du soleil pour calculer les angles de rotation des servomoteurs, un par rapport au Zénith du Soleil et un par rapport à l’Azimut.

 

Azimut et Zénith (ici hauteur) :

 

 

 

Pour cela, nous avons utilisé de nombreux sites afin de nous renseigner au maximum tels que http://www.solartopo.com ou encore www.sunearthtools.com que nous allons utiliser pour récupérer les données.

 

Au préalable, nous avons calculé la hauteur (Zénith) grâce à une formule trouvée sur le site www.buzzcasonits.blogspot.com pour vérifier que les valeurs soient cohérentes.

 

 

Le meilleur moyen d’avoir les données étant de les récupérer directement sur le site web, nous avons téléchargé le fichier csv pour l’année 2019.

 

 

Par la suite nous avons testé nos hypothèses en vrai, grâce à notre réflecteur et à un Fluke Thermal Imager, muni d’un laser.

 

 

II. Création du support

 

1.Pied et rotation

 

Pour créer le support, nous avons récupéré un bon nombre de pièces. Tout d’abord, pour la base nous avons utilisé un tube rectangulaire muni d’un pied. Nous avons alors mesuré les dimensions du servomoteur puis découper le haut du support aux bonnes dimensions. Pour soutenir le servomoteur, la partie découpée a été pliée. Pour finaliser cette partie nous avons limé les bords afin d’éviter les rayures.

 

 

Ensuite nous avons tracé le schéma pour les parties supérieures du support. Nous avons découpé le tout dans du bois (medium). Ce système sera composé de 2 disques en bois, l’un posé sur l’autre grâce à des billes en verre calées dans un rainure afin d’éviter de mettre tout le poids de la partie supérieure sur le servomoteur

 

 

Après avoir tracé le schéma sur papier nous avons fait une modélisation 3D grâce au logiciel de CAO FreeCAD (logiciel libre totalement gratuit) dans le but de les réaliser grâce à la fraiseuse CNC 3 axes à l’IUTlab ; voici les figures représenter en 3D dans le logiciel :

 

 

 

Malheureusement nous n’avons pas pu réaliser les cylindres à la fraiseuse 3 axes ; nous les avons donc faits « à la main » : pour créer le cylindre ainsi que la gouttière nous avons utilisé la fraiseuse manuelle, pour les parties qui durent être creusée nous avons dégrossi le travail grâce à la perceuse à colonne puis affiné aux ciseaux à bois. Voici le résultat :

 

 

 

 

Pour pouvoir fixer le tout nous avons vissé (temporairement pour avoir un pied stable) une plaque bien plus grande en bois (medium de 5 cm d’épaisseur). Le tout monté donne ce résultat :

 

 

2.Cadre et pivotement

 

Une fois les deux cylindres fixés sur le pied nous sommes passés au second axe qui lui est en deux parties : le support du miroir et l’entraînement du servomoteur :

 

– le support en miroir est entouré d’un cadre en aluminium qui fait le pourtour du miroir, lui étant coincé entre une barre en bois et le cadre justement pour éviter de devoir le percer

 

 

 

-l’entrainement est fait par le servomoteur qui agit sur deux barres reliées entre elles et au miroir, mais le servomoteur manquant de puissance pour soulever le miroir nous allons devoir améliorer ce mécanisme.

 

 

3.Montage final

 

Après de multiples tests, nous avons constaté que le moteur n’était pas assez puissant pour pouvoir faire remonter le panneau. C’est pourquoi nous avons changé notre deuxième axe en utilisant une tige filetée avec un moteur pas à pas.

Contrairement au servomoteur, le moteur pas à pas va fonctionner en nombre de tours et va faire tourner la tige filetée ce qui va provoquer l’inclinaison du miroir.

 

 

Après avoir modifié cet axe, nous avons assemblé les deux parties entre elles grâce à trois vis et deux tiges filetés avec écrous.

 

 

 

III.Programmation

 

1.Branchements du système

 

A savoir : l’Arduino est alimentée grâce au port Vin connecté à l’un des servomoteurs directement branché sur le secteur

 

Configuration carte Arduino Uno

2.Test des servomoteurs avec des valeurs données

 

3.Amélioration à l’aide de la carte SD

 

Une fois que les moteurs tournent nous devons cette fois-ci obtenir les valeurs à leur envoyer à partir d’un fichier texte. Pour ce faire nous avons choisi l’option d’utiliser une carte SD car l’accès à celle-ci est plus simple que si nous devions accéder à la mémoire de l’Arduino. Nous avons donc commandé une extension SD pour notre carte Arduino UNO et branché soigneusement sur celle-ci.

4.Modifications complémentaires

 

 

Suite à l’avancement du projet, nous avons remarqués que notre programme initial ne convenait plus à nos besoins. Nous avons fait des modifications : une par rapport à la récupération de données et l’autre par rapport à une modification faite dans le montage.

 

– Modification pour la récupération de données sur un an : Dans ce cas , nous avons remplacé le fichier sur la carte SD par un fichier ayant les valeurs pour toute l’année, puis nous avons modifié le programme car la lecture sur un an n’est pas pareil que celle sur un jour.

 

 

-Modification pour le fonctionnement du moteur pas à pas

 

Dans ce cas, nous avons remplacé notre servomoteur par un moteur pas à pas donc nous avons changé la formule pour ce dernier. Pour cela nous calculons le nombre de pas de que le moteur doit faire pour obtenir le nombre de tours, ce qui diminuera ou augmentera la distance entre le moteur et le bout de la tige filetée et donc incliner le panneau d’un certain angle

 

 

 

IV.Conclusion et remerciements

 

Nous voulons tout d’abord remercier Mr OULD ABDESLAM Djafar de nous avoir guidé et aidé tout au long du projet. Nous voulons aussi remercier Mr DE SABBATA pour nous avoir donné de nombreux conseils et aussi pour nous avoir autorisé à utiliser l’IUT Lab pour nos besoins. Nous aimerions également remercier Mr WIRA pour son aide concernant la gestion de la carte SD et la lecture du fichier.

Pour conclure, ce projet a été pour nous une expérience importante pour notre cursus car nous avons pu travailler en groupe tout au long de l’année. Nous avons appris à nous partager les tâches, à faire des compromis entre nous pour pouvoir satisfaire au mieux les besoins du projet. De plus cette expérience fut d’autant plus enrichissante car nous avions un projet concret avec une réalisation à la clé qui s’est concrétisée.

Nous pouvons également ajouter à ce projet divers points d’amélioration, que ce soit remplacer les pièces en bois par de l’aluminium pour augmenter sa robustesse, un anémomètre permettant de coucher le panneau en cas de vent fort détecté, une cale pour éviter le redressement quelque peu brusque du retour en position initiale du panneau. Un capteur serait également à prévoir sous le miroir pour l’éviter de descendre trop loin et causer des dégâts.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Mallette qualité de l’énergie

Quentin JACQUEY

Anas BOUHSSINE

Emre TEKIN

Mise en œuvre d’un module WAGO

Rapport de Projet

Introduction

 

Dans le cadre de notre DUT GEII, il nous fallait réaliser un projet pendant notre troisième semestre. Ce projet reposait sur un automate programmable WAGO, celui-ci nous permettrait de réaliser des mesures et une récupération des données de consommations électriques d’une installation.

Nous avons alors dû programmer une interface graphique pour faciliter la prise en main de l’utilisateur.

Finalement, la récupération et affichage des données de l’automate se feront au travers d’un Janitza, un appareil de mesure couplé au WAGO.

 

Afin de mener à bien ce projet, nous avions à notre disposition une mallette, composée de l’automate auquel nous avons ajouté un appareil, tenant le rôle de transformateur 230/24 V afin d’alimenter l’automate. Nous avons également utilisé un Janitza, dont le rôle sera détaillé plus loin.

Sommaire

A. Objectifs

B. Ressources

  1. Avancement

  2. Installation

  3. Mesures

  4. Banque de données

  5. Reprise de toutes les étapes

C. Reprise de la banque de données

D. Difficultés rencontrées

E. Conclusion

F. Annexes

 

A. Objectif

Notre projet WAGO permet de mesurer et analyser une ou plusieurs installations électriques, ce qui permet à l’utilisateur de contrôler ou optimiser sa consommation électrique.

Nous avons comme projet également de transférer les données vers l’automate depuis un Janitza, afin de créer une banque de données qui va permettre de récupérer et stocker les données instantanées dans l’automate venant du Janitza.

B. Ressources

 

Pour notre projet, nous avions à disposition :

  • Automate WAGO (Référence 6028-2186)(Centrale Fastlogger 3G)

  • Module 750-494 Module de mesure

  • Module 750-495 Module de mesure

  • Module 750-600 Module d’extrémité

  • 3 sondes de courants 60V/1A
  • 4 boucles de Rogowski

 

 

 

Nous avons intégré un transformateur 230/24V qui est utilisé comme alimentation.

Nous utilisons comme câbles un câble d’ordinateur recyclé et dénudé. Nous branchons ce câble à la prise de la mallette.

Nous avons également utilisé plusieurs logiciels :

 

  • WAGO Ethernet settings

  • WAGO-IO Check

 

  • Fastlogger

Nous avions envisagé d’utiliser le logiciel Codesys et éventuellement un Raspberry PI afin de créer une base de données où stocker les données.

Nous avons finalement opté pour la solution du Janitza.

Le Janitza est un appareil de mesure  que nous avons utilisé afin de projeter les données récoltées par le Janitza vers notre automate.  Son installation et branchement sont détaillés ci-dessous.

 

C. Avancement

Le schéma ci-dessous démontre le but de notre projet et les différentes étapes de notre projet.

 

Notre projet ce sépare en plusieurs étapes :

  1. L’installation
  2. Les mesures
  3. Programmation envoi des données
  4. Reprise des étapes

Le contenu de chacune de ces étapes ainsi que l’avancement actuel sont développées ci-dessous.

 

1.L’installation

Nous avons dû, en premier lieu, nous approprier le matériel à disposition, et comprendre le fonctionnement de celui-ci en lisant les documentations techniques.

Les branchements de l’automate ont été préalablement effectués, il nous fallait cependant connecter l’automate à une alimentation. Là où les étudiants de l’année précédente avaient utilisé un transformateur externe, nous avons opté pour un transformateur interne à la mallette.  Pour cela, nous avons utilisé un transformateur 230/24V fourni par le professeur. Il nous fallait donc intégrer le transformateur dans la mallette qui nous était fourni. Pour cela, nous avons utilisé un câble d’ordinateur que nous avons dénudé afin de servir de câble d’alimentation reliant la prise de la mallette au transformateur.

Après avoir testé le bon fonctionnement du transformateur et de l’automate, il nous fallait maintenant s’occuper de l’adresse IP de l’automate.

Une adresse nous avait été fournie : 10.95.11.33, préalablement configuré grâce à WAGO Ethernet Settings cette adresse correspond à l’adresse de l’automate dans le réseau UHA.  Pour tester la concordance de l’adresse, nous avons configuré un ordinateur portable sur le même sous-réseau que l’automate à l’adresse : 10.95.11.32.

Après vérification, l’automate a la bonne adresse.

Nous avons également installé FASTLOGGER dans l’automate grâce aux étapes décrites en Annexe 1.

 

2.Mesures

Une fois l’automate correctement configuré, nous avons effectué des mesures grâces à des lampes halogènes.

Nous avons utilisé IO-CHECK pour voir les mesures.

Pour mesurer, nous avons utilisé les sondes de courants sur une seule phase.

Voici les mesures obtenues :

D’abord, avec les lampes à mi-puissance :

Puis avec les lampes à leur puissance maximale:

Grâce à ces mesures, nous nous sommes assurés du bon fonctionnement et du logiciel, et de l’automate.

En effet, nous constatons qu’à leur puissance maximale, les lampes produisent des harmoniques plus importantes et plus nombreuses, ce qui démontre le bon fonctionnement des mesures de notre automate.

 

 

3.Banque de Donnée

 

Pour créer une banque de données, nous envisagions d’utiliser CODESYS ainsi qu’un Raspberry PI. Cependant, nous avons  eu des problèmes vis-à-vis des logiciels. Nous possédions CODESYS 2.3, mais les automates WAGO ne sont pas reconnus comme des cibles du logiciel. Pour résoudre ce problème, nous avons communiqué avec Mr. MARTIN, qui travaille chez WAGO. Mr. MARTIN a répondu à notre demande et nous a donné accès au logiciel avec la référence de notre automate.

Nous avons trouvé la référence correspondante du logiciel qui allait avec notre automate. Nous pouvions désormais nous consacrer à la programmation de la banque de données. Quant au Raspberry PI, nous avions décidé d’abandonner l’idée de l’utiliser. En effet, le logiciel qui nous permettrait d’utiliser le Raspberry PI était payant.  De plus, CODESYS remplissait déjà toutes les fonctions nécessaires à notre projet.

Nous avions besoin d’accéder à la fonction ‘‘root’’ du logiciel Putty afin de pouvoir modifier, supprimer ou ajouter des fonctions dans l’automate. Pour y accéder, il nous fallait un identifiant et un mot de passe, malheureusement aucun des deux ne nous a été donné par les anciens étudiants en charge de ce projet. Nous étions donc obligés de reboot l’automate et refaire alors toutes les étapes décrites précédemment.

 

4.Reprise de étapes

 

Après avoir fait un « reset » de l’automate grâce à ces  étapes (Annexe 2), nous avons perdu toutes les données que contenait l’automate. Nous voulions donc reprendre toutes les étapes. Malheureusement l’adresse IP initiale qui nous a été donnée est fausse. Nous avions donc activement recherché l’adresse IP actuelle de l’automate. Nous avons trouvé comment faire (Annexe 2). L’adresse IP de l’automate est donc désormais 192.168.1.17.

Nous avons également reset les identifiants et mot de passe pour le site Web-Base Management, ce que l’on recherchait. Nous avons défini les mots de passe tel quels:

Identifiant :                  1.user                           2.admin

Mot de passe :            1.wago                         2.user

Nous avions donc dû refaire toutes les étapes précédentes, une fois l’adresse IP de l’automate reconfiguré sur 10.95.11.33.

 

Après que notre automate ait été reconfiguré correctement, nous pouvions reprendre la programmation de la banque de données grâce à Codesys.

Nous avions pour cela configuré le logiciel pour qu’il reconnaisse l’adresse de l’automate.

 

Afin de compiler et charger le programme dans l’automate, nous avions besoin d’un mot de passe qui était :

Mot de passe : user

Ainsi, nous avons réussi à transférer le programme dans l’automate, nous pouvions alors récupérer les données de la consommation électrique des installations.

Le résultat est montré ci-dessous.

Après de nombreux tests, nous avions compris qu’il nous fallait utiliser Fastlogger après avoir discuté au téléphone avec notre contact WAGO.

 

Après avoir eu accès aux pleins pouvoirs sur l’automate grâce à Putty (Annexe 3), nous avons pu accéder à Fastlogger, que nous avions installé précédemment. Ce logiciel nous permet d’accéder directement aux données récoltées dans l’automate.

 

Le logiciel Fastlogger se présente sous cette forme :

 

Après avoir vu un aperçu de ce que donnait la récolte des données.

Fastlogger va nous permettre d’archiver ces données sur un fichier .csv contenu dans la carte mémoire.

Nous allons alors transférer ces données archivées et récoltées sur un serveur FTP donné par l’IUT.

Malheureusement, le serveur FTP était inutilisable, en effet,  la complexité du réseau empêchait d’établir une liaison avec notre automate. Nous avons donc dû abandonner l’idée du serveur.

Nous devions également nous servir d’un module de mesure, le Janitza 96 RM-E. Il s’agit d’un équivalent du Wago que nous utilisons comme centre de mesure. Pour cela, nous avons connecté le Janitza avec l’automate en Modbus TCP/IP afin de récupérer les valeurs mesurées par le Janitza. Le Wago sert alors de centre de collecte des données du Janitza que l’on enregistre sous CSV grâce à un adressage spécifique.  (ANNEXE 4)

 

D. Difficulté rencontré

 

Lors de notre projet, nous avons rencontré certaines difficultés. En effet, la première difficulté fut de trouver le logiciel adapté pour nous permettre de coder notre banque de données. Après avoir trouvé Codesys, la difficulté a été de nous le procurer. La version WAGO n’étant pas disponible sur leur site, nous avons envoyé des mails à notre contact MR. Martin, il nous a envoyé un lien pour le télécharger mais qui ne contenait pas la référence de notre automate. Il nous a alors fallu attendre qu’il nous renvoie le lien contenant le logiciel avec notre référence.

  • Nous avons rencontré des difficultés afin de transférer le programme depuis le logiciel vers l’automate. Nous avons donc essayé plusieurs méthodes. D’abord avec un câble ETHERNET, cela ne marchait pas. Nous avons alors essayé avec un câble RS232, cela ne marchait pas non plus. Enfin nous avons branché l’automate sur le réseau, et nous avons pu nous connecter à lui depuis le logiciel grâce à son adresse IP.
  • Le problème majeur que nous avons rencontré a été l’accès au noyau de l’automate Wago. En effet l’installation du fastlogger doit se faire dans le noyau par le logiciel « Putty ». Ce logiciel comporte 3 utilisateurs. Le premier ne servant à rien est « User » utiliser pour voir les fichiers installé dans le noyau. Le second est « admin » qui peut être utilisé pour accéder au noyau et y transférer certains fichiers. Enfin il y a le super admin « root » qui donne libre accès à toute manipulation du noyau. C’est celui-ci qui était la cause du problème car le mot de passe défaut a été modifier.

La solution est donc de réinstaller le firmware du wago (Annexe 5…) et d’utiliser le mot de passe par défaut.

  • Nous avons eu également l’idée d’utiliser un serveur FTP afin d’y stocker les données. Malheureusement, la connexion de l’automate avec le serveur était impossible, dû à la complexité du réseau UHA (sécurité).
  • Nous avons donc dû utiliser un Janitza 96 Rm-E. La complexité de son utilisation ainsi que celle de la connexion avec notre automate nous a apporté des difficultés sur la compréhension de ceux-ci. Grâce à des recherches fructueuses, nous avons compris son utilisation et nous avons donc pu utiliser le Janitza tel que nous en avions besoin.

 

E. Conclusion

 

Si on devait résumer notre projet, nous pourrions dire que nous avons apporté :

  • Un transformateur interne, afin d’alimenter de manière autonome l’automate
  • Modification des mots de passe des différents logiciels que nous avons dû réinitialiser
  • Installation du Fastlogger dans l’automate, ainsi que son codage et son utilisation
  • Après de nombreux problèmes, l’utilisation du Janitza comme module de mesure et utilisation de notre Wago comme centre de collecte de ces données

Cependant, nous sommes conscients que notre projet aurait pu être amélioré :

En effet, si l’utilisation du serveur FTP, la récolte des données aurait pu être plus ludique et attractive.

Nous aurions pu également créer une interface graphique pour mieux représenter les données récoltées à partir du Janitza.

 

F. Annexes

 

Annexe 1 : Installer FASTLOGGER

  • Copier-coller le fichier .ipk dans le dossier tmp du FTP du contrôleur
  • Ouvrir une connexion SSH sur le contrôleur grâce à Putty [se connecter avec les identifiants suivant : root (utilisateur) et wago (mot de passe)]
  • Sous Putty, ouvrir le dossier tmp (grâce à la commande « cd /tmp »).
    Il faut respecter l’espace entre le ‘d’ et le ‘/’
  • Lancer la commande d’installation :« ipkg install install-fastlogger_1.2.10_arm.ipk ».

Il faut respecter tous les espaces et bien renseigner le nom du fichier y compris l’extension. FASTLOGGER se lance donc.

Annexe 2 : Reset et trouver l’adresse IP

Reset :

  • Appui sur Bouton « RST » pendant 8 secondes, jusqu’à ce que la led « SYS » clignote en orange.
  • Mettre le Switch en mode « Reset ».
  • Attendre 3 secondes le temps que la Led « Sys » soit rouge.

Trouver adresse IP :

  • Mettre le Switch en mode « STOP »
  • Appui sur Bouton « RST » pendant 8 secondes, jusqu’à ce que la led « SYS » clignote en orange
  • L’adresse IP de l’automate est alors : 192.168.1.17

Source : Data sheet 750-8207

 

Annexe 3 : Avoir les pleins droits sur l’automate

 

Sur Putty, rentrer les informations telles quelle :

Un message d’information va s’afficher, cliquer sur « Oui ».

Une boite de dialogue va alors s’afficher :

S’identifier en tant que « root », le mot de passe correspondant est : « user ».

Vous aurez dès lors un accès total sur l’automate, c’est-à-dire que vous pourrez avoir accès aux programmes installés sur l’automate, les modifier, en supprimer, ou en créer.

 

Annexe 4 : Configuration Janitza

 

Configuration de l’adresse IP du Janitza :

Appuyer pendant 5 secondes sur la touche 1 et 2 du janitza pour entrer dans le mode de paramétrage du janitza.

La navigation dans le menu est possible grâce à la touche sur laquelle se trouve une flèche vers la droite et la validation la touche vers le haut.

En navigant dans ce menu, on peut changer l’adresse IP du Janitza dans la sous-section addr où l’adressage ce fait en 4 étapes.

Suite à cela on rentre cette adresse dans la case dédié dans le fastlogger dans l’onglet configuration modbus TCP/IP

Dans l’onglet requête, on ajoute l’adressage spécifique à la valeur que l’on veut.

Dans l’onglet donné on peut visualiser les données et aussi archiver les valeurs que l’on souhaite.

Attention à l’ état !!

Etat 150: Sans réponse

Etat 129: Problème Communication

Etat 0: En fonctionnement

Visualisation des données avec possibilité d’archivage.

 

Attention à l’adressage ! L’adressage fournit dans le noyau du wago est incorrecte et il faut ajouter un par un les adressages de registre que l’on souhaite récupérer retrouvable dans la datasheets du Janitza.

Annexe 5 : Réinstallation Firmware

1.Télécharger ce fichier

http://www.wago.com/public-download/Support/FW/0750-8xxx/WAGO_FW_0750-8xxx_I.ZIP

2.3.4.

5. Insérer la carte SD dans le PFC200 ou la microSD dans le PFC100, puis le redémarrer électriquement. Le lecteur de cartes SD ou microSD clignote orange pendant plusieurs secondes. L’image du noyau est automatiquement chargée dans la mémoire RAM.

Après la séquence d’initialisation, les LEDS SYS et I/O sont vertes fixes. La LED RUN est rouge fixe, le lecteur de cartes SD ne clignote plus.

A ce stade, l’image du noyau est simplement présente en mémoire RAM, il est nécessaire de la copier sur la mémoire Flash interne.

6. Une fois tous cela fait connecter vous à Web-Based Management.

7. Retirer la carte SD ou microSD, puis redémarrer le PFC. Le PFC a été mis à jour. Retourner sur le Web-Based Management afin de vérifier la version du firmware.

8.La carte SD n’est pas utilisable en stockage. Il faut donc la formater.

 

 


Supervision Efficacité Energétique

HEGE Simon

MINERY Loïc

Rapport Efficace Energie

Projet 2018/2019

 

 

 


Sommaire

  1. Remerciements

  2. Introduction

  3. Cahier des Charges

    1. Bêtes à corne
    2. Diagramme pieuvre
    3. Partage des tâches
    4. Schéma de fonctionnement
    5. Environnement logiciel
    6. Environnement matériel
    7. Capteurs utilisés
    8. Comparaison capteurs
      1. Première partie
      2. Deuxième partie
  4. Recensement capteurs

    1. Création d’une interface VBA sur Excel
  5. Logiciel EfficaceEnergie

    1. Prise en main
    2. Création plan IUT
    3. Enregistrement nouveaux capteurs
    4. Compte admin et utilisateur
    5. Analyse de résultats
  6. Conclusion

  7. Annexes

    1. Captures d’écrans Comparaison
    2. Novembre
    3. Septembre
    4. Octobre

Remerciements

Nous tenons à remercier notre professeur référent, M. Ould qui nous a proposé ce projet et nous a guidé tout au long de ses semaines de recherches et de supervision. Nous souhaitons également remercier M.Marco SANGWA qui nous a permis d’utiliser son rapport de stage.

Introduction

Le but principal de ce projet était d’analyser les données de capteurs de la société Distrame afin d’avoir une meilleure efficacité énergétique au sein de l’IUT de Mulhouse. Notre projet Efficacenergie a donc consister en l’installation de capteurs dans l’établissement, puis en leur enregistrement dans le logiciel Efficacenergie afin de relever leurs courbes de consommation ou leurs courbes de température. Nous avons recenser les capteurs existants et nous avons analyser les données des capteurs déjà installés. Nous avons également utilisé le rapport de stage de M. Marco SANGWA, étudiant de l’année passée, qui nous as permis de comprendre le fonctionnement des différents logiciels afin d’installer les capteurs plus facilement et plus rapidement.


Cahier des Charges

Bêtes à corne

 

Diagramme pieuvre

Contraintes majeurs

  • Plan interactif : Le plan devait être clair et intuitif afin de pouvoir effectuer le suivi de la consommation pour chaque capteur.
  • Déclaration des capteurs : Chaque capteur devait être déclaré sur le logiciel wavenet, on lui a attribué ensuite un répéteur si cela était nécessaire.
  • Cohérence des valeurs : Trouver l’origine d’un décalage de ± 9 % entre les relevés des capteurs Distrame et UHA.

Contraintes mineurs

  • Esthétique : L’interface doit être esthétique dans la mesure du possible.
  • Fiabilité : L’interface doit fonctionner correctement ainsi que la déclaration des capteurs dans l’architecture.
  • Simplicité : Elle doit être simple d’utilisation.
  • Sécurité : Mise en place de comptes utilisateur et administrateur.

Partage des tâches

MINERY Loïc :

  • Création plan IUT interactif avec courbes et mesures pour chaque capteur de chaque bâtiment.
  • Comparaison capteurs UHA et Distrame
  • Recensement des capteurs
  • Installation des nouveaux capteurs
  • Powerpoint

HEGE Simon :

  • Création de l’interface pour le recensement des capteurs
  • Recensement des capteurs
  • Comparaison capteurs UHA et Distrame
  • Installation des nouveaux capteurs
  • Rapport

Schéma de fonctionnement

Environnement logiciel

  • Interface Distrame Efficacenergie
  • Logiciel Wavenet monitor
  • Logiciel Diris Digiware

Environnement matériel

  • Capteurs
  • Ordinateurs

Capteurs utilisés

Comparaison capteurs

Première partie

Notre enseignant référent, M. OULD nous a demandé de comparer sur plusieurs mois les valeurs de consommation électriques mesurées par les capteurs de la société DISTRAME et ceux de l’UHA. Nous avons utilisé le logiciel EfficaceEnergie ainsi que le logiciel Diris Digiware de l’UHA, auquel nous avons eu accès grâce au compte utilisateur de M. OULD. Nous avons ainsi comparé les données des capteurs installés dans différents bâtiments.

 

Tableau de la consommation des bâtiments selon le mois
Tableau de la consommation des bâtiments par semaines

 

Nous avons alors remarqué que les capteurs UHA ont toujours des valeurs plus élevées que ceux de DISTRAME sauf au mois de Juillet (valeurs en rouges) où nous constatons que les capteurs UHA du bâtiment A et Générale sont plus élevées que ceux de Distrame.

Nous avons calculé les pourcentages de différences entre les capteurs et il semble qu’en générale, sur trois mois, la différence soit d’environ 9 %.

Conclusion première partie

Nous avons remarqué une différence d’environ 9 % entre les capteurs des deux sociétés. Nous avons alors contacté, par mail et téléphone, M. LALLEMANT, un agent de DISTRAME, pour lui demander s’il avait une explication à cette différence entre les capteurs. Il ne pouvait malheureusement pas nous répondre. Nous avons ensuite contacté par téléphone M. SCHMIDT qui nous a redirigé vers le support de Distrame. Un agent nous a demandé les références de nos capteurs ainsi que celles des compteurs. Il souhaitait aussi connaitre les valeurs de nos boucles de courants, mais nous n’y avons pas accès seul.  Nous lui avons envoyé toutes les informations par mail par deux fois, sans réponse de sa part.


Deuxième partie

Notre enseignant référent nous a demandé, dans un second temps, de comparer les valeurs de consommation électriques des capteurs DISTRAME et UHA mais cette fois sur une période de 6 mois. Ainsi , nous avons comparé les données du mois de juillet 2018 au mois de décembre de la même année afin de vérifier si la différence de 9 % persistait sur une longue période.

Rapport de consommation sur la période juillet-décembre 2018

Consommation bâtiment A

 

La valeur du capteur Distrame de consommation du bâtiment A est plus élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous obtenons un point de pourcentage de 3.94%.

Nous observons un pic de consommation à environ 200 kWh pour le capteur UHA, à la date du 10 décembre 2018, qui n’est pas présent sur le relevé du capteur Distrame.

Consommation bâtiment B

 

La valeur du capteur Distrame de consommation du bâtiment B est plus élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous obtenons un point de pourcentage de 3.59%, ce qui est assez proche de la valeur obtenue pour le bâtiment A.

A la date du 10 décembre 2018, nous observons à nouveau un pic de consommation à environ 440 kWh pour le capteur UHA, qui n’est pas présent sur le relevé du capteur Distrame.

Consommation bâtiment C

 

La valeur du capteur Distrame de consommation du bâtiment C est plus élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous obtenons un point de pourcentage de 2.52%.

 

Nous observons encore un pic de consommation à environ 700 kWh pour le capteur UHA, à la date du 10 décembre 2018, qui n’est pas présent sur le relevé du capteur Distrame. Les relevés sont cohérents.

Consommation bâtiment E

 

La valeur du capteur Distrame de consommation du bâtiment E est plus élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous obtenons un point de pourcentage de 1.99%, ce qui est beaucoup moins élevé que les valeurs obtenues pour les bâtiments A et B.

 

A la date du 10 décembre 2018, nous observons de nouveau un pic de consommation à environ 760 kWh pour le capteur UHA, qui n’est pas présent sur le relevé du capteur Distrame. Les relevés sont cohérents.

Consommation bâtiments DFGH

 

La valeur du capteur Distrame de consommation des bâtiments D, F, G et H est cette fois-ci moins élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous obtenons donc un point de pourcentage négatif de -2.04%.

A la date du 10 décembre 2018, nous observons un pic de consommation à environ 1300 kWh pour le capteur UHA qui n’est pas présent sur le relevé du capteur Distrame.

Consommation logements de fonctions

 

La valeur du capteur Distrame de consommation des logements de fonctions est plus élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous obtenons un point de pourcentage de 1.14%, ce qui qui représente l’écart le plus faible entre les capteurs de l’UHA et ceux de Distrame.

On n’observe pas de pic de consommation au 10 décembre, les deux graphiques semblent équivalents.

Consommation générale de l’IUT

 

La valeur du capteur Distrame de consommation générale est plus élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous observons un plus grand écart avec un point de pourcentage de 4.74%.

On observe un pic de consommation le 10 décembre 2018 pour environ 3500 kWh.

 

Nous avons remarqué une différence entre les valeurs générales mesurées par les capteurs et celles obtenues en additionnant les valeurs obtenues précédemment. Ainsi, la valeur mesurée par le capteur UHA est plus petite que celle obtenue par la somme alors que la valeur mesurée par le capteur Distrame est plus élevé. Les valeurs obtenues par la somme sont plus cohérentes car plus rapprochées l’une de l’autre.

Conclusion deuxième partie

Nous avons remarqué que les relevés des capteurs UHA et Distrame sont cohérents entre eux. Les valeurs des capteurs Distrame sont généralement plus élevées que celles des capteurs UHA sauf pour les bâtiments D-F-G-H.

Nous avons également remarqué un pic de consommation au 10 décembre 2018, uniquement présent sur les relevés des capteurs UHA. Ce pic n’est pas présent sur le relevé de la consommation des logements de fonctions ni sur les relevés des capteurs Distrame. Il s’est donc produit quelque chose au niveau des capteurs UHA ce jour-là.

Enfin, la moyenne de la différence des pourcentages entre les valeurs obtenues sur 6 mois par les capteurs UHA et Distrame est de 1.99%, en comptant le pourcentage négatif des bâtiments D-F-G-H. On remarque donc que la différence de 9% sur une semaine diminue à 2 % sur 6 mois ce qui est une très bonne chose. Les différents capteurs ne donnent donc pas des valeurs trop différentes.


Recensement capteurs

Tout d’abord, nous avons recensé tous les capteurs non-installés physiquement, car il y en avait des nouveaux et des anciens, puis nous avons vérifiés lesquels étaient déjà enregistrés dans EfficacEnergie. Nous en avons également profité pour vérifier les noms de tous les capteurs sur le logiciel et repérer les doublons, les capteurs obsolètes ou bien tout simplement les capteurs mal déclarés.

Ainsi, nous avons comptés 14 capteurs-émetteurs et 5 répéteurs non-installés physiquement. Sur ces 14 capteurs, 10 sont des capteurs waveflows, 3 sont des nouveaux capteurs et 1 seul est un capteur wavesense. Sur les 3 nouveaux capteurs, nous avons 2 capteurs wavetherms et 1 capteur LEM.

Nous avons également recensé 5 répéteurs dont 2 sont des wavetalks.

Certains capteurs non-installés physiquement étaient déjà enregistrés sur le logiciel EfficacEnergie, nous n’aurons donc pas besoin de les enregistrer mais juste les installer sur un compteur. Ils étaient enregistrés sous le collecteur Ethernet qu’il faudra changer pour le collecteur Webdyn. C’était le cas des WFL3 à 9.

Ensuite, nous avons recensés les capteurs physiquement installés dans l’enceinte de l’IUT. Certains capteurs étaient enregistrés sous le collecteur Ethernet dans le logiciel EfficacEnergie, ils ne donnaient donc aucun relevé sur le logiciel. Ainsi le capteur WFL de la salle B010 n’envoyait aucun résultat depuis avril, date à laquelle il a été mis sur le mauvais collecteur. Afin de les faire fonctionner, nous les avons enregistrés sous le collecteur Webdyn qui reçoit toutes les données et les envois au serveur.

Mise en place du capteur sur le collecteur webdyn

Nous avons aussi remarqué que certain capteur enregistré ne correspondait en réalité à aucun capteur réel, il faudra donc les supprimer.

Capteurs ne relevant aucunes données car n’existant pas physiquement

D’autres capteurs étaient utilisés en double sous deux noms différents, nous allons donc en supprimer un des deux.

Capteurs existants en double

Création d’une interface VBA sur Excel

Cette interface permet de rechercher rapidement l’adresse radio, la localisation ainsi que le type de capteur associés au nom d’un capteur ou répéteur. Elle permet également d’ajouter à tout moment un capteur ou un répéteur en plus.

Tableau Excel recensant les capteurs + Interface

Logiciel EfficaceEnergie

Prise en main

Pour débuter, nous avons créé un fichier à notre nom, dans lequel nous avons créé tous les graphiques et tableau. Afin d’obtenir ces fameux graphiques, nous nous sommes aidés du rapport de projet de l’année dernière ainsi que de l’aide présente sur le logiciel.  Nous avons ainsi créé notre premier graphique.

 

Paramétrages permettant la création d’un graphique
Comparaison de la consommation entre les bâtiments de l’IUT (RGB) et la courbe de consommation générale (Noir)

 

Nous remarquons sur ce graphique que la consommation générale n’est pas l’addition de toutes les consommations mais plutôt leur moyenne.

Après la création d’un graphique nous avons voulu créer un tableau.

Graphique et tableau montrant la consommation du bâtiment B sur une journée (Les graphiques barres ont été remplacés par des graphiques linéaires depuis)

Création plan IUT

Après avoir pris en main le site EfficacEnergie, nous avons été capable de créer une carte de l’IUT avec la position des capteurs et ce qu’ils mesurent. Pour cela, nous nous sommes aidés  du rapport de projet de l’année dernière dans lequel toutes les positions des capteurs étaient précisées. Après vérification, certains capteurs avaient malheureusement été changés de place comme le capteur de température WTH salle B016 qui à été déplacé dans l’amphithéâtre nord et que nous avons donc renommé. Nous avons également nous-mêmes rajouté certains capteurs, comme le capteur de température de la cave A ou bien encore celui du bureau de M.Ould.

Plan interactif de l’IUT

Chaque capteur est ainsi représenté par un point avec son nom sur lequel on peut cliquer afin d’avoir le détail de ses mesures. S’il s’agit d’un capteur de température, il est représenté par un point rouge tandis qu’un capteur de consommation est lui représenté par un point vert. Lorsqu’il s’agit de la consommation de plusieurs bâtiments, le capteur est représenté par une maison.

Détail des mesures du capteur de température du bâtiment A

Enregistrement nouveaux capteurs

Le cahier des charges du projet impliquait d’installer de nouveaux capteurs aussi bien physiquement que sur le logiciel. Ainsi, nous avons installé deux capteurs de température Wavethermes que nous avons appelés respectivement WTH15 et WTH16. Le capteur-transmetteur WTH15 a été installé dans le bureau de M. Ould tandis que le WTH16 à lui été installé dans la cave du bâtiment A par un technicien de l’IUT. Avant de les installer physiquement, nous les avons d’abord configurés dans le logiciel wavenet monitor, permettant de vérifier qu’ils fonctionnent correctement et de créer l’architecture réseau.

Ajout d’un capteur à l’aide de son adresse radio
Capteur assigné par défaut. Mauvaise architecture.
Capteur assigné au waveport. Bonne architecture.
Test du signal du capteur concluant

Puis nous avons rentrés les capteurs dans le logiciel Efficaceenergie grâce à leurs codes. Nous avons ensuite pu effectuer toute sortes de tests comme le test RSSI, qui permet de vérifier le pourcentage de signal qui arrive au collecteur, le test de batteries, qui permet de voir le pourcentage de batteries restantes dans chaque capteurs et transmetteurs, ainsi qu’un test de rapatriement, qui permet d’enregistrer la valeur que le capteur lit à l’instant présent.

Activation du collecteur WebdynRF obligatoire pour ajouter des capteurs

 

Ajout du capteur avec sa période d’échantillonnage

 

Test signal du capteur

 

Test du niveau de batterie

 

Test des valeurs rapatriées depuis le capteur

Compte admin et utilisateur

Nous avons créé un compte admin dans lequel nous pouvons ajouter des capteurs et créer des tableaux et courbes. Le compte utilisateur ne permet pas de créer de courbes mais uniquement de visualiser les relevés dont l’admin a donné les droits de visualisation. Nous ne pouvons malheureusement pas créer de compte où l’on pourrait créer des graphiques mais ne pas avoir accès aux configurations.

Fichiers et paramètres auxquels l’admin à accès

Seul le fichier avec le plan et le paramètre de déconnexion sont accessibles au compte utilisateur

Analyse de résultats

Le capteur WFL salle B010 donnait des courbes inadéquates. En effet, les courbes étaient sous formes de pulsions complètement irréalistes pour une valeur de consommation. Nous avons vérifier son branchement au compteur et cela ne changeant rien, nous avons décidé de l’enlever car il ne servait à rien.

Consommation en janvier 2019
Consommation en avril 2018

Le capteur de température de la cave A marche correctement et on remarque que la température reste bien constante à 16 degrés Celsius.

Température de la cave par jour durant une semaine

Le capteur de température du bureau de M. Ould marche lui aussi correctement et on remarque que la température baisse jusqu’à 18 degrés Celsius le week-end, notamment le dimanche. En effet, l’IUT pour baisser sa consommation ne chauffe pas les salles le week-end. Le dimanche 3 mars, la température dans le bureau reste à 20 degrés Celsius car il y avait les portes ouvertes ce week-end là.

Température du bureau de M.Ould tous les jours sur un mois

Conclusion

Notre projet abouti permet la visualisation et l’analyse des données des capteurs de la société Distrame afin d’avoir une meilleure efficacité énergétique au sein de l’IUT de Mulhouse. La surveillance de la consommation par les intervenants de l’IUT sera aussi plus efficace et rapide grâce à la carte interactive. Cette carte devrait être mise sur grand écran au sein même de l’IUT afin que le public puisse y accéder à tous moment grâce au compte utilisateur. La justesse des données pourrait être améliorée si l’on découvre d’où vient la légère différence entre les capteurs UHA et Distrame. Notre projet a également permis la surveillance de la température de la cave A afin que la bière du projet micro-brasserie automatisée soit toujours à bonne température. Il permettrait également la surveillance de la production énergétique du projet Centrale d’autoconsommation solaire.


Annexes

Septembre

Relevé du capteur de consommation Distrame du bâtiment A
Relevé du capteur de consommation UHA du bâtiment A

Octobre

 

Novembre

 

 

 


Micro-Brasserie solaire automatisée

Sommaire:

Remerciement

Introduction

  1. La passionnante histoire de la bière
    1. Chronologie de la bière
    2. Fabrication
  2. Réalisation des bières de GEII
    1. Première bière: apprentissage de brassage
    2. Deuxième Bière: consommation d’énergie
  3. Automatisation
    1. liste du matériel nécessaire
    2. Motorisation du moulin
    3. motorisation du malaxeur
    4. Asservissement de température
  4. Amélioration possible
  5. Conclusion

Remerciements:

Ce projet n’aurait pu être réalisé sans l’aide d’une multitude de personnes que nous tenons à remercier ici. Parmi elles :

– M. Ould-Abdeslam pour la proposition et le suivi complet de ce projet ainsi que pour les commandes de matériel,

– les techniciens de l’IUT qui nous ont permis d’automatiser le moulin à l’aide d’une simple pièce qui nous manquait,

– M. De Sabatta pour sa patience et ses nombreux conseils,

– M. Hiebel, du lycée Charles de Gaulle à PULVERSHEIM, section “chaudronnerie”, pour la tôle en inox qui nous manquait afin de réaliser notre malaxeur.

Nous tenons également à remercier M. Drouaz qui nous a apporté des conseils pour la fabrication de la bière et qui était présent à chacun de nos brassages ainsi que pour les stérilisations du matériel, ainsi que toutes les personnes qui se sont démenées pour nous trouver des bouteilles de bières refermables ou qui peuvent être encapsulées.

Pour finir, nous remercions l’IUT qui nous a donné le financement pour aboutir et surtout commencer ce magnifique projet.  

Introduction:

Nous sommes deux étudiantes de deuxième année en GEII: Toussaint Raphaëlle et Dusausay Laura.

Dans le cadre de notre scolarité, nous avons choisi, dans notre projet, de créer une microbrasserie, dont l’automatisation exploite l’énergie solaire.

Mais dans un premier temps, laissez-nous vous faire découvrir cet art ancestral à travers son histoire, sa fabrication ainsi que son automatisation.

1.La passionnante histoire de la bière :

    1. Chronologie de la bière

Le principe de la bière est de réaliser une fermentation de céréales. La première a vu le jour à Jericho (à côté de Jérusalem)  en 12 000 avant J.C.

Celui-ci s’est développé partout dans le monde en faisant évoluer sa recette de siècle en siècle.

En 4 000 av JC, en Egypte, la bière était une boisson divine. Plus tard elle gagnera l’Europe en devenant une boisson remplie de vertus médicinales. En 1435 ce sont les prêtres qui ont l’exclusivité de la fabrication de ce breuvage. Puis durant l’ère industrielle Pasteur va faire la découverte de la levure ce qui va révolutionner le mode de préparation. Finalement ce n’est qu’en 1950 que la bière va commencer à être industrialisée.

    1.2 Fabrication

1.2.1 Matières premières

Eau Il faut 6L à 8L pour 1L de bière
malt Orge germé et caramélisé, froment, ou seigle
houblon Pour l’amertume, l’arôme, aseptisation, digestibilité
levure Pour la fermentation alcoolique

Tab 1: Les matières premières de la bière

1.2.2 Les 5 grandes étapes

maltage Le malt crée les enzymes nécessaires à la  création d’alcool lors de la fermentation (déjà fait lors de la commande du malt)
Le brassage On hydrate et chauffe le malt permettant l’activation des enzymes ainsi que l’obtention des sucres
cuisson du moût On filtre la fermentation. Le liquide qui en ressort est chauffé à plusieurs températures avec du houblon et d’autres épices. Cette étape permet de donner du goût à la bière
fermentation Cela désigne la réaction chimique qui transforme le sucre en alcool. L’ajout de levure permet de gérer ce procédé.Celui-ci est fait en 2 temps de repos avec des températures différentes.
la garde Procédé de la gazéification

  Tab 2: Explication des procédés de fabrication

2.Réalisation des bières de GEII

    2.1 Première Bière: apprentissage de brassage

Pour notre projet nous avons commandé une microbrasserie afin de l’automatiser. Mais avant toute chose il fallait que l’on se familiarise avec les différents procédés pour connaître les étapes essentielles à automatiser.

Nous voilà donc parties dans la création de notre Première bière.

2.1.1 Matériel et matières premières

Pour 20L de bière:

Kit Brewferm; Une balance; Un minuteur; Récipient pour le malt concassé; Rallonge électrique; Cotons tiges pour stériliser le robinet des cuves

4,4 kg de malt du kit Brewferm; Houblon du kit Brewferm; Eau (suffisamment pour les différentes phases de cuisson et le refroidissement); Sucre Candy du kit Brewferm; Levure du kit Brewferm

2.1.2 Recette de fabrication

Pour commencer, moudre le malt à l’aide du moulin.

Faire chauffer 20 L d’eau jusqu’à atteindre 52°C. Puis ajouter le malt. Après 15 minutes de cuisson, augmenter la température à 62°C puis attendre 45 minutes. Augmenter la température jusqu’à 72°C puis laisser cuire 15 minutes. Enfin, augmenter la température jusqu’à 78°C et attendre 5 minutes. La phase d’empâtage est terminée, on peut passer à la filtration.

Mettre le contenu de la cuve dans une cuve de filtration puis récupérer le liquide sortant du robinet qu’on remet à nouveau dans la cuve de filtration jusqu’à ce que le liquide devienne plus clair.

Vider le contenu de la cuve par le robinet dans la cuve chauffante jusqu’à atteindre 24 L. Pour cela, ajouter de l’eau à la température de 75°C dans la cuve de filtration et patienter. Une fois la valeur de 24L atteinte, faire chauffer jusqu’à atteindre l’ébullition. Une fois le mélange porté à ébullition mettre la chaussette contenant le houblon et patienter pendant 80 minutes.

Commencer à stériliser le refroidisseur, la cuillère ainsi que la cuve de fermentation.

ATTENTION : une fois stérilisé, il ne faut plus mettre ce matériel en contact avec autre chose que la future bière.

A la fin des 80 minutes de cuisson, enlever la chaussette et passer à la phase de refroidissement.

Brancher un tuyau entre le robinet de la cuve chauffante et le refroidisseur, un tuyau entre le refroidisseur et la cuve de fermentation, brancher un tuyau entre le refroidisseur et le robinet d’eau froide et le dernier tuyau entre le refroidisseur et l’évier dans lequel ressortira l’eau qui sera chaude. Activer l’eau froide avec un gros flux puis ouvrir le robinet de la cuve chauffante pour libérer la bière. Attendre que le processus soit terminé.

Pour terminer, ajouter la levure dans de l’eau suivant les indications de la levure. Ajouter cette levure dans la bière et mélanger sans faire de bulle.

Enfin fermer la cuve de fermentation et ajouter le barboteur, dans celui-ci, mettre un peu d’eau.

ATTENTION : l’eau ne doit pas entrer en contact avec la bière.

Mettre la cuve de fermentation dans une salle à 20°C pendant 2 semainesAprès 2 semaines de fermentation, mettre la cuve dans une salle/cave à 15°C pendant 2 semaines.

Stériliser les bouteilles qui vont contenir la bière 48h avant la mise en bouteille à l’aide de chemipro dilué dans de l’eau. Le jour de la mise en bouteille, faire fondre avec de l’eau 7g/L de sucre puis l’ajouter dans la cuve de fermentation (après avoir stérilisé la cuillère).

Stériliser le robinet de la cuve de fermentation. Mettre les bouteilles stérilisées 10 minutes dans de l’eau bouillante puis mettre la bière dans les bouteilles. Stériliser les capsules et capsuler les bouteilles.

Laisser la bière minimum 2 semaines en bouteilles à température ambiante avant dégustation.

 

2.2 Deuxième Bière : consommation d’énergie

Début juin 2018 l’IUT de Mulhouse a investi dans 2 panneaux solaires. Ils peuvent produire jusqu’à 2,2 kWh.

Fonctionnement d’un panneau solaire:

Un panneau solaire est constitué de cellules dites photovoltaïque. Une cellule est constituée de 2 couches de silicium dopées respectivement P et N. Initialement, cette jonction PN est électriquement neutre. Un photon d’énergie suffisante va créer un trou par arrachement d’un l’électron. Par l’agitation des électrons voisins, ce trou va être comblé en piégeant un électron. À l’échelle de la cellule, le comportement est équivalent à une force électromotrice. Si la jonction est insérée dans un circuit fermé, un courant va circuler. Pour augmenter la puissance disponible, il faut placer plusieurs cellules pour former un panneau solaire. La tension est continue. L’énergie peut alors être stockée dans une batterie, qui joue le rôle de récepteur quand elle se charge, puis de générateur lorsqu’elle débite vers un utilisateur. Si l’utilisateur exploite une tension sinusoïdale, il faut alors intercaler un onduleur.

Lors de l’installation il faut veiller qu’aucun objet faisant de l’ombre soit à proximité du panneau. En effet contre toute attente, lorsqu’une cellule est ombragée, c’est la totalité du panneau qui cesse de produire.  Ainsi, à l’IUT, un arbre cache une partie du panneau et fait perdre 30% de la production.

Lors de la première bière nous n’avons pas pu mesurer la consommation d’énergie dont nous avons besoin lors de la fabrication. C’est lors de la fabrication d’une seconde bière, dont la recette est en annexes 2 et 3, que nous avons mesuré la consommation d’énergie nécessaire. Toute les données de production des panneaux solaire de l’IUT sont envoyées sur la plateforme.

Ainsi nous avons pu voir notre consommation d’énergie.

Lors de la fabrication de cette bière, nous avons mesuré la consommation électrique de tout le processus en utilisant les batteries (stock maximal de 4,8 kWh). Ces batteries conservent l’énergie récupérée grâce au panneau solaire installé à l’extérieur du bâtiment. Nous nous baserons sur la consommation des batteries pour ultérieurement faire une analyse de la consommation d’énergie totale d’un brassage.

Au début du processus les batteries étaient chargées à 89% de la charge maximale. On a fait chauffer de l’eau jusqu’à 80°C avant de la laisser refroidir à 67°C. Une fois à 80°C les batteries étaient à 72% de leur charge maximale. Juste avant la phase de filtration les batteries étaient à 68%. Puis on fait chauffer de l’eau de rinçage, une fois l’eau à 78°C les batteries étaient à 60%. Puis on porte l’eau à ébullition. Au début des 80 minutes de cuisson les batteries étaient à 43% puis à la fin de la cuisson elles étaient à 26%.

Remarque: Lors de cette journée les batteries ont pu se recharger légèrement.

Nous voyons sur la courbe de production des batteries ci-dessus, que de 10 h à 11 h 30 le panneau a produit une puissance jusqu’à 600 W et de 15 h 30 à 16 h la consommation était moindre (cf les encadrés noirs de la Fig 8)

Au bilan, pour faire tout le processus (sans compter la mise en bouteille) on a utilisé 89 % – 26 % = 63 % des batteries. Soit 0,63 x 4,8 kWh = 3 kWh. En toute rigueur, on a remarqué que lors de cette journée, les batteries ont pu se recharger légèrement, ce qui signifie que l’énergie réelle consommée est légèrement supérieure.

Cet essai a montré la faisabilité d’alimenter notre installation par le réseau issu des panneaux solaire.

3. Automatisation :

3.1 Liste du matériel nécessaire :

pour le malaxeur et le moulin Pour le PID de la cuve
Une perceuse 900W/230V Une carte Raspberry Pi avec son écran tactile, son alimentation et une carte SD
Des boulot M6 et M8 en inox Un clavier, souris

Une tige filetée M6 en inox d’une longueure d’un mètre

Une tige filetée M8 en inox d’une longueure d’un mètre

Une LED de roue libre 1N4002
Un fer plat en inox une sonde PT100

Pour la sécurité:

Un transformateur 12V 500mA

Un relais de puissance 12V 300mA

Un relais 5V

Une multiprise et une prise terre

Une carte Arduino Uno avec son câble et une résistance 100 Ohm

3.2 Motorisation du moulin :

Lors de la fabrication de la deuxième bière, nous avons motorisé la rotation du moulin à malt. Pour cela les techniciens de l’IUT nous ont usiné une pièce s’adaptant directement au moulinet du moulin pour ainsi utiliser une perceuse. 

La motorisation du moulin est terminée.

3.3 Motorisation du malaxeur :

Nous avons décidé de créer une pièce totalement en inox pour mélanger la bière de façon autonome.

Le choix de l’inox n’est pas anodin: c’est le seul métal inoxydable, adapté à l’alimentaire, et sans influence sur la saveur de la bière.

De ce fait nous avons réalisé un carré avec un fer plat d’un mètre où nous avons inséré des tiges filetées.

De ce fait lors de la rotation fait par la perceuse le liquide dans la cuve est mélangé de façon homogène.

 

 

3.4 Asservissement de la température :

Afin d’asservir la température, nous avons utilisé une sonde PT100, une carte Arduino Uno, une carte Raspberry Pi, un écran, un relais 5V, un relais 12V, un transformateur, une prise avec terre et la cuve chauffante Brewferm.

Le but est de commander la sonde PT100 à l’aide d’un Raspberry Pi afin que la température soit affichée sur un écran et qu’elle se régule seule suivant le programme de cuisson demandé. La sonde PT100 envoie un signal analogique et le Raspberry Pi ne reçoit que des signaux numériques, c’est pourquoi on ajoute une carte Arduino Uno qui fait office de convertisseur analogique/numérique. La carte Raspberry Pi sera donc reliée à un écran qui affichera le programme de cuisson et la température.

Elle sera aussi reliée à un relais 5V qui sera relié à un relais de puissance 12V. Les deux relais servent de protection à notre matériel. Ce relais de puissance sera relié d’un côté par la cuve chauffante Brewferm, et d’un autre côté par un transformateur qui sera branché au 230V de la prise secteur. 

Nous avons choisi la sonde PT100 grâce à ses caractéristiques :

– une précision d’un dixième de degré : largement suffisant pour notre application,

– gamme de température allant de 0 °C à 100 °C : adaptée à notre température de cuisson qui est de 90 °C,

– temps de réponse inférieure à 1 s : parfaitement cohérent avec notre projet. En effet, la montée en température de notre cuve est environ de 30 minutes pour une élévation de 20 °C. Le temps de réponse du capteur seul est donc négligeable.

3.4.1 Connectique Raspberry Pi → Cuve

 cuve relais de puissance relais 5V Raspy

Pour s’assurer de la sécurité de la cuve ainsi que de l’interface, nous utilisons des relais. 

On va utiliser une triplette avec un arrêt ON/OFF de plus de 3000W pour s’assurer qu’elle supporte les 2000W de la cuve, la perceuse du malaxeur ainsi que les relais. 

Par loi de Joule, 2kW, 230 V aboutit à un courant de 8,7 A. Ce qui nécessite un câble de section 1 mm2. Une fois le branchement réalisé nous pouvons passer à la programmation.

3.4.2 Programmation de la sonde:

Objectif : à travers une interface l’utilisateur choisira les 3 temps de cuisson et les températures associées ainsi que le temps de houblon. De cette façon l’utilisateur peut vaquer à ses occupations en recevant un email à chaque changement de cuisson, pour chaque houblon et fin de cuisson.

Nous avons donc commencé cette partie de l’automatisation par la programmation de la carte Raspberry Pi et de la carte Arduino Uno. La particularité de la sonde PT100, c’est qu’à 0 degrés Celsius celle-ci agit comme une résistance de 100 ohms. Celle-ci est reliée à la carte Arduino à l’aide d’un pont diviseur de tension avec une résistance 100 Ohm afin de faire la conversion analogique/numérique et de sortir une valeur de la température. (Fig 13) Cette valeur de température sera ensuite envoyée au Raspberry Pi. Le Raspberry Pi sera programmé pour recevoir les informations de la sonde dans un premier temps.

Pour l’arduino nous avons fait un programme nous permet de récupérer les valeurs de la sonde qui arrivent sur le port analogique de l’Arduino. Nous recevons les valeurs en millivolts que nous convertissons en degrés Celsius.

Pour ce faire, nous utilisons la fonction map qui permet de faire cette conversion. Pour calibrer la sonde, nous la mettons à 0°C et récupérons la valeur en millivolt. Nous ferons de même pour 100°C. Pour finir nous affichons le résultat en degrés sur la console. 

3.4.3 Programmation du contrôle de la cuve

Nous allons utiliser le  logiciel python pour programmer la cuve. Le principe de fonctionnement est le suivant :

  • Nous contrôlons constamment la température, si elle est trop froide on active le GPIO 12 (pin sur lequel est branché la cuve) donc on allume la cuve, sinon on le désactive pour l’éteindre.
  • Nous avons créé des paliers de température et de houblons
  • Nous utilisons des minuteurs pour savoir si le temps des paliers sont écoulés pour passer au suivant
  • Nous pilotons également 5 autres GPIO qui vont servir à envoyer des mails de suivi à l’utilisateur

Initialisation :

En début de programme toutes les variables, mettrons les GPIO sur FALSE (éteint), nous enregistrons les temps de cuisson et des houblons saisis

Chronomètre:

Nous utilisons le temps instantané sur lequel nous allons ajouter la durée saisie par l’utilisateur. 

Cependant l’utilisateur rentre dans l’interface une durée en minute uniquement, telle que 90 minutes. Ainsi, nous avons créé 2 fonctions permettant de transformer et d’ajouter la saisie des minutes de l’utilisateur, en heure et minute d’arrivée.

ex: il est 13h30, nous saisissons 70 min →  70 minutes c’est 1h et 10 minutes.–> la fonction renvoie heure prévu= 1h, Minute prévu=40

Régulation de la température:

Pour cela, nous avons créé une fonction qui va piloter le GPIO relié à la cuve pour l’activer ou non. Le principe est le suivant : si la température reçue par la sonde est inférieure à la température désirée, on allume la cuve sinon on l’éteint.

Architecture du programme:

Le programme est essentiellement constitué de “while” et de condition ”if”. Pour la première cuisson nous attendons que l’utilisateur lance le programme en appuyant sur le bouton de l’interface. Le programme est fait en deux parties : première cuisson et deuxième cuisson. A chaque fois nous devons attendre que l’utilisateur active la cuisson pour lancer l’algorithme. 

Dès lors, pour la première cuisson, nous allons créer des boucles qui vont s’exécuter tant que la cuisson avec ses paliers ne sont pas arrivées à termes.  A l’intérieur nous y plaçons la condition suivante :

Si la température relevé par la sonde est inférieure ou supérieure à 5°C de la température voulue pour le palier, nous la régulons comme nous avons vu précédemment.

Sinon nous lançons le chronomètre adéquat au palier. Et rentrons dans une boucle “tant que  l’heure instantanée est inférieure à l’heure de fin du chronomètre” , nous relevons la température de la sonde, nous ajustons en conséquence la température et nous relevons l’heure instantanée. Dès qu’on sort du “tant que” nous activons le GPIO adapté pour envoyer un mail puis nous le remettons en état OFF.

Cette condition va être répétée 3 fois soit le nombre de paliers maximum dans la première cuisson.

Lorsque les 3 paliers ont été exécutés, nous envoyons un mail de fin de première cuisson, sortons de tous les “tant que”, et coupons la cuve. 

Pour la deuxième cuisson le principe est similaire mais simplifié car la température reste constante à 90°C.

Ainsi nous allons faire une série de chronomètre avec comme consigne tant que le chronomètre précédent n’est pas écoulé on ne passe pas au suivant. Dès qu’un chronomètre est écoulé nous envoyons un mail, indiquant qu’il faut rajouter un houblon.

3.4.4 Programmation de NodeRed

L’application Node Red se fait en trois étapes distinctes, nous commençons par détecter un changement de front sur l’un des pins du Raspberry Pi (boite bleue). Ce changement de front nous indiquera à quel moment de la cuisson nous nous situons. Ensuite, suivant le pin détecté, on fait une fonction dans laquelle on affiche le message voulu (boite orange). Pour finir, ce message est envoyé par email afin de prévenir l’utilisateur du changement de température dans une cuisson ou alors pour prévenir qu’il faut mettre le houblon (boite verte).

3.4.5 Programmation de l’interface

Voici l’interface utilisée:

La programmation de l’interface se fait plutôt facilement. Il suffit de connaître les lignes de codes qui permettent de faire apparaître un bouton, une liste ou encore un texte et le tour est joué.

Voici des extraits de codes expliqués:

Nous avons choisi d’afficher l’heure  sur l’interface afin de nous éviter d’avoir une montre à côté de nous. Pour cela, nous avons créé une fonction qui permet de récupérer l’heure instantanée du Raspberry Pi. Puis on sélectionne l’endroit où l’on veut l’affiche à l’aide de la fonction “.grid”. On choisit la colonne et la ligne dans lesquelles on veut que l’heure s’affiche. 

Ensuite nous avons différentes zones de textes, ce sont les zones dans lesquelles on a déjà un texte comme “Palier 1”.  Pour cela, nous utilisons un “Label”, nous lui donnons un nom et le plaçons dans l’interface toujours à l’aide de la fonction “.grid”.

Nous avons également créé des “Spinbox” qui représentent les cases dans lesquelles nous choisissons une valeur. Nous décidons de pouvoir avoir des valeurs entre 0 et 150 “from_=0, to=150”, sauf pour la température que nous décidons d’avoir comme minimum 30 (from_=30, to=150). Les trois quarts du programme sont constitués de ces quatre lignes. 

Pour terminer, nous avons ajouté deux boutons : un qui lancera le chronomètre de la première cuisson, et un qui lancera le chronomètre de la deuxième cuisson.

On utilise donc la fonction “Button” dans laquelle nous entrons un texte, qui figurera sur le bouton, ainsi qu’une commande à lancer et sa position dans l’interface. Cette commande se trouve dans le programme qui contrôle la cuve. Ainsi, lors de l’appui sur le bouton de l’interface, le chronomètre ainsi que les fonctions de chauffe se mettent en route grâce à la liaison entre les deux programmes.

Le petit plus de notre interface est d’avoir une barre de menu dans lequel nous avons un seul menu, “Fichier”.

Dans ce menu “Fichier” nous avons créé un sous-menu “Bière blonde” et un sous-menu “Bière Ambrée”. En cliquant sur ces sous-menus, la recette de la bière s’affiche dans la console grâce à la fonction “command=”. Les fonctions “Recette_biere_blonde” et “Recette_biere_ambree” nous permettent tout simplement d’écrire dans la console le texte voulu qui est entre guillemets. Nous avons également ajouté un sous-menu “Quitter” qui permet de fermer l’interface.

4.Améliorations possibles :

 

Pour améliorer ce projet nous pouvons y apporter certaines modifications au niveau de la programmation, du malaxeur ou encore de la sonde.

4.1 La programmation:

Faute de temps, nous n’avons pas pu rassembler les programmes de l’interface et du programme principal. Pour les rassembler il y a 2 solutions. La première c’est de les rassembler tout en gardant 2 programmes différents, un pour le programme principal et un pour le programme de l’interface. La deuxième solution est de mettre les 2 programmes dans un seul et même programme qui lancera tout en même temps, cependant cette solution donnera un programme très long et assez complexe.

4.2 Le malaxeur:

Le malaxeur est prêt mais il n’est pas en place. Pour cela, il faudrait faire un trou dans le couvercle de la cuve afin d’y faire passer la tige filetée qui se logera dans le mandrin de la perceuse. Mais pour tenir la perceuse il faudrait aussi pouvoir

 

4.3 La sonde:

La sonde est programmée mais pour l’instant elle est juste posée dans la cuve. Pour la fixer, il faudrait faire un trou dans le couvercle de la cuve afin d’y faire passer la sonde, mais attention, il faudrait trouver une solution afin qu’elle ne soit pas emportée par le remous du malaxeur.

5. Conclusion

Ce projet fut très enrichissant que ce soit d‘un point de vue technique  que d’un point de vue humain. En effet à travers ce projet nous avons pu rencontrer plusieurs personnes qui nous ont soutenu et partagé leurs savoirs.

Sur le côté technique, l’automatisation de la micro brasserie fut très complet. Nous avons vu la programmation sur 3 supports différents (Raspberry Pi, Node Red, Arduino). Pour la mécanique nous avons pensé, découpé, plié, assemblé différentes pièces. Côté électronique, nous nous sommes occupées des commandes et de l’assemblage des éléments.

La partie énergie nous a sensibilisé au fonctionnement et à la lecture des graphiques fournis par le panneau solaire.

Finalement, ce projet est bien plus qu’un simple projet brassage. C’est un assemblage de savoir faire que nous avons mené à bien grâce à nos connaissances et au partage des savoir-faire. Pour le mener à terme, nous n’avons pas hésité à prendre de notre temps personnel.

Malgré les difficultés rencontrées nous avons réussi à obtenir un système qui fonctionne convenablement.

 


Gestion énergétique d’un système d’arrosage

 

                                 Système d’arrosage automatique

Groupe :

HARMRI Anis

BAVERA MVOU Joël

Tuteur: Stéphane BAZEILLE et Nicolas VERRIER

Sommaire :

  1. Les objectifs

  2. Matériels

  3. Programmation

  4. Consommation énergétique

  5. Conclusion

 

INTRODUCTION

 

Nous sommes deux étudiants en deuxième année GEII et avons comme projet l’amélioration d’un système d’arrosage automatique proposé par Soléa. Nous étions chargés de la partie alimentation tandis qu’un autre groupe était chargé de la partie «  intelligence ».

 

1 – Objectif du projet

A- Contexte

L’objectif du projet est d’élaborer un système d’arrosage automatisé alimenté à l’aide d’un système d’alimentation indépendant et renouvelable. Pour limiter la consommation d’énergie on devait programmer l’allumage et l’extinction du système.  Afin de mener notre projet à bien nous avions structuré notre travail de façon à accomplir ces taches-là :

Estimation de la consommation du système complet

  1. Alimentation de la raspberry sur batterie

 

  1. Mise en place du panneau solaire pour le rechargement de la batterie

 

  1. Extinction et allumage automatique de la Raspberry

 

  1. Conception CAO

B- énoncé du besoin

 

C- environnement du produit

 

le système devra résister à la température et à l’humidité ambiante . La batterie devra être à l’abri de l’humidité  pour éviter qu’elle ne s’abime. Pour ce qui est du panneau solaire il faut évidemment qu’il soit exposé entièrement au soleil pour fournir de l’énergie. NB il suffit qu’une seule cellule soit recouverte pour que le panneau ne fournisse pas d’énergie , il faut faire très attention à la position du panneau

2–Matériels

Dès le début nous disposions d’un certain nombre d’équipements à l’élaboration de notre projet :

  1. Carte Raspberry pi 3

c’est la base du projet, c’est à partir d’elle que nous avons réalisé notre profilage énergique

 

 

 

  1. Batterie en lithium

cette batterie polymère de 2000mAh a servit à alimenter la Raspberry pi ainsi que les capteurs

 

3.Un panneau solaire :

Le panneau photovoltaïque utilisé pour recharger notre batterie a une puissance de 2W et une tension de 6V

 

 

  1. Un driver  :  ce qui permet la charge décharge simultané de la batterie et maximise l’énergie produite par le panneau

 

 

 

  5  .Witty pi 2

 

elle a servit pour programmer les séquences d’allumage extinction

 

 

 

6. booster de tension

Toutefois la batterie débite une tension de 3.7 V ce qui est insuffisant devant les 5V nécessaire à l’alimentation de la raspberry pi. nous avons donc utilisé un booster de tension qui transforme les 3.7V d’entrée en 5V de sortie pour alimentation la Raspberry.

 

 

 

 

 

5 -Programmation

1.Envoi d’un mail

Dans notre cas nous n’utilisons que des adresses gmail

XXX@gmail.com est l’adresse d’envoi et YYY@gmail.com est le destinataire. Nous avons utilisé le serveur SMTP.gmail.com qui est un serveur gratuit qui nous permet d’envoyer jusqu’à 100 mails par jour

Ce code est indépendant de la configuration du serveur. Pas besoin d’installer quoi que ce soit pour que le mail puisse être envoyé, toutes les librairies nécessaires sont normalement déjà installées.

Cette fonction sera utilisé pour signaler l’ouverture et la fermeture de la vanne .

 

2.Lancement d’un script au démarrage

Pour le lancement  il suffit tout simplement de placer le chemin du script voulu dans le fichier Rc. Local tout à la fin avant  le « exit 0 ». Et le script se lancera tout seul au démarrage. Cependant dans certains  cas il faut ajouter le caractère « & »  pour éviter que le code se répète en boucle.

pour vérifier que le code se lance bien au démarrage nous avons relié une Led à notre Raspberry pi qui s’allume pour confirmer que le programme se lance bien .

A chaque fois que la Raspberry pui démarre elle envoi une impulsion pour allumer la Led

 

3.Séquence allumage/extinction

Pour cette partie nous avons utilisé une Witty Pi 2 qui est une horloge temps Réel pour Raspberry Pi. Nous avions d’abord utilisé une RTC for Pi au début mais elle nétait pas adapté car elle ne disposait pas de pin d’alarme

Après avoir connectée la Witty Pi 2 à notre Raspberry, l’installation de notre module se fait en exécutant ces lignes de codes  :

Après avoir installé le module on peut ouvrir de menu et constater que 8 possibilités s’offrent à nous

les options 1,2 et 3 servent à régler la date et l’heure. Ce qui vas nous intéresser ici sont les points 4,5 et 6.

l’option 4 sert à programmer la prochaine extinction , l’option 5 elle sert à programmer le prochain démarrage tandis que l’option 6 nous permet de choisir un script de séquence d’allumage/ extinction.

voici un exemple simple de séquence

ce script tout simple met en marche la Raspberry pi pendant 5 minutes toutes les 20 minutes

nous avons utilisé des scripts du même type

 

si les conditions d’arrosage sont bonnes on active le script de gauche :

on met en marche la raspberry pi pendant 5 min   c’est à dire le temps d’ouvrir la vanne , puis elle s’arrête pour redémarrer à 4h pendant 5 min pour fermer la vanne

si les conditions sont mauvaises :

on met en marche la raspberry et on l’arrête jusqu’au lendemain.

la commande python pour lancer le script est  :

4.Consommation énergétique

1. Recharge par panneau solaire

voici la courbe caractéristique de notre panneau solaire .

Nous pouvons constater qu’avec une luminosité maximale , nous pouvons récolter 0.038 A par cellules. Le panneau étant constitué de 12 cellules on fait le produit.
12*0.038= 0.456 A

Ainsi grâce à la relation suivante nous pouvons déterminer le temps de charge de la batterie avec un rayonnement optimal.
T = Q / I
T représente le temps en secondes
Q la quantité de charge en coulomb (1000mAh = 3600 Coulomb)
I l’intensité en ampères
Donc :
T = 7200 / 0.456 = 15789.4s   soit 4h et environ 20 minutes de temps de charge
La même formule nous servira par la suite afin de calculer notre temps de décharge avec l’ensemble des équipements nécessaire à l’élaboration du projet.

 

2.Estimation de la consommation du système

pour notre batterie de 2000mAh on a :

1 capteur de 35 mA

1 capteur de 0.15 mA

1 Raspi de 490 mA

dans la formule I = intensité en Ampères

Q= quantité de charge en Coulomb ou en Ah (1Ah = 3600 coulombs)

et t correspond au temps en secondes

calculons à présent le temps qu’il faut à notre système pour décharger la batterie.

Notre batterie peut donc tenir environ 3H48mn

 

3. Courbe de charge et de décharge

 

courbe de charge pratique

En extrapolant nous avions obtenus ces résultats en chargeant la batterie avec le panneau solaire.
Donc un temps de charge d’environ 6 heures avec l’ensoleillement présent ce jour-là. Cette courbe
nous prouve que la batterie peut bien se charger grâce au panneau solaire.

 

courbe de charge théorique 

Nous avions tracé la courbe de charge de la batterie avec le logiciel Scilab. Afin de faire une
hypothèse sur le temps que pourrait mettre la batterie à se décharger

 

 

courbe de décharge théorique

Nous faisons la même expérience en pratique en utilisant un moteur à courant continue et en
relevant la tension à plusieurs moments à l’aide d’un voltmètre.

 

 

 

courbe en pratique

 

 

 

Donc avec un moteur à courant continue la batterie se déchargeait au bout d’environ 33 minutes.
Donc en faisant cette mesure nous avons pu déterminer si la batterie fonctionnait.
Cette courbe de décharge nous l’avions réalisée en relevant plusieurs mesures au cours de la
décharge à l’aide d’un voltmètre, puis en extrapolant ces valeurs obtenus afin d’obtenir une courbe.

 

 

4. Allumage et extinction

nous avons le courant consommé pendant 10 min par notre système. Nous constatons des pics pendant l’allumage et pendant l’extinction . on a mesuré environ 82mAh

 

 

 

nous avons réalisé les mêmes mesure mais cette fois nous avons allumé et éteint 2 fois notre système pendant 3 min . on a mesuré environ 47 mAh d’où l’intérêt de faire des allumage et extinction pour économiser la batterie .

5. importance du driver

La puce MCP73871 du chargeur USB / solaire possède une fonctionnalité très astucieuse appelée « partage de charge ». Supposons que nous ayons un chargeur lipoly tous les jours et que nous souhaitions utiliser la batterie pendant la charge. Pour ce faire, nous pouvons connecter le projet directement à la sortie de la batterie. Cela signifie toutefois que le chargeur charge à la fois une batterie et pilote votre projet en même temps. il fait parfois sombre et nous ne pouvons pas utiliser de chargeur solaire. Il y a donc également un port USB sur le tableau. Nous pouvons utiliser n’importe quel câble mini-B pour brancher et charger.
Si quelque chose est connecté à la prise CC, il débranchera mécaniquement le mini-connecteur USB. Il faut donc s’assurer de débrancher le panneau solaire lors du chargement par USB.

 

                                                                                  CONCLUSION

 

Nous voudrions tout d’abord remercier Monsieur Nicolas VERRIER et Monsieur Stéphane BAZEILLE de nous avoir donné l’opportunité de réaliser ce projet et de nous avoir apporter leur aide tout au long de celui-ci. Ce projet nous a permit d’apprendre à travailler en équipe et à se repartir les taches de façon à finir le travail qui nous avait été confié.
Pour conclure, grâce à un grand travail de recherche nous avons pus élaborer un système d’arrosage automatique avec une alimentation indépendante et renouvelable.
Nous avons pus déterminer quels équipements étaient nécessaire, faire un bilan de consommation énergétique et de déterminer le moyen le plus économique d’utiliser la batterie. nous avions aussi réussi à programmer en langage python de nombreux programmes dont l’allumage et l’extinction de la raspberry pi 3. finalement nous avons réalisé une conception CAO pour stocker nos composants électroniques.
Nous pourrions également ajouter à ce projet divers point d’amélioration. Comme par exemple, installer un capteur qui mesurerai l’état de la batterie et ainsi l’envoyer par mail.
Voici une vidéo illustrant la mise en action des scripts, extinction/allumage et le rechargement de la batterie par le panneau solaire.


Système d’arrosage intelligent

PROJET ER2 : Mise en œuvre d’un système de régulation d’un arrosage automatique

Contexte :
L’entreprise Soléa a pris contact avec l’IUT de Mulhouse dans le but de commanditer un projet auprès des étudiants de deuxième année GEII :
Ils souhaiteraient que nous réalisons pour eux un système intelligent et autonome de régulation pour leur système d’arrosage automatique des pelouses sur les voies de tramway.

Pour réaliser cette commande, le travail sera divisé en deux projets : notre groupe se concentrera sur la partie “intelligence” du système, un autre groupe de nos camarades se chargera de la partie “autonomie” du système.

Matériel :
Pour mener à bien ce projet, l’IUT a mis à notre disposition le matériel suivant :

– 2 Raspberry Pi 3
– Capteurs de température, pression & humidité du sol
– Shield GrovePi+
– 2 Modules Xbee (communication sans fil longue portée)

Objectifs :
Nous devons réaliser un système de régulation pour un arrosage automatique des pelouses.
Le système devra contrôler l’arrosage en fonction de plusieurs paramètres : température, humidité du sol, la pression atmosphérique.

Notre système doit pouvoir se raccorder par dessus le système déjà existant en station.
Pour ce faire, nous allons devoir faire communiquer sur une longue distance un Raspberry Pi de mesure situé a coté de l’électrovanne, et un Raspberry Pi de contrôle se situant en station.
On souhaite aussi pouvoir présenter une analyse statistique à l’utilisateur.

 

Tout d’abord, nous avons commencé par tester nos capteurs :
Après avoir écrit des petits programmes simples, nous avons pu relever des valeurs sur nos capteurs.

Toutefois, certains capteurs n’étaient pas compatibles avec un Raspberry Pi 3 : En effet, le quartz régulant la fréquence de synchronisation des capteurs sur les Pi 2 sert a la communication BlueTooth sur les Pi 3 ; les Raspberry Pi 3 ne sont donc pas compatibles avec les protocoles de communication synchrone.
Seuls les capteurs se connectant sur les ports I2C fonctionnent : le protocole I2C est asynchrone et utilise des acquittement et des handshakes.

Ensuite, nous avons assemblé ces codes simples permettant de relever les valeurs de chaque capteurs, pour obtenir un code capable de relever les valeurs de chaque capteur, l’un après l’autre, puis de les enregistrer dans un fichier texte à fin de les traiter puis de les transmettre par la suite à la Raspberry Pi réceptrice.

Nous avons tout d’abord établi une communication sur le réseau Ethernet local de l’UHA entre nos deux Raspberry Pi.
Nous avons opté pour le protocole TFTP car il était simple d’utilisation et répondait à nos besoins

Après avoir réussi à récupérer les valeurs de nos capteurs sur la Raspberry Pi réceptrice et à contrôler l’allumage d’une LED (représentant l’électrovanne) en fonction des valeurs reçues, nous nous sommes attelés à réaliser la communication sans fil à l’aide des modules Xbee.

Nous avons alors opté de moyenner nos mesures sur une période d’une dizaine de mesures avant de les émettre, la transmission textuelle des donnée n’étant pas instantanée.
Après, nous avons ajouté à notre code de réception l’écriture des données reçues dans un fichier Excel dans le but de permettre une analyse statistique par l’utilisateur.

Voici l’un des graphiques que nous avons pu obtenir en changeant d’environment le capteur d’humidité du sol.
On constate un pic anormal pour les valeurs d’humidité  « Moisture » : celui ci correspond à une erreur de transmission.
On voit aussi des intervalles ou il n’y a pas de mesures enregistrées : ces intervalles correspondent à une perte de la communication.

Ici, on peut voir à gauche le ficher .txt dans lequel les valeurs brutes relevées sont stockées, et à droite, les valeurs traitées apparaitre dans la console de Raspberry Pi réceptrice.

Enfin, voici les algorigrammes de nos codes émetteurs et récepteurs :

 

 

 

 

 

 

 

 

 

 

 

 

 


Vidéo de démonstration :

Conclusion :
Nous estimons avoir bel et bien montré la faisabilité d’un tel système.
L’un de nos camarades qui viendra à réaliser son stage de fin d’études au sien de l’entreprise Soléa pourrait bien devoir approfondir sur ce projet et le mettre en place en conditions réelles.

 


Supervision d’un four à tabac

 

Tuteur: Stéphane BAZEILLE et Nicolas VERRIER

 

Groupe: Florian BRAUN, Noah BEAUPERE et Hugo TISSOT

 


 

Sommaire

Cahier des charges

1. Présentation générale du problème

1.1. Projet

1.2. Contexte

1.3. Énoncé du besoin

1.4. Environnement du produit

2. Expression fonctionnelle du besoin

 

Gestion et réalisation du projet

1. Simulation des capteurs

A) Générateur de fonctions arbitraires

              a) Analyse du système des valeurs recherchés
              b) Création de la fonction arbitraire
              c) Le générateur

B) Convertisseur Analogique Numérique

            a) Branchement
            b) Configuration
            c) Code

C) Avertissement visuel

            a) Branchement
            b) code

 

2. Programmation du RaspberryPI

A) Récupération des données

B) Communiquer entre les RaspberryPi

C) Analyse et utilisation des données

D) Envoie des données au serveurs

 

3. Stockage et Interprétation des Données

A) Récolte et Stockage

              a) Étude de marché
              b) Architecture

B) Accès à Distance et Interprétation

 

 

 

 

 


Cahier des charges

1.Présentation générale du produit

1.1. Projet

Le but du projet est de collecter les données de température sur chacun des fours à tabac d’une exploitation, les envoyer sur un serveur accessible depuis un smartphone ou autre pour permettre de visualiser et comparer facilement les données instantanées. Une alarme sera également créée, en cas de fort dépassement des valeurs attendues ou de problèmes matériels et l’utilisateur sera averti.

1.2. Contexte

Lors du processus de séchage du tabac, le séchage des feuilles doit passer par différents cycles avec différentes température et humidité afin d’extraire efficacement toute l’humidité. Ces cycles de séchage durent, au total, une semaine avec des fours continuellement allumés. Si un four vient à tomber en panne ou subi une anomalie durant le processus et qu’il n’y a pas de surveillance, (la nuit par exemple) les dégâts et la perte de la récolte peuvent se chiffrer en milliers d’euros.

1.3. Énonce du besoin

1.4. Environnement du produit

Le dispositif final doit pouvoir directement se connecter aux capteurs des fours et doit répondre à un minimum de contraintes environnementales:

  • résister à une température minimum de 90°C
  • résister à l’humidité ambiante

Liste du matériel:

  • 2 Raspberry Pi
  • Générateur de tension (fonction arbitraire)
  • Oscilloscope
  • CAN
  • Afficheur 7-seg
  • Relais wifi

On estime le coup total à 158€, étant donner que l’oscilloscope et le Générateur nous on été prêté.

 

2.Expression fonctionnelle du besoin

Tableau des Fonctions

Fonction Désignation Critères d’appréciations Niveau Flexibilité Observations

Limite d’accep-

tation

  

     FP1

Permettre à l’utilisateur de consulter l’état des fours en temps réel

– visualiser sur un smartphone

– comparer les valeurs attendues et réelles

/ / /
FP2 Avertir l’utilisateur en cas de dysfonctionnement d’un four

– envoyer une notification ou mettre en place une alarme sur le smartphone

– mettre en place un avertisseur visuel

état des alarmes récoltées toutes les 15 minutes / fréquence d’acquisition de 30s pour la simulation

 

FS1

Récolter les données des fours – récolter les données de température et d’humidité avec les Raspberry PI données récoltées toutes les 15 minutes / fréquence d’acquisition de 30s pour la simulation
 FS2 Détecter un dysfonctionnement

– etre capable de détecter un écart de température trop grand

– réguler la température

15minutes / régulation de la température uniquement dans la simulation
FS3 Être alimenté en énergie – branchement secteur / / /
FS4 Résister aux agressions du milieu ambiant

– résister à une haute température

– résister à l’humidité ambiante

90°C + ou- 5°C /
FS5 Communiquer entre les Raspberry PI et le serveur

– communiquer entre la raspberry et le serveur internet

– communiquer entre les deux raspberry PI

/ / /
FS6 Respecter le budget du client -Coût final accessible 500€ + ou – 100€ /

 

 


 

Gestion et réalisation du projet

1. Simulation des capteurs

A) Générateur de fonctions arbitraires

(Tissot)

                a) Analyse du système des valeurs recherchés

On sait que les différents four à tabac possède déjà leurs propres capteurs de températures,n’ayant pas la références de ces capteur, on choisit comme référence un capteur qui correspond le plus nos besoins.

Ici on choisit donc comme référence un thermomètre à sortie analogique “THERMOSA”, avec les caractéristiques suivantes:

  • Gamme de température : -20 à +120 °C
  • Sortie analogique : Tension proportionnelle à la température -2,5 V (-20 °C) à +2,5 V (+120 °C)

On a donc 140°C sur une tension d’amplitude 5V, 1°C correspond à 0.035V.

Pour des raison pratique lié à la simulation, on affirme que 0°C correspond à une tension 0V.

 

On a pour but de créer une fonction capable de reproduire le cycle du séchage du tabac (voir courbe si-dessous).

 

La fonction devra donc obligatoirement passer par tous ces points.

On va donc avoir:

  • 1°C correspond à 0.035V
  • 20s dans la simulation correspond à 1h

On établit donc les points principaux de la fonction:

température (c°) temps simulation (s) tension de sortie (V)
32 0 1,12
40 160 1,4
40 960 1,4
57 1300 1,995
57 2400 1,995
73 2720 2,555
73 3110 2,555
40 3120 1,4
40 3280 1,4

 

                  b) Création de la fonction arbitraire

Afin de créer cette fonction, on a besoin de générer un fichier de points (CSV File). Pour le générer il existe de nombreuses solutions, ici nous allons utiliser le logiciel gratuit EasyWawe.

 

 

Pour cela, après avoir installé ce logiciel, exécutez le.

 

Une fenêtre va s’ouvrir, cliquez sur “File” puis “New”.

 

La fenêtre “Property setting” s’ouvre, dans la case “Sample” vous pouvez sélectionner le maximum de points pour avoir la meilleur précision.

 

Sélectionnez ensuite une période de 3280s, puis cliquez sur “Ok”.

 

La fenêtre “Wawe1” s’ouvre, cliquez sur “Draw” puis “Coordinate Draw”.

 

Indiquez le nombres de points nécessaire, ici “9”, et sélectionnez ensuite “Table”.

 

Rentrez ensuite les coordonnées des différents points. (ATTENTION Xpos est en kiloseconde et non en seconde).

temps simulation (s) tension de sortie (V)
0 1,12
160 1,4
960 1,4
1300 1,995
2400 1,995
2720 2,555
3110 2,555
3120 1,4
3280 1,4

 

Une fois tous les points entrés cliquez sur “Ok” et votre fonctions va être générer.

Il ne vous reste plus qu’à enregistrer en “.csv”, et vous avez votre fichier de points.

 

 

            c) Le générateur

Concernant le générateur, nous utilisons le générateur de fonctions arbitraire hameg hmf2525. Celui-ci est très pratique car il permet d’obtenir des période très longue et possède un port USB. On va donc utiliser ce port afin d’y transférer le fichier CSV précédemment créé (munissez vous de la notice de générateur si vous ne connaissez pas son fonctionnement).

Chargez le fichier

 

Réglez ensuite la période à 3280s, l’amplitude à 2.555V et l’offset à 1.25V afin que la tension de sortie corresponde à la tension souhaiter précédemment.

Il ne faut pas hésiter à utiliser un oscilloscope pour mieux visualiser la courbe.

 

 

B) Convertisseur Analogique Numérique

(Tissot)

Le CAN (Convertisseur Analogique Numérique) va nous servir à convertire la tension analogique du générateur, afin de pouvoir l’analyser sur le Raspberry PI. Le CAN possède deux entrées, on va donc y rajouter un potentiomètre pour simuler un second four.

Nous utilisons le CAN MCP 3002:

 

 

 

                a)Branchement

A l’aide d’une Breadboard, on va connecter la sortie du générateur et le potentiomètre au CAN, et le CAN au Raspberry PI comme ci dessous:

                    b) Configuration

Il faut configurer votre Raspberry PI pour utiliser le CAN.

Il faut tout d’abord vérifier que le SPI est activer.

Ouvrez un terminal et lancez la commande suivante :

sudo raspi-config

Sélectionnez « Advanced Options » puis validez :

Puis sélectionnez « SPI » puis validez :

Une fois cela fait, exécuter les commande suivante dans le terminal:

sudo apt-get install python2.7-dev

sudo apt-get install python3-dev

sudo apt-get libevent-dev

sudo pip install spidev

 

 

 

                      c) Code

#!/usr/bin/python

import time    

import spidev

DEBUG = 0

 

spi = spidev.SpiDev()

spi.open(0,0)

   

# read SPI data from MCP3002 chip

def get_adc(channel):

          # Only 2 channels 0 and 1 else return -1

          if ((channel > 1) or (channel < 0)):

                    return -1

           r = spi.xfer2([1,(2+channel)<<6,0])

           ret = ((r[1]&31) << 6) + (r[2] >> 2)

          return ret   

while 1:   

          print (get_adc(1))

         Tension = (get_adc(1)*2.7)/1024

         print (Tension)

        time.sleep(5)

 

 

Dans ce code on va créer une fonction “get_adc(channel)” qui va nous permettre de sélectionner l’entré du CAN et d’y lire la valeur. Si “channel” est différent de 0 ou 1 on retourne -1.

La valeur reçu est entre 0 et 1023, on procède alors à un calcul pour que cette valeur corresponde à une tension.

 

C) Avertissement visuel

(Tissot/Braun)

Le but est d’avertir visuellement l’utilisateur à l’aide d’un afficheur 7 segments.Il va alors pouvoir savoir sur quel four une alarme s’est déclenchée, cela peut être dû à un écart de température ou un problème matériel.

                 a) Branchement

 

Pour procéder correctement au branchement il nous faut un afficheur 7 segment et 7 résistances de 240 . Un segment va alors correspondre à un pin du Raspberry PI, il  suffit de suivre le schéma ci-dessous

Pour ma part, j’ai connecter:

  • le segment A au PIN11
  • le segment B au PIN12
  • le segment C au PIN13
  • le segment D au PIN22
  • le segment E au PIN18
  • le segment F au PIN16
  • le segment G au PIN15

 

             b) code


#librairies à importer

import time

GPIO.setmode(GPIO.BOARD)

GPIO.setwarnings(False)# On supprime les avertissements inutiles

seg={« A » : 11, « B » : 12, « C » : 13, « D » : 22, « E » : 18, « F » : 16, « G » : 15} #on indique quel segment est sur quel PIN

#fonction d’affichage

def display(x) :

GPIO.output(seg[‘A’], x in [1,4])

GPIO.output(seg[‘B’], x in [5,6])

GPIO.output(seg[‘C’], x in [2])

GPIO.output(seg[‘D’], x in [1,4,7])

GPIO.output(seg[‘E’], x in [1,3,4,5,7,9])

GPIO.output(seg[‘F’], x in [1,2,3,7])

GPIO.output(seg[‘G’], x in [0,1,7])

La fonction display va permettre de choisir quelle pin il faut allumer en fonction du nombre x. L’afficheur 7 segment étant en logique inverse on indique les nombres pour lesquels chaque segment ne doit pas s’allumer.

On intègrera donc la fonction display dans le code final.

 


2. Programmation du Raspberry PI

(Braun)

A) Récupération des données

import cantest2 #cantest2 est le programme du Convertisseur Analogique-Numérique.
Il me permet de récupérer les données à l’aide d’une fonction


def RecupTfour(Nfour) :
Tfour[Nfour] = ((cantest2.get_adc(0)*3.35)/1024)/k

Cette fonction va récupérer la température du four (Tfour), d’un four précis choisi (Nfour), il converti également la tension que le programme cantest2 me donne en une température lisible.

 

B) Communiquer entre les RaspberryPI

La communication entre les Raspberry Pi est gérée par un serveur MySQL, celui-ci sera gérer sur le Raspberry maître et l’esclave lui enverra ses données. Il faut d’abord initialiser la connexion avec MySQL :


os.system ("sudo service mysql restart")
mydb = mysql.connector.connect(  host = '192.168.xxx.xxx',
user = 'FAT',
passwd = '****',
database = 'FAT')

Cette fonctionnalité est faite par une fonction qui enverra chaque valeur au serveur qu’il pourra par la suite gérer

 

C) Analyse et utilisation des données

L’analyse des données de se fait four par four, chaque seconde.
La première étape dans l’analyse d’un four est l’initialisation de celui-ci. Pour cela, on considère que le four s’allume quand on détecte une température entre 31 et 33 °C.


 def InitialisationFour(Nfour) :
              if (Tfour[Nfour]>=31) and (cycle_start[Nfour]==0) and (Tfour[Nfour]<=33) :
                           temps_depart[Nfour] = time.time()
                           cycle_start[Nfour] = 1

A partir de ce moment, on active un timer (temps_depart) pour savoir depuis quand ce four est allumé.
Une fois le four allumé, il faut calculer la température attendue : le tabac doit sécher pendant une semaine à des paliers de température différents.


def CourbeAttendu(Nfour) :

              if (time.time()-temps_depart[Nfour]<=16) :
                          Tatt[Nfour]=32+(time.time()-temps_depart[Nfour])*0.5

              if (time.time()-temps_depart[Nfour]>16) and (time.time()-temps_depart[Nfour]<=96) : #palier 40
                         Tatt[Nfour]=40

              if (time.time()-temps_depart[Nfour]>96) and (time.time()-temps_depart[Nfour]<=130) : #montée 40-57
                         Tatt[Nfour]=40+(time.time()-temps_depart[Nfour]-96)*0.5

              if (time.time()-temps_depart[Nfour]>130) and (time.time()-temps_depart[Nfour]<=240) : #palier 57
                         Tatt[Nfour]=57

              if (time.time()-temps_depart[Nfour]>240) and (time.time()-temps_depart[Nfour]<=272) : #montée 57-73
                         Tatt[Nfour]=57+(time.time()-temps_depart[Nfour]-240)*0.5

              if (time.time()-temps_depart[Nfour]>272) and (time.time()-temps_depart[Nfour]<=312) : #palier 73
                         Tatt[Nfour]=73

              if (time.time()-temps_depart[Nfour]>312) and (time.time()-temps_depart[Nfour]<=328) : #palier 40
                         Tatt[Nfour]=40

              if (time.time()-temps_depart[Nfour]>328) :
                         Tatt[Nfour]=0
                         cycle_start[Nfour]=0
                         temps_depart[Nfour]=0

On peut voir ici que l’on a des conditions pour savoir à quel palier le four devrait se trouver.
Suivant ce palier, on définit un Tatt qui est la température théorique que le four devrait avoir à cet instant précis. Puis à la fin, quand le four a fini son cycle, on remet l’état du four (Cycle_start) à 0 pour qu’il soit considéré comme éteint et on reset son timer.


def Alarme(Nfour) :

              if (abs(Tatt[Nfour]-Tfour[Nfour])<3) :
                         temps_ecart[Nfour] = time.time()-temps_depart[Nfour]
                         alarme_ecart[Nfour] = 0
                         display(10)
             if ((time.time()-temps_depart[Nfour])-temps_ecart[Nfour]>5) :
                        #print(« ecart de temperature de plus de 5s »);
                        alarme_ecart[Nfour] = 1
                        display(Nfour)

A coté de cela, il y a une fonction alarme qui compare l’écart entre la température théorique (Tatt) et la température actuelle du four (Tfour) et actionne une alarme si cet écart dure dans le temps (5 secondes).

 

D) Envoie des données au serveurs

Une fois l’analyse des données terminée, il faut envoyer celles-ci au serveur.


def Ecriture(Nfour) :
              if (temps_different[Nfour]!=int(time.time()-temps_depart[Nfour])) :
                        date = datetime.datetime.now()
                        sql = "INSERT INTO Four_" + str(Nfour) + " VALUE (null, %s, %s, %s, %s)"
                        cur.execute(sql, (str(date), str(Tfour[i]), str(defaut[i]), str(alarme_ecart[i])))
                        mydb.commit()
                        temps_different[Nfour]=int(time.time()-temps_depart[Nfour])
                        print("four ={}, time= {}, Tatt={}, Tfour= {}, Alarme ={}".format(Nfour, int(time.time()-temps_depart[Nfour]), int(Tatt[Nfour]), int(Tfour[Nfour]),alarme_ecart[Nfour]))

Cette fonction s’occupe d’envoyer chaque donnée de chaque four au serveur et cela chaque seconde.

 


3. Stockage et Interprétation des Données

A) Récolte et Stockage

(Beaupere)

              a) Étude de marché

Avant de commencer à coder, nous avons effectué une étude de marché pour connaitre la solution technique la plus fiable, simple et peu coûteuse sur le long-terme afin de ne pas compliquer la tâche de l’utilisateur avec des maintenances ou des actions pénibles ou excessives hors de son domaine de confort.

  • Première idée : Tirer des câbles entre les capteurs et le serveur

Les câbles résistants à une utilisation extérieure sont chers et devraient être remplacés ou réparés au minimum annuellement si ce n’est plus. Un seul défaut dans le câble et toutes les données reçues jusqu’à la réparation seront inutilisables.

  • Deuxième idée : Connecter les capteurs à un micro-ordinateur possédant une liaison GSM

Il existe des services tout prêt permettant ce genre de prouesse mais malheureusement ces services sont dimensionnés pour des cas ayant plusieurs machines à superviser (comme une industrie) et serait donc un coût beaucoup trop élevé pour notre cas particulier.

  • Troisième idée : Étendre le réseau Wi-Fi jusqu’aux fours à tabac grâce à des répéteurs

Contrairement aux 2 autres solutions celle-ci n’implique qu’une simple vérification logicielle et physique des relais afin de s’assurer de leur bon fonctionnement, et dans le cas échéant le remplacement du matériel. Les facteurs d’erreurs potentielles seront les intempéries puissantes.

La solution finale a donc été le choix de la troisième idée : Étendre le réseau Wi-Fi et donc connecter 2 Raspberry Pi entre elles via le SGBD (Système de Gestion de Base de Données) MySQL.

              b) Architecture

Pour plus de clarté voici un schéma des différentes connexions :

Les 2 RaspBerry Pi sont reliées entre elles via le Wi-fi. L’un occupe la fonction de serveur MySQL et donc stockera les données ainsi que le site Web et l’autre sera la client MySQL.

Le tabaculteur accède aux données depuis son ordinateur (ou son smartphone) seulement si il est connecté en Wi-Fi.

Et voici également un schéma du trafic de données :

Chaque RaspBerry Pi possède un identifiant pour se connecter à la base de données, ainsi que le Site Web qui utilise un autre identifiant afin d’éviter des modifications non voulues.

Toutes les secondes, les données sont transmises à la base de données, 1 table pour chaque four. Une fois en situation réel, on pourra espacer la transmission des données (jusqu’à 15 minutes) vu que le processus complet dure une semaine et qu’une erreur de température n’est fatale qu’après 1 ou 2 heures.

B) Accès à Distance et Interprétation

(Beaupere)

Sur le RaspBerry Pi Serveur, nous avons codé une page a l’aide des langages de programmation Html5, CSS et PHP. Il a été pensé comme une application Web pour simplifier sa compréhension et son utilisation par le tabaculteur. Le résultat est le suivant :

Page d’accueil pour accéder aux dernières mise à jour des fours, ainsi qu’une ‘‘Led’’ de couleur verte ou rouge pour les alarmes de température ou de défaut matériel.

Page détaillé d’un four pour suivre l’avancement sur le cycle hebdomadaire. En bleu, le cycle idéal et en noir, qui apparaîtra au fur et à mesure du cycle, nous verrons le cycle actuel.

 

Vidéo de présentation


Remerciements

Merci à nos professeurs référents M. BAZEILLE et M. VERRIER et l’IUT.Lab pour le matériel.


Table tactile « FTIR »

Table Interactive

 

 Giudilli – Merimeche – Vessot – Binder

 

 

 

 


SOMMAIRE

 

  1. Phase d’étude
    1. Présentation du projet
    2. Matériel en possession
    3. Répartition des tâches
    4. Recherche de matériel
    5. Conception du prototype
    6. Conception de la table
  2. Phase prototypage
    1. Réalisation du prototype
    2. Polissage du polycarbonate
    3. Connections des LEDs avec des fils
    4. Connections des LEDs avec des PCB
    5. Fabrication de la surface de couplage
    6. Assemblage
  3. Phase réalisation
    1. Réalisation de la table
    2. Soudure des LEDs
    3. Programmation
    4. Jeux
    5. Démonstration
    6. Améliorations possibles

 

 


Introduction

 

Lors de notre deuxième année de DUT GEII, nous avons proposé nous-même un projet à nos professeurs. C’est ainsi que nous avons choisi de travailler sur la conception et la création d’une table interactive. Il s’agit d’une table dotée d’un écran tactile et qui peut être utilisée de différentes situations, comme lors de réunions ou simplement pour se divertir, dessiner ou jouer.

Nous tenons à remercier Messieurs Verrier et Bazeille, nos professeurs, qui nous ont encadré lors de ce projet et sans qui il n’aurait pas été possible.

 


1. Phase d’étude

   1. Présentation du projet

 

Notre table tactile est basée sur une technologie nommée “FTIR” (Frustrated Internal Reflection).  Pour mettre en place un tel écran, il faut d’abord une plaque translucide entourée de leds infrarouges.  Cette plaque servira de support aux rayonnements infrarouges des leds qui se dispersent de manière uniforme dans ce support.

Lorsqu’un doigt est posé sur la surface, nous modifions le comportement de la lumière infrarouge dans la plaque. Une partie de cette lumière est alors déviée vers le sol et grâce à une caméra infrarouge, nous pouvons repérer cette modification sous la forme de “blobs”.

En traitant les images reçues de la caméra, nous pouvons déterminer à quel endroit simuler un clic de souris sur l’ordinateur.

Le choix de cette méthode dite “FTIR” est intéressant car nous pouvons utiliser un vidéoprojecteur pour afficher l’écran de l’ordinateur. En effet le vidéoprojecteur émet de la lumière visible et ne perturbe donc pas notre système infrarouge.

Cependant afin de pouvoir projeter sur l’écran (qui est entièrement transparent), il faut rajouter une surface de couplage légèrement opaque. Cette surface de projection, comme visible sur le schéma, permet aussi d’améliorer la réflection de la lumière infrarouge lorsque nous touchons l’écran.

   2. Matériel en possession

 

Pour réaliser notre projet l’IUT nous a prêté un vidéo projecteur et un Raspberry Pi 3 pour réaliser le traitement d’image et la programmation de la détection de blob et le tracking.

   3. Répartition des tâches

 

Nous nous sommes réparti les tâches afin que tout le monde puisse contribuer au projet. Nous avons tous réalisé de la surface de couplage. M. Merimeche a fait la conception et la réalisation de la table, il a fait la recherche des caméras que nous pouvons modifier afin de lui enlever son filtre infrarouge. M. Vessot s’est occupé de la recherche des composants pour l’écran, a réalisé le schéma électrique et le soudage des LED.  M. Giudilli s’est occupé surtout de la programmation et du polissage du polycarbonate du prototype. M. Binder s’est occupé de l’organisation du projet et du polissage du polycarbonate de la table. Quand une personne avait fini sa tâche, il en aidait une autre afin d’aller plus vite.

   4. Recherche de matériel

 

Il nous a fallu rechercher un écran transparent, nous pensions à une plaque de plastique. Après de nombreuses recherches, nous avons opté pour un écran en polycarbonate.

Nous avons dû ensuite chercher une webcam sur laquelle le filtre infrarouge est facile à enlever, nous avons retenu quelques modèles :

  • Sony Playstation Eye Camera
  • Philips SPC900NC
  • Logitech QuickCam Express
  • Microsoft LifeCam VX-1000

Nous avons finalement choisi la Sony Playstation Eye Camera car elle était plus facile à obtenir et dans un délai rapide. Cependant après certains tests, nous avons tout de même changer l’objectif de cette caméra pour mieux détecter les infrarouges et supprimer le visible.

   5. Conception du prototype

 

Il nous a fallu d’abord concevoir un prototype avant de commencer la table tactile. Ce prototype a d’abord été modélisé en 3D sur le logiciel Fusion 360. De dimension raisonnable (40*20*20 cm), il permettait d’être transporté facilement et de simuler correctement le comportement d’une table tactile grandeur nature.

   Le prototype modélisé sur Fusion360

 

La fente supérieure permet d’accueillir une plaque de polycarbonate de 10x20cm avec sa surface de couplage ainsi que les leds infrarouges qui l’entourent. Ce prototype intègre une partie amovible à l’avant (en rouge) pour faciliter l’installation de la caméra sous l’écran.

Nous avons choisi de maintenir les leds autours de l’écran en utilisant des profilés en aluminium

   6. Conception de la table

 

Après des essais concluant sur le prototype, nous avons modélisé notre table tactile en 3D. Ce modèle nous a permis de quantifier le matériel nécessaire (bois et visserie). Nous nous sommes inspirés de différents modèles de tables et d’établis pour concevoir une table solide et non bancale.


2. Phase prototypage

   1. Réalisation du prototype

 

Le prototype a été réalisé à la découpe laser selon le modèle vu précédemment. Voici son apparence une fois les différentes pièces montées.

   2. Polissage du polycarbonate

 

La lumière ne passait pas bien dans la plaque de polycarbonate. De ce fait, nous avons dû la polir à l’aide du papier à poncer, du fil de fer et une dremel.

   3. Connection des LEDs avec des fils

 

Nous avons choisi d’utiliser une alimentation d’ordinateur pour alimenter nos leds. Cette alimentation à une tension de 3.3 V à ses bornes et est capable de délivrer jusqu’à 33A. Ainsi, nous avons dimensionné nos résistances sur 18 Ω pour que nos leds puissent bénéficier d’un courant optimal. Toutes les leds étaient placées en parallèle.

Voici le schéma électrique :

 

Dans un premier temps, nous avons voulu connecter les LEDs avec des fils sur le prototype, cependant il s’est avéré que cette connection n’était pas adaptée pour ce prototype.

Ils y auraient eu trop de fils, l’isolation aurait été très compliqué à réaliser sur l’ensemble du prototype qui comportait déjà 15 LEDs. Nous avion donc un problème au niveau de l’espace que nous avions pour les fils et aussi de l’isolation du système. Nous avons donc cherché une autre méthode qui résolvait ces deux problèmes.

 

   4. Connection des LEDs avec des PCB

 

Afin de pallier aux problèmes de dimension et d’isolation du schéma électronique, nous avons opté pour une méthode de connections avec PCB. Cette méthode nous permet en effet de gagner beaucoup de place dans le prototype car la soudure des LEDs est faite sur le PCB à des petits fils. Cela a donc permis un gain de place important, pour résoudre le problème de l’isolation, le PCB en lui-même était déjà bien adapté pour isoler le système électronique, mais nous avon rajouté par-dessus de la colle qui permettait d’isoler les parties un peu plus vulnérable que le PCB ne pouvait pas protéger.

Nous avons donc vu que ce système est très pratique pour un schéma électronique de petite taille et avec un courant peu élevé (jusqu’à 1,5A). Cependant pour un schéma électronique plus grand, le choix des PCB aurait été trop coûteux, nous avons donc dû chercher une autre méthode pour la table.

   5. Fabrication de la surface de couplage

 

La surface de couplage à deux fonctions : elle sert à afficher l’écran via le vidéoprojecteur et à mieux détecter les doigts. Elle a été créée à partir d’une feuille de papier calque (ayant les mêmes dimensions que la plaque de polycarbonate) qui a été enduit d’un mélange de silicone et de diluant.

   6. Assemblage

 

Nous avons installé les différentes composantes du prototype vues dans les parties précédentes sur la maquette.


3. Phase réalisation

   1. Réalisation de la table

 

Une fois la commande de bois reçue, nous avons découpé les planches et les chevrons en se basant sur la modélisation 3D pour les dimensions. Nous les avons ensuite assemblés.

Une fois la table montée nous avons installé la plaque de polycarbonate par-dessus. Ensuite, nous avons rajouté autour de l’écran les profilés U avec les leds et la surface de couplage a été posée par-dessus.

   2. Soudure des LEDs

La solution que nous avons choisie pour connecter les leds entre elles sur la table est de modéliser nos propres PCB en bois et de les fabriquer avec la découpe laser.

    PCB en bois modélisé en 3D

 

   Soudure des leds

 

   3. Programmation

 

Traitement flux d’entrée : Pour repérer uniquement les changements effectué sur l’image d’entrée nous soustrayons l’image acquise par une première image prise lorsqu’il n’y a aucun doigt de posé. Ensuite nous appliquons différents filtres pour supprimer le bruit de fond dû à la caméra.

 

Détection des blobs : Comme nous l’avons vu précédemment, notre système infrarouge permet de repérer les doigts posés sur l’écran sous la forme de “blobs”.

 

Tracking : La détection de blob nous permet d’avoir un tableau de coordonnées représentant les différentes positions de chaque blob. Pour identifier ces derniers et les différencier un algorithme de proche en proche programmé par nos soins est utilisé ainsi chaque blob se voit donner un ID unique nous permettant de le différencier.

 

Calibrage : La webcam étant en train de filmer avec un grand angle, il fallait donc lui donner à travers le programme les dimensions de l’écran. Aussi, cette caméra n’étant pas totalement droite par rapport à l’écran, l’image reçue n’était pas 100% rectangulaire. Pour cela notre programme intègre une partie de calibrage. Il faut lui donner 4 positions sous la forme de blobs (en posant nos doigts) aux 4 coins de l’écran. Ainsi le programme en traitant ces données récupère les dimensions de l’écran et est capable de le redresser sous la forme d’un rectangle.

Interface et application : Les différentes parties du programme ont été regroupées sous une même interface.

 

   4. Jeux

 

Nous avons aussi programmé quelques applications qui ont été optimisées pour la table. Elles ont été programmées en C++ et à l’aide de la librairie SFML.

“Paint” : Notre Paint reprend les bases du Paint sur ordinateur et on peut être plusieurs à l’utiliser en même temps.

 

“Hanoï” : Notre jeu des tours de Hanoï reprend les règles classiques du jeu pour 3 disques, il faudra donc utiliser le tactile afin de les déplacer.

 

“Pong” : Ce jeu n’a pas encore été implémenté sur la table et nécessite 2 joueurs. Son amélioration et installation pourrait faire l’objet d’un projet futur.

 

   5. Démonstration

 

 

   6.Améliorations possibles

 

Des améliorations peuvent encore être réalisées sur notre table tactile. En voici certaines :

  • Adapter les jeux Hanoï et Pong sur la table
  • Soigner son esthétique (ponçage, peinture ..)
  • Investir dans une caméra de meilleure qualité (avec un plus grand nombre d’image par seconde notamment)
  • Porter les programmes sur un ordinateur plus puissant et l’intégrer dans la table
  • Réaliser l’alimentation des leds

 


Puissance 4 vs. Bras robot

 


 

HEBINGER Pierre   –   ECKLER Louis

 


SOMMAIRE

 

I. Préparation

  • Contexte et principe
  • Matériel et logiciel
  • Bête à cornes
  • Diagramme Pieuvre

II. Programmation P4

  • Format du code
  • Création de la logique et structure du jeu
  • Mode PvP
  • Création d’une IA
  • Ajout d’intelligence pour l’IA
  • IA logique
  • IA prédictive
  • Interface utilisateur
  • Visuelle
  • Tactile
  • Assemblage du programme (Main)

III. Bras robotisé

  • Programme embarqué sur le robot
  • Communication
  • CAO

IV. Conclusion et remerciements

 

V. Notice et Code

 

I. Préparation

Contexte et principe

 

Le but de ce projet est de créer un programme permettant à une personne d’affronter soit une personne soit une intelligence artificielle via un écran connecté à une Raspberry Pi. L’intelligence artificielle aura plusieurs niveaux de difficultés. Par la suite, il a été convenu de faire en sorte que la partie se joue sur un vrai puissance 4, avec un bras robotisé qui effectue les mouvements pour le joueur et l’intelligence artificielle.

 

Le programme devra s’exécuter sur une Raspberry Pi, c’est pourquoi notre code sera en Python. L’interface devra être également tactile, ce qui nous amène à prendre du matériel spécifique.

 

Matériel et logiciel

 

Pour le matériel, il faudra:

  • une Raspberry Pi 3
  • un écran tactile LCD 7″ Raspberry Pi Officiel
  • un bras robotisé Staübli TX40 avec une pince

 

On utilisera également comme logiciel:

  • Python IDLE
  • Staübli Robotics Suite

 

Bête à cornes

Au niveau de la bête à cornes, on aura quelque chose de plutôt simple:

 

Bête à cornes

Traduction: Grâce au programme “Puissance 4”, on rend service au joueur en le divertissant.

 

Diagramme Pieuvre

 

Pour le diagramme pieuvre, on a deux fonctions principales et six fonctions contraintes:

Diagramme Pieuvre

Fonctions principales:

  • FP1: L’information venant du programme puissance 4 devra être accessible à l’utilisateur
  • FP2: L’information devra être livrée de façon ergonomique afin d’être comprise

 

Fonctions contraintes:

  • FC1: Le projet puissance 4 devra être utilisable par un utilisateur quelconque
  • FC2: Le projet devra fournir des informations de jeu
  • FC3: Le projet devra être ergonomique lors de son utilisation
  • FC4: Le projet sera exécuté sur une Raspberry Pi en continu
  • FC5: Le projet doit être adapté à son environnement, c’est-à-dire en dans une pièce
  • FC6: Le projet ne devra pas excéder un certain coût

 

Solutions face aux contraintes:

  • FC1: L’utilisateur pourra exécuter et utiliser le programme via l’écran
  • FC2: Les informations seront affichées sur l’écran via des images (jeu sur écran) ou via du texte (jeu avec le robot)
  • FC3: Le joueur pourra sélectionner avec l’écran tactile la colonne de son choix
  • FC4: La Raspberry Pi sera alimenté sur secteur
  • FC5: Aucune protection à l’environnement n’est nécessaire du fait que le projet est utilisé en intérieur
  • FC6: Le matériel étant déjà disponible, le coût du projet est nul

 

II. Programmation P4

Format du code

 

Nous avons choisi d’utiliser majoritairement de l’anglais afin d’éviter les accents qui ne font pas partie des caractères utilisables dans les noms de fonction.

Pour les noms de fonction nous avons utilisé le préfixe “is” ou “has” pour les fonctions retournant une valeur booléenne. Puis nous avons utilisé “get” et “set” pour les fonctions retournant ou modifiant l’état d’une variable.

 

exemples:

De plus nous avons essayé de respecter autant que possible la règle disant qu’une fonction ne doit pas effectuer plus d’une seule tâche afin de rendre le code plus simple à utiliser et débugger.

 

Finalement nous avons décidé d’utiliser uniquement Python 3 car elle était déjà présente sur la Raspberry Pi et que les différentes versions de python n’ont pas toujours le même comportement.

C’est pour cela que les programmes ne fonctionnent pas sur les PC de l’IUT qui eux sont sous Python 2.7 !

 

    Création de la logique et structure du jeu

 

Dans un premier temps nous avons créé la classe au cœur de notre programme : “Tableau”

Cette dernière nous permet de stocker l’état du jeu, de lui apporter des modifications simples ainsi que de vérifier divers éléments sur l’avancement de la partie.

 

Elle se présente de la façon suivante:

L’état du jeu est stocké dans un tableau en 2 dimensions de 7 colonnes et 6 lignes, chaque case de ce tableau représente une case du puissance 4 réel.

Une case vide prend la valeur de 0, une case avec un pièce du joueur 1 prend la valeur 1 et finalement une case avec une pièce du joueur 2 prend la valeur -1.

Descriptif des fonctions

 

_init_()

Constructeur de l’objet, elle permet d’initialiser les valeurs du tableau.

getTableau()

Renvoi le tableau de valeurs du jeu.

display()

Permet d’afficher le tableau de jeu de façon ergonomique dans la console python en ajoutant le numéro des colonnes et en remplaçant les valeurs par des symboles.

getSlot()

isSlotPlayable()

Permet de savoir si la case est jouable.

getRowSlot()

Cette fonction permet d’identifier la position “y” de la case jouable dans la colonne “x”.

Si cette colonne est pleine la fonction renvoie “-1”.

 

setPiece()

isFull()

Cette fonction permet de savoir si il ne reste plus aucune case de libre dans la grille du puissance 4.

hasPlayerWon()

Cette fonction nous permet de vérifier si un des joueurs a gagné la partie en alignant 4 pièces de sa couleur. Elle nous renvoie la position x, y de la case et la direction de cette ligne dans un tableau. Si le joueur n’as pas fait de ligne de 4 pièces la fonction renvoie “false” (0).

 

    Mode PvP

 

Tout d’abord, il faut savoir que chaque niveau est représenté par un chiffre dans le code:

  • Niveau 0 : mode PvP
  • Niveau 1 : mode IA aléatoire (baptisé “Timmy”)
  • Niveau 2 : mode IA logique (baptisé “Captain Obvious”)
  • Niveau 3 et supérieur : mode IA prédictive (baptisé “Hawking”)

Dans les variables globales, on choisira donc le niveau de l’adversaire dans la variable “level”, ici 4 soit le niveau IA prédictive.

Pour la création du mode PvP ou “level=0”, nous avons simplement fait en sorte de demander au joueur 2 quelle colonne il veut jouer comme le joueur 1. Pour cela nous avons réalisé la chose suivante:

Si c’est au tour de l’adversaire (soit turn différent de 1) et si le level = 0 (soit le mode PvP), alors on demande au joueur 2 quelle colonne il souhaite jouer ( x = askPlayer( ) ) . Dans le cas contraire soit (level différent de 0) il faudra demander à l’IA de jouer.

    Création d’une IA

Une fois le système d’alternance entre joueur mis en place nous avons ajouté au code pour le deuxième joueur, la fonction askIA(). Cette fonction fait appel à différents algorithmes qui vont être chargés de retourner la colonne jouée par l’ordinateur avec une difficulté variable.

 

Dans un premier temps nous avons créé une “IA” retournant simplement une colonne jouable aléatoirement afin de tester le bon fonctionnement du code.

Ajout d’intelligence pour l’IA

    IA logique

 

L’IA logique, nommée “CaptainObvious”, doit faire en sorte de bloquer le joueur, tout d’abord en lui empêchant d’aligner 4 pièces. Si le joueur ne peut pas en aligner 4, alors il lui empêchera d’en aligner 3. Si le joueur ne peut pas en aligner 3, alors “CaptainObvious” va chercher à en aligner 3. Si il ne peut pas en aligner 3, alors il va chercher à empêcher le joueur d’en aligner 2. Le code se présente de la façon suivante:

La fonction CheckFor() permet d’identifier toutes les cases vides qu’un joueur donné pourrait jouer afin de faire une ligne de n pièces de sa couleur. Elle va nous renvoyer le résultat sous forme de tableau de position.

Exemple:

Si on effectue une vérification de 4 pièces pour le joueur 1, la fonction nous renvoie  “[1,0] [4,1]”, ce sont les coordonnées de tous les cases vides que le joueur pourrait utiliser pour faire une ligne de 4 pièces en un seul coup.

Afin de vérifier si le joueur peut réellement faire le coup permettant de mettre une pièce à une de ces positions, on se sert de la fonction isSlotPlayable(). En effet dans l’exemple suivant le coup en “[4,1]” n’est pas possible car la case en dessous est vide.

    IA prédictive

 

Cette IA représente le niveau de difficulté le plus élevé de notre programme.

Elle va se baser sur la prédiction et l’analyse de tous les états futurs possibles du jeu.

 

Pour ce faire nous avons pris exemple sur l’algorithme surnommé “minimax“, celui-ci se base sur tous les états du dernier rang pour faire sa prédiction.

Cet algorithme se base sur le fait que le joueur lui aussi, fait à chaque fois le coup le plus avantageux pour lui. Les règles sont simples, un joueur tente d’arriver au nombre le plus faible et l’autre au nombre le plus élevé.

 

Il va donc partir du bas de “l’arbre” en sélectionnant à chaque fois l’option la plus avantageuse pour chaque joueur afin d’identifier le chemin que l’IA doit prendre pour avoir le plus de chances de gagner.

 

La clé de la réussite de cet algorithme est l’identification de la valeur de l’état actuel du jeu.

Il serait en effet simple de se contenter de vérifier si l’IA ou le joueur gagne dans une branche donnée mais la puissance de calcul de la Raspberry Pi étant limitée il nous est pas possible de calculer tous les coups possible avec beaucoup de coups d’avance.

 

Nous avons donc décidé de créer une fonction attribuant une valeur à un jeu. Elle va nous retourner une valeur positive si le joueur gagne et une valeur négative si l’IA gagne. Dans le cas ou aucun des deux gagne la fonction va nous retourner une valeur intermédiaire dépendant de l’avantage qu’a un joueur. En effet si le joueur possède plusieurs options pour aligner 3 pions alors que l’IA n’en a aucune la valeur du jeu va être en faveur du joueur.

 

Pour cela elle va s’appuyer sur la fonction countPossible() qui va retourner le nombre de coups possibles qu’un joueur va pouvoir faire pour aligner un certain nombre de pièces.

Il a fallu ensuite créer une fonction permettant de simuler tous les coups possibles et de renvoyer la valeur du coup à l’IA.

Finalement nous avons réalisé la fonction permettant de faire le choix de l’IA en fonction de toutes les possibilités qui lui sont proposées.

Elle va prendre le résultat de chaque branche pour trouver le coup avec la valeur la plus faible car c’est ce coup qui va lui donner le plus de chances de gagner.

 

Interface utilisateur

 

Pour l’interface utilisateur, nous avons utilisé PyGame qui permet de créer des interfaces via Python.

Tout d’abord on définit les dimensions de l’IHM (ici l’écran tactile), la taille d’un emplacement, le titre de la fenêtre et l’ouverture de la fenêtre:

Par la suite on charge les images et on les adapte au format que l’on souhaite:

les variables red_image et yellow_image sont utilisées uniquement pour l’interface avec le jeu sur écran.

On affiche ensuite l’écran puis le fond d’écran :

La suite du programme diffère en fonction de son utilisation avec le jeu sur écran ou avec le robot.

 

    Interface avec jeu sur écran uniquement

On va donc d’abord afficher le puissance 4. Pour cela on écrit une fonction qui colle des cases bleues (slot_image) en 6 lignes et 7 colonnes soit 42 cases. La fonction est donc la suivante:

Il faut ensuite afficher chaque pièce jouée. Pour cela on regarde d’abord si c’est la pièce du joueur ou de l’adversaire qui doit être ajoutée ( tableau[x][y] == 1 ou tableau[x][y] == -1) et on affiche la pièce de couleur rouge ou jaune en fonction de ça:

 

Joueur:

Adversaire:

Au final la fonction complète sera la suivante:

Pour savoir quelle colonne le joueur souhaite utiliser, on doit recueillir l’emplacement du curseur de la souris ou du doigt avec l’écran tactile.

 

position[0] correspond à la position en x du curseur.

position[1] correspond à la position en y du curseur.

 

On cherche d’abord à voir si le curseur est posé sur une case et non en dehors du puissance 4, on va donc vérifier de la façon suivante:

Si la position en x est inférieure à la position en x de la case la plus à gauche ou supérieure à la position en x de la case la plus à droite, alors on return -1 pour signifier que le curseur est en dehors du jeu.

 

De même, si la position en y est inférieure à la position en y de la case la plus en bas, on return -1 pour signifier que le le curseur n’est pas dans le jeu. Nous avons décidé de ne pas faire de même si le curseur est au dessus de la case la plus haute pour que le joueur puisse poser sa pièce au dessus du jeu, afin de paraître plus réel.

 

Si le curseur est dans le jeu, alors on return la position en x du curseur.

 

La dernière fonction utilisée pour l’interface permet d’animer cette dernière. Lors de la pose d’une pièce, on souhaite la faire défiler du haut de l’écran jusqu’à son emplacement. Pour cela, on définit d’abord la hauteur de début (startheight = 0) et la hauteur finale qui dépendra de l’emplacement de la pièce jouée. On fait avancer la pièce et on réaffiche le fond d’écran, puis la pièce ajoutée, puis le puissance 4 et les autres pièces et on on affiche le tout.

La fonction est donc représentée de la manière suivante:

Le rendu visuel sera donc le suivant:

la zone avec le contour rouge représente la surface sur laquelle on peut cliquer pour mettre une pièce dans la colonne n°0.

 

Interface avec jeu via le robot

 

Pour l’interface avec le robot, on n’affichera pas autant d’éléments que pour une partie sur l’écran uniquement. On n’affichera qu’une ligne du puissance 4 et on n’affichera pas les pièces, étant donné que l’utilisateur les verra en vrai. On laissera donc l’utilisateur choisir uniquement la colonne de son choix.

Pour l’affichage des cases on aura donc ceci:

Étant donné qu’on n’aura qu’une ligne, la fonction qui prend la position en x du curseur change également:

Il ne reste donc plus qu’à utiliser ces fonctions dans le code principal (Main).

Voici une image montrant l’écran lorsque qu’on joue avec le robot:

 

 

    Assemblage du programme (Main)

Diagramme des classes

Tout d’abord, on importe les autres fichiers:

Afin de pouvoir faire plusieurs actions en même temps, on utilise le threading.

On initialise par la suite toutes les variables vues dans les programmes précédents:

On initialise le tableau, puis on définit que le premier à jouer sera le joueur. On met le level à 4, soit l’IA prédictive et on définit que la variable qui arrête l’affichage est a False.

 

On affiche le jeu:

On crée une fonction qui va demander au joueur quelle colonne il souhaite jouer.

 

On regarde d’abord si le joueur veut quitter le jeu ou si il a cliqué pour jouer:

Si le joueur veut quitter le jeu, on renvoie x = -2.

Si le joueur a cliqué, on vérifie qu’il a cliqué dans une colonne, sinon on envoie un message à l’utilisateur:

“le nombre choisi doit être entre 0 et 6, veuillez réessayer”.

Si le joueur a cliqué dans une colonne mais qu’elle est pleine , on envoie un message à l’utilisateur:

“la colonne est pleine, veuillez en choisir une autre”.

Si le joueur a cliqué dans une colonne est qu’elle n’est pas pleine, on renvoie la valeur de x.

La fonction complète est la suivante:

 

 

On crée également une fonction qui va demander à l’IA la colonne qu’elle souhaite jouer via AITread.

C’est à ce moment qu’on va utiliser le threading. En effet, pendant que l’IA va calculer la colonne qu’elle doit jouer, on doit continuer à rafraîchir l’écran pour éviter un “freeze” de l’application.

 

A nouveau, si le joueur cherche à quitter le jeu, on renvoie la valeur x = -2.

Si le joueur ne souhaite pas quitter le jeu, on arrête le threading et on récupère la réponse de l’IA.

 

Le code de la fonction est le suivant:

 

La fonction IATread va donc recueillir la réponse de l’IA. En fonction du niveau de l’IA, on va demander la réponse à l’IA correspondante:

On crée la boucle de jeu. On regarde d’abord à qui est le tour. Si c’est le tour du joueur, on va utiliser la fonction askPlayer(). Si c’est le tour de l’adversaire, on regarde si l’adversaire est un autre joueur (mode PvP avec level = 0), sinon on utilise la fonction AskIA().

 

Si la valeur de x est de -2, on met la variable quit_game à True, la partie s’arrête.

 

Sinon, on utilise slotAnimation pour afficher la pièce qui rentre dans le puissance 4.

Quand l’animation est finie, on définit la place de la nouvelle pièce.

On affiche le fond d’écran, les pièces et le puissance 4. On aura donc le code suivant:

On vérifie par la suite si quelqu’un a gagné: si c’est le joueur 1 qui gagne, on lui envoie “Le joueur 1 a gagné”. Sinon, on regarde si c’est le joueur 2 qui gagne et on envoie le message “Le joueur 2 a gagné”. On fait de même avec l’IA, avec un message personnalisé en fonction du niveau de l’IA. Enfin, on arrête le programme.

 

Si personne ne gagne, on vérifie si le puissance 4 est plein, dans ce cas là on envoie le message “Personne ne gagne, retente ta chance” et on arrête le programme.

Sinon, on passe le tour à l’autre: turn = turn * (-1).

On a le code suivant:

On crée une autre boucle qui vérifie si le joueur souhaite quitter le jeu:

 

Main version robot

 

Dans cette version nous avons simplement repris le code déjà écrit pour le main précédent et nous y avons ajouté les éléments permettant d’interagir avec le robot.

Diagramme des classes version Robot

 

La classe “DisplayRobot” est une version simplifiée de la classe “Display”. en effet il n’est plus nécessaire d’afficher l’état du jeu sur l’écran vu que nous pouvons le voir en réel. Son but est simplement de proposer à l’utilisateur une grille simplifiée pour qu’il puisse choisir ou le robot doit jouer.

 

On ajoute aussi la nouvelle classe “SocketCom” qui permet, à l’aide de la fonction “sendSocketToRobot()”, d’envoyer les coups joués au robot, on reviendra plus en détail sur cette classe dans la troisième partie.

Il a fallu ici encore faire appel à des threads pour pouvoir envoyer les données au robot car une fois de plus le programme ne peut pas se permettre d’attendre le robot. Cette technique permet au programme de continuer à exécuter sa boucle principale tout en attendant que le robot confirme la réception des données.

On va utiliser une variable “SocketComState” afin de resynchroniser le programme une fois le message envoyé.

Voici une vidéo de présentation du projet puissance 4 avec le jeu sur écran:

III. Bras robotisé

Étant donné que nous n’avions pas utilisé tout le temps consacré au projet après avoir finalisé le programme, nous avons eu pour nouvel objectif de prendre notre programme et de faire jouer un robot sur un vrai puissance 4.

    Programme embarqué sur le robot

 

En premier nous avons écrit le code qui va être exécuté sur le robot.

Celui-ci va stocker la position des piles de pièces ainsi que l’emplacement du plateau de puissance 4. Il va pouvoir recevoir la colonne et la couleur de la pièce jouée par le joueur ou l’IA.

 

Le programme est initialisé par la fonction start qui va se charger de placer le robot à sa position de départ et d’initialiser la hauteurs des piles de pièces.

C’est elle aussi qui va configurer le port du serveur Socket en “timeout” (temps d’attente) limité car on ne connaît pas le temps que va prendre le programme pour envoyer les données au robot (le joueur humain pouvant attendre des heures avant de faire un coup si il le veut). Finalement elle va appeler la fonction “p4” qui  s’occupe de la réception des données et du calcul des mouvements du robot.

La fonction p4

Cette fonction contient la boucle principale du programme.

Elle va attendre les données de la Raspberry Pi avec la fonction “sioGet” qui prend comme argument le serveur Socket configuré au préalable dans les configurations du robot et une variable de sortie “nCom” qui va stocker les données reçues. La fonction “clearBuffer()” permet de supprimer les données après leur lecture afin que le serveur puisse recevoir les données du prochain coup.

 

Après avoir calculé les positions de déplacement du robot on va faire appel à la fonction “mouvement()”  qui elle, va ajouter les vitesses et les points d’approche des mouvements du robot ainsi que la gestion de l’ouverture et de la fermeture de la pince.

On a par la suite ajouté un delay avant que le robot lâche les pièces car les pièces qui restaient légèrement collées à la pince se voient projetées en arrière.

 

Il ne reste donc plus qu’à transmettre les coups du programme au robot afin qu’il puisse les réaliser sur le plateau du puissance 4.

Communication

A la place d’afficher les différents coups des joueurs sur l’écran nous devons désormais envoyer ces derniers au robot. Pour cela nous avons créé une nouvelle librairie du nom de “SocketCom”  (pour la communication par socket).

 

Dans un premier temps nous avons mis en place une convention d’envoi des données aussi utilisée lors de la réception du coté robot.

Les données sont envoyées en paquet de 3 char (nombre de 8 bits). Le premier donne la colonne jouée, le deuxième la couleur jouée et le troisième est utilisé pour envoyer des commandes au robot. Si ce dernier est à 1 par exemple, le robot va automatiquement arrêter le programme et ainsi ne pas être dangereux. Comme le robot ne contient aucune intelligence cela est le seul moyen pour lui de savoir quand la partie est terminée.

La fonction “moveRobot” se charge de la création du message à transmettre et de la boucle d’envoi du message qui s’assure que le robot a bien reçu le message avant de continuer.

La fonction chargée de l’envoi du message est “sendMoveToRobot”. Elle crée la connection avec le robot, encode le message et le transmet au robot.

    CAO

(Conception Assistée par Ordinateur)

 

L’utilisation du bras robotisé entraîne des contraintes que nous avons dû gérer. En effet, les vibrations causées par le déplacement du bras font bouger le puissance 4, ce qui provoque une imprécision notable. Il est donc nécessaire de faire en sorte que le puissance 4 reste stable. Pour cela nous avons eu l’idée de créer un support permettant de caler le jeu sur la table, qui soit en plus installé de manière non définitive. Le support a donc été créé avec le logiciel Corel Draw et une découpeuse laser.

Le support est en bois et est muni de deux encoches pour insérer les pieds du puissance 4 ainsi que deux emplacements gravés afin de savoir ou poser précisément les piles de pièces rouges et jaunes.

Étant donné que le puissance 4 sera utilisé dans la salle où se trouve le Staübli, la table utilisée est munie d’encoches comme vous pouvez le voir ci-dessus. Nous avons donc créé une encoche dans chaque coin du support afin de le fixer à la table, comme ci-dessous:

Suite à cela, malgré le fait que le puissance 4 soit stable, nous avons remarqué que le nombre de pièces tombant en dehors du puissance 4 reste conséquent (environ 7% des pièces tombent en dehors lors d’une partie).

 

Après plusieurs observations, nous avons conclu que cette imprécision peut provenir de différents éléments:

 

  • Les pièces collent parfois à la pince
  • Le robot peut avoir une erreur de 2mm sur un mouvement
  • Le robot n’est pas bien calibré à la table

 

Une des solutions possible est d’ajouter une mousse sur la pince pour que les pièces ne collent plus. Cependant cela n’aurait pas suffit car même lorsque les pièces ne collent pas il arrive que la pièce tombe en dehors du puissance 4.

 

C’est pourquoi nous avons décidé de créer une goulotte afin d’agrandir la “zone de chute” de la pièce. Nous avons donc à nouveau utilisé Corel Draw afin de créer la goulotte. Cette fois-ci nous avons utilisé du plastique bleu, afin d’avoir la même couleur que le puissance 4.

La forme du puissance 4 nous a permis de réaliser une goulotte amovible. Le puissance 4 n’a donc pas été modifié directement, il peut être utilisé sans goulotte.

Après plusieurs essais avec la goulotte, nous avons observé une erreur de 0%. La solution est donc validée.

Voici une vidéo de présentation du programme en action, joué avec le Staübli:

IV. Conclusion et remerciements

 

Nous tenons à remercier avant tout M.VERRIER Nicolas ainsi que M.BAZEILLE Stéphane pour nous avoir aidé pendant le projet. Nous tenons également à remercier M.DE SABBATA qui nous a été d’une grande aide pour la réalisation de la CAO.

 

En conclusion, nous pouvons affirmer que ce projet nous a offert une expérience non négligeable dans le domaine de l’informatique, la robotique et  la CAO. Ce projet nous a également appris à nous partager les tâches en fonction des nos compétences et surtout à travailler durablement en groupe. Nous sommes d’autant plus heureux de savoir que ce projet sera utilisé lors des portes ouvertes de l’IUT de Mulhouse.

 

Quant aux améliorations éventuelles à réaliser sur ce projet, il serait possible de rajouter un deuxième bras robotisé qui puisse jouer contre le premier. Cela servirait donc à faire une démonstration du programme devant les spectateurs. Nous avons également pensé à rajouter une caméra visant le puissance 4 afin de pouvoir faire jouer directement l’utilisateur sur le puissance 4, cependant le robot Staübli n’étant pas fait pour une utilisation ludique, la sécurité ne serait pas assurée. Pour ajouter des fonctionnalités au robots, on pourrait néanmoins faire en sorte qu’il ouvre la grille en fin de partie et qu’il empile les pièces sur deux piles. Il faudrait alors rajouter une caméra en plus.

 

V. Notice et code

 

Vous trouverez ci-dessous les liens utiles:

  • La notice d’utilisation du projet:

https://drive.google.com/file/d/1QyNU8MFcEi8Y3eGVnGr0a0IhyVS3yis5/view?usp=sharing

  • Le code:

https://drive.google.com/drive/folders/1iRYLxJR4iJaN3XV4ZD_5T1SGecX8y07u?usp=sharing

 

Vous pouvez nous contacter aux adresses mails suivantes:

hebinger.68(at)gmail.com

louis.eckler(at)gmail.com