Calibration automatique

RAPPORT DE PROJET  2ème ANNÉE DUT GEII

Calibrage d’une Caméra à l’aide d’une mire

Année 2018/2019

Fridmann Charlie

( Rey Mathieu et Tort Anthony pour la première partie du projet )

Encadrants: Mr. Stéphane Bazeille et Mr. Martin Rebert

 

Ce document a pour but de décrire le déroulement de mon  projet effectué lors du troisième et du quatrième semestre du DUT GEII.  Il consiste en la création d’un programme permettant de calibrer une caméra à l’aide d’une mire.

Ce rapport contient l’ensemble des éléments du projet d’un point de vue technique, puis la description du fonctionnement du projet dans son ensemble. Tout en prouvant le bon fonctionnement de celui-ci.

Pour finir, l’ensemble des apport du projet d’un point de vue technique et personnel seront évoqués.

 

Sommaire :

1) Contexte du projet.

2) Prise en main de python.

3) Création de la mire.

4) Programme principale.

5) Programme du Robot.

6) Conclusion.

7) Remerciement.

Contexte du projet :

 

En traitement d’image, l’opération de calibration de caméra revient à modéliser le processus de formation des images, c’est-à-dire trouver la relation entre les coordonnées spatiales d’un point de l’espace avec le point associé dans l’image prise par la caméra. Pour cela j’ai du créer deux programmes différents. Un permettant le mouvement de la mire grâce au Robot Staubli et un second utilisant les données recueillis par la caméra afin d’effectuer les calculs et d’obtenir un bon calibrage.

J’ai eu à ma disposition pour  faire ce projet, une webcam, un raspberry pi avec écran souris et clavier et pour finir une image de mire. Je vais dans un premier temps vous parler de la prise en main de python et de la fabrication de la mire puis des programmes principaux ( python et robot ) et pour finir je vais vous présenter les résultats finaux. J’ai effectuer la prise en main de python et création de la mire avec Rey Mathieu et Tort Anthony, puis le reste du projet je l’ai réaliser seul.

 

 

 

 

 

 

Prise en main de Python :

 

 

Les premières étapes du projet ont été dédiés à la prise en main de la programmation en python. Durant cette étape j’ai appris à capturer et enregistrer une image à l’aide de la webcam, mais aussi à modifier une image et à l’enregistrer à la place de l’image précédente. Ensuite après avoir fait cela j’ai modifié mon programme afin que la caméra puisse reconnaître la mire et  récupérer un tableau de points qui sont recueillis grâce à la mire. Ci-dessous vous pouvez observer des points de couleurs au niveau des coins de la mire. Les coordonnées de ses points se retrouve sur l’image de droite sous forme de tableau. A la fin du tableau le programme indique “calibrage réussi”, ce qui signifie que la mire a bien détecté toutes les tous les points présent sur la mire.

 

 

 

 

Création de la mire  :

 

Pour créer la mire que j’ai utilisé ci-dessus, j’ai tout d’abord imprimer la photo de la mire que j’ai reçus en annexe avec le projet. Puis j’ai découpé à la scie à bois une fine plaque de bois de la même dimension que la mire. J’ai ensuite fixé à l’arrière de la planche en bois un morceau de bois plus épais afin que le robot puisse l’attraper à l’aide de sa pince. Par la suite j’ai remarqué que la webcam avait du mal à reconnaître la mire en fin de journée en raison d’un manque de luminosité. Pour régler ce problème j’ai collé des morceaux de papiers afin que les contours de la mire soit blanc. La mire était alors bien plus facilement reconnaissable par la webcam.

 

 

 

 

Programme principale :

 

Puis j’ai commencer a créer le programme principale. La base du programme permet de calibrer la caméra à l’aide de plusieurs image de la mire. Afin que le calibrage soit optimale, il faut récupérer des données de positions différentes. c’est pour cela que pour chaque photo la mire doit être dans une position et/ou angle différents. Afin de savoir si notre calibrage est bien effectué j’ai mis en place un calcul d’erreur. Plus l’erreur est petite plus le calibrage est bon. Par la suite j’ai modifier le programme afin que l’utilisateur puisse choisir le pourcentage d’erreur qu’il veut atteindre, le programme tourne jusqu’à ce qu’il atteint le pourcentage d’erreur demander. Et pour finir j’ai décidé de modéliser ces résultats à l’aide de courbe.     

 

 

 

Nous pouvons observer sur ces deux courbes que le pourcentage d’erreur est plus bas lorsque le nombre de prise est supérieur, mais le plus intéressant à observer est que sur la seconde courbes le pourcentage d’erreur stagne et ne s’améliore plus dans les dernières prises. Cela démontre les limites que l’on peut atteindre avec cette méthode.

 

 

 

Programme du robot :

 

Afin d’optimiser les mouvements de la mire j’ai du créer un programme permettant le mouvement du Robot staubli. Le programme me permettait de bouger la mire dans 20 positions différentes toutes les 5 secondes. Mais avant de pouvoir le mettre sur le Robot , les professeurs m’ont appris les règles de sécurités du Robot mais aussi a le contrôlés manuellement à l’aide de la manette. Pour les différentes position j’ai créer a chaque fois une variable différents et cela m’a posé problème car lorsque le programme est transmis au robot, chaque points doit être refait manuellement. C’est à dire que pour chaque point je devais bouger le robot à l’aide de la manette et lui indiquer lorsqu’il était à la bonne position. Pour régler ce petit problème j’ai utilisé qu’une seule variable que j’ai modifié tout au long du programme.

 

 

 

 

 

 

 

 

Malheureusement par un manque de temps je n’ai pas pu mettre en relation mes deux programmes et j’ai dû simuler moi-même les mouvements de la mire. Donc si j’avais eu plus de temps sur le projet j’aurais mis les deux programmes en relation afin d’obtenir de meilleurs résultats.

 

 

 

 

 

 

 

Conclusion :

 

En conclusion, le projet d’études et Réalisation m’a permis de découvrir et d’enrichir mes connaissances dans le domaine de la robotique et de la programmation en python. Durant ce projet j’ai dû faire face à quelques difficultés, la principale est que j’ai du faire ce projet seul comme deux de mes coéquipiers n’ont pas pus poursuivre le projet, de ce fait je n’ai pas eu le temps  de finir le projet comme je l’aurais souhaité. Néanmoins malgré ce contretemps, le calibrage de la caméras à pu quand même être effectuée manuellement et faire ressortir des résultats satisfaisants.

 

Remerciement :

 

Je tiens à adresser en premier lieu, mes remerciements aux enseignants qui m’ont aider dans la réalisation de ce projet. Tout particulièrement à Mr Bazeille et Mr Rebert,  enseignant de l’IUT de Mulhouse.

Dans un second temps je remerci l’Institut universitaire et technologique de Mulhouse, de nous avoir permis de faire plusieurs projets durant notre cursus de DUT, ce qui nous à permis d’enrichir nos connaissances dans différents domaines.

 


Hanoi

PROJET HANOI

 

Résultat de recherche d'images pour "photo robot tx60"

CRIQUI JULES – SCHABAT SIMON

2018-2019

 

 


SOMMAIRE

 

I. Introduction
     Présentation du sujet

     Matériel utilisé
c   Présentation du groupe
  Distribution du temps

 

II. Objectifs
     Résultats attendus

 

III. Partie sur Raspberry pi
     Détection d’angles
     Détection d’une couleur
     Application d’un filtre de couleur
     Interface graphique

 

IV. Partie communication
     Mise en place client-serveur
     Création socket

 

V. Partie sur l’environnement Stäubli
     Réception de l’information
c   Traitement de l’information

 

VI. Amélioration
     Ajout d’un ultrason

 

VII. Problèmes rencontrés
     Partie Stäubli
  Partie Raspberry pi

 

VIII. Résultats

 

IX. Conclusion et remerciements

 

 


 

I.Introduction

 

1. Présentation du sujet

 

Dans le cadre de la 2ème année du DUT Génie Électrique et Informatique Industrielle, nous avons dû réaliser un projet mettant en pratiques nos connaissances. Plusieurs projets nous on été présentés et ce projet nous a particulièrement intéressé. Accompagnés de nos tuteurs, M. BAZEILLE Stéphane et M. REBERT Martin, nous avons eu 100 heures pour atteindre les objectifs attendus. Notre projet consiste à automatiser un système à l’aide d’un nano-ordinateur.

Les tours de Hanoï (originellement, la tour d’Hanoï) sont un jeu de réflexion consistant à déplacer des disques de diamètres différents d’une tour de « départ » à une tour d’« arrivée » en passant par une tour « intermédiaire », et ceci en un minimum de coups. Le joueur ne peut pas déplacer plus d’un disque à la fois et ne peut placer un disque que sur un autre disque plus grand que lui ou sur un emplacement vide.

Voici un exemple de la résolution des tours de Hanoï avec 4 disques :

 

Le but de notre projet n’est pas simplement de résoudre les tours de Hanoï mais d’automatiser la résolution à l’aide d’un robot.

 

L’utilisateur place la tour sur une des colonne résolution Hanoï, ensuite la caméra prend une photo, traite l’image pour connaître son emplacement et le nombre de pièces. Si la tour est située sur la première colonne ( colonne gauche ) la résolution sera directement effectuée. Si la tour est placée sur la colonne du milieu, alors la tour sera déplacée pièce par pièce sur les colonnes déplacement pile. Si la tour est située sur la dernière colonne ( colonne de droite ), la résolution ne sera pas effectuée car la tour se situe déjà sur la colonne finale.

 

2. Matériel utilisé

 

Pour réaliser notre projet nous avons eu à disposition un robot de la marque Stäubli, un nano-ordinateur de la marque Raspberry pi, un ultrason et une caméra.

Le robot Stäubli est un robot utilisé dans le monde de l’industrie permettant d’automatiser des tâches offrant davantage de productivité et de performances qu’une personne. Dans notre projet, nous avons utilisé un robot TX60 6 axes pour déplacer les pièces :

Résultat de recherche d'images pour "photo robot tx60"

c                                                                                                         Robot Stäubli TX60

 

La caméra nous a permis de prendre des photos qui seront traitées à l’aide du Raspberry pi.

Logitech C270   Résultat de recherche d'images pour "raspberry pi"

c                          Caméra Logitech C270                                                       Raspberry Pi

 

L’ultrason nous permet de détecter la présence de la tour.

 

c                  Capteur ultrason HC-SR04

 

3. Présentation du groupe

 

Le groupe est composé de 2 personnes, CRIQUI Jules et SCHABAT Simon. Chaque personne s’est occupée de l’écriture du code en python ( langage de programmation ). CRIQUI Jules s’est occupé d’exécuter le programme et d’enregistrer les positions initiales sur le robot, il s’agit de déplacer le robot manuellement (commande libre) à un endroit précis pour que le robot sache où est placée la tour. SCHABAT Simon s’est occupé de la simulation logicielle du robot, cette partie consiste à écrire et tester le programme.

 

4. Distribution du temps

 

Notre projet a duré 100 heures. Voici la répartition du temps des différentes parties du projet :

Les deux parties les plus longues ont été l’écriture des programmes python et Stäubli.

 


II. Objectifs

 

1. Résultats attendus

 

L’objectif initial de ce projet était de connaître la position de la tour peut importe son emplacement, composé de trois personnes. La charge de travail a été diminuée car nous étions seulement deux personnes. L’objectif final a été modifié, nous ne pouvons mettre la tour à 3 endroits possibles. Ceci facilite grandement le projet car traiter une image avec autant de précision demande du travail supplémentaire et donc une autre personne.

Le nouvel objectif est alors de trouver sur quelle colonne est placée la tour et de déterminer le nombre de pièces pour ensuite résoudre Hanoï et/ou déplacer la tour.

 

 


III. Partie sur Raspberry

 

1. Détection d’angles

 

La première méthode que nous avons utilisé est une détection d’angles. Pour cela, nous allons prendre une photo globale de l’environnement des tours puis nous allons effectuer un zoom dans l’image pour isoler la tour.

Nous avons ensuite exécuté un algorithme pour détecter les angles.

Nous remarquons que l’algorithme détecte des angles (correspondant aux points sur l’image), les points ne sont pas très visibles à l’écran, nous avons alors changé la couleur des points.

Cela ne correspond pas aux résultats attendus, cette méthode n’est donc pas fiable. Nous allons alors utilisés une autre méthode.

 

2. Détection d’une couleur

 

La tour étant métallique, elle reflète énormément ce qui nous empêche de traiter l’image correctement. Nous avons alors décidé de scotché la tour pour supprimer les reflets et d’uniformiser la couleur de la tour.

 

Nous avons ensuite créée un algorithme pour ne garder que la couleur bleu de la tour.

 

c                             Résultat

On constate donc que la tour n’est pas isolée de l’environnement. Pour tester si notre programme fonctionne, nous avons pris du bleu pur et appliqué le programme.

Nous remarquons que notre programme fonctionne car il a gardé le carré bleu. On peut en déduire que le bleu de la tour n’est pas un bleu pur mais composé de plusieurs couleurs. Sachant qu’un pixel est composé de Rouge, de Vert et de Bleu (RGB), nous allons utiliser un logiciel (GIMP) pour connaitre la composition des pixels de la tour.

 

3. Application d’un filtre de couleur

 

Sachant qu’une image est un tableau composée de pixels, nous avons comparé chaque pixels de l’image avec le filtre que nous avons défini à l’aide du logiciel GIMP. Nous avons sélectionné le pixel la plus clair et le plus sombre pour déterminer les bornes du filtre. Nous appliquons donc ce filtre à l’image prise avec la caméra, les pixels compris dans le filtre sont gardés puis remplacés en blanc et les pixels exclus sont remplacés par du noir.

Voici le résultat du filtre :

Nous pouvons voir que des parties de la tour ne rentrent pas dans le filtre. On a donc utilisé un algorithme permettant de combler les trous.

 

A partir du résultat final, nous avons déterminé la position de la tour grâce à des intervalles. Nous avons comparé un pixel de la tour aux 3 intervalles prédéfinis. Les intervalles ont été définis de la manière suivante, nous avons pris la longueur de l’image et nous l’avons divisé par 3. Ainsi nous avons des intervalles de même taille.

 

Pour déterminer le nombre de pièces, nous avons travaillé avec la hauteur de la pile. Pour connaitre cette hauteur, nous avons pris le pixel blanc le plus haut dans l’image et le pixel le plus bas. Nous avons ensuite soustrait leurs coordonnées en Y pour connaitre la hauteur de la tour. Connaissant la hauteur d’une pièce à l’aide du logiciel GIMP, nous avons ensuite divisé la hauteur totale avec la hauteur d’une pièce. Nous avons arrondie le résultat à la valeur la plus proche.

Pour résumer notre méthode, nous avons pris une photo, fait un zoom dans cette photo. Ensuite nous y avons appliqué le filtre de couleur et transformé la photo en noir et blanc. Enfin nous avons comblé les imperfections et évalué la hauteur de la tour puis sa position. Cette méthode a un inconvénient, elle ne fonctionne seulement lorsque l’environnement est sombre. Dans un environnement lumineux, il est difficile de déterminer les intervalles du filtre de couleur ne contenant que la tour.

Pour pallier au problème lumineux, nous avons modifié les paramètres de la caméra pour que la tour ressorte de l’environnement.

 

4. Interface graphique

 

Pour simplifier l’utilisation du programme, nous avons mis en place une interface graphique qui nous permet de lancer le programme lors de la présence d’une tour. Cette interface nous informe aussi sur le nombre de pièces détectés et la position de la tour. La détection de la tour s’effectue grâce à un capteur ultrason (cf Partie VI).

     

c                          Attente                                                                    Tour détectée                                                    Programme lancé

 

 


IV Partie communication

 

1. Mise en place Client-Serveur

 

L’objectif est de mettre en place une communication entre le robot et le raspberry pi. Pour que deux systèmes communiquent, il faut que l’un soit serveur, et que l’autre soit client. Le serveur attend les requêtes du client. Le client envoie des requêtes de connexion, une fois acceptées, le client peut envoyer des données. Dans notre cas, le serveur est le robot et le client est le raspberry pi.

Premièrement pour que deux systèmes communiquent, ils doivent être sur le même sous-réseau (réseau local). Les sous réseaux sont différenciés par leurs adresses IP.

Un serveur peut héberger plusieurs services, grâce aux ports nous pouvons donc atteindre le bon service. Nous avons donc configuré les adresses et les ports des deux systèmes.

Pour que deux systèmes communiquent, ils doivent être capable de lire des données, c’est pour cela que nous avons créé un socket. Un socket est un trou qui laisse passer les données.

Grâce à ce socket, nous pouvons envoyer une chaîne de caractère comme par exemple « 5_3\r ». Le 5 correspond au nombre de pièces, le 3 correspond à la colonne et le \r correspond au caractère de fin de chaîne, il détermine la fin de la réception pour le serveur.

 


V.Partie sur l’environnement Stäubli

 

1. Réception de l’information

 

Pour recevoir et stocker une chaîne de caractère, nous avons créé une variable de type « SIO » (entrées-sorties sur liaison série et socket TCP/IP). De plus, pour traiter la chaîne de caractères, nous avons créé un algorithme qui permet de séparer le nombre de pièces et le numéro de la colonne dans 2 variables différentes, comme montré ci-dessous.

 

2. Traitement de l’information

 

Une fois les deux informations stockées, le programme se lance. La tour peut être placée à 3 endroits différents : Colonne 1 , Colonne 2, Colonne 3. En fonction de la position de la tour, la résolution sera différente. Voici les 3 cas possibles :

1er cas :

Dans ce cas, la tour est placée sur la première colonne. Le programme va donc effectuer directement la résolution de Hanoï.

 

2ème cas :

 

Dans ce cas, la tour est placée sur la deuxième colonne. Le programme va alors déplacer la tour sur les colonnes déplacement pile (schéma ci-dessous).

 

Le programme va ensuite replacer les pièces sur la première colonne (schéma ci-dessous). La résolution va ensuite commencer.

 

 

3ème cas :

Dans ce dernier cas, la tour est placée dans la 3ème colonne. Le programme ne va donc rien exécuter car la tour se situe déjà dans la colonne finale.

 

 


VI. Amélioration

 

1. Ajout d’un ultrason

 

Dans le but d’améliorer le projet, nous avons ajouté un capteur ultrason qui détecte la présence de la tour. Tant que la tour n’est pas détectée, l’utilisateur ne peut pas lancer le programme via l’interface graphique. Cela sécurise le lancement du programme.

Voici la disposition réel du projet :

 

 

 


VII. Problèmes rencontrés

 

1. Partie Stäubli

 

Nous avons lancé le programme sur des cartons pour des raisons de sécurité. Nous avons eu à maintes reprises des problèmes de hauteur, le robot s’enfonçait dans le carton :

Nous avons aussi eu des problèmes pour que les deux systèmes communiquent.

 

2. Partie Raspberry Pi

 

L’écriture du programme en python était particulièrement difficile car c’était la première fois que nous utilisions ce langage. Nous manquions de connaissance sur cet environnement et lorsque nous avions des erreurs d’exécution du programme, nous ne trouvions pas l’erreur.

 

 


VIII. Résultats

 

Voici quelques tests du programme en variant le nombre de pièce et la position de la colonne :


IX. Conclusion et remerciements

 

Nous voulons tout d’abord remercier Mr BAZEILLE Stéphane et Mr REBERT Martin de nous avoir guidés et aidés tout au long du projet.

Pour conclure, ce projet a été très enrichissant pour nous car il nous a permis de découvrir dans les détails le secteur de la robotique et du traitement d’image. Ce projet en groupe nous a appris à nous partager les tâches et mettre en commun les parties de chacun, pour concrétiser à un projet abouti.

 

 


 

 

 

 

 

 

 

 

 


Vidéo surveillance

KAPPS Caroline

HOSATTE Clément

BYRON Kevin

 

 

 

Sujet donné :

Nous devions créer un système autonome capable de détecter et prendre en photo les personnes entrant dans une salle et être capable d’envoyer un fichier par e-mail avec le nombre de personnes dans cette salle. Nous avions eu 96 heures pour finir ce projet.

 

Problématique:

L’IUT est un lieu où de nombreuse personnes rentrent et sortent des salles de classe: étudiants, enseignants, chercheurs ou les personnes qui participent à l’entretien des locaux et à son bon fonctionnement au quotidien. Cette affluence quotidienne peut être la cible d’attentat ou tout simplement être la source d’insécurité liée à un nombre trop importants de personnes que l’établissement ne peut correctement assumer. Notre projet se concentrera dans la salle d’automatisme disposant de nombreux automates et dispositifs coûteux et fragile.

C’est pourquoi nous cherchons à créer un programme qui sera un capteur de présence, capable de prendre en photo le nombre de personne qui rentrent et qui sortent de la salle d’automatisme. Ce dispositif permettra donc de renforcer la sécurité de la salle.

 

Objectifs:

Notre dispositif doit être capable, à l’aide de capteurs, de déclencher une prise de photo lorsque une personne entre ou sort de la salle B4, puis d’envoyer ces photos sur l’adresse mail du professeur responsable afin de pouvoir traiter les informations obtenues.

 

Répartition des tâches :

Bête à corne :

Voici le diagramme de bête à corne pour mieux comprendre l’enjeu de notre projet.

 

Validation du besoin:

Budget/matériel:

Dans le cadre de notre projet nous avons besoin de matériel spécifique: raspberry pi, capteurs à ultrason, pi caméra et enfin un écran d’ordinateur. Tout le matériel était déjà disponible à l’IUT. Nous n’avons pas eu à engendrer de frais. Le matériel a tout de même un coup  qui est estimé au total à 128 euro :

 

Notre prototype final :

Notre prototype final est donc capable de détecter le passage d’une personne, de déterminer si cette personne entre ou sorte de cette salle. Il est capable de compter le nombre de personne actuellement dans la salle grâce à un comptage-décomptage, d’envoyer ces informations par mail et de générer un graphique du signal des ultrasons qui vont représenter les entrées et sorties.

Pour aboutir à cette solution, nous allons vous exposer le cheminement mené.

 

Cheminement :

La programmation a été faite essentiellement sous Python. Ce logiciel était pour la plus part des élèves une découverte pour son fonctionnement et son nouveau type de langage se rapprochant du langage C. Dans les premières heures de notre projet, nos deux professeurs Mr.Martin et Mr.Bazeille nous ont appris à utiliser les différentes fonctions sous Linux et programmer sous Python.

Nous avons fonctionné étape par étape dans la réalisation de nos programmes.

Le premier programme concernait les ultrasons pour détecter le passage des personnes. Pour mesurer la distance entre l’ultrason et un objet, l’ultrason va envoyer plusieurs impulsion sonore (inaudible pour l’humain) et mesurer le temps entre le moments où il émet ces impulsions et le moment où il les reçoit. On va multiplier ce temps par la vitesse du son (340 m/s) puis diviser par deux car le temps comprends l’aller retour du son.

Nous avons ensuite programmer la prise de photo avec la pi camera, qui s’enregistre dans un dossier précis et qui est nommé par la date et l’heure précise du moment où elle a était prise.

La suite était d’assembler la prise de photo déclenchée par l’ultrason, quand il détecte un objet à une certaine distance. Pour éviter de renvoyer la distance avec les murs d’en face et éviter le plus possible un défaut de passage, nous prenons en compte les mesures entre 40 cm et 2 m. Nous avons donc déjà un premier début de prototype qui détecte les passage et déclenche une photo. Mais l’inconvénient est qu’il ne dissocie pas l’entrée de la sortie. Nous l’avons donc positionner de manière à acquérir correctement les photos lorsque les personnes entrent dans la salle.

Les photos obtenues sont les suivantes:

Nous avons donc une photo où nous voyons bien quelqu’un renter mais lorsque la personne sort nous voyons à peine son dos. La photo n’est pas de grande qualité, ceci expliquer par une caméra bon marcher mais dans notre situation ça ne pose pas de problème. Mais nous avons donc dû laisser de côté l’idée d’utiliser la détection de visage à l’aide d’open cv.

A ce stade nous avons partiellement répondu aux objectifs de détection de personne et de prise de photo.

Nous décidons de continuer avec la création et le transfères des données, avant de régler la dissociation entrée-sortie de notre dispositif.

Pour cela nous créons un fichier texte qui indique la date et l’heure de chaque passage avec un compteur qui accumule le nombre de passage. Une fois fait nous créons une adresse mail pour le projets afin de pouvoir transférer ce dossier texte par mail, à travers le raspberry pi,de cette adresse mail vers celle d’un professeur. Les données collectées sont ensuite stocké dans un tableau.

 

Vous pourrez retrouver la vidéo de fonctionnement de ce premier prototype sur le site.

Pour la suite de notre projet, nous avons décidé de connecter un deuxième ultrason afin de différencier les entrées et les sorties. En dissociant ces deux paramètres, nous pouvons maintenant avoir un compteur qui nous indique le nombre de personne dans cette salle en temps réelle. Lorsque le capteur détecte une entrée, il ajoute 1 et se décrémente lorsqu’il détecte une sortie. Cependant il prends toujours en photo chaque passage, ce qui ne nous intéresse pas forcément du point de vue sortie car nous ne voyons que leur dos. Nous décidons de ne déclencher la photo que lors de l’entrée et le passage de sortie ne sert qu’à la décrémentation du compteur temps réel.

Du point de vue des capteurs, la dissociation entrée-sortie se fait en regardant quel capteur détecte le premier, le second qui envois un peu après aussi une distance n’est pas pris en compte, il nous montre juste la cohérence du système. Pour mieux comprendre ce principe nous pouvons regarder la courbe ci-dessous:

 

La courbe rouge corresponds a l’ultrason de sortie et la courbe verte à celui d’entrée. On voit ici que le capteur de sortie est déclencher le premier et que celui d’entrée est déclencher rapidement après. On peut donc en déduire qu’une personne est entrain de sortir de la pièce, le compteurs se décrémente de 1.

Cependant nous souhaitons obtenir plus de point pendant le passage dans le but d’éviter les défaut du capteur et de pouvoir identifier ces incohérence. Pour cela il a fallu accélérer le système, nous avons d’abords enlever l’affichage de la photo lorsqu’elle était prise. N’étant clairement pas suffisant nous avons enlever la prise de photo et sommes aller restreindre le programme au strict nécessaire. Mais lors de cette opération le système restait bloqué dans une boucle, il a donc fallu l’analyser et tester les différentes boucles et n’avons eu à rajouter qu’une seule condition.

Nous obtenons donc des courbes plus réalistes:

Sur cette simulation on détecte:                     1= sortie                  2= entrée                          3=sortie                               4=sortie

Après la sortie 3 on peut voir que le capteur d’entrée capte encore quelque chose on peut donc en déduire que ce n’est pas un passage, soit c’est une erreur du capteur ou alors la personne est resté un peu devant le capteur d’entrée.

 

Remerciement

Nous tenons à remercier les enseignants Mr. Martin et Mr. Bazeille pour leur accompagnement et leur présence tout au long de ce projet. Nous avons découvert et améliorer nos connaissances en python sur un projet ludique et réaliste. Cela nous a également permis de travail en équipe et de devoir se confronter à certains aléas pour les surmonter.  Nous tenons également à remercier chaleureusement Christophe De Sabatta, toujours présent pour nous apporter son aide et ses conseils. Et nous remercions pour finir l’IUT de Mulhouse pour le matériel mis à disposition ainsi que toutes ces installations qui nous ont permis de réaliser notre projet avec un matériel technique et adapter.

 


PSA Vision

Projet PSA

 

 

JENNY Lou – DRAZEVICANIN Aleksandar – VOS Quentin

 

Sommaire

I)Introduction
Présentation du sujet
Matériel à disposition
Présentation du groupe

II)Objectifs du projet
Résultats attendus par PSA

III)Partie programmation
Familiarisation avec Linux et le Raspberry Pi
Utilisation de la librairie Opencv2
Le traitement d’image avec le langage Python

IV)Problèmes rencontrés
Limite du système
Étiquette entourée d’un cadre

V)Résultats

VI)Améliorations possibles
Utilisation d’une Intelligence Artificielle
Qualité de la caméra
Meilleur système

VII)Conclusion et remerciements

 

 

 

 

 

 

 

 

I)Introduction

1.Présentation du sujet

Dans le cadre de notre 2ème année de DUT GEII, nous avons dû réaliser un projet en groupe que nous avions choisis. Il y a eu plusieurs projets présentés par Mr. BAZEILLE Stéphane, ainsi que Mr. REBERT Martin, qui étaient donc nos tuteurs pour le projet.
Le projet que nous avons choisi est celui appelé « Projet PSA ».
Nous avions à notre disposition 100 heures de projet dans l’emploi du temps, mais aussi le temps libre en dehors des heures de projet pour le réaliser.

Notre projet consistait donc à faire du traitement d’image sur une étiquette pour en extraire les caractères et les différentes informations demandées par PSA.

              Zones qui nous intéressent encadrées en vert

 

Voici une étiquette type de chez PSA qui est sur toutes les palettes disponibles dans leur entrepôt.

Nous avons donc pris conscience de ce que PSA nous demandait de faire, et le début du projet fut très flou pour nous, c’est pourquoi nous avons organisés une visite de leur entrepôt pour mieux comprendre le problème, ainsi que la situation dans laquelle il était.

C’est par le biais de cette visite, que nous avons pu comprendre clairement ce qui était demandé, et donc ce qui était désiré était donc d’extraire et d’afficher la date et l’heure de cette étiquette, pour permettre au cariste qui range les palettes de ne pas se tromper, et d’en sauvegarder la référence dans un dossier texte pour pouvoir retrouver justement la personne qui a fait une erreur sur le placement d’une palette, si une erreur se présente.

Le traitement d’image était donc le sujet de notre projet, nous devions bien comprendre comment résoudre ce problème et surtout comment le faire avec un Raspberry Pi et le langage Python, qui n’a jamais été utilisé par notre groupe auparavant. C’est aussi grâce à la librairie d’Opencv2 que nous avions pu faire notre projet.

 

2. Matériel à disposition

Pour notre projet, nous avons eu à notre disposition un Raspberry Pi, un écran tactile de Raspberry Pi, et une caméra apportée par un membre du groupe.

Caméra Logitech C270
Raspberry Pi

 

 

 

 

 

 

 

 

La caméra nous a permise d’avoir des photos de notre étiquette et de faire des tests pour notre programme de traitement d’image.

 

3. Présentation du groupe

Le groupe est composé de 3 étudiants JENNY Lou, DRAZEVICANIN Aleksandar et VOS Quentin.
JENNY Lou s’est occupé principalement de la partie programmation sur le Raspberry Pi, DRAZEVICANIN Aleksandar et VOS Quentin se sont occupés des différentes recherches pour aider sur la programmation, ainsi que des différentes recherches au sujet des librairies.

 

II)Objectifs du projet

 

1.Résultats attendus par PSA

Durant notre visite à l’entrepôt de PSA, nous avons eu certaines contraintes qui ont été présentées par les personnes sur place qui suivaient notre projet :

  • La distance entre le cariste et les palettes est d’environ 1,5 mètres
  • Afficher la zone de destination du colis (la date et l’heure présente sur l’étiquette donc)
  • Sauvegarder la référence de chaque étiquette de chaque palette pour pouvoir détecter quel cariste à fait une erreur, s’il y a une erreur

Après avoir eu ces contraintes, nous avons donc tout de suite eu les besoins suivants qui s’ajoutaient :

  • Un boîtier solide requis à cause de l’environnement de travail
  • Une batterie performante pour alimenter le Raspberry Pi
  • Une application qui va donc permettre d’avoir le programme dessus
  • Un écran tactile pour exécuter le code

C’est après cette visite que notre travail a fini par se complexifier.

 

III) Partie programmation

1. Familiarisation avec Linux et le Raspberry Pi

Notre projet fut une grande découverte au niveau du matériel à utiliser ainsi que le domaine de développement adéquat.
Nous avons dû apprendre le langage Python, qui nous a été présenté par Mr. REBERT Martin, et qui nous a aidé en cas de problème ou de questions sur le langage. Nous avons donc dû nous familiariser avec ce langage et malgré les difficultés rencontrées, c’était une expérience et un apprentissage très enrichissant pour notre groupe.

2. Utilisation de la librairie Opencv2

La librairie d’Opencv2 était celle que nous devions utiliser et qui nous offrait la possibilité de faire du traitement d’image en temps réel, et c’est grâce à ceci que notre projet a pu être mené à bien.

3. Le traitement d’image avec le langage Python

Le traitement d’image est le cœur du projet. Une fois la photo de l’étiquette prise, nous avons dû procéder par étape pour obtenir des résultats fiables.

On utilisera alors plusieurs fonctions et méthodes soit la transformée de Hough, des Homography et un traitement d’image par Pytesseract pour extraire les caractères.

 

IV) Problèmes rencontrés

1. Limite du système

Le Raspberry Pi devenait de plus en plus lent au niveau de l’exécution du code car il devenait dense à force que nous développions notre programme, et c’est pour ceci qu’un système plus rapide commençait à s’imposer car si nous voulions implémenter le système sur le terrain à l’entrepôt de PSA, il fallait avoir un système très rapide, facile d’utilisation et surtout fiable, car les caristes travaillent très rapidement, c’est pourquoi, si le système ne suivait pas la cadence, PSA ne pourrait pas le mettre en place et l’utiliser.

2. Etiquette entourée d’un cadre

Pour notre projet nous avons eu un problème pendant l’extraction des caractères de notre étiquette, en effet nous avons eu l’idée de la part de nos tuteurs, de rajouter un cadre de couleur pour pouvoir repérer l’étiquette plus facilement et pouvoir zoomer dessus et en extraire les caractères qui nous intéressent.

 

 

C’est donc cette étiquette que nous avions dû utiliser pour nos tests et surtout pour la suite de tout notre projet, c’est ce qui a pu nous débloquer car nous étions bloqués sur le traitement de notre étiquette.

Le seul problème de cette étiquette était :

  • Comment présenter ceci à PSA ?

Effectivement, comme ce n’est pas PSA qui créait ces étiquettes, il fallait que ce soit les entreprises qui faisaient les différents matériaux pour PSA qui devaient changer toute leurs étiquettes, ce qui serait impossible à réaliser.

V) Résultats

Pour ce qui est des résultats obtenus, nous avons décidés de faire plusieurs tests dans de différentes situations, qui peuvent arriver à l’entrepôt de PSA, ce sont bien sûr des situations que nous avons pu voir durant notre visite.

Voici une photo prise par notre caméra de notre étiquette, nous pouvons voir que celle-ci est de travers.
Grâce à une transformée de Hough ainsi que de la méthode de l’Homography, nous arrivons à découper notre image comme ceci :

 

 

On peut donc voir que notre programme remet l’étiquette droite et réussi à zoomer dessus, ce qui permet de la voir plus nettement et surtout de plus près, ce qui rend le tout plus facile à lire et surtout traiter.

 

Après avoir découper l’image comme ceci, nous avons appliqués un deuxième traitement sur l’image découpée, pour pouvoir enlever le cadre jaune grâce au traitement, ce qui va donner ceci :

 

Et après avoir eu cette image-là, nous avons pu faire notre extraction de caractère sur les deux zones que nous avons besoin, et le programme nous retourne bien le bon résultat :

On peut donc voir que nous obtenons bien la bonne référence ainsi que la bonne date, qui s’affiche bien comme il faut.

Cette extraction est faite grâce à Pytesseract qui permet d’extraire des caractères d’une image.

 

Après avoir eu nos résultats, nous avons essayés de nous mettre dans les conditions que nous avions pu voir à l’entrepôt, car la distance entre le cariste et les palettes est de minimum 1.5m, donc il nous faut une très bonne caméra qui puisse repérer l’étiquette sans problème à cette distance.
Les tests que nous avons faits nous donnent ces résultats :

 

 

 

Distance Référence Date et heure Date et heure d’enregistrement
30cm 106778 181210 08:30 2019/02/06  17:30
50cm 106778 181210 08:30 2019/02/06  17:32
70cm 106778 181210 08:30 2019/02/12  14:08
80cm 106778 181210 08:30 2019/02/12 14:10
90cm 106778 181210 08:30 2019/02/12 14:33
100cm 106778 [E1210 08:30 2019/02/06 17:34
110cm 106778 [EE210 08:30 2019/02/06  17:34
120cm ‘ « i’ 06778 [EE210 08:30 2019/02/06  17:35
130cm 106778 [EE20830 2019/02/06  17:36
140cm (J__G1_18 [« ‘ »ILFJE »‘ 2019/02/06  17:26
150cm IUDII6.ll EE208″JI »0 2019/02/06  17:30
160cm 2019/02/06  17:21
170cm 2019/02/06  17:26
180cm 2019/02/06  14:12

 

 

On se rend vite compte que plus la distance augmente, plus c’est difficile voir impossible d’extraire les caractères exacts de ce qui nous intéresse, voir les caractères extraits sont très, ou totalement, hasardeux.

Ceci est dû à cause de notre caméra qui n’est pas non plus une caméra de bonne qualité, c’est une webcam, et avec une meilleure caméra il est possible de pouvoir extraire exactement les bons caractères à ces distances.

On peut se rendre compte que notre programme fonctionne bien sur une distance modérée, et que l’on arrive à extraire ce qui nous était demandé, mais bien évidemment avec le cadre jaune autour de l’étiquette.

 

VI) Améliorations possibles

1.Utilisation d’une Intelligence Artificielle

Il serait possible d’utiliser une Intelligence Artificielle pour l’adapter à la situation et lui faire de l’apprentissage sur l’étiquette, pour lui permettre de découper l’étiquette, d’en extraire les caractères sans aucun problème, et ceci dans n’importe quelle situation, et surtout sans le cadre jaune que nous avons.

Nous pensons que c’est une solution qui permettrait de résoudre le problème que PSA rencontre dans son entrepôt, mais surtout par faute de moyens, et de connaissances de l’environnement, nous ne sommes pas capables de mettre en place ceci.

2.Qualité de la caméra

La qualité de la caméra était un problème que nous avions car nous disposions seulement d’une webcam bas de gamme, qui n’est pas appropriée pour ce genre de projets et pour la vision dans ce domaine.
Une solution que nous pensons être bonne serait d’intégrer un système de vision utilisable par les caristes avec une caméra dotée d’Intelligence Artificielle en elle.

3.Meilleur système

Un meilleur système est nécessaire pour pouvoir avoir une vitesse d’exécution de notre programme, une meilleure autonomie et une meilleure qualité en général.

VII) Conclusion et remerciements

Nous voulons particulièrement remercier Mr. BAZEILLE Stéphane et Mr. REBERT Martin de nous avoir guidés durant tout le projet et surtout de nous avoir permis de faire ce projet.

C’était une expérience très enrichissante pour nous car ceci nous a permis de nous faire découvrir de nouvelles choses, comme le langage Python, l’environnement Linux ainsi qu’Opencv2 qui permet de faire du traitement d’image. Ce projet nous a appris à collaborer en groupe pour s’entraider et atteindre l’objectif qui nous était demandé, dans un domaine que nous ne connaissions pas forcément.


Surveillance Parking


 

GAUDIOZ Alexandre | ZAID EL KHIL Damien

 


Sommaire

  1. Présentation du projet

    1. Contexte

  2. Cahier des charges

    1. Objectifs

    2. Ressources données

  3. Recherches effectuées

    1. Caméra et orientation

    2. Bibliothèques nécessaires

  4. Expérimentations

    1. Traitement d’image

    2. Système miniature

    3. Première version du programme

    4. Deuxième version du programme

  5. Application plus poussée

    1. Vitesse d’acquisition

    2. Analyse temporelle

    3. Deuxième version du programme

  6. Conclusion

    1. Améliorations envisageables

    2. Apports


Présentation du projet

Contexte

Notre projet « ParkWatcher » cherche à s’inscrire dans les nouveaux procédés de surveillance, partiellement ou entièrement automatisés. Basé sur un programme existant et popularisé ces dernière années, OpenCV. Notre projet consiste à traiter les images provenant d’une caméra de surveillance orientée sur un parking afin d’optimiser les nombre de véhicules pouvant y stationner en signalant tout manquement aux règles qui régissent les parkings privés et à établir des statistiques.

 

En effet, la démocratisation des véhicules particuliers pousse les institutions publiques et privées à aménager des endroits prévus pour accueillir ces derniers. Toutefois, le nombre croissant de véhicules utilisés au quotidien implique une difficulté à assurer la pérennité de ces endroits. Ces derniers temps, les parkings technologiquement équipés pullulent car nous sommes dans une optique de stockage de données afin de mieux répondre aux attentes des consommateurs, mais certains parkings ne peuvent pas s’offrir ce luxe car ils nécessitent une configuration adaptée à la lecture de plaques, à la disposition de capteurs inductifs, indiquant, avec un témoin lumineux, la disponibilité des places. C’est pour ces mêmes raisons que ces parkings sont généralement des parkings couverts.

exemple de technologie indiquant la disponibilité d’une place
Figure 1 : Exemple de technologie indiquant la disponibilité d’une place.

Mais qu’en est t il des parkings ouverts ? Le dispositif que nous avons développé est une alternative à ces infrastructures onéreuses, rendant le contrôle et l’acquisition de données plus accessibles.


Cahier des charges

Objectifs

Certains objectifs nous ont été imposés :

  1. Identification des véhicules : Détecter les différents éléments apparaissant sur le retour image de la caméra de surveillance et les identifier dans le but de les filtrer (dans notre cas, identification des véhicules et des piétons).
  2. Délimitation des places de stationnement et définition de leurs états : Identifier les places de stationnement, distinguer la disponibilité de l’emplacement, observer si un véhicule est bien ou mal stationné.
  3. Statistiques : à l’aide des relevés, établir des statistiques tels que : le temps de stationnement moyen, le nombre d’emplacements disponibles ou encore l’heure d’affluence.
  4. Affichage : Créer une interface propre, agréable, où ls statistiques et les informations sont clairement visibles et accessibles à tous les utilisateurs.
Carte heuristique détaillant les objectifs
Figure 2 : Carte heuristique détaillant les objectifs.

Ressources données

Pour mieux comprendre la suite, il est nécessaire de faire une brève présentation de ce qu’est OpenCV : OpenCV est une bibliothèque employée dans le traitement d’images. Elle est grandement appréciée car permet le traitement d’image en temps réel et est sous licence libre (BSD).

 

Afin de gagner du temps, un programme python nous a été fourni. Ce code permet d’utiliser le réseau de neurone généré par OpenCV afin de reconnaître des éléments appartenant à la base de donnée « Darknet ». Chaque élément à un identifiant propre qui lui est attribué; cet identifiant est contenu dans un “ClassId(XX)”, XX étant l’identifiant. Pour le projet nous nous sommes limités à reconnaître les personnes et les voitures, les autres véhicules n’étant pas censés circuler sur le campus et les autres objets ne présentant pas d’intérêt notable. Cette sélection est aisément modifiable.

Correspondance d’un élément avec un ClassID
Figure 3 : Correspondance d’un élément avec un ClassID.

Le programme affiche en sortie l’image ou la vidéo traitée, avec les éléments graphiques générés par OpenCV (les éléments tels que les visages, les ordinateurs, chiens, chats, voitures sont encadrés et leur nature est indiquée en haut du susdit cadre via un texte).

Exemple d’image que peut récupérer le programme de base OpenCV / Darknet à la fin de son exécution.
Figure 4 : Exemple d’image que peut récupérer le programme de base OpenCV / Darknet à la fin de son exécution.

En terme de matériel physique, il a été mis à notre disposition une Raspberry Pi 3 ainsi qu’une webcam. La Raspberry Pi 3 étant sous Raspbian, une distribution Linux, le python s’est imposé comme langage de programmation le plus adapté à nos besoins.


Recherches effectuées

Caméra et orientation

Nous avons effectué plusieurs tests pour déterminer quelle prise de vue est la plus adaptée au projet, et aux vues des méthodes présentées dans la partie « Expérimentations », la vue de dessus est un choix logique. Elle nous permet de biens distinguer les véhicules, et de bien les situer dans l’espace, à la différence d’une prise de vue oblique ou ras du sol.

 

Une webcam Logitech C170 nous a été fourni, sa résolution est suffisante pour le bon fonctionnement du projet.

Bibliothèques nécessaires

Après quelques recherches, nous avons établi une liste des bibliothèques nécessitant une importation dans notre programme python. Ainsi on y retrouve “time” et “datetime” qui servent à gérer le temps, que ce soit pour indiquer la date et l’heure actuelle ou pour calculer des intervalles de temps, déterminants la durée de stationnement d’un véhicule. Il y a aussi “numpy” qui est une extension du langage python permet d’effectuer certains types de calculs, “cv2” qui n’est autre que OpenCV, “matplotlib” qui apporte de nombreuses fonctionnalités au niveau de l’interface graphique et “collections” qui nous a aidé à gérer les couleurs.

Bibliothèques importées dans le programme principal final.
Figure 5 : Bibliothèques importées dans le programme principal final.

Expérimentations

Traitement d’images

 

Une fois l’image proprement récupérée et les véhicules reconnus, il a fallu identifier les places de parkings. Nous avons décidé de mettre un point à coordonnées X Y au centre des stationnements et de développer un algorithme qui aura comme seules coordonnées celles du point. Deux méthodes se sont présentées à nous : d’une part le mode manuel, qui consiste à entrer à la main les coordonnées des différentes places et d’autre part la détection de lignes par traitement d’image.

 

Le mode manuel consiste à entrer dans le programme la valeur de X et de Y à partir d’une image témoin (voir figure XX). Dans le programme, il se présente comme ceci : “TabPlaceXY = np.array([[100,257],[300,257],[500,257],…])” avec entre chaques crochets, le point [X,Y] du centre de la place. L’avantage de cette méthode est qu’elle est très simple à mettre en oeuvre et qu’elle est légère à compiler, ce qui n’est pas négligeable car OpenCV rend le programme lourd à compiler, que qui ralenti le nombre d’image par secondes. En revanche, si la caméra subit un mouvement, le programme devient caduc et une intervention est nécessaire pour modifier les coordonnées des points.

 

La détection de lignes est une méthode très intéressante, elle consiste à analyser l’image pour en extraire les lignes qui la compose, à partir de là, les places pourraient êtres identifiées automatiquement et actualisées en cas d’un mouvement de caméra; de plus, connaissant la taille moyenne d’une place de parking, l’algorithme pourrait s’adapter à tout parking, quelle que soit la hauteur de la caméra. Pour ce faire, nous avons utilisé la transformée de Hough qui repère les différences de contraste entre 2 pixels et si ces différences se perpétue à des endroits suffisamment proches, le programme en déduit qu’une ligne s’y trouve. OpenCV intègre la transformée de Hough, et nous permet de l’appeler comme suit: “cv2.HoughLinesp(edges,1,np.pi/180,100,minLineLenght,maxLineGap)”. Nous avons appris à nos dépens que pour utiliser cette méthode, une image très propre est nécessaire, nous l’avons donc expérimentée sur des images fictives (parking avec asphalt homogènement noir et lignes blanches parfaites) mais n’avons réussis à le porter sur système réel.

Transformée de Hough sur système réel.
Figure 6 : Transformée de Hough sur système réel.
Transformée de Hough sur une image parfaite.
Figure 7 : Transformée de Hough sur une image parfaite (Exemple 1).
Transformée de Hough sur image parfaite.
Figure 8 : Transformée de Hough sur une image parfaite (Exemple 2).

La méthode manuelle a donc été utilisée.

 

Ensuite, il a suffit de récupérer le barycentre du rectangle encadrant les véhicules (qui nous est donné par OpenCV) puis d’établir sa position par rapport au centre d’une place et ainsi, de voir dans quelle zone il se situe et donc, dans quelle zone le véhicule se situe.

Système miniature

Parking miniature.
Figure 9 : Parking miniature.

Suite au besoin évident de tester le programme, un environnement simulé était nécessaire. Un parking miniature a alors été réalisé avec des voiture miniatures. OpenCV nous a renvoyé le ClassId « 62 », autrement dit il voyait les voitures miniatures comme étant des téléphones portables; nous y avons remédié en traitant dans le programme, les téléphones portables comme des voitures; a noter que cela ne se produit pas uniquement avec les voitures miniatures mais avec toute voiture vue à la verticale.

 

À partir de ce modèle, nous avons réalisé différents cas de figures, mettant en évidence les qualités et les défauts du programme.

 

Les premières expérimentations ne furent pas probantes, en effet, les voitures n’étaient pas reconnues, du moins pas toutes, et pas tout le temps. Il nous fallu du temps pour s’apercevoir que le problème ne venait pas de notre programme mais de la luminosité. Ne pouvant bénéficier de la lumière naturelle en de bonnes conditions, nous avons utilisé un éclairage artificiel, à l’aide de nos smartphones comme visible sur la Figure 9. Le problème était résolu.

Première version du programme

Ayant une méthode d’approche et des ressources suffisantes, un premier programme a pu être conçu. En un premier temps les informations concernant l’état des places apparaissaient dans un terminal puis nous les avons intégrées au retour image pour plus de visibilité et de simplicité d’utilisation.

Situations dans lesquelles la première version du programme fonctionne bien.
Figure 10 : Situations dans lesquelles la première version du programme fonctionne bien.

On peut remarquer que dans ces 4 différentes situations, le programme fonctionne correctement, certes, l’interface graphique n’est pas très attrayante et reste peu lisible mais on peut y remarquer certaines fonctionnalités :

  1. Les véhicules sont reconnus et encadrés (L’affichage de la nature de l’objet « cell phone » est due à l’amalgame que fait OpenCV des voitures en vue aérienne comme expliqué précédemment).
  2. Les places sont numérotées et affichent un code couleur : Jaune lorsque la place est disponible, Vert lorsque la place est occupée et Rouge lorsque la place est prise par un véhicule mal stationné.
  3. Des informations sont disposées à gauche : Nombre de places disponibles, de véhicules, de véhicules mal stationnés, de véhicules bien stationnés et une mention « LA CIRCULATION EST PERTURBÉE » fait son apparition lorsqu’un véhicule n’est pas assez rentré dans sa place, comme visible sur le troisième cas de figure.
Erreur si un véhicule stationne entre 2 places.
Figure 11 : Erreur si un véhicule stationne entre 2 places.

La première erreur rencontrée (visible sur la Figure 11) est facilement rectifiable. En effet, un seul véhicule est détecté mais à l’écran apparaît « VEHICULE(S) MAL STATIONNE(S) = 2 », cela vient simplement du fait que le programme travail avec les places et non avec les véhicules, autrement dit, le programme regarde si la place est occupée par un véhicule et non pas si le véhicule occupe une place. Nous avons donc changé l’ordre dans lequel travail le programme (visible sur Figure 12).

Algorigramme de la deuxième version du programme.
Figure 12 : Algorigramme de la deuxième version du programme.
Erreur si un véhicule se stationne à l'horizontale.
Figure 13 : Erreur si un véhicule se stationne perpendiculairement.

La deuxième erreur rencontrée (visible sur la Figure 12) est due a notre manque de méfiance. Si un véhicule se positionne au milieu de la place, mais perpendiculairement, son barycentre est dans la zone de véhicule bien stationné. Pour y remédier, nous avons établi que si la largeur du véhicule est supérieure à sa longueur, il est reconnu par le logiciel comme étant mal stationné.


Application plus poussée

Vitesse d’acquisition

Jusque là, seul des photos étaient traitées, la Raspberry Pi 3 peut exécuter le programme mais pas sans peines, la carte chauffe, parfois se coupe et met jusqu’à 1 minute pour afficher le résultat. Dans le but de traiter des images en temps réel et en continu, un environnement plus stable et plus performant était nécessaire. Pour avoir un temps d’exécution plus raisonnable nous avons transféré le programme sur une machine Linux.

Type d’ordinateur Raspberry Pi 3 Machine Linux
Fréquence processeur 1,2 GHz 2,4 GHz
Temps d’exécution 50 secondes 2 secondes

Le temps d’exécution fut grandement réduit et les risques de surchauffes quasiment nulles. Pour que le retour vidéo soit totalement fluide il faudrait que l’ordinateur utilisé puisse afficher environ 24 images par secondes, soit environ 50 fois plus que la machine utilisée. Il n’aurait pas raisonnable d’utiliser une telle machine pour le projet car l’intérêt est moindre : en l’espace de 2 secondes, il n’y a pas d’événement impactant pouvant se produire sur un parking.

Analyse Temporelle

Afin de répondre pleinement au cahier des charges, il nous a fallu introduire une référence de temps dans notre programme. Ainsi certaines fonctionnalités peuvent être ajoutées, telles que le temps de stationnement de chaque véhicule, individuellement, le temps moyen de stationnement des véhicules, l’heure d’affluence ainsi qu’un affichage de la date sur l’interface pour avoir un repère temporel en cas d’enregistrement des vidéos de surveillance.

Deuxième version du programme

La deuxième version du programme intègre : la correction des bugs constatés après les tests sur la première version, une nouvelle interface plus claire, plus fonctionnelle et les nouvelles fonctionnalités rendues possibles grâce à la considération du temps.

Deuxième version du programme (Capture d'écran 1).
Figure 14 : Deuxième version du programme (Capture d’écran 1).
Deuxième version du programme (Capture d'écran 2).
Figure 15 : Deuxième version du programme (Capture d’écran 2).

L’interface a été entièrement repensée, rendant les informations bien plus lisibles et attrayantes. Hélas, appliqué à un système réel, le programme ne fonctionne pas correctement, on voit, par exemple que l’état de la place 4 est différent entre la Figure 14 et la Figure 15 alors que le véhicule n’a pas bougé. Malheureusement le programme a été intégralement développé sur le système miniature, ces dysfonctionnements n’ont pas étés anticipés et se sont révélés lors des tests tardifs avec des vidéos de surveillance. Les paramètres changeants entre le système miniature et le système réel sont : la caméra, l’échelle, le nombre de véhicules (bien plus important). Nous supposons donc que le problème est lié à un de ces paramètres.


Conclusion

Améliorations envisageables

En un premier temps, il faudrait corriger ce dysfonctionnement lorsque l’on travail sur un système réel. Ensuite, certaines améliorations pourrait être apportées :

  1. La transformée de Hough : trop complexe pour que l’on puisse l’utiliser correctement, il serait très plaisant de l’incorporer au programme principal.
  2. Base de données : les statistiques s’accumulant tout les jours, il pourrait être intéressant de les retrouver dans une base de données.

Apports

Ce projet nous a appris a travailler en autonomie, tout en renforçant nos connaissances du langage python et du traitement d’image.

 

 

Nous tenons à adresser nos remerciements à Mr Bazeille Stéphane et Mr Rebert Martin pour nous avoir suivi tout au long du projet en nous donnant des conseils avisés.


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