Centrale d’autoconsommation solaire

Projet GEII 2ème année

Centrale d’autoconsommation solaire

 

 

Sommaire:

  1. Présentation de l’équipe

  2. Principe de l’autoconsommation

  3. Présentation du Projet

  4. Cahier des charges

  5. Etude du projet

  6. Réalisation du projet

  7. Bilan du projet

  8. Conclusion

  9. Remerciements

  10. Sources

1. Présentation de l’équipe

Nous sommes un groupe d’élèves en 2ème année de Dut GEII, Maillot Thibaut, Raedersdorf Adrien et Schaeffer Victor

2. Principe de l’autoconsommation

L’autoconsommation se définit par le fait de consommer l’énergie produite soit même à l’aide d’énergies renouvelables, mais c’est plus souvent l’énergie solaire qui utilisée par les particuliers produisant leur propre énergie par volonté de préserver la planète, faire des économies ou être indépendant énergétiquement. On associe l’autoconsommation à l’autoproduction qui est le fait de produire sa propre énergie.

En France 77% de l’énergie produite est issue du nucléaire et seul 1,6% de l’énergie produite est de l’énergie  solaire. Ce chiffre varie d’ailleur en fonctions de plusieurs conditions comme la météo, ou l’heure de la journée.

Quand on parle d’autoconsommation énergétique on parle généralement d’énergie photovoltaïque car c’est la plus simple à utiliser pour un particulier, il existe également l’autoconsommation éolienne mais elle est plus compliquée à mettre en place de par la réglementation et d’autre part l’incertitude de production d’une éolienne.

La France avait un retard par rapport à ses voisins l’Allemagne et l’Italie et qui favorisent déjà l’autoconsommation solaire avec des primes à la conversion et des possibilités de revente d’électricité aux producteurs. La France commence seulement à investir dans ce secteur, en légifèrent avec l’union européenne pour augmenter sa part de production en énergie renouvelable.

Depuis la loi du 24 juillet 2017 la vente de courant entre fournisseur et particuliers est légiférée, les particuliers peuvent vendre du courant à leur fournisseur électrique en réinjectant du courant dans le réseau et les auto-consommateurs sont exonérés de la taxe départementale de consommation finale d’électricité et de la CSPE.

En France en  2016  environ 40% des demandes de raccordement étaient pour l’autoconsommation solaire en  2017 il y a eu 19 000 installations photovoltaïques, dont 7 000 pour l’autoconsommation. Et le nombre d’installations solaire en autoconsommation ne cesse d’augmenter depuis 2017.

C’est dans ce contexte, que notre projet ce déroule, en effet en tant qu’étudiant en GEII nous devons nous tenir à la page, ce projet est donc dans l’ère du temps.

 

3. Cahier des charges

diagramme bête à cornes

Préambule

Le projet consiste à réaliser une centrale d’autoconsommation solaire.

Contexte

Nous devons réaliser un projet en groupe tutoré par un enseignant, dans la filière DUT GEII de l’IUT de Mulhouse. Ce projet est organisé en parallèle des cours et est une initiative de l’enseignant tutorant, au vu de l’augmentation de systèmes autoconsommation en France, réaliser et étudier une centrale autoconsommation est un projet qui s’inscrit dans l’esprit d’une filière technologique.

Objectifs

Nous devons dimensionner et réaliser un système MPPT transportable à partir d’un panneau photovoltaïque mobile. Ce système doit être autonome, et pourra alimenter divers appareils de faible puissance.

Description de l’environnement logiciel

  • Arduino
  • KiCad
  • Victron connect
  • Coreldraw

Description de l’environnement matériel

  • Dispositifs électroniques.
  • Matériel d’ER de l‘IUT.
  • Outillage de l’IUT lab.

Contraintes techniques:

  • La limite de puissance de notre onduleur est de 300W
  • La sécurité du système, il ne faut pas déconnecter la batterie quand le panneau délivre du courant au risque d’abîmer nos composants, il faut prévoir de l’aération pour que la batterie ne chauffe pas trop.
  • Eviter La décharge complète de la batterie car celà réduit sa durée de vie.

 

4. Etude du projet

Schéma de principe

  • Le panneau photovoltaïque fournit du courant continu au régulateur MPPT
    1. Par traitement algorithmique la MPPT utilise le courant du panneau pour gérer la charger la batterie, elle maintient également la charge de la batterie et gère la décharge à l’aide de ses algorithmes préprogrammés.
    2. La MPPT peut directement alimenter une charge continue avec le courant délivré par le panneau photovoltaïque.
    3. Le remote on/off câble sert à contrôler l’allumage l’onduleur par  la MPPT
  • La batterie délivre du courant continu à l’onduleur qui convertit ce courant continu en alternatif.
  • L’onduleur est relié à des prises terre  et permet d’alimenter des appareils en 230V/50Hz
  • A noter la présence d’un fusible de 4 A pour protéger la batterie.

Composants

Panneau photovoltaïque

Un panneau photovoltaïque est un dispositif d’énergie renouvelable, qui transforme l’énergie solaire en énergie électrique.

La lumière du soleil est composée de particules appelées photons qui en entrants en contact avec les cellules de silicium du panneau vont exciter celles-ci et provoquer un mouvement d’électrons entre les parties chargées négativement et positivement,  générant du courant .

Notre panneau est un A-50M  de la marque Atersa, fourni par l’enseignant qui n’est plus disponible sur la marché .

 

 

C’est un panneau photovoltaïque polycristallin, c’est à dire que ses cellules sont composées de plusieurs cristaux de silicium agencées pour former la cellule.

 

 

Caractéristiques:

En conditions de test standard (1 kW/m², 25±2°C AM 1,5)

Puissance (w) 50 ±8%
Ipc (A) 2,64
Upc (V) 18,95
Icc (A) 2,95
Pnom(W) 220W
Uoc (V) 22,46
Eff 13,94%

 

 

 

Régulateur de charge solaire  MPPT

Une MPPT est un dispositif électronique, qui par traitement algorithmique gère le niveau de décharge de la batterie et la puissance que fournit la panneau au système.

Il existe différents algorithmes mais le plus rependu et le plus simple est l’algorithme Perturb and Observe.

P&O (Perturb and Observe)

  1. On mesure P1 la puissance du panneau photovoltaïque pour une tension U1 donnée.
  2. L’algorithme impose une tension U2 = U1 + dU et mesure la puissance correspondante à U2
  3. Si P2>P1 l’algorithme impose U3=U2 + dU
  4. SI P2<P1 l’algorithme impose U3=U1- dU

 

Nous utilisons une MPPT  SmartSolar 75V/15A de la marque Victron

Caractéristiques:

U (V) 13,8 V
I (A) 14,4
Icharge (A) 15
Uemax (V) 75
Imax (A) 15

Autoconsommation de la MPPT  25mA

 

Onduleur

Un onduleur est un système d’électronique de puissance qui convertit un courant continu en courant alternatif, dans un système d’autoproduction on utilise des onduleurs hybrides.

 

Nous utilisons un convertisseur Phoenix 350/12  de la marque Victron

Caractéristiques:

Puissance (VA) 350
Puissance (W) 300/250
Umoy (V) 230 ± 3%
F (HZ) 50 ± 0.1%
Ue 12
Eff 89%

 

Batterie AGM « Absorbed Glass Mat »

Une batterie à accumulateurs abrégé batterie est un système pouvant « stocker » du courant par des réactions électrochimiques, une batterie AGM (absorbed glass mat) est un type de batterie destiné à l’autoconsommation solaire au même titre que les batteries GEL, elles sont adaptées aux petits systèmes d’autoconsommation car supportent mieux la décharge profonde,  se chargent rapidement, sont plus légères que des batteries GEL et sont résistantes aux changements de température.

 

Batterie 12 V 60 Ah AGM de la marque Victron

 

 

Dimensionnement des composants

On dimensionne nos composants à partir des caractéristiques du panneau :

Puissance maximale en Watt-crête (W) 50 ±8%
Ipc (A) 2,64
Upc (V) 18,95
Icc (A) 2,95
Uoc (V) 22,46
Eff 13,94%

 

1 l’intensité maximale du régulateur MPTT

Cette intensité doit être supérieure à l’intensité de court-circuit (Icc) de notre panneau, avec une marge de sécurité de ±10-20%

Dans notre cas le courant de court-circuit du panneau est Icc =2,95 A, la MPPT doit donc pouvoir accepter

2,95 ±20% soit 3,54 A.

2 choix du parc de batterie en fonction de la puissance du panneau

 

Puissance de l’installation photovoltaïque Tension de batterie recommandée
0 – 800 Wc 12V
800 – 1600 Wc 24V
1600 Wc  et + 48V

 

Dans notre cas le panneau fournit 50 Wc en condition optimales on choisit donc un parc de batterie 12V.

Une méthode plus simple est de dimensionner par rapport au nombre de cellules du panneau ex : 36 cellules 12V, 72 cellules 24V

Avec un régulateur MPPT Il faut que la tension du panneau en circuit ouvert soit supérieure à celle de la batterie dans notre cas Uoc = 22,46V > 12V donc on peut utiliser une batterie 12V.

3 Tension maximale MPPT

On doit déterminer la compatibilité de la MMPT avec la tension du panneau en circuit ouvert +20% marge de sécurité en fonction de la température, dans notre ca on a

20% de 22,46 soit 4,492

Uoc= 22,46 + 4,492=26,952 V, on arrondit à 27 V.

Grâce à ces calculs on peut déterminer que notre régulateur de charge solaire sera une MPPT 75V/15A, pour deux  raisons, la première c’est qu’on surdimensionne  la MPPT en courant (on prend 15A au lieu de 10A) au cas où on devrait  rajouter un panneau. La deuxième raison est qu’il n’existe pas de modèle de MPPT en dessous de 75V.

4 l’onduleur

Il faut que la somme des puissances (en Watt) de nos appareils branchés soit inférieure à la puissance délivrée par l’onduleur.

Notre onduleur 12/350 délivre entre 300 W maximum il faut donc que nos appareils branchés ne dépassent pas cette puissance, un gros pc fixe par exemple ne doit pas être alimenté à notre système

Choix des câbles :  

On débite moins de 16 ampères, on prend donc  des sections de 1,5mm².

5. Réalisation du projet

Fabrication du support

Nous étions au départ partit sur un modèle design basé sur Skavenji mais au vu du poids total de nos composants (environ 50kg), ils nous fallait se rabattre sur un support solide et simple.

Nous avons acheté une planche de bois de sapin résistant aux changements de température de la batterie et assez épaisse qui servirait de support de base pour notre montage. Nous avions pros la taille des composants pour définir la taille minimale de notre base sur laquelle est fixée la batterie et l’onduleur, donc les composants les plus lourds (30kg au total)  de la base en prévoyant de l’espace pour la batterie qui chauffe.

Nous avons également acheté des roues pour les fixer sur le support, en effet le poids ne permettant pas d transporter notre montage manuellement les roues permettent un transport plus facile de notre centrale.

Pour le reste de la boite nous avons utilisé des plaques de contreplaqué fournies par Mr. De Sabbta, que nous avons découpées au laser, à partir d’un schéma réalisé sur Coreldraw. Nous avons prévu des emplacement pour mettre 2 prises terres, un allume cigare et des connecteurs bananes 4mm femelles pour connecter notre panneau solaire au système.

 

 

 

 

 

Les plaques de contreplaqué sont tenues entre-elles et à la base  par des équerres vissées.

 

Nous avons utilisé Des vis pour l’onduleur et la MPPT qui elle est fixée sur une des plaques de contreplaqué à la vertical comme demandé dans le manuel d’utilisation du produit. La batterie ne dois pas être percée ou abîmée il  nous a fallu la caler avec des  plaquettes de bois clouées à la base.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Notre onduleur ayant des sorties connecteurs IEC C/14 femelles, il nous faut câbler un adaptateur pour relier l’onduleur aux prises terre.

 

 

 

 

 

 

Commande par Arduino

 

 

Il était  l’origine prévu de réaliser un switch entre  la MPPT  l’onduleur et la batterie pour pouvoir tirer du panneau depuis l’onduleur

Nous avions donc pensé à une carte électronique à transistors NPN,  commandée en 5V par un Arduino UNO. Le but était de faire commuter la sortie de la MPPT directement sur l’onduleur si le panneau fournissait son maximum de puissance, que l’on aurait mesuré avec les capteurs de l’arduino.

 

 

Nous avons réalisé une plaquette test avec un programme de commutation de transistors fonctionnel. Nous avons également prévus les capteurs de courant connectés à l’arduino ainsi que la partie du programme qui s’occupe de traiter les informations des capteurs.

Nous avons ensuite conceptionné et fabriqué la carte de commande avec ses 4 transistors, mais nous nous sommes posé la question de la présence de la carte  pour commander le système.

Nous avons conclu qu’il valait mieux abandonner pour les raisons suivantes:

  • Notre système MPPT Victron est déjà complètement autonome,  ajouter un élément extérieur qui perturberait le comportement de notre système ne serait pas une bonne idée.
  • Il est déconseillé de débrancher la batterie pour une commutation sur onduleur car cela risque d »endommager le système ou au minimum le perturber.
  • Commander notre système pour le faire commuter au moments ou le panneau produit à son maximum aurait réduit l’efficacité de la charge de la batterie.
  • Le panneau est de faible puissance et l’onduleur reçoit 12V de tension nominale hors notre panneau fournit environ 18V il y adonc peu de chance que la commutation par transistors fonctionne.

7. Bilan du projet

Résultats

 

Au moment ou nous rendons ce rapport, la boite est opérationnelle et peut alimenter des appareils, il manque un adaptateur c/14 pour la prise terre restante et l’allume cigare n’est toujours pas connecté.

Il est inutile de faire de la réinjection sur le réseau avec un panneau de faible puissance comme le notre, cet aspect n’est donc pas étudié dans notre projet.

Suite à une concertation avec l’enseignant tutorant, nous avons décidé de changer notre MPPT pour un modèle avec Bluetooth intégré afin de pouvoir faire des mesures de consommation et de production de notre système avec l’application Victro Connect.

8. Conclusion

Le projet doit encore être perfectionné et nous pensons qu’il aurait été plus intéressant de réaliser la majorité du système nous mêmes, par exemple en créant intégralement un véritable régulateur MPPT à partir d’un Arduino ou d’un Raspberry Py. Cela aurait pu pousser l’aspect technique à un niveau supérieur. En plus de rendre possible la commutation directe sur onduleur possible, même si au vu de la faible puissance de notre système cela n’aurait pu ne pas fonctionner.

9. Remerciements

Nous souhaitons remercier notre enseignant tutorant Mr Ould Djafar Abdeslam pour son aide sur et ses indications sur la partie théorique ainsi que Mr De Sabbat qui nous a accueilli au sein de l’IUT lab et pour son aide sur la partie réalisation.

10. Sources

https://www.myshop-solaire.com/comment-choisir-son-regulateur–_r_80_a_454.html

http://www.repereelec.fr/cables-dom.htm

https://www.energiedouce.com/content/14-tout-savoir-sur-les-panneaux-solaires

https://www.rte-france.com/fr/eco2mix/eco2mix-mix-energetique

https://www.edfenr.com/autoconsommation/

https://www.legifrance.gouv.fr/eli/loi/2017/2/24/DEVR1623346L/jo/texte

 


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.