Rapport de Pfe Finale (1) - Converti
Rapport de Pfe Finale (1) - Converti
Rapport de Pfe Finale (1) - Converti
Dédicaces................................................................................................................................................i
Remerciements......................................................................................................................................ii
Les acronymes.....................................................................................................................................vi
Introduction Générale...........................................................................................................................1
Chapitre Ⅰ : Contexte Général de Projet ...........................................................................................
Ⅰ.1 Introduction....................................................................................................................................2
Ⅰ.2 Présentation de l’entreprise...........................................................................................................2
Ⅰ.2.1 Les différents services de la société........................................................................................2
Ⅰ.2.1.1 Le service Méthode/Process.............................................................................................2
Ⅰ.2.1.2 Le service Logistique........................................................................................................2
Ⅰ.2.1.3 Le service Financier..........................................................................................................2
Ⅰ.2.1.4 Le service Achats.............................................................................................................2
Ⅰ.2.1.5 Le service Industrialisation..............................................................................................2
Ⅰ.2.2 Les filiales de Sagemcom.........................................................................................................3
Ⅰ.2.3 Les unités de fabrication de Sagemcom.................................................................................3
Ⅰ.3 Présentation du projet....................................................................................................................4
Ⅰ.3.1 Les compteurs électriques de Sagem......................................................................................4
Ⅰ.3.2 Etude de l’existant...................................................................................................................5
Ⅰ.3.3 Problématique..........................................................................................................................6
Ⅰ.3.4 La solution proposée................................................................................................................7
Ⅰ.3.4.1 Architecture générale de la solution proposée................................................................7
Ⅰ.3.5 Spécification des besoins.........................................................................................................8
Ⅰ.3.5.1 Besoins fonctionnelles.......................................................................................................8
Ⅰ.3.5.2 Besoins non fonctionnelles................................................................................................8
Ⅰ.4 Conclusion.......................................................................................................................................8
Chapitre 2 : Spécifications des besoins..............................................................................................
Matériels et logiciels...........................................................................................................................
Ⅱ.1 Introduction...................................................................................................................................9
Ⅱ.2 Spécifications des besoins matériels.............................................................................................9
Ⅱ.2.1 Plateformes de commande.....................................................................................................9
Ⅱ.2.2 Caméra SVS-VISTEK.........................................................................................................10
Ⅱ.2.3 Communication compteur-ordinateur................................................................................10
Ⅱ.2.4 IoLogik E1214.......................................................................................................................11
Ⅱ.2.4.1 ioSearch..........................................................................................................................12
Ⅱ.3 Spécifications des besoins logiciels.............................................................................................13
Ⅱ.3.1 Environnement de développement......................................................................................14
Ⅱ.3.2 Langage de programmation................................................................................................14
Ⅱ.3.2.1 Langage Python.............................................................................................................14
Ⅱ.3.3 OpenCV.................................................................................................................................14
Ⅱ.3.4 Les Frameworks utilisées pour la réalisation du projet....................................................15
Ⅱ.3.4.1 Généralité.......................................................................................................................15
Ⅱ.3.4.2 les différents Frameworks existants.............................................................................15
Ⅱ.3.4.3 Le choix du framework.................................................................................................16
Ⅱ.3.5 le choix de l’outil pour la conception de l’interface Graphique (GUI).............................16
Ⅱ.3.5.1 La librairie QT..............................................................................................................16
Ⅱ.3.5.2 PYQT.............................................................................................................................16
Ⅱ.3.5.3 Qt Designer....................................................................................................................17
Ⅱ.4 Conclusion...................................................................................................................................17
Chapitre 3 : Réalisation de la phase d’inspection .............................................................................
III.1 Introduction................................................................................................................................18
III.2 Les anomalies à détecter............................................................................................................18
III.3 Test des Leds..............................................................................................................................18
III.3.1 Détection de couleur...........................................................................................................18
III.3.2 Description du flux de détection de couleur......................................................................18
III.3.3 Pré-traitement.....................................................................................................................19
III.3.4 Le système de couleur HSV................................................................................................20
III.3.5 Les Masks............................................................................................................................20
III.3.6 Opérations au niveau du bit...............................................................................................21
III.3.7 test et résultats obtenus......................................................................................................21
III.4 Test de l’afficheur LCD.............................................................................................................22
III.4.1 Apprentissage supervisé.....................................................................................................22
III.4.1.1 Classification................................................................................................................22
III.4.1.2 La régression................................................................................................................22
III.4.2 Les étapes de la partie d’apprentissage supervisé.............................................................22
III.4.2.1 Le type du problème....................................................................................................23
III.4.2.2 La Préparation des données........................................................................................23
III.4.2.3 Séparation train- test...................................................................................................26
III.4.2.4Apprentissage du modèle..............................................................................................26
III.4.2.5 Mesure de performance...............................................................................................28
III.4.2.6 Réglage du modèle.......................................................................................................31
III.4.2.7 Evaluation du modèle..................................................................................................33
III.5 Problèmes rencontrés................................................................................................................34
III.6 Conclusion..................................................................................................................................34
Chapitre 4 : Conception et réalisation...............................................................................................
De l’interface de test ..........................................................................................................................
IV.1 Introduction...............................................................................................................................36
IV.2 Description du fonctionnement de process du test..................................................................36
IV.2.1 Diagramme de cas d’utilisation général............................................................................36
IV.2.2 Diagramme de séquences général......................................................................................37
IV.3 Logigramme d’organisation des étapes d’un scénario de test............................................38
IV.4 Communication et commande compteur.................................................................................39
IV.5 Interface graphique...................................................................................................................40
IV.5.1 Etapes de réalisation............................................................................................................40
IV.5.1.1 QT Designer..................................................................................................................40
IV.5.1.2 Conversion en script python.......................................................................................41
IV.5.1.2.1 création de l’exécutable................................................................................................41
IV.6 Implémentation et test...............................................................................................................42
IV.6.1 Résultats des tests de Leds visualisés sur l’interface........................................................42
IV.6.1.1 Résultats des tests de l’afficheur LCD visualisées sur l’interface................................43
IV.7 Simulation..............................................................................................................................43
IV. 8 Génération du rapport..............................................................................................................46
IV.9 Conclusion..................................................................................................................................46
Conclusion générale............................................................................................................................47
Références bibliographiques..............................................................................................................48
Dédicaces
Mon père :
Aucune dédicace ne saurait exprimer l’amour, l’estime et le respect
que j’ai toujours eu pour toi. Ce modeste travail est le fruit de tous les
sacrifices que tu as déployés pour mon éducation et ma formation.
Ma chère grand-mère :
Je te dois ce que je suis aujourd’hui et ce que je serai demain.
i
Remerciements
ii
Liste des figures
iii
Figure IV. 10 : visualisation d'un test de compteur réussi sur l'interface..............................................45
Figure IV. 11 : visualisation d'un test de compteur défaillant sur l'interface........................................45
Figure IV. 12: aperçu du rapport généré à la fin du test........................................................................46
iv
Liste des
v
Les
v
Introduction Générale
Au sein de cete problématique, notre projet intitulé « Conception et réalisation d’un testeur
des compteurs électriques » vise à proposer une solution à ces problèmes de manière à
répondre le mieux possible aux besoins et au cahier des charges proposé par la société
Sagemcom.
Le processus de test et la machine poste vision représentent le centre d’intérêt de notre projet.
En effet, notre tâche consiste essentiellement à améliorer tout le processus de test actuel pour
avoir une meilleure qualité de test et une meilleure performance.
Outre l’introduction générale, ce rapport comprend quatre chapitres, le premier chapitre est
destiné pour la présentation du contexte du projet, l’identification des besoins fonctionnels et
non fonctionnels ainsi que la présentation de la solution proposée.
Le deuxième chapitre est consacré à la spécification des besoins matériels et logiciels.
Le troisième chapitre détaille les différentes étapes suivis pour la réalisation de la partie
d’inspection.
Le dernier chapitre présente la dernière partie destinée à la réalisation de l’interface graphique
de test.
Finalement nous clôturons ce rapport par une conclusion générale et quelques perspectives.
1
Chapitre Ⅰ : Contexte Général de Projet
E.N.I. Chapitre 1: Contexte général de
Ⅰ.1 Introduction
Ce premier chapitre est dédié dans une première partie pour la présentation de l’entreprise
d’accueil SAGEMCOM , ses différents services et son domaine d’activité. Dans une
deuxième partie, nous exposons la problématique pour finaliser avec la présentation du travail
demandé.
2
E.N.I. Chapitre 1: Contexte général de
Le chiffre d’affaires total de ces filiales s’élève à 2,1 milliards d’euros. L’effectif de 5 500
personnes est réparti dans plus de 50 pays. Sagemcom est rentable depuis sa création en 2008
et 31% de ses employés sont actionnaires. Elle conçoit, fabrique et expédie plus de 40
millions de terminaux dans le monde chaque année. Sagem est créée en Tunisie en Décembre
2002. C’est une Société SARL, elle est totalement exportatrice et non résidente. Elle est
implantée dans la banlieue Sud de Tunis (Ben Arous). Parmi les filiales énumérées dans la
figure ci-dessus
, nous trouvons STC notre organisme d’accueil.
Ⅰ.2.3 Les unités de fabrication de Sagemcom
Cette entreprise fabrique une large gamme de produits en grandes et moyennes séries. Les
Unités de Fabrication (UF) au sein de cette entreprise assurent la réalisation du programme de
production en termes de qualité, coûts et délais. Sagemcom compte actuellement quatre unités
de fabrication (figure ).
• UF Décodeurs
• UF Compteurs (Terminaux Énergétique)
• UF Terminaux Hauts débit
• UF Fast et PLT
3
E.N.I. Chapitre 1: Contexte général de
Les différents composants du compteur de Sagemcom sont illustrés dans le tableau suivant :
4
E.N.I. Chapitre 1: Contexte général de
Le poste est devisé en deux parties : une partie bas de la baie qui contient les instruments et une
partie haute de la baie qui est destiné pour le posage des compteurs à tester.
Ce poste consiste en une machine de test automatique. Elle se base sur le logiciel Vision
Builder pour l’automatisation de l’inspection et LabVIEW pour gérer les instruments.
5
E.N.I. Chapitre 1: Contexte général de
Ⅰ.3.3 Problématique
L’industrie électronique n’a pas cessé de se développer durant les dernières décennies afin
d’améliorer la qualité de leurs produits et conserver un avantage concurrentiel sur le marché
mondial. Dans ce cadre, « SAGEMCOM » a fixé des objectifs pour le développement durable
tout en respectant les exigences de ces clients et des normes mondiales.
Dans les réseaux électriques actuels, pour limiter les risques d’avoir des produits non
conformes avec certaines anomalies, les postes de vision jouent un rôle majeur dans le
contrôle des compteurs.
Suite à une observation et étude de déroulement actuel de la phase de test, deux calculs sont
effectuées au sein du service : le calcul du taux TRG (tableau Ⅰ.2) qui représente le taux de
rendement global ainsi que le rendement du premier passage FPY (tableau Ⅰ.3) .
La formule utilisée pour calculer le taux TRG :
TRG = le rapport temps de production sur le temps d’ouverture.
La formule utilisée pour calculer le rendement FPY :
FPY = le nombre des unités testés non défaillants par rapport au nombre des unités
testées.
6
E.N.I. Chapitre 1: Contexte général de
- En plus le logiciel Vision Builder n’est pas open source et gourmand en ressources
(processeur et RAM). Pour développer une inspection automatisée, Sagemcom a
besoin d’acheter la licence qui coûte € 2 450,00.
Ⅰ.3.4 La solution proposée
Afin d’optimiser la performance de la procédure de test, de réduire les pertes de temps pour
améliorer la cadence de production , nous avons proposé au service TEST et industrialisation
de SAGEMCOM un nouveau processus de test automatisé programmé en langage Python ,
pour les deux parties : inspection et instrumentation afin de développer une interface
permettant le déroulement des cycles de tests sans l’intégration de la partie LABVIEW
existante ni de la partie d’instrumentation Vision Builder .
Cette solution va permettre de garantir une meilleure fiabilité et d’augmenter les
performances des postes de vision, une réduction du temps d’intervention, ainsi qu’un gain en
termes de coût en se passant de Vision Builder dont la licence coute cher.
Ⅰ.3.4.1 Architecture générale de la solution proposée
L’architecture générale de la solution proposée, donnée par la figure Ⅰ.7, se décompose en
trois parties :
7
E.N.I. Chapitre 1: Contexte général de
Ⅰ.4 Conclusion
Dans ce chapitre, nous avons présenté en premier lieu l’entreprise d'accueil Sagemcom. Nous
avons aussi présenté les compteurs électriques objet de notre projet. Par la suite, nous avons
étalé la problématique cernée suite à une étude de l’existant et nous avons préciser une
description brève de la solution proposée. Dans le chapitre suivant, nous allons procéder à la
spécification des besoins matériels et logiciels.
8
Chapitre 2 : Spécifications des besoins
Matériels et logiciels
E.N.I. Chapitre 2 : spécifications des besoins logiciels et
Ⅱ.1 Introduction
Afin de concevoir une solution adéquate garantissant le besoin technique déjà exprimé, il est
nécessaire de détailler les exigences matérielles et logicielles et de donner une étude complète
visant à comprendre les interactions entre les composants et le programme développé. Nous
entamons ce chapitre qui présente les ressources matérielles et logicielles exploitées pour
l’implémentation de notre solution.
9
E.N.I. Chapitre 2 : spécifications des besoins logiciels et
Figure Ⅱ. 3 : Moxa-nport-5210
1
E.N.I. Chapitre 2 : spécifications des besoins logiciels et
Le Nport 5210 se branche directement sur l’ordinateur via un port Ethernet. Ce port joue le
rôle de l’intermédiaire entre l’ordinateur et le port optique pour envoyer les commandes au
compteur via l’interface VISA ("Virtual Instrument Software Architecture"). Ces commandes
sont mises au SPEC (spécification de test") par l’équipe URD ("Unité de recherche et de
développement")
Ce port a les caractéristiques techniques suivantes [B3] :
En plus du port série, nous avons besoin aussi d’un lecteur de port optique (figure Ⅱ. 4)
Le lecteur de port optique OPTO permet la communication avec le protocole CEI 62056-21
entre différents types de compteurs d’électricité et un dispositif de lecture qui possède un port
RS-232.
Ce lecteur OPTO possède les caractéristiques mentionnées dans le tableaux ci-dessous [B4]:
Tableau Ⅱ. 4: Caractéristiques du port OPTO
Poids 100 g
Communication RS-232
Dimensions 32 x 24 mm
Force de maintien magnétique 15N
Débit binaire 19200bit/s
Longueur de câble 1.8 m
1
E.N.I. Chapitre 2 : spécifications des besoins logiciels et
1
E.N.I. Chapitre 2 : spécifications des besoins logiciels et
1.Titre
2.barre de menus
3.lien rapide
4.paneau de navigation
5.fenetre principale
Figure Ⅱ. 6: Fenêtre principale du IoSearch
1
E.N.I. Chapitre 2 : spécifications des besoins logiciels et
Python est le langage de programmation open source le plus employé par les
informaticiens. Ce langage s’est propulsé en tête de la gestion d’infrastructure,
d’analyse de données ou dans le domaine du développement de logiciels. En
effet,
parmi ses qualités, Python permet notamment aux développeurs de se concentrer sur ce qu’ils font
plutôt que sur la manière dont ils le font. Il a libéré les développeurs des contraintes de formes qui
occupaient leur temps avec les langages plus anciens. Ainsi, développer du code avec Python est
plus rapide qu’avec d’autres langages.
Les principales utilisations de Python par les développeurs sont :
La programmation d’applications ;
La création de services web ;
La génération de code.
Nous avons utilisé python pour la programmation de tout le projet : la programmation de la
partie inspection, la partie automatisation ainsi que pour la réalisation de la partie interface
graphique.
Ⅱ.3.3 OpenCV
OpenCV (Open Source Computer Vision) est une bibliothèque Open Source,
développée par intel pour résoudre les problèmes de la vision par ordinateur ("computer
vision") qui propose plus de 2500 algorithmes pour le traitement d’images et le machine
learning.
Elle a été créer pour proposer une infrastructure commune aux projets de vision par ordinateur
avec une considération importante pour l’efficacité de calcul et les applications temps réel.
Nous allons donc utiliser la bibliothèque OpenCV en programmant en Python pour la mise en
place des fonctions de base du traitement d’images.
1
E.N.I. Chapitre 2 : spécifications des besoins logiciels et
Ⅱ.3.4.2.2 PYTORCH
Ce framework utilise CUDA avec des bibliothèques C / C ++ pour le traitement Ces dernières
années, PyTorch a connu un niveau élevé d'adoption au sein de la communauté des cadres
d'apprentissage en profondeur et est considéré comme un concurrent de TensorFlow.
PyTorch est essentiellement un portage vers le framework d'apprentissage en profondeur
Torch utilisé pour construire des réseaux de neurones profonds et exécuter des calculs
tensoriels élevés en termes de complexité.
Ses points forts sont [B7] :
1
E.N.I. Chapitre 2 : spécifications des besoins logiciels et
Ⅱ.3.4.2.3 KÉRAS
Écrit en Python, la bibliothèque de réseaux de neurones Keras prend en charge les réseaux
convolutifs et récurrents capables de fonctionner sur TensorFlow. Comme l'interface
TensorFlow est un peu difficile et peut être complexe pour les nouveaux utilisateurs, le cadre
d'apprentissage en profondeur Keras a été conçu pour fournir une interface simpliste pour un
prototypage rapide en construisant des réseaux de neurones actifs qui peuvent fonctionner
avec TensorFlow.
Le format d'interface Keras est devenu un standard dans le monde du développement de
l'apprentissage en profondeur. C'est pourquoi, il est possible d'utiliser Keras en tant que
module de Tensorflow. Cela facilite le développement et réduit les différences entre ces deux
frameworks. Il combine également les avantages de l'utilisation de chacun d'eux.
Les points forts de keras sont [B7] :
API facile à comprendre et cohérentes ;
S'intègre parfaitement au flux de travail TensorFlow. ;
PyQt[B8] est un module qui permet de lier le langage Python avec la bibliothèque Qt.
Il permet ainsi de créer des interfaces graphiques en python. Une extension de
QtDesigner (utilitaire graphique de création d'interfaces Qt) permet de gérer le code
python
d'interfaces graphiques. PyQt dispose de tous les avantages liés à Qt.
1
E.N.I. Chapitre 2 : spécifications des besoins logiciels et
Pourquoi PyQt ?
PyQt fournit de nombreuses classes, méthodes et widgets. Cela permet de créer une
application de bureau riche. On peut ajouter tous types de boutons (push, radio, check), des
images, interagir avec des bases de données et bien plus encore [B8].
Ⅱ.3.5.3 Qt Designer
1
Chapitre 3 : Réalisation de la phase d’inspection
E.N.I. Chapitre 3 : Réalisation de la phase
III.1 Introduction
Dans ce chapitre, nous expliquons les démarches suivies pour la réalisation de la phase
d’inspection.
Dans une première partie nous allons citer les anomalies qui doivent être détectées au niveau
du compteur électrique, puis dans une deuxième partie nous allons détailler les méthodes
choisies pour chaque test.
1
E.N.I. Chapitre 3 : Réalisation de la phase
1
E.N.I. Chapitre 3 : Réalisation de la phase
Cv2.cvtColor(frame,
III.3.4 Le système de couleur HSV cv2.COLOR_BGR2HSV
Le système HSV (Teinte, saturation, valeur) est un mode de coloration des images qui se
révèle souvent plus efficace que le système classique RGB (Red, Green, Blue)
• La teinte (Hue) se lit sur un cercle : elle est codée par un angle entre 0 et 360°. En fixant la
saturation et la luminosité (Value) à leurs valeurs maximales, on a les correspondances
suivantes :
• La saturation se lit sur le rayon du cercle : elle est codée par un nombre entre 0 et 1 (ou par
un pourcentage). La saturation traduit la vivacité de la couleur. Les fortes valeurs
correspondent à des couleurs vives, les valeurs intermédiaires à des tons pastels. Aux très
faibles valeurs, on n'a plus que du gris plus ou moins foncé suivant la luminosité.
• La luminosité (Value) se lit sur la coordonnée verticale : tout comme la saturation, elle
s'exprime par un nombre entre 0 et 1. En augmentant la luminosité, on va du noir vers la
couleur spécifiée par H.
Pourquoi on utilise l’espace HSV :
Contrairement au BGR, le HSV sépare la luminosité, ou l’intensité de l’image, de la
chrominance ou des informations de couleur. Ceci est très utile dans de nombreuses
applications. En vision par ordinateur, nous souhaitons souvent séparer les composants
couleur de l'intensité pour différentes raisons, telles que la robustesse aux changements
d'éclairage ou la suppression des ombres. Cependant, le HSV est l’un des nombreux espaces
colorimétriques qui séparent la couleur de l’intensité.
III.3.5 Les Masks
La détection des couleurs se repose sur des intervalles de couleurs que nous avons mis et qui
sont configurables :
Pour la led CPL il faut que le testeur détecte une lumière verte définie par les intervalles
suivants :
Min[102,
Max [50, 255,
52, 72]
255]
Pour le deuxième test de la Led MTR, il faut détecter la couleur orange qui est définie par les
intervalles suivants :
Max[10,
Min [25,100,
255,20]
255]
2
E.N.I. Chapitre 3 : Réalisation de la phase
La figure (III. 2) montre le test de la Led CPL verte, on a bien réussi à détecter la couleur verte.
La figure (III. 3) montre qu’on a réussi le test des deux Leds MTR et CPL, on a bien détecter à
la fois la couleur orange et la couleur verte.
2
E.N.I. Chapitre 3 : Réalisation de la phase
2
E.N.I. Chapitre 3 : Réalisation de la phase
2
E.N.I. Chapitre 3 : Réalisation de la phase
droit du rectangle . Les boîtes englobantes sont représentées soit par (x1,y1) et (x2,y2) soit par
(x1,y1) et w et h respectivement la largeur et la hauteur de la boîte (figure III. 4) .
Figure III. 5 : Boîte englobante montrant les coordonnées x1, y1, x2, y2, largeur (w) et hauteur (h)
III.4.2.2.3.2segmentation polygonale
Au lieu d’utiliser des boites rectangulaires, cette méthode consiste a utiliser des polygones
complexes pour définir la forme, et le lieu de l’objet avec précision.
III.4.2.2.3.3 segmentation sémantique
Cette méthode est utilisée dans les cas ou le contexte environnemental est très important. Son
principe est basé sur l’annotation par pixel. Chaque est affecté à une classe et à une
signification sémantique (figure III. 5 )
III.4.2.2.3.4 Cuboïdes 3D
Avec cette méthode on obtient une représentation 3D de l’objet. Cette méthode permet de
relever des informations sur le volume et la position du l’objet dans l’espace (figure III. 6)
.
2
E.N.I. Chapitre 3 : Réalisation de la phase
Figure III. 8: Exemples d'annotations de points clés à partir du jeu de données COCO
Pour la classe KO
2
E.N.I. Chapitre 3 : Réalisation de la phase
Une partie convolutive : Son objectif final est d’extraire des caractéristiques propres à
chaque image en les compressant de façon à réduire leur taille initiale. En résumé, l’image
fournie en entrée passe à travers une succession de filtres, créant par la même occasion de
nouvelles images appelées cartes de convolutions. Enfin, les cartes de convolutions obtenues
sont concaténées dans un vecteur de caractéristiques appelé code CNN.
Une partie classification : Le code CNN obtenu en sortie de la partie convolutive est fourni
en entrée dans une deuxième partie, constituée de couches entièrement connectées appelées
perceptron multicouche.
a/ Couche de Convolution :
Les couches de convolution analyse l’image par zone. Elles se focalisent sur chaque partie de
la donnée. Grâce à ces couches de convolution le modelé est capable d’extraire des
caractéristiques.
Trouvant des caractéristiques approximatives qui se ressemblent à peu près dans 2 images
2
E.N.I. Chapitre 3 : Réalisation de la phase
différentes, le CNN est bien meilleur à détecter des similitudes que par une comparaison
entière
2
E.N.I. Chapitre 3 : Réalisation de la phase
image à image. Chaque caractéristique est une mini-image, un petit tableau de valeurs en 2
dimensions. Les caractéristiques rassemblent les aspects les plus communs des images quand
on lui présente une nouvelle image, le CNN ne sait pas exactement si les caractéristiques
seront présentes dans l’image ou où elles pourraient être, il cherche donc à les trouver dans
toute l’image et dans n’importe quelle position.
En calculant dans toute l’image si une caractéristique est présente, on applique un filtrage. Les
mathématiques utilisées pour réaliser cette opération sont appelés une convolution, de laquelle
les réseaux de neurones à convolution tiennent leur nom. Cette méthode est bien plus efficace
que l’approche classique pour deux principales raisons :
Moins d’erreur dans l’apprentissage car le modèle n’apprend pas des images mais des
caractéristiques, des motifs
Plus de précision dans la détection, car le modèle doit justement reconnaître des
caractéristiques, des motifs
Une première couche de convolution apprendra les petits motifs, une deuxième couche de
convolution apprendra des motifs plus importants constitués des caractéristiques des
premières couches, etc. Notre base de données contient des images à plusieurs caractéristiques
et détails c’est pourquoi on a besoin de plus que deux couches de convolution pour bien
extraire les détails.
Deux couches à 64 filtres de taille (3 ,3)
Deux autres couches à 128 chacun de taille (3,3)
Cela permet au modèle d’apprendre efficacement des concepts de plus en plus complexes et
abstraits. Cette couche produit ce qu’on appelle des feature-maps possédant chacune des
caractéristiques différentes de l’image.
b/ Maxpooling :
Après avoir utilisé une couche Conv2D, on obtient des features-maps contenant des
caractéristiques correspondantes aux images, il faut donc de réduire le résultat obtenu pour
réduire les calculs énormes. Ceci se fait par la couche Maxpooling.
Le MaxPooling est aussi une couche de convolution. Il extrait des motifs, la valeur la plus
importante ou la valeur max de chaque motif des feature-maps. Il garde seulement les
informations importantes pour réduire la dimension de chacune de ces feature-maps. Cela
permet au modèle de Deep Learning de :
2
E.N.I. Chapitre 3 : Réalisation de la phase
On utilise alors une couche appelée Flatten qui permet d’aplatir le tenseur, de réduire sa
dimension. Elle prend en entrée un 3D-tensor (vecteur) et retourne un 1D-tensor (vecteur)
C’est une opération simple mais essentielle. La couche Flatten permet d’établir une connexion
entre les couches de convolution et les couches de base du Deep Learning.
III.4.2.5 Mesure de performance
Les courbes d’apprentissage sont utilisées pour le diagnostic et la mesure de performance des
algorithmes d’apprentissage.
Les modèles d’apprentissage sont évalués sur l’ensemble des données d’entrainement et aussi
sur l’ensemble des données de test.
Après chaque mise à jour, pendant l'entraînement et le test, des tracés des performances
mesurés peuvent être créés pour montrer les courbes d'apprentissage
Courbes d’apprentissage d'entraînement qui seront présentées par la suite en
couleur bleue : courbe d'apprentissage calculée à partir de l'ensemble de données
d'entraînement qui donne une idée de la qualité de l'apprentissage du modèle [B12] .
Courbes d'apprentissage de test qui seront présentés par la suite en couleur orange :
courbe d'apprentissage calculée à partir d'un ensemble de données de test qui donne
une idée de l'efficacité de la généralisation du modèle [B12].
Dans certains cas, il est également courant de créer des courbes d'apprentissage pour plusieurs
indicateurs. Par exemple, dans le cas de problèmes de classification, le modèle peut être
optimisé en fonction de la perte, et les méthodes suivantes peuvent être utilisées pour évaluer
la précision de la classification.
Dans ce cas, deux graphiques sont créés, un pour la courbe d'apprentissage de chaque
indicateur, et chaque graphique peut afficher deux courbes d'apprentissage, une pour les
ensembles de données d'apprentissage et de test.
Courbe d'apprentissage d’erreur (Error) : la courbe d'apprentissage calculée en
fonction de l'indice (comme la perte) des paramètres optimisés du modèle.
Courbe d'apprentissage de précision (Accuracy) : courbe d'apprentissage calculée
sur la base des indicateurs (tels que la précision) du modèle d'évaluation et de
sélection.
Les paramètres d’entrainement ne sont pas fixes, on doit essayer différentes valeurs et
comparer les résultats pour pouvoir choisir les meilleurs paramètres les deux principaux
paramètres sur lesquelles on va travailler sont la taille du lot (batchsize) et le nombre
d’époques (epochs).
Qu’est-ce qu’un lot :
La taille du lot est un hyperparamètre qui définit le nombre d'échantillons à traiter avant de
mettre à jour les paramètres du modèle interne [B15].
Qu’est-ce que le nombre d’époques :
Le nombre d'époques est un hyperparamètre qui définit le nombre de fois que l'algorithme
d'apprentissage fonctionnera à travers l'ensemble de données d’entraînement [B15].
On va essayer par la suite de varier les deux hyperparamètres : la taille du lot (Batchsize) et le
nombre d’époques (epochs), de comparer les résultats ainsi on va fixer les paramètres en
2
E.N.I. Chapitre 3 : Réalisation de la phase
choisissant les paramètres qui donne les meilleurs résultats.
3
E.N.I. Chapitre 3 : Réalisation de la phase
Pour ces paramètres fixés (figure III.10) on peut voir d’après la courbe d’apprentissage
d’erreur correspondante à l’entrainement (train error) que l’erreur d’entrainement reste stable
quel que soit l’entrainement, et continue à diminuer jusqu’à la fin de l’entrainement. On peut
donc dire qu’il s’agit d’un modèle sous ajusté c’est-à-dire que le modèle n'a pas apprendre
l'ensemble de données d'apprentissage.
D’après les courbes présentées par la figure III. 11, on peut distinguer que la précision a
augmenté de 0.38 à 0.82. Mais pour l’erreur n’a pas évolué donc le modèle est encore sous
ajusté.
3
E.N.I. Chapitre 3 : Réalisation de la phase
D’après les courbes présentées par la figure III.12, on peut distinguer que la perte diminue
jusqu'à un point de stabilité, validation diminue jusqu'à un point de stabilité et présente un
écart plus ou moins faible avec la perte d'entraînement.
D’après les courbes présentées par la figure III.13 on peut distinguer que :
- Le tracé de la perte d'entraînement diminue jusqu'à un point de stabilité.
- Le tracé de la perte de validation diminue jusqu'à un point de stabilité et présente un
écart très faible avec la perte d'entraînement
Test accuracy =
0.989 Test loss =
0.04
3
E.N.I. Chapitre 3 : Réalisation de la phase
La même interprétation pour les courbes présentées sur la figure III.14 que pour celle
présentées par les courbes de la figure III.13, mais on peut voir que les résultats de précision
est de perte sont meilleurs pour la figure III.13.
Nous pouvons conclure alors que les performances sont bonnes pour les paramètres fixes :
batch size = 5 et le nombre d’epochs = 100
Les paramètres à considérer sont alors :
batch size = 5
epochs = 100
Un bon ajustement est identifié par une perte d'apprentissage et de validation qui diminue
jusqu'à un point de stabilité avec un écart minimal entre les deux valeurs de perte finales ce
qui est le cas pour le modèle aux paramètres déjà fixées
Notre modèle donc, n’est pas sur ajusté c’est-à-dire que sur les données d’entraînement, le
modèle est de plus en plus performant de même sur les données de validation.
3
E.N.I. Chapitre 3 : Réalisation de la phase
3
E.N.I. Chapitre 3 : Réalisation de la phase
Après l’utilisation de la méthode Dropout, les performances du modèle sont devenues plus
performantes, ce qui montre l’efficacité de cette méthode sur notre modèle. Il nous reste
maintenant que l’évaluation de notre modèle.
III.4.2.7 Evaluation du modèle
On doit récupérer tous les pixels sur l’écran de l’afficheur comme l’indique la figure III.17
pour pouvoir dire que le LCD est OK.
La figure III. 18 montre quelques tests de l’afficheur LCD, comparés à l’état OK on peut bien
détecter les défauts pour les cas défaillants.
3
E.N.I. Chapitre 3 : Réalisation de la phase
III.6 Conclusion
Ce chapitre décrit les différents aspects de la réalisation de la première phase de notre travail :
la phase d’inspection, nous avons détaillé en premier lieu les anomalies qu’on doit détecter
lors du process du test, dans une deuxième partie nous avons expliqué le choix pour le test des
Leds et nous avons clôturé par la démarche suivie pour le test du l’afficheur LCD ainsi que les
problèmes rencontrés. Dans le chapitre suivant nous entamons la dernière partie du notre
projet qui est la phase de conception et développement de l’interface de test.
3
Chapitre 4 : Conception et réalisation
De l’interface de test
E.N.I. Chapitre 4 : Conception et réalisation de l’interface de
IV.1 Introduction
Nous clôturons notre rapport par ce dernier chapitre au cours duquel nous décrivons les
différentes phases de la réalisation de l’interface graphique de test.
Afin de mieux comprendre le fonctionnement de l’application, nous avons essayé au niveau
de cette partie d’expliquer les technologies choisies et les étapes effectuées
Poste Vision
3
E.N.I. Chapitre 4 : Conception et réalisation de l’interface de
L’opérateur chargé de l’opération de test met le compteur à tester en place, il appui sur le
bouton départ cycle pour lancer le test.
Une fois le bouton est appuyé, l’interface s’affiche sur l’écran du poste, le compteur est
commandé (envoi des commandes spécifiques à chaque élément à tester) : la Led CPL et la
Led MTR s’allument en plus de l’affichage des pixels sur l’afficheur LCD.
Le test des 3 éléments est effectué et affiché sur l’interface indiquant ainsi l’état final du
compteur en se référant aux résultats des test de ses éléments.
A la fin du test, un rapport contenant toutes les informations est généré.
IV.2.2 Diagramme de séquences général
Dans cette partie, nous exploitons les diagrammes de séquences pour modéliser les différents
échanges entre les différents acteurs du système selon un ordre chronologique.
Le digramme de séquence des échanges entre l’opérateur et le poste vision, figure IV.2, nous
permet de mettre en ordre chronologique les différentes actions de l’opérateur durant le
processus de test.
Le diagramme de séquences des échanges qui se déroulent dans le système (figure IV.3) est une
3
E.N.I. Chapitre 4 : Conception et réalisation de l’interface de
Démonstration du déroulement des différentes phases d’un test dans un poste vision.
3
E.N.I. Chapitre 4 : Conception et réalisation de l’interface de
3
E.N.I. Chapitre 4 : Conception et réalisation de l’interface de
Ces commandes sont mises au SPEC (spécification de test") par l’équipe URD ("Unité de
recherche et de développement")
Le tableau résume un ensemble de commandes dont nous avons besoin :
4
E.N.I. Chapitre 4 : Conception et réalisation de l’interface de
L’interface de l’IHM définit l’état du poste avant le démarrage d’un test. Elle comprend 7
parties qui sont :
— Partie 1 : Logo de l’entreprise et le nom de la machine ;
— Partie 2 : Les messages affichés par le poste vision ;
— Partie 3 : affichage de la date et temps en temps réel ;
— Partie 4 : la zone correspondante à l’affichage du flux vidéo capturé par la caméra ;
— Partie 5 : la zone correspondante à la visualisation des résultats des test des Leds et de
l’afficheur ainsi le résultat final du compteur ;
— Partie 6 : la zone correspondante à l’affichage du nombre de compteurs testés, le nombre
des compteurs défaillants et le nombre des compteurs non défaillants ;
— Partie 7 : la zone correspondante a l’affichage du taux de FPY calculé à chaque phase de
test d’un nouveau compteur.
Le premier fichier généré par Qt Designer est un fichier « .ui »
IV.5.1.2 Conversion en script python
La conversion de l’interface utilisateur décrite dans le fichier .ui créer par Qt Designer doit être
traduite en un script python.
1/ Dans le chemin d’accès du répertoire où trouve le fichier.ui on tape la commande cmd
2/ Dans l’invité de commande on tape la commande : pyuic5 -x GUI.ui -o GUI.py
4
E.N.I. Chapitre 4 : Conception et réalisation de l’interface de
Importer Pyinstaller
La figure IV.7 montre le résultat du test de la Led MTR , après l’envoi de commande
correspondante pour allumer la Led orange. La zone correspondante au test de cette Led est
colorée en Rouge ce qui veut dire que nous n’avons pas détecter la couleur orange alors ce test
n’est pas réussi .
4
E.N.I. Chapitre 4 : Conception et réalisation de l’interface de
IV.7 Simulation
Pour la phase de simulation, et à cause de plusieurs facteurs liées à la société et à la situation
sanitaire, nous n’avons pas pu tester la solution sur le testeur de vision déjà existant, c’est
pourquoi nous avons essayé de préparer un dispositif semblable au testeur à l’aide des
composants suivants :
- Une camera HIKVISION FULL HD DS-U12[B17]:
Une interface avec l’ordinateur : USB ;
FULL HD CMOS ;
4
E.N.I. Chapitre 4 : Conception et réalisation de l’interface de
La figure IV.10 montre un résultat réussi « SUCCEED » de ce compteur puisque tous les
tests de ces éléments sont réussis.
4
E.N.I. Chapitre 4 : Conception et réalisation de l’interface de
Une fois on a commandé le compteur, l’afficheur LCD n’a pas affiché les pixels donc il y’a un
défaut au niveau de cet élément, le résultat de test du compteur est « FAIL » puisque le test du
LCD n’est pas réussi
4
E.N.I. Chapitre 4 : Conception et réalisation de l’interface de
IV.9 Conclusion
Dans ce dernier chapitre, nous avons expliqué le scénario d’un process de test dans un premier
lieu. Nous avons ensuite détaillé la partie de conception de l’interface graphique. A la fin,
nous avons évalué notre nouveau processus de test en se basant sur certains tests effectués.
4
Conclusion générale
Ce rapport présente notre projet de fin d’études réalisé au sein de la société Sagemcom.
Nous avons contribué, au cours de ce travail au développement d’un testeur de vision des
compteurs électriques, qui va contribuer à automatiser ces tests, puisque le processus de test
existant est fastidieux et long, par conséquence le but essentiel de ce projet est d’améliorer du
process existant.
En effet, les améliorations se présentent dans le gain du temps, la précision et la réduction des
coûts.
Nous avons développé une interface facile à manipuler et adaptée à l’utilisateur. Tout le
process du test est développé en langage python donc nous n’avons pas besoin du logiciel «
Vision Builder » qui coute cher, en plus cette application réalisée est plus rapide et permettant
d’effectuer tous les tests en un seul coup au lieu de tester chaque élément séparément.
Aussi, au lieu de retourner aux captures générées lors des tests pour identifier les défaillances
existantes, le rapport généré par le nouveau système contient tous les détails y compris les
anomalies si elles existent.
De plus, notre système est extensible et modulaire. L’enrichissement du programme par la
modification des fonctions et l’intégration de nouvelles fonctions est facile.
Ce projet était une bonne occasion pour nous afin d’apprendre des nouvelles méthodologies de
programmation, et aussi pour acquérir des multiples connaissances, tels que les fondamentaux
de l’industrie et la technologie d’intégration des systèmes informatiques dans une entreprise.
Cette expérience nous a également fait découvrir le monde professionnel et de développer nos
compétences d’un point de vue relationnel et surtout en matière de communication et de
coopération au sein d’une équipe.
Il est à signaler également que ce travail va construire le noyau d'un futur projet que
Sagemcom souhaite réaliser. Ce Projet futur consiste à tester automatiquement les compteurs
électriques, ainsi que déterminer les anomalies si elles existent pour l’amélioration du cycle
de production au sein de l’entreprise.
4
Références bibliographiques
[B1]https://advdownload.advantech.com/productfile/PIS/ACP-2020/file/ACP-
2020_DS(060721)20210610175907.pdf ; [consulté le 23/04/2021]
[B2]https://www.svs-vistek.com/en/industrial-cameras/svs-camera-
detail.php?id=eco655CVGE [consulté le 23/04/2021]
[B3] https ://moxa.ru/files/manuals-nport [consulté le 23/04/2021]
[B4] http://www.meter-test-equipment.com/fr/p/lecteur-de-port-optique-opto/
[consulté le 23/04/2021]
[B5]https://www.moxa.com/Moxa/media/PDIM/S100000327/moxa-iologik-e1200-series-
manual-v15.2.pdf [consulté le 23/04/2021]
[B6] https://geekflare.com/fr/best-python-ide/ [consulté le 02/03/2021]
[B7] https://www.netguru.com/blog/deep-learning-frameworks-comparison
[consulté le 15/03/2021]
[B8] https://fr.wikibooks.org/wiki/PyQt/Pr%C3%A9sentation_de_la_librairie
[consulté le 20/06/2021]
[B9] https://realpython.com/qt-designer-python/ [consulté le 15/06/2021]
[B10 ] : https://www.lemagit.fr/definition/Apprentissage-supervise [consulté le 02/03/2021]
[B11 ] https://inside-machinelearning.com/cnn-couche-de-convolution/ [consulté le
10/03/2021]
[B12] https://machinelearningmastery.com/learning-curves-for-diagnosing-machine-learning-
model-performance/[consulté le 02/04/2021]
[B13] https://machinelearningmastery.com/difference-between-a-batch-and-an-epoch/
[consulté le 02/04/2021]
[B14] : https://inside-machinelearning.com/cnn-couche-de-convolution/[consulté le
01/04/2021]
[B15]: https://machinelearningmastery.com/difference-between-a-batch-and-an-epoch/
[consulté le 02/04/2021]
[B16] CEI 62056-21 [consulté le 18/07/2021]
[B17] http://micromedia.tn/webcam/1052-webcam-hikvision-full-hd-ds-u12.html
[consulté le 05/08/2021]