Études de cas
Le logiciel de ROC de vision machine et la caméra mis ensemble pour inspecter des étiquettes de céréales et de collations à haute vitesse
Dans le passé, les systèmes de vision de reconnaissance optique de caractères (ROC) n’étaient généralement pas rapides, flexibles ou maintenables. Toutefois, les systèmes d’aujourd’hui sont différents, alors lorsqu’un important fabricant international de céréales et de collations a donné la tâche à EPIC Machine Vision Systems d’en installer un, l’intégrateur de système vision était confiant de son approche.
Sur le site du fabricant, un système rejette du convoyeur les produits de nourriture emballés dont le code de données est incorrectement imprimé. Alors que le système précédent fonctionnait raisonnablement bien, il était vieux et n’était plus pris en charge par le développeur de logiciel d’origine. Le fabricant cherchait à mettre à jour son système existant afin de respecter les normes de qualité et de sécurité alimentaire de l’industrie ainsi que pour améliorer l’ensemble du procédé d’inspection ROC.
L’équipe de conception a débuté avec une méthodologie d’ingénierie préliminaire (F.E.E.) qui impliquait la collecte de dizaines de milliers d’images en ligne en cours de traitement de plusieurs unités de stock (SKU), imprimantes et formats d’impression à des fins de tests.
« Nous passons plus de temps au début afin de nous assurer que le système de vision final clef en main n’a pas besoin d’un « ajustement » constant qui est trop commun avec les systèmes de vision » dit Dan Nadolny, le directeur d’ingénierie de EPIC.
Afin d’installer un système de ROC pour l’entreprise, qui a plus de 50 sites de production dans le monde, EPIC a déployé l’outil SureDotOCR du logiciel MIL (Matrox Imaging Library) de Matrox Imaging qui est spécifiquement conçu pour lire des textes en matrice de point. Avec l’appui de Matrox Imaging, EPIC a utilisé ces banques d’images pour optimiser les paramètres d’algorithmes et établir un point de départ pour le traitement nécessaire et le matériel d’imagerie. Les résultats de test comprenaient plusieurs imprimantes et de grandes quantités de variations d’impressions (par exemple le contraste, le rapport de format, les positions des lignes, l’espacement des caractères et les lignes courbes).
En ce qui concerne la portion caméra du système de vision, EPIC a choisi la caméra Genie Nano M1940 de Teledyne DALSA. La caméra M1940 GigE Vision est un modèle monochrome avec un capteur d’image 2.4 MPixel IMX174 CMOS de Sony qui a une taille de pixel de 5.86 µm et peut atteindre une cadence standard de 51 images par secondes. La caméra a été configurée pour fournir un diamètre de point de 5 pixels et était interfacé avec une carte de communication PCIe Matrox Indio I/O, qui offre un port Gigabit Ethernet avec prise en charge de Power over Ethernet (PoE) et 16 E/S numériques en temps réels et discrets. L’application utilise des ordinateurs standard et industriels, avec une caméra et un éclairage dôme « temps nuageux » fournissant un éclairage uniforme sur le contraste de surface du produit.
Le but à atteindre était un taux de lecture de 99,97 %, ou un taux d’échec de moins de 300 lectures par million.
« L’algorithme de SureDotOCR atteignait un taux de lecture de 99,90 %, avec un réglage d’un diamètre d’un point et un taux de lecture de 99,99 % avec trois essais de lecture à différents réglages de diamètre de point » mentionne Chris Walker, chef de projet chez EPIC. « Le « diamètre de points » est défini par la moyenne du diamètre de pixels des points individuels dans la chaîne de texte imprimée en matrice de points. Matrox recommande un diamètre de point de 7 pixels, mais l’équipe de conception a opté pour un diamètre de points de 5 pixels pour réduire les besoins de stockage d’image et de bande passante. »
Le temps d’inspection typique pour un seul essai de lecture, impliquant deux lignes de textes et environ 36 caractères au total, était d’environ 40 ms, selon M. Walker.
« Des fichiers en police étrangère ont été créés et testés avec des performances similaires aux polices alphanumériques anglaises standard » dit-il. « L’algorithme pouvait excéder 1200 inspections par minute sur deux lignes de texte avec environ 36 caractères imprimés au total. Les taux de lecture atteignant aussi haut que 2500 inspections par minute ont été vus lors des essais lecture unique. Le traitement multifil et multicœur supporté par MIL a permis d’atteindre les taux de lectures requis.»
Un taux d’inspection de 1200 produits par minute fourni un temps d’inspections consécutives de seulement 50 ms par produit. Le temps moyen d’inspection pour un essai de lecture unique était tout juste sous cette valeur à 40 ms. Il est recommandé de faire trois essais de lecture/d’inspection pour augmenter la robustesse du système. Les temps d’inspections excèdent périodiquement 100ms et sont même aussi élevés que 286 ms lors des tests initiaux. Le système de vision dépendait de la composante d’architecture multifils, une composante importante supporté par MIL SDK, pour surmonter ces temps. Le multifil est synonyme du traitement parallèle et c’est la fonction avec laquelle un ordinateur peut effectuer plusieurs traitements en concurrence.
Le système de vision, par MIL, peut aussi recevoir et tamponner des images pour le traitement en file d’attente et avoir plusieurs fils pour traiter ces images en parallèle. Alors que l’architecture multifils permet d’atteindre de hauts taux de traitement, ceci requiert au système de vision de suivre les produits sous inspection afin de bien rejeter les produits en échec sujet à de plus longs temps d’inspection.
Par exemple, si les produits voyagent sur un convoyeur à haute vitesse et le système de vision commence à refouler en raison d’une grande file d’images à traiter, ou si une lecture prend un temps considérablement long pour le traitement, le produit en attente d’inspection sera nettement plus loin sur le convoyeur lorsque l’inspection sera terminée et que le résultat de passage/échec sera prêt. Pour cette application, si le temps d’une seule lecture pour traiter le produit est de 500 ms, le produit serait près de 1 m plus loin sur le convoyeur.
Ce problème a été surmonté en fournissant une rétroaction d’encodage pour la ligne de convoyeur existante pour suivre les distances des produits entre le point d’inspection et l’éjecteur situé 1,5 m plus loin, permettant au système de vision de fonctionner avec des problèmes occasionnels de temps de lecture considérablement plus long tout en assurant que les résultats d’inspections seront communiqués avant que le produit soit à l’éjecteur.
En fin de compte, la solution de la ROC était flexible et assez robuste pour répondre aux exigences de l’application selon M. Walker.
Pour plus d'informations, contactez notre équipe de relations avec les médias.
