Catégorie : 2019
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.
PROJET HANOI
CRIQUI JULES – SCHABAT SIMON
2018-2019
SOMMAIRE
I. Introduction
Présentation du sujet
Matériel utilisé
c Présentation du groupe
c 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
c 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 :
c Robot Stäubli TX60
La caméra nous a permis de prendre des photos qui seront traitées à l’aide du 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.
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.
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.
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.
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.
GAUDIOZ Alexandre | ZAID EL KHIL Damien
Sommaire
-
Présentation du projet
-
Cahier des charges
-
Recherches effectuées
-
Expérimentations
-
Application plus poussée
-
Conclusion
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.
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 :
- 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).
- 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é.
- 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.
- Affichage : Créer une interface propre, agréable, où ls statistiques et les informations sont clairement visibles et accessibles à tous les utilisateurs.
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.
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).
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.
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.
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
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.
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 :
- 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).
- 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é.
- 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.
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).
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.
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 :
- 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.
- 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.
Sommaire
- Introduction
- Définition du besoin
- Analyse solaire
- Analyse mécanique
- Analyse électrique
- Réalisation
- Conclusion
Introduction
Dans le cadre d’un projet de deuxième année de DUT partagé entre le département GEII et le département GMP, nous travaillons sur un système de tracker solaire. L’objectif du projet est de créer un système asservi capable de suivre la trajectoire du soleil afin de maximiser le rendement de la production d’un panneau solaire. A travers ce document, nous allons présenter les différentes études menées, les problématiques rencontrées et les solutions proposées pour répondre à la problématique du projet.
Notre groupe est ainsi composé de 6 étudiants :
- Kelian Khassani – GMP
- Arnaud Zehringer – GMP
- Timothé Roussel – GMP
- Boubacar Diallo – GEII
- Sofian Beldi – GEII
- Hugo Houillon – GEII
Définition du besoin
La première étape de la réalisation de ce projet est la réalisation du cahier des charges et la définition du besoin ainsi que des différentes contraintes que nous serons amenés à rencontrer.
La but premier de ce projet est d’établir un système permettant pour l’instant à un panneau solaire de suivre la trajectoire du soleil afin de maximiser sa production.
Analyse solaire
La trajectoire du soleil se définie selon deux paramètres exprimés en degré :
- L’azimut : Représente la position du soleil selon les 4 points cardinaux
- La hauteur : Représente l’inclinaison du soleil par rapport à l’origine du plan horizontal
Les panneaux solaires devront donc être orientés de façon à être perpendiculaire aux rayons du soleil.
Afin de déterminer exactement les intervalles de position des panneaux selon ces deux paramètres, nous avons utilisé le site internet SunEarthTool. Ce site permet de calculer automatiquement la position du soleil dans l’année selon des coordonnées GPS.
Nous avons donc renseigné à ce site internet la position à laquelle nous souhaitons installer les panneaux solaires :
Une fois le site choisi, le site nous donne la position du soleil selon les mois de l’année :
Nous avons donc pu déterminer que le panneau solaire devra avoir une course de 50 à 310 ° en azimuth et de 20 à 90 ° en hauteur.
Afin d’estimer la production du panneau solaire tracké sur deux axes, nous avons utilisé un second site qui calcule automatiquement la production d’un panneau solaire selon les mois de l’année.
Nous avons renseigné les caractéristiques du panneau dont on dispose :
- Puissance maximale : 145 W
- Courant de court-circuit : 4,7 A
- Tension maximum : 34 V
- Courant maximum : 4,26 A
Nous avons regardé combien produirai potentiellement un panneau fixe incliné à 35° et combien produirai potentiellement un panneau tracké sur deux axes. Nous avons ensuite comparé les deux tableaux pour voir s’il est rentable d’effectuer un panneau solaire tracké sur deux axes.
En moyenne, nous remarquons qu’un système de panneau solaire tracké sur deux axes pourrait produire 30% de plus qu’un panneau fixe et incliné à 30°.
Il faut également faire attention au fait que le tracker ne doive pas consommer plus que le surplus produit par un système tracké pendant le mois le plus défavorable. Il faut donc que le tracker ne consomme pas plus de 1,2 kWh mensuel.
Analyse mécanique
Afin de permettre au panneau solaire de se déplacer sur 2 axes les GMP ont imaginé un système équipé d’un motoréducteur pour suivre l’azimut du soleil et d’un vérin électrique pour suivre la hauteur du soleil.
Analyse électrique
Toute l’énergie produite par le panneau solaire est acheminée au travers d’un régulateur de charge qui va s’occuper de charger les batteries correctement.
Pour ce projet, nous avons fait le choix de travailler en 24V. C’est pourquoi, nous avons acheté 2 batteries de 12V 12Ah branchées en série. Le motoréducteur et lé vérin électrique fonctionneront donc en 24V.
D’après l’analyse mécanique et électrique, nous devions trouver un vérin électrique avec les caractéristiques suivantes :
- Course du vérin : 300mm
- Force : 900N
- Tension de fonctionnement : 24V
Nous avons donc acheté le vérin électrique MPP-EC 90kg 300mm 900N 24V.
Nous avons également acheté un motoréducteur qui fonctionne en 24V capable de faire tourner l’axe du système du tracker solaire.
Afin de capter la position du soleil, nous avons nous avons conçu un système composé de 3 photorésistances qui délivrent une tension analogique en fonction de l’intensité lumineuse. Ces trois photos résistances sont séparées chacune par une paroi opaque. Ce capteur est perpendiculaire aux rayons du soleil lorsque les trois photorésistances mesurent la même valeur d’intensité lumineuse.
Nous avons réalisé ce capteur et voici à quoi il ressemble :
Une fois que nous savons capter la position du soleil, nous avons donc réfléchi à comment piloter le motoréducteur et le vérin électrique pour orienter le panneau perpendiculairement aux rayons du soleil.
Pour se faire, nous avons décidé de travailler avec des modules Arduino. Premièrement, un Arduino UNO est utilisé pour interpréter les mesures des trois photorésistances. En fonction des valeurs lues, l’arduino va estimer s’il est nécessaire de modifier l’angle du panneau en azimut ou en hauteur. Il va envoyer les informations de commande à un Arduino Motoshield qui lui va piloter le motoréducteur et le vérin électrique.
Le MotorShield pilote les actionneurs en PWM. Il utilise en entrée le courant des batteries pour piloter les actionneurs.
Voici le schéma global de notre installation électrique :
Voici l’algorithme simplifié de l’Arduino qui va permettre d’orienter le panneau dans la bonne direction :
Nous avons mis en place un coffret électrique qui contient les batteries, le régulateur de charge et les modules Arduino :
Réalisation
Afin d’installer toute la structure du tracker et du panneau solaire, nous avons coulé une petite dalle en béton (1.20m * 0.8m) :
Conclusion
Nous n’avons pas pu continuer ce projet, malheureusement il nous manquait des pièces mécaniques, ce qui nous a empêché d’installer toute la structure. Nous laissons à disposition du futur groupe d’étudiant un dossier de conception du système de tracker solaire.
Ce projet nous aura permis d’apprendre à travailler en groupe et également a appréhender un projet : les contraintes qui s’y appliquent, la réalisation d’un cahier des charges, le travail de groupe, les dates limites, etc..
Ne pouvant plus nous rendre à l’université, il nous est impossible de joindre les codes arduino utilisés. Afin d’aider les futurs étudiants à la programmation de l’arduino, il va falloir utiliser une librairie arduino motorshield capable de piloter les actionneurs en PWM. Il faut également savoir lire et interpréter les valeurs analogiques fournies par les photorésistances.
Nous remercions l’ensemble des enseignants ainsi que le personnel de l’UHA qui nous auront permis de réaliser et d’avancer au mieux dans notre projet.
Dossier de conception Tracker Solaire
Groupe du projet
Didierjean Romain
Kettela Antoine
Kontzler Louis
Sommaire
1. Présentation du projet
2. Analyse fonctionnelle
3. Réalisation du projet
4. Production de la bière
5. Conclusion
6. Annexes
Présentation projet
La bière est une boisson alcoolisée millénaire obtenu par fermentation d’un moût végétal. Il s’en boit des millions de litres chaque années et chaque pays revendique un savoir-faire unique. Nous allons donc nous plonger dans cette boisson et produisant notre propre bière.
Pour produire une bière, il faut 4 ingrédients :
- De l’eau
- Du malt
- Du houblon
- De la levure
Il y a ensuite plusieurs étapes de la production à respecter pour réussir sa bière :
- Le concassage
- Le brassage
- La fermentation
- La garde au froid
- L’embouteillage et la refermentation
Le choix des ingrédients, des quantités utilisées et le temps de fermentation détermineront le goût, le degré d’alcool et la couleur de la bière. Il faut aussi veuillez à respecter au mieux les étapes pour ne pas rater la boisson.
Nous allons donc faire une analyse fonctionnelle du projet, puis nous allons réaliser la partie technique du projet en câblant l’armoire électrique chargé d’alimenter le malaxeur, le malaxeur qui brassera la bière, il faudra aussi créer un GRAFCET et un programme afin d’automatiser le brassage. Ensuite, nous détaillerons la production de notre bière. Et pour finir, nous conclurons sur ce que nous à apporter le projet et des possibles évolutions qu’on pourrait lui apporter.
Analyse fonctionnelle
Un projet de bière avait déjà été fait par initiaux en 2018. Nous avons donc pour objectif de partir de leur projet et de l’améliorer en automatisant le brassage afin de simplifier et fiabiliser cette étape. Le cahier des charges est de faire une bière légèrement ambrée tout en respectant des paliers de températures/ Il faut donc automatiser le brassage avec un automate Siemens S7-1200 pour réguler la température.
La diagramme bête à cornes du projet est le suivant :
Les paliers de températures à respecter :
Réalisation du projet
1. Câblage de l’armoire
L’armoire était déjà câblée. Il fallait donc optimiser les branchements, sertir des fils, et rendre l’armoire fonctionnelle pour le projet. Pour cela, nous avons utiliser des relais de commandes, des relais de puissance, l’automate, un variateur et il a fallu relier les fils au malaxeur.
Les contacteurs utilisés ont les fonctions suivantes :
- KVAR = Mise sous tension
variateur - KA0 = Relais de maintien du
disjoncteur de la
partie puissance - KA2 = Fin de course bas
- KA1 = Fin de course haut
- KAdef = Défauts
- KADE = Descendre la pâle
- KDET = Chauffage
- KAMO = Monter la pâle
2. Câblage du malaxeur
Les étapes que nous avons suivi pour faire la partie câble ont été :
- Enlever tous les câbles de l’Ecolsab Habils
- Câbler selon les anciens schémas
- Noter les modifications effectuées
- Ajouter une sonde PT100
- Modifier les schémas sur QElectroTech (Annexe 1)
3. Programmation de l’automate
L’automate utilisé est un siemens S7-1200, il nous a été prêté pour le projet et par la suite il faudra en acheter un. Nous avons aussi utiliser un écran pour d’IHM. Un switch a fait le lien entre l’IHM et l’automate.
Il a ensuite fallu élaborer les GRAFCET (Annexes 2 et 3) et développer le ladder sut TIAGrafcet_Choix_du_Mode Portal.
4. Création de l’IHM
L’IHM a deux vues : vue principale(à gauche) et vue Recette (à droite).
La vue Principale sert à choisir le mode de fonctionnement, acquitter une étape, mettre en marche/ arrêter et de voir si la résistance électrique chauffe. Elle permet d’avoir des informations en temps réel, pour le moment seulement la température relevé par la sonde PT100. Changer le temps et la température des paliers est possible dans la vue Recette.
Production de la bière
1. Concassage
Concasser les grains permet de mieux faire infuser le malt dans l’eau durant le brassage. La photo nous montre la différence entre le grain concassé (à gauche) et le grain entier (à droite).
Pour notre bière ambrée, nous avons utilisé :
- 2250g de malt Munich
- 2250g de malt Vienna
2. Brassage
Durant cette étape, il faut chauffer et brasser en respectant les paliers du cahiers des charges (voir Analyse fonctionnelle) que nous avons défini dans notre programme. Cette étape va caractériser notre bière.
3. Rinçage
Le rinçage des drêches permet de séparer les grains du moût à l’aide d’un filtre. Sur l’image, nous observons bien l’utilité du filtrage. Tous les grains son rester dans la cuve, tandis que le moût est passé à travers.
4. Ébullition
C’est le dernier palier de chauffe, il permet de stériliser la bière. C’est aussi à ce moment que l’on ajoute le houblon. Il y a deux types d’houblon:
- L’amérisant : nous avons utiliser 33g de Styrian Goldinds pour notre première bière que nous avons du laisser 60 minutes.
- L’aromatique : nous n’en avons pas utiliser pour la première bière. Pour la deuxième nous l’avons mis 10 minutes avant la fin.
5. Refroidissement
La cassure de la température permet de produire des protéines dans la bière. La bière doit impérativement ne pas être chaude pour ne pas tuer les levures incorporées par la suite.
Le refroidissement idéal est rapide et doit se faire avec un serpentin ou refroidisseur à plaque. Nous avons refroidis la première bière en mettant la cuve dans l’eau, ce qui n’est pas un refroidissement optimal.
6. Fermentation
C’est à cette étape que l’on ajoute la levure pour la première fermentation.La fermentation dure 3 semaines dans une cuve avec un barboteur, à température ambiante (25°).
7. Mise en bouteille
Avant de mettre en bouteille, on ajoute le sucre dans la bière. C’est la deuxième fermentation. Il faut faire attention a ne pas mettre trop de liquide dans les bouteilles car il y a un risque d’explosion s’il y a trop de pression. Il faut ensuite mettre les capsules manuellement.
8. Création d’une étiquette
Nous avons décider de créer une étiquette à mettre sur les bouteilles que nous avons produites. Romain s’est chargé de la créer, elle est libre de droit pour de futures bières.
Conclusion
Ce projet nous a permis de mettre en pratique les notions de supervision et d’automatismes que nous avions reçu. Il nous a aussi permis de nous familiarisé avec des schémas électriques et prendre en main un logiciel pour les modifier. il nous a aussi appris a mieux gérer notre temps car il fallait avoir fini assez tôt pour pouvoir produire la bière en comptant les fermentations.
Donc, c’était un projet très intéressant. Nous avons découvert l’univers de la bière avec pédagogie et il y a eu du concret grâce à la production de notre propre bière, il reste cependant quelques améliorations à faire.
Les futures améliorations du projet auxquelles nous avons pensé sont :
- Pouvoir lire la température de la plaque dans l’automate sur l’IHM
- Améliorer l’étape de refroidissement (en ajoutant un serpentin ou un refroidisseur à plaques)
- Utiliser un PWM ou PID pour la régulation de la température
Annexes
Annexe 1 : Schémas électrique de l’Ecolsab Habilis
Annexe 2 : Grafcet Choix du Mode
Annexe 3 : Grafcet du mode Auto