Contraintes temps-réel non-strictes
L’application de vision reçoit 25 images par seconde, et doit générer les résultats correspondant à chacune de ces images, sans pour autant qu’un dépassement de délai occasionnel ne pose de problème grave au reste du système. L’application fonctionne par conséquent en temps-réel non-strict, on souhaite respecter cette cadence, en restant donc en moyenne en dessous de 40ms par image. La définition du terme « temps-réel » est un sujet de malentendus et de discussions animées, étant donné les différences fondamentales entre le temps-réel dit « non strict » et le temps-réel dit « dur », seul vrai « temps-réel » pour la communauté scientifique associée. On parlera de temps-réel dur pour une application qui doit respecter à tout moment des contraintes temporelles strictes. Le moindre dépassement de ces durées maximales d’exécution est alors considéré comme une défaillance grave du système. Il est à noter que la rapidité du système ne rentre pas en ligne de compte pour déterminer si une application est temps-réel « dur », une application fournissant une réponse à une requête au bout de plusieurs semaines peut être considérée temps-réel « dur », du moment que ce temps de réponse reste toujours inférieur à la limite fixée au préalable. Les systèmes critiques reposant sur un fonctionnement totalement déterministe et d’une fiabilité à toute épreuve, ils sont les principaux concernés par le temps-réel « dur ». Tous les systèmes n’étant pas aussi exigeants du point de vue de la fiabilité, il est souvent possible de déployer une application plus performante en réduisant la fiabilité temporelle (tendance des résultats à être générés avant leurs échéances) dans des limites acceptables. Ainsi, le temps-réel « non-strict », plus flexible, regroupe les applications qui doivent fournir un résultat dans des délais fixés à l’avance, mais qui peuvent accepter des dépassement de ces délais, voire des non-distributions de ces résultats, dans une mesure acceptable pour l’utilisateur (notion subjective). Par exemple, un décodeur vidéo sur un ordinateur peut sauter plusieurs images par seconde sans que l’expérience utilisateur ne soit trop perturbée, le maintien de la vitesse normale de la vidéo est par contre essentiel. Cet exemple est assez représentatif du temps-réel non-strict. Le système de vision robotique est étudiée ici dans un contexte temps-réel non strict, ce qui permet de fixer une cadence de fonctionnement plus élevée qu’en temps réel dur : le temps-réel non-strict gère les éventuels dépassements dûs à cette cadence plus élevée. Le temps de développement est aussi plus court pour mettre en place une application en temps-réel non-strict, une application en temps-réel dur nécessitant une étude temporelle approfondie (durées d’exécution maximales, risque d’interblocage, et autres) pour garantir le respect à tout moment des contraintes. La prédictibilité et par conséquent la fiabilité du système de vision sont les prix à payer pour déployer ce système de vision en temps-réel non-strict.
Consommation électrique et dimensions du système
Le système de vision étant prévue pour des robots mobiles autonomes, il est nécessaire d’identifier et de respecter les contraintes énergétiques, volumiques, et pondérales.Pour un système alimenté par batteries, la consommation énergétique est souvent un aspect primordial. Un même système peut être considéré comme exigeant ou économe en énergie électrique selon l’environnement dans lequel il sera implanté. En effet, une même puce électronique pourra avoir une consommation négligeable pour un camion,mais trop grande pour un téléphone portable. Pour le déploiement d’un système embarquée, il convient de choisir une plate-forme respectant les contraintes électriques de l’hôte qui l’alimente (le robot dans le cas présent). En fonction de l’énergie qu’il est acceptable de consommer au sein du robot (dimensions de la batterie propre, ou puissance disponible sur la batterie principale), le déploiement du système de vision peut être très fortement contraint. Parallèlement à la contrainte en puissance électrique, un système embarqué est généralement contraint à un encombrement limité. Il faut alors concevoir ce système en gardant à l’esprit ces contraintes de dimensions. Une capsule endoscopique et le système informatique d’un bateau de croisière n’ont pas les mêmes contraintes de volume, il faut donc évaluer la capacité de stockage physique de l’environnement pour envisager la conception du système. On notera que dans le cas de la capsule endoscopique, les contraintes d’encombrement sont telles, qu’on n’embarquera que le minimum dans la capsule, la quasi-totalité des traitements étant déportés sur des unités de calcul externes. En revanche, dans le cas d’un robot mobile autonome, on ne déportera pas de traitements à l’extérieur du robot, sans quoi on ne parlera plus de robot autonome. Comme pour la consommation électrique, les plate-formes envisageables pour répondre aux besoins du système de vision en accord avec les contraintes d’encombrement sont en nombre limité.
Pyramide Gaussienne
La pyramide Gaussienne de Crowley et al. (CRP02) est une approche multirésolution du traitement d’image, au même titre que la théorie des ondelettes, qui est aussi utilisée pour la détection de points d’intérêts (FKA06). Le principe de l’étude multirésolution est de découper le gradient en bandes de fréquence spatiale, ce qui permet d’obtenir des informations visuelles séparées pour chacune de ces bandes. L’étude multirésolution de l’image est utilisée dans le cadre de la vision bio-inspirée (Oue03, GSB04), pour sa modélisation plus précise du fonctionnement du cerveau des mammifères. Elle présente de nombreux avantages quant à la pertinence des résultats obtenus dans les différentes résolutions (Dye87). Le but est ici de permettre au réseau de neurones de mieux représenter son environnement (Mai07), tout en s’inspirant des mécanismes de vision des mammifères. La première portion de la pyramide Gaussienne se compose d’une cascade de filtres Gaussiens et de ré-échantillonnages, dont le but est de générer des filtrages passe-bas de l’image d’entrée à des fréquences de plus en plus basses. L’image est sous-échantillonnée à chaque octave, ce qui permet de réduire les durées d’exécution des traitements ultérieurs. Ceré-échantillonnage n’influe pas sur la qualité des informations d’après le théorème de Shannon. Ainsi, une sortie de sous-échantillonnage sera considérée comme un résultat de filtrage Gaussien pour la suite des calculs. La seconde partie de cette pyramide est constituée de soustractions d’images. Les soustractions pixel par pixel des résultats des filtrages Gaussiens successifs de chaque résolution sont appelées Différences de Gaussiennes (DoG). Ces DoG sont équivalentes à des filtrage passe-bande de l’image d’entrée de la pyramide, dans le cas présent, la norme du gradient de la caméra. Les bandes passantes des filtres équivalents des DoG correspondent à des demi-octaves successives.
Recherche de points d’intérêt
La recherche d’informations dans l’image est un sujet très actif dans le domaine du traitement d’image. Dans (Low99), Lowe s’inspire de la méthode de Schmid et Mohr (SM97) qui étudie les dérivées de Gaussiennes pour localiser des points d’intérêt dans une image, à plusieurs bandes de fréquence spatiale. La variante de Lowe repose sur l’identification d’extrema dans des Différences de Gaussiennes de l’image d’origine. Dans le cas du système de vision robotique, la pyramide Gaussienne de Crowleya été choisie pour l’étape de découpage multirésolution, cependant la localisation des points d’intérêt se fera de façon similaire à la méthode de Lowe. Un algorithme de recherche de maxima locaux identifie les points de plus forte luminance locale dans les sorties des DoG. Étant donné que la luminance dans le gradient représente la variation spatiale de luminance dans l’image d’entrée, les maxima locaux dans le gradient représentent les points saillants (les points de grandes variation de luminance) dans l’image de la caméra. Par extension, les maxima locaux dans une DoG représenteront les points les plus saillants dans l’image de départ, dans la bande de fréquence spatiale couverte par cette DoG. Les maxima locaux ne sont pas recherchés dans l’image de sortie du bloc gradient, mais uniquement dans les images de sortie des DoG : les points d’intérêt trouvés seront ainsi toujours associés à une information sur leur bande de fréquence correspondante. La recherche de maxima locaux se fait sur une fenêtre glissante circulaire autour des pixels testés. Si un pixel dans un rayon R autour du pixel étudié est supérieur à celui-ci, le pixel étudié ne sera pas considéré comme maximum local, et par conséquent ne sera pas identifié comme un point d’intérêt. En effet, on souhaite qu’une distance minimale soit respectée entre deux points d’intérêt, c’est le sens du mot « local » dans le terme « maximum local ». Une fenêtre carrée impliquerait que cette distance varierait selon l’angle par rapport auquel deux pixels se trouvent : deux points d’intérêt sur une même ligne devraient respecter un écart de R, tandis que deux points sur une même droite inclinée à 45˚par rapport à l’horizontale devraient respecter un écart de √ 2R. Les recherches de points d’intérêt sont paramétrables, selon deux variables :
– γ : seuil de détection. Pour être considéré comme point d’intérêt, un pixel d’une DoG doit avoir une valeur supérieure à ce seuil. Le réglage de ce seuil permet de réduire le bruit correspondant à des maxima locaux de valeur trop faible. Ces points, jugés trop peu saillants dans l’image de la caméra, sont donc écartés.
– R : rayon de la zone locale de recherche. Le rôle de ce paramètre est d’empêcher la trop forte proximité de deux points d’intérêt. Si deux maxima locaux trop proches l’un de l’autre (donc de même valeur) sont découverts, un seul des deux sera considéré comme point d’intérêt, l’autre sera inhibé. R évolue proportionnellement avec la résolution d’image, d’une octave à une autre.
|
Table des matières
Table des figures
Liste des tableaux
Introduction
Cadre du projet
Problématique
Structure du document
1 Présentation du projet
1.1 Contexte
1.1.1 Équipes Neurocybernétique et ASTRE
1.1.2 Présentation du système de vision
1.1.3 Place du système de vision au sein du robot
1.1.4 Contraintes temps-réel non-strictes
1.1.5 Consommation électrique et dimensions du système
1.2 Découpage fonctionnel
1.2.1 Gradient
1.2.2 Pyramide Gaussienne
1.2.3 Recherche de points d’intérêt
1.2.4 Tri des points d’intérêt
1.2.5 Mise en forme des caractéristiques locales
1.3 Flot de conception du système de vision
1.3.1 Flot de conception logiciel embarqué
1.3.1.1 Caractérisation de l’application complète
1.3.1.2 Découpage logiciel/matériel
1.3.1.3 Optimisation de la partie logicielle du SoC
1.3.1.4 Validation
1.3.2 Déploiement matériel
1.3.2.1 Parallélisation
1.3.2.2 Mise en cascade
1.3.2.3 Validation – modèle logiciel d’IP
1.3.3 Architecture globale du système de vision
1.3.4 Tests et validation
2 État de l’art
2.1 Vision artificielle
2.1.1 Vision robotique
2.1.2 Vision artificielle bio-inspirée
2.2 Caméras intelligentes
2.3 Traitement d’image
2.3.1 Caractérisation d’images
2.3.2 Cartographie log-polaire
2.4 Aspects technologiques
2.4.1 Systèmes sur puces (SoC)
2.4.2 Parallélisation des traitements
3 Exploration logicielle
3.1 Algorithmes
3.1.1 Norme de gradient 2D
3.1.2 Pyramide Gaussienne
3.1.2.1 Filtrages Gaussiens
3.1.2.2 Sous-échantillonnages
3.1.2.3 Différences de Gaussiennes
3.1.3 Recherche de points d’intérêt
3.1.4 Tri des points d’intérêt
3.1.5 Mise en forme des voisinages de points d’intérêt
3.2 Caractérisation de l’application
3.2.1 Durées d’exécution sur PC
3.2.2 Durées d’exécution sur processeur embarqué
3.2.3 Parallélisation logicielle embarquée
3.2.4 Charge des canaux de communication
3.3 Conclusion
4 Architecture des traitements matériels (IP)
4.1 Vue d’ensemble
4.2 Squelette des IP
4.3 Intensité de gradient
4.4 Filtrage Gaussien
4.4.1 État de l’art : convolution Gaussienne 2D
4.4.2 Noyau de convolution et division
4.4.3 Convolution 2D
4.4.4 Coefficients redondants dans les noyaux de convolution
4.4.5 Séparation en deux convolutions 1D
4.4.6 Gestion des effets de bords
4.5 Différence de Gaussiennes
4.6 Sous-échantillonnage
4.7 Recherche de points d’intérêt
4.8 Tri de points d’intérêt
4.9 Mise en forme des caractéristiques log-polaires
4.10 Conclusion
5 Déploiement
5.1 Plate-forme de traitements
5.1.1 Partitionnement logiciel/matériel
5.1.2 Interface réseau
5.2 Validation de l’architecture
5.2.1 Modèle logiciel des IP
5.2.2 Simulation
5.3 Réglage des paramètres
5.3.1 Ressources utilisées par IP
5.3.2 Filtrage Gaussien
5.3.3 Recherche de points d’intérêt
5.3.4 Extraction de voisinages de points d’intérêt
5.4 Choix de la plate-forme FPGA
Conclusion
Références
Annexes
Résultats de synthèse supplémentaires
Télécharger le rapport complet
