Le calcul de normales permet d’avoir des amers beaucoup plus riches que les simples amer- point. On a d’ailleurs pu constater, en le comparant avec le SIFT, que cela permet de s’éloigner grandement de la trajectoire en conservant une meilleure mise en correspondance. L’amélio- ration est particulièrement sensible en terme de nombre d’appariements réalisés. Cela pourra donc permettre, lors de la localisation de conserver suffisamment d’appariements pour pouvoir localiser le véhicule malgré des écarts importants à la référence. De plus, avec sa capacité à s’adapter à la vue courante, il est assez peu probable de confondre un appariement avec un autre.
Il est cependant important de noter que l’utilisation de patchs nécessite une prédiction de la localisation aussi précise que possible. En effet lorsque la prédiction est très imprécise, de nombreux faux appariements sont réalisés. Cet inconvénient reste toutefois peu gênant dans le cadre d’une localisation, car le véhicule suit une trajectoire connue que l’on peut facilement prédire.
Tout semble donc indiquer que l’utilisation de patchs est une méthode très prometteuse pour la navigation autonome. Néanmoins, cela nécessite des calculs de projection sur chaque image qui sont assez lourds à mettre en œuvre. Afin d’atteindre des performances temps réel, il est donc indispensable d’améliorer les performances de l’algorithme et son implémentation.
Implémentation GPU
3.1
Analyse de la durée d’exécution
L’algorithme a tout d’abord été conçu sans se préoccuper de la contrainte temps réel. En effet, l’utilisation de nombreux patchs et leur reprojection un à un est assez lourde en temps de calcul et les moyens tels que la programmation sur GPU sont connus pour résoudre les problèmes de ce type.
Lors des premières exécutions, la localisation du véhicule prend plusieurs secondes à chaque image sur une machine offrant des performances dans la moyenne. Cela rend donc cet algo- rithme inutilisable en l’état dans un cadre de navigation autonome. Il est en effet impossible de commander un véhicule si sa position n’est connue que 3 secondes après avoir acquis une image sans pouvoir en traiter plus d’une toutes les 3 secondes. Il est donc nécessaire, en travaillant sur l’implémentation elle-même, de parvenir à une accélération du processus. Afin d’améliorer spé- cifiquement les parties les plus longues, une analyse du temps d’exécution du programme est réalisée. Les temps de calcul sont mesurés avec l’horloge de la machine avec une précision de l’ordre de la microseconde. L’ordinateur a un processeur Intel core quad cadencé à 2,4 GHz, et dispose de 4 Gio de mémoire RAM. L’implémentation n’utilise cependant qu’un seul cœur du processeur. La localisation a été exécutée sur une séquence de 1 140 images en utilisant 15 683 patchs et le temps de chaque itération a été mesuré. Les résultats sont présentés dans le tableau 3.1.
La partie la plus gourmande en calcul est la projection des patchs. Une analyse plus fine de l’exécution montre que c’est plus précisément le processus d’interpolation bilinéaire qui consomme la plupart du temps. Une autre partie qui nécessite presque un tiers du temps est le calcul des descripteurs de PI. Cette partie consiste en fait à extraire une vignette de l’image courante, et à lui soustraire la moyenne et la diviser par l’écart-type. Cette partie nécessite beaucoup de temps parce que prenant des valeurs extraites d’une image, il est difficile d’avoir une mémoire cache assez performante. En effet les changements de ligne avant d’avoir atteint l’extrémité de l’image causent généralement des défauts de cache c’est-à-dire des accès à des
Moyenne (ms) Médiane (ms) Écart-type (ms) Maximum (ms) Temps écoulé (%) Correction d’image 14,95 14,94 0,14 16,97 0,41 Détection des points 30,57 30,39 1,00 33,12 0,83
Sélection des patchs
visibles 1,96 1,90 0,26 2,57 0,05
Calcul des ROI 21,94 20,82 6,12 36,76 0,59
Projection des patchs 2403,16 2252,29 706,75 4057,52 65,11
Calcul des
descripteurs de PI 1099,75 1197,21 168,54 1614,22 29,80
Appariement 116,49 3,16
Total 3690,83 3497,17 834,26 5581,49 100
TABLE 3.1 – Profiling du code sur CPU. Les couleurs et noms des fonctions correspondent à celle de la figure 2.10. Le calcul du score et des descripteur de PI ayant été réalisé simultané- ment, il n’a pas été possible d’en déterminer leur valeur à chaque itération. Toutefois la valeur moyenne par image a pu être évaluée séparément. Les parties de l’algorithme mettant moins de 1 ms par itération ont été ignorées
données non présentes dans le cache. De plus il s’agit d’une opération qui est exécutée de ma- nière identique sur tous les pixels du voisinage d’un point. L’implémentation initiale nécessite un parcours de chaque image mais pourrait être parallélisée. Pour finir, ces deux étapes sont ap- pliquées sur l’ensemble des points détectés ou des patchs visibles. Là encore on applique donc de nombreuses fois la même opération sur des données légèrement différentes. Il semble donc intéressant d’appliquer une méthode de parallélisation à cet algorithme.
Pour toutes ces raisons l’implémentation sur GPU (Graphic Processing Unit) parait intéres- sante. En premier lieu, le fait de projeter des patchs correspond aux calculs pour lesquels ont été conçues les cartes graphiques. En effet, les cartes graphiques servent initialement à réaliser de la synthèse d’image 3D, c’est-à-dire projeter des primitives graphiques dans différentes vues. Elles disposent donc de tous les outils nécessaires pour réaliser des interpolations bilinéaires et des calculs de projection le plus efficacement possible. De plus, leur architecture permet une exécution massivement parallèle, c’est-à-dire qu’une même opération peut être exécutée simultanément sur de très nombreuses données. Cela est également intéressant pour traiter des algorithmes sur chaque pixel et sur chaque patch de manière simultanée.