Récemment, l'équipe R&D de Homsh a finalisé l'intégration en cascade à trois niveaux du module de capture binoculaire MD31, de la plateforme de calcul edge RK3588 et de la carte d'accélérateur FPGA AXU9EGB, et a publié un rapport technique par phases. De la capture d'une image d'œil en niveaux de gris de 640x480 par la caméra, en passant par l'évaluation de la qualité, la localisation de l'iris, l'inférence des caractéristiques, la correspondance 1:N, jusqu'à l'affichage des résultats de reconnaissance à l'écran — tout ce pipeline s'exécute désormais entièrement sur trois cartes matérielles.
Pour Homsh, il ne s'agit pas seulement d'un autre test d'intégration réussi. Cela signifie que nous avons migré les capacités de reconnaissance d'iris, qui fonctionnaient auparavant sur des PC industriels sous Windows, vers une architecture edge avec une consommation d'énergie réduite, des facteurs de forme plus flexibles et la possibilité d'être intégrées dans divers appareils terminaux.
L'ensemble du système adopte une architecture en cascade : capture et recadrage par la caméra MD31, accès et transmission par le RK3588, inférence par le FPGA AXU9EGB, et retour visuel par le RK3588. Le MD31 produit des images recadrées d'un seul œil pour l'œil gauche et l'œil droit ; le RK3588 fonctionne sous Android ARM64, responsable de l'appariement binoculaire, de la gestion des tâches et de la transmission réseau ; le FPGA gère le contrôle qualité et tous les algorithmes d'iris, et renvoie les résultats au RK3588 pour l'affichage.
Cette répartition des tâches a une signification plus profonde : la capture par la caméra et l'inférence par le FPGA sont entièrement découplées, connectées par une couche sémantique de protocole unifiée. Chaque ensemble d'images d'œil gauche et droit est associé à un ID d'opération et à un numéro de séquence strictement croissant, garantissant qu'il n'y a pas de confusion entre les images d'aperçu, les images de nouvelle tentative et les images des tâches précédentes. Par conséquent, notre solution Windows existante et la nouvelle solution RK3588 partagent le même ensemble de protocoles FPGA et de définitions de résultats d'inférence, avec un ensemble de services embarqués prenant en charge deux générations de systèmes hôtes.
Flux de données global de la cascade à trois niveaux
Le FPGA renvoie simultanément le statut de qualité, les identités candidates, les scores de similarité, les distances, les seuils et les durées des étapes, rendant l'ensemble du processus de reconnaissance entièrement visible pour les utilisateurs.
La partie la plus lourde du pipeline se trouve sur l'AXU9EGB. Basé sur la carte FPGA Zynq UltraScale+ MPSoC, et activé par Vitis AI 3.0 et l'accélération matérielle DPU, il prend en charge le pipeline d'inférence complet en sept étapes : de la validation de l'entrée, la localisation de la pupille et de l'iris via un modèle circulaire à six paramètres, le contrôle qualité, le déroulement du système de coordonnées polaires de Daugman, jusqu'à la génération de caractéristiques d'iris à 512 dimensions par le réseau profond IResNet100, la correspondance 1:N après normalisation L2, et enfin le renvoi des résultats avec la latence par étape.
Permettre à un réseau profond de cent couches d'extraire des caractéristiques de manière stable sur FPGA repose sur un alignement strict entre la quantification du modèle, les jeux de données de calibration et les distributions d'images réelles de la caméra, ainsi que sur un backend d'accélération zero-copy personnalisé pour le modèle circulaire. C'est exactement ce que Homsh fait depuis 15 ans : intégrer des algorithmes dans le matériel, afin que la reconnaissance se produise au plus près de l'appareil.
Pipeline d'inférence embarqué en sept étapes sur FPGA
Les images échouant aux contrôles de qualité sont rejetées à la troisième étape, évitant ainsi des calculs de caractéristiques inutiles. Vecteur de caractéristiques d'iris à 512 dimensions — pipeline d'inférence embarqué en 7 étapes — 326 tests cumulatifs réussis
En termes de logique d'utilisation, le système adhère au principe "enregistrement strict, reconnaissance flexible". Lors de l'enregistrement, les modèles des yeux gauche et droit de l'utilisateur doivent passer le contrôle qualité et être enregistrés avec succès ; les images échouées, les côtés d'œil dupliqués et les côtés d'œil inconnus sont exclus du compte d'enregistrement. Lors de la reconnaissance, en revanche, les yeux gauche et droit sont inférés séparément et comparés 1:N aux modèles d'yeux gauche et droit de la bibliothèque de modèles respectivement. Une correspondance d'une seule image de requête d'œil avec n'importe quel modèle renvoie un résultat — les utilisateurs n'ont pas besoin de positionner les deux yeux pour le système ; l'œil capturé est traité.
Les échecs de qualité, les correspondances temporaires ou les erreurs de communication récupérables ne terminent pas brusquement la tâche. Le système conserve l'état de la tâche et continue d'attendre le prochain ensemble d'images ; après la récupération de la connexion, il reprend à partir de l'ID de l'opération et des numéros de séquence reconnus sans resoumettre les images déjà reçues par le FPGA. Chaque étape de reconnaissance — qualité, similarité, distance, seuil, latence — est renvoyée à l'interface, rendant le succès, l'échec et les nouvelles tentatives visibles pour les utilisateurs.
L'enregistrement nécessite des modèles binoculaires complets, tandis que la reconnaissance n'a besoin que d'une correspondance de l'un ou l'autre œil, équilibrant ainsi sécurité et expérience utilisateur.
Ce dont nous sommes le plus fiers dans ce rapport par phases, c'est en fait sa méthodologie. Chaque conclusion de vérification est clairement catégorisée en quatre types : "Vérifié" pour les résultats de test reproductibles, "Historiquement vérifié" à partir des enregistrements d'intégration précédents, "Déduit" dérivé de la logique d'implémentation, et honnêtement marqué "À vérifier" pour les éléments temporairement non confirmés. Les 176 tests automatisés sur la base Windows ont tous été réussis, 150 tests Python embarqués ont été réussis, et les fonctions d'enregistrement/reconnaissance et de récupération de connexion ont été intégrées — tout cela est documenté dans le rapport. Les éléments non encore re-testés sur site sont également clairement marqués "À vérifier" noir sur blanc, sans ambiguïté.
La reconnaissance d'iris concerne l'identité, ne laissant aucune place au "probablement correct". Documenter les incertitudes sur papier est notre engagement envers nos clients, et envers nous-mêmes.
Trois chiffres clés : caractéristiques à 512 dimensions générées via l'accélération DPU ; tous les 176 tests automatisés de base Windows réussis ; 150 enregistrements de tests Python embarqués réussis.
Le jugement global du rapport est que la solution actuelle a jeté les bases d'une démonstration, d'une intégration et d'une documentation par phases, avec des limites architecturales claires et une architecture en cascade globalement techniquement réalisable. Les prochaines priorités sont tout aussi claires : stabilité de bout en bout, qualité d'image en temps réel, cohérence du déroulement des coordonnées polaires, et surveillance de l'état en boucle fermée pour un fonctionnement à long terme, faisant passer le pipeline de "fonctionnel" à "stable et fiable", puis à des produits prêts pour la production.
Des puces de reconnaissance d'iris auto-développées, à la synergie logiciel-matériel entre algorithmes et FPGA, jusqu'à la pipeline de reconnaissance complète intégrée dans des appareils edge aujourd'hui, Homsh a toujours cru que l'avenir de la biométrie se trouve à l'edge. Ce rapport par phases est une nouvelle étape vers cet avenir.
