Quelles étapes sont nécessaires pour migrer les algorithmes Assembly Vision vers un NPU Ascend ?

Article technique

La migration de l'algorithme de vision d'assemblage vers Ascend NPU ne signifie pas copier les fichiers de modèle d'origine sur l'appareil Atlas, mais compléter la personnalisation du système du format du modèle, des opérateurs, des entrées et sorties, de l'interface d'exécution et des critères d'acceptation. La méthode typique est la suivante : corrigez la ligne de base du modèle d'origine, exportez ONNX, vérifiez la structure du graphique et les opérateurs, utilisez ATC pour générer le modèle OM pour le processeur cible Ascend, accédez à l'inférence via AscendCL, puis effectuez la vérification de la cohérence avant et après le traitement, les résultats de détection, les performances d'exécution et le déploiement de la version.

Le logiciel d'inspection visuelle et les applications algorithmiques de Winge Technology pour les assemblages fonctionnent déjà sur le Huawei Ascend Atlas 200I DK A2. Pour les projets qui utilisent des modèles de classification, de détection d'objets ou de segmentation, des liens d'inférence de modèle Ascend NPU peuvent être ajoutés en fonction de l'accès à la caméra existant, de la configuration du retour sur investissement, de l'enregistrement des résultats et du déploiement local.

Quelles entrées doivent être corrigées avant la migration ?

Avant de démarrer la migration, il convient de constituer un package de base reproductible comprenant au moins les éléments suivants :

Cadre de formation original, structure du modèle, poids et scripts d'exportation ;
Exigences relatives au nom d'entrée, à la taille d'entrée, au type de données et aux dimensions dynamiques pour les modèles ONNX ;
Méthodes de classement, de mise à l'échelle, de recadrage, de normalisation et de tensorisation des couleurs d'images ;
Etiquettes de classification, décodage des trames de reconnaissance, seuils de confiance, règles de traitement NMS ou post-segmentation ;
Un ensemble fixe d'échantillons OK, NG et limites et leurs résultats attendus ;
Appareil Target Atlas, modèle de processeur Ascend, système d'exploitation, CANN et version du package opérateur ;
Indicateurs d'acceptation du projet tels que l'exactitude, les faux positifs, les faux positifs, la consommation de temps unique, le débit et le stockage.

Si ces entrées ne sont pas prises en compte, même si la conversion du modèle réussit, il ne peut pas être déterminé si la différence avant et après la migration est due au modèle, au prétraitement, au post-traitement ou à l'environnement de gestion des versions.

Étape 1 : Créer une référence à partir des résultats du modèle d'origine

Utilisez le même ensemble d'images d'acceptation pour exécuter le modèle d'origine et stocker les tenseurs d'entrée, la sortie d'origine, les résultats de post-traitement et les décisions commerciales finales. Le projet de détection d'objets doit également enregistrer les résultats du cadre de détection, de la catégorie, de la confiance et du NMS ; Le projet de segmentation doit stocker la taille du masque, le mappage des catégories et les résultats de contour.

Le rôle de la référence n'est pas de fournir un taux d'exactitude uniforme, mais plutôt de fournir un échantillon de base de comparaison pour les résultats ultérieurs ONNX et OM. Les indicateurs du projet doivent être déterminés sur la base d'échantillons de clients, de définitions de défauts et de conditions de travail.

Étape 2 : Exporter et vérifier le modèle ONNX

Après avoir exporté ONNX depuis le framework de formation, vous devez vérifier les points suivants :

Les noms des nœuds d’entrée et de sortie sont-ils stables ?
Si la taille d'entrée est une taille fixe ou une taille dynamique ;
Si la version de l'opérateur et la structure du graphique correspondent à l'environnement de conversion cible ;
S'il faut inclure les nœuds qui ne sont utilisés que pendant la phase de formation ;
Si les résultats de l'exécution ONNX et les résultats du modèle d'origine se situent dans la plage d'erreur convenue.

Dans cette étape, vous devez d'abord résoudre le problème d'exportation du modèle lui-même, puis effectuer la conversion côté Ascend pour éviter que les différences dans le modèle source soient transférées côté appareil.

Étape 3 : Vérifiez la compatibilité des opérateurs et la structure du graphique

Avant la conversion ATC, les opérateurs, attributs, types de données et contraintes de forme utilisés par le modèle doivent être vérifiés. S'il existe des opérateurs ou des combinaisons non pris en charge, vous pouvez choisir entre la réécriture de graphiques, le remplacement d'opérateurs équivalents, le fractionnement et le post-traitement, ou des opérateurs personnalisés basés sur la structure du modèle. Vous ne devez pas uniquement utiliser « exécution de la commande de conversion terminée » comme critère d'achèvement de la personnalisation.

Pour les piles dynamiques, la taille d'image dynamique ou les dimensions dynamiques, les engrenages correspondants doivent être configurés en fonction de l'entrée réelle du poste de travail. Les stations d'assemblage dotées de caméras fixes et de dimensions de capture fixes peuvent généralement utiliser initialement des formes fixes pour réduire les branchements d'exécution et faciliter l'acceptation.

Step 4: Use ATC to generate an OM model

La documentation officielle Ascend de Huawei indique que l'ATC est utilisé pour convertir des modèles de framework open source tels que ONNX en modèles hors ligne OM pouvant être reconnus par le processeur Ascend AI. A typical command structure is as follows:

« Bash

atc --model=model.onnx

--framework=5

--output=modèle_atlas

--input_shape="images:1,3,H,W"

--soc_version=<target Ascend processor model>

Les paramètres réels doivent correspondre à l'entrée du modèle, au processeur cible et à l'environnement du projet. Pendant la conversion, la commande ATC SHA-256, la version de l'environnement, le journal de conversion, le rapport d'inspection et le fichier généré doivent être enregistrés pour suivre et reproduire le processus de création du modèle OM.

Étape 5 : Connectez-vous au lien d'inférence AscendCL

Une fois le modèle OM généré, l'application côté appareil doit terminer l'initialisation des ressources, la sélection de l'appareil, le chargement du modèle, la gestion de la mémoire d'entrée et de sortie, l'exécution du modèle, la lecture des résultats et la libération des ressources. Le chemin de données complet pour un système de vision d’assemblage est généralement :

Industrial camera or image files

-> Decoding, cropping and checking image quality

-> Redimensionnement, conversion des couleurs, normalisation et disposition des tenseurs

-> Raisonnement du modèle OM

-> Décoder le résultat de classification, de détection ou de segmentation

-> ROI with assembly business rules

-> PASS / FAIL / UNKNOWN

-> Tableau des preuves, journal des résultats et interface du poste de travail

L'interface d'inférence est uniquement responsable du calcul du modèle, et la détermination finale du poste de travail gère également la déduplication du déclenchement, la qualité de l'image, la preuve des résultats, l'état anormal, l'interface API ou E/S et le suivi des données.

Étape 6 : Vérifier la cohérence du pré- et post-traitement

Les différences communes dans les projets de migration ne proviennent pas nécessairement du modèle lui-même. L'ordre des couleurs, la méthode d'interpolation, le coefficient de normalisation, la méthode de quantification, la disposition du tenseur, la mise à l'échelle des coordonnées et les paramètres NMS peuvent modifier la sortie.

Il est recommandé de comparer aux niveaux suivants :

- Couche d'entrée : comparez les tenseurs entrés dans le modèle d'origine et le modèle OM. - Couche de sortie : comparez la forme, la plage de valeurs et l'ordre des nœuds de la sortie originale du modèle. - Niveau algorithme : comparer les catégories, les champs de détection, les masques et la confiance ; - Couche métier : Comparez les résultats PASS, FAIL ou INCONNU de chaque échantillon. - Niveau de preuve : comparez les emplacements des défauts, les cartes d'annotations et les enregistrements de résultats pour déterminer s'ils correspondent à la même pièce.

Ce n'est qu'en identifiant les différences couche par couche que nous pouvons juger si la conversion du modèle, le traitement des données ou les règles métier doivent être ajustés.

Étape 7 : Effectuez la vérification des performances et de la stabilité de l'appareil

Les tests de performances doivent être effectués sur les appareils cibles Atlas, les tailles d'image formelles et les connexions de traitement réelles, en distinguant :

- le temps de capture ou de décodage des images ; - le temps de prétraitement ; - Temps d'inférence pour un seul modèle ; - Temps de post-traitement et règles métiers ; - Temps de rédaction des images de preuves et des fichiers de résultats ; - Temps de réponse de bout en bout des postes de travail.

Les résultats des tests doivent également enregistrer la version du modèle, le hachage du fichier OM, la version CANN, le modèle de processeur, la taille d'entrée, le lot, le mode de précision, le nombre d'échauffements et le nombre d'échantillons. La précision, la durée du cycle de production et la stabilité à long terme sont confirmées par des inspections indépendantes de projets spécifiques et des conditions de fonctionnement continues.

Étape 8 : Former une livraison de version enroulable

La livraison formelle doit contenir au moins les éléments suivants :

- Modèle original ou fichiers sources du modèle dans la portée convenue ; - Modèle ONNX et instructions d'exportation ; -Modèle OM, commande ATC, protocole de conversion et valeur de contrôle ; - Code de prétraitement, d'inférence, de post-traitement et d'interface métier ; - Système d'exploitation, CANN, package opérateur et liste des versions dépendantes ; - Exemples de résultats de vérification, enregistrements de différences et rapports de tests de performance ; - Instructions de configuration, de démarrage du service, de journalisation, de mise à niveau, de sauvegarde et de restauration.

Winge Technology peut effectuer un travail de migration de modèles avec les caméras, les optiques, le retour sur investissement,

Quels sont les problèmes les plus susceptibles d’avoir un impact sur les résultats de la migration ?

| Question | Symptômes courants | Sens de traitement | |---|---|---| | Les définitions d'entrée sont incohérentes | Changement général des résultats ou niveau de confiance anormal | Couleur, taille, normalisation et disposition du tenseur corrigées | | L'opérateur ou le formulaire n'est pas compatible | La conversion ATC échoue ou la structure de sortie change | Réécriture de graphiques, remplacement d'opérateurs, d'engrenages dynamiques ou d'opérateurs personnalisés | | Post-traitement incohérent | Le nombre, l'emplacement ou la catégorie des cadres de reconnaissance sont différents | Décodage unifié, seuillage, NMS et récupération de coordonnées | | La combinaison de versions n'est pas fixe | Le même modèle se comporte différemment dans différents environnements | Système fixe, CANN, package opérateur et dossier de construction OM | | Le simple fait de tester le modèle prend du temps | Le rythme live ne répond toujours pas aux exigences | Lien complet depuis l'acquisition des mesures jusqu'à la sortie des résultats | | Collection de validation indépendante manquante | Il n'existe aucun moyen de déterminer si la migration maintiendra les résultats de l'entreprise | Utiliser OK, NG et limiter les échantillons qui ne sont pas impliqués dans l'optimisation des paramètres |

FAQ

### Les modèles ONNX peuvent-ils fonctionner directement sur le NPU Ascend ?

En règle générale, il est nécessaire d'utiliser ATC pour convertir le modèle ONNX en un modèle hors ligne OM basé sur le processeur Ascend cible et l'environnement CANN, puis de le charger et de l'exécuter via des interfaces côté périphérique telles que AscendCL.

### La conversion pour générer des fichiers OM signifie-t-elle que la migration est terminée ?

Pas tout de suite. Il est également nécessaire d'effectuer l'amarrage des entrées et des sorties, la cohérence avant et après le traitement, la comparaison aléatoire des résultats, les tests de performances côté appareil, la gestion des exceptions et la vérification de la livraison des versions.

### Toutes les règles de vision traditionnelles doivent-elles être converties en réseaux de neurones ?

Pas besoin. Les règles de retour sur investissement avec des positions fixes et des limites claires peuvent toujours être maintenues ; Des modèles de classification, de détection d'objets ou de segmentation sont utilisés pour gérer les changements de catégorie, les arrière-plans complexes et les tâches de reconnaissance sémantique, et les deux peuvent être combinés dans la même application Atlas.

### Le même modèle OM peut-il être utilisé directement pour tous les appareils Atlas ?

Les paramètres de conversion du modèle OM concernent le processeur cible Ascend et l'environnement logiciel. Lors de la mise en œuvre du projet, le modèle de processeur, le CANN et la version du package opérateur doivent être confirmés en fonction du périphérique cible et les enregistrements de build correspondants doivent être conservés.

### Comment évaluer si les résultats avant et après migration sont cohérents ?

Un échantillonnage fixe doit être utilisé pour comparer le tenseur d'entrée, la sortie originale du modèle, les résultats de l'algorithme et le jugement commercial final couche par couche. L'acceptation doit être basée sur l'erreur, l'exactitude et les règles du poste de travail confirmées par les deux parties. Vous ne pouvez pas simplement comparer un petit nombre d’images de démonstration.

sources officielles

- Huawei Ascend : modèle ONNX passé au modèle OM https://www.hiascend.com/document/detail/zh/CANNCommunityEdition/81RC1beta1/quickstart/quickstart/quickstart_18_0010.html - Huawei Ascend : paramètres de ligne de commande ATC et restrictions de l'opérateur https://www.hiascend.com/document/detail/fr/canncommercial/850/devaids/atctool/atlasatc_16_0039.html - Huawei Ascend : construction de modèles AscendCL et développement d'applications https://www.hiascend.com/document/detail/zh/canncommercial/850/appdevg/acldevg/aclcppdevg_000027.html

Atlas, Ascend, CANN, AscendCL et les noms associés appartiennent à leurs détenteurs de droits d'auteur. Cet article explique les méthodes de personnalisation des projets Assembly Vision fournies par Winge Technology. Cela ne signifie pas que les titulaires de droits concernés participent ou soutiennent le projet spécifique. Les capacités de l'équipement et des outils sont soumises aux documents de publication officiels pertinents, et les résultats du projet sont soumis aux modèles, échantillons, équipements et conditions d'acceptation réels.