Introduction à la géo-réalité augmentée + se positionner depuis le navigateur
Nous avons entamé une série de billets de blog sur les défis de la construction d’un Navigateur du Monde Réel, au niveau technique bien sûr, mais aussi en termes d’interface homme-machine, de données, etc.
Nous y parlons de capteurs mobiles, de cartes, de l’apprentissage machine et de bases de données, de développement web et mobiles, d’orientation et de systèmes de positionnement, de bâtiments et de villes et de bien plus encore :)
Pour commencer nous allons parler des enjeux techniques de la mesure de l’orientation du téléphone depuis le navigateur, en commençant par quelques rappels sur la réalité augmenté géolocalisée (Geo AR).
Chez Wemap, notre vision est de vouloir proposer à nos clients une expérience légère (pas de téléchargement), qui fonctionne dans le monde entier et sur un maximum de téléphones. Ce sont pour ces différentes raisons que nous avons fait porter une partie de nos efforts de recherche vers de la Géo AR web.
Le principe de la GéoAR
Pour réaliser de la Géo AR, l’approche la plus répandue consiste à associer des données provenant: (1) du GNSS (GPS, GLONASS, Galileo…) et (2) de la centrale inertielle (accéléromètre, gyroscope, magnétomètre). Le GNSS permet de connaître la position du téléphone alors que la centrale inertielle permet d’estimer l’orientation du téléphone (nord, est, haut, bas…).
Dans ce blog post nous allons nous focaliser sur cette deuxième partie: l’estimation de l’orientation du smartphone.
Qu’est-ce que l’orientation d’un smartphone et comment on l’estime ?
L’orientation du smartphone
L’orientation du smartphone est défini comme la rotation entre le repère du téléphone (en bleu) et le repère local terrestre (en rouge).
Le repère du téléphone (en bleu) et le repère local terrestre (en rouge).
Cette rotation peut être exprimée de différentes façons: matrice de rotation, quaternion, angle d’Euler ou encore axis-angle. Pour en savoir plus, je vous invite à lire les documents présents sur le site euclideanspace.com.
L’estimation
Il existe plusieurs façon d’estimer l’orientation d’un objet (traitement d’image, centrale inertielle…). Dans le cas d’un smartphone, l’estimation d’orientation que nous allons voir ici est basée sur la centrale inertielle. Pour cela nous avons besoin d’utiliser au moins deux capteurs: l’accéléromètre et le magnétomètre. Les axes sont les mêmes que ceux en bleu sur le schéma précédent.
- L’accéléromètre: Il mesure les accélérations sur les 3 axes du téléphone : la gravité et les translations. L’unité est le G ou le m.s^-2
- Le magnétomètre: Il mesure le champ magnétique autour de lui : le champ magnétique terrestre et toutes les sources émettant un champ magnétique (ex : la structure d’un bâtiment, une ceinture…). L’unité est le Tesla ou le Gauss.
Un troisième capteur vient lisser les données provenant de ces deux précédents capteurs :
- Le gyroscope: Il mesure la vitesse de rotation autour des 3 axes du téléphone. L’unité est le radian.s^-1.
Ces trois capteurs sont fusionnés en utilisant un filtre d’estimation d’orientation. Le filtre peut être de différentes natures: un filtre de Kalman, un observeur, une descente de gradient… Leur point commun est qu’ils implémentent tous une solution au problème de Wahba (1965).
Un autre point commun à tous ces algorithmes est que pour estimer l’orientation du smartphone ils font tous l’hypothèse que :
- Le smartphone doit être statique (pas de translation).
- Il n’y a pas de perturbations magnétiques. C’est à dire qu’il faut que le magnétomètre ne mesure que le champ magnétique terrestre et pas d’autres champs magnétiques émis par des objets ferromagnétiques (ex: les murs/sols d’un bâtiment).
La première hypothèse (même si elle n’est pas exactement respectée) ne pose pas vraiment de problème dans le cas de la Réalité Augmentée. Cependant, ce n’est pas le cas pour la seconde, elle est la source de la plupart des erreurs d’estimation en AR. En Europe, le champ magnétique terrestre est de l’ordre de 45 microTesla. Un magnétomètre de smartphone non calibré peut mesurer un champs magnétique d’environ 300 microTesla, juste à cause de la batterie et du speaker qui se trouvent à seulement quelques centimètres de lui. Les variations dues aux structures immobilières peuvent faire varier les mesures jusqu’à +/- 100 microTesla. La conséquence est que des perturbations magnétiques de quelques dizaines de microTeslas peut changer l’orientation du smartphone de quelques (dizaines) de degrés.
Aucun filtre n’est vraiment capable de faire abstraction de ces deux hypothèses, cependant certains algorithmes permettent de réduire l’impact des perturbations magnétiques (https://hal.inria.fr/hal-01650142/document).
L’estimation d’orientation dans les web browsers
Heureusement, à chaque fois qu’un développeur veut utiliser les données d’orientation d’un smartphone il n’est pas obligé de réimplémenter un filtre de Kalman. Les smartphones sous Android, iOS et Microsoft nous permettent d’accéder très facilement à l’estimation d’orientation dans nos applications natives. Du côté du web, l’accès à ces données est plus fastidieux, les navigateurs ne donnent pas accès à toutes les informations nécessaires. D’un navigateur à l’autre, ou même d’un téléphone à un autre, les données auxquelles nous avons accès sont sensiblement différentes. De plus, il nous est impossible de savoir si les filtres utilisés par les constructeurs prennent en compte la réduction de l’impact des perturbations magnétiques. Voici ci-dessous certaines des contraintes liées au web:
Les contraintes d’accès
- Les API web actuelles ne donnent accès ni au quaternion, ni à la matrice de rotation, seulement aux angles d’Euler. Théoriquement ce n’est pas une contrainte, mais lié aux incohérences (section suivante), cela rend fastidieux l’utilisation des ces données.
- Il n’y a pas accès au magnétomètre sur la quasi-totalité des navigateurs. Il est alors impossible d’utiliser directement les meilleurs filtres d’estimation d’orientation en web.
Les incohérences limitantes
- Sur iPhone quand l’inclinaison du téléphone dépasse les 62°, l’orientation renvoyée est une projection sur un autre repère (East-Up-South). Quand le téléphone repasse sous les 30° il réutilise le repère classique (East-North-Up). Quand la page web est ouverte avec une inclinaison entre 30° et 62° il est alors impossible de savoir quelle projection est utilisée.
- Sur certains téléphones avec Chrome Android, l’orientation relative (provenant de deviceorientation) est aléatoirement initialisée à 0° ou -90°.
Les incohérences d’hétérogénéité
Ces incohérences ne sont pas limitantes, elles doivent juste être prises en compte lors de l’implémentation des algorithmes.
- Safari iOS et Chrome Android n’utilisent pas les même rotations pour exprimer les angles d’Euler (ZXY vs -ZXY).
- Pour obtenir une orientation absolue, Safari iOS utilise l’événement deviceorientation alors que Chrome Android utilise l’événement deviceorientationabsolute.
- Sur Safari iOS le vecteur d’accélération est l’opposé de celui de Chrome Android.
Approche utilisée
Pour éviter les effets de bord décrits ci-dessus, nous avons décidé de mettre en place notre propre algorithme. Cela nous permet d’avoir totalement la main sur l’expérience AR que nous proposons. Notre algorithme est notamment basé sur un filtre de Kalman étendu (EKF) qui a été spécialement conçu pour la RA Géo. Il réutilise directement les données issues de l’accéléromètre, du gyroscope et du magnétomètre. Il s’agit d’un algorithme opportuniste, c’est à dire qu’il s’adapte aux capteurs auxquels il a accès. Par exemple, si le magnétomètre est accessible nous allons l’utiliser. S’il n’est pas accessible (comme il est majoritairement le cas), nous utilisons un EKF sans magnétomètre qu’on fusionne aux données issues de “deviceorientationabsolute”.
La plupart de nos algorithmes ont été testés et comparés à des dizaines d’autres dans un environnement contrôlé (http://tyrex.inria.fr/mobile/benchmarks-attitude/).
Conclusion
Le web est un environnement fastidieux pour travailler avec les capteurs de la centrale inertielle, cependant il est quand même possible de proposer à l’utilisateur une expérience AR légère. Les filtres décrits ci-dessus ne sont pas très gourmands en ressources comparé à une approche basé sur le traitement d’image, cela donne un avantage conséquent pour leur implémentation en Web. Contactez nous si vous souhaitez avoir de plus amples informations.
Pour Wemap AR, nous avons mis en place des solutions hybrides afin de fusionner les données provenant de la centrale inertielle, du GNSS mais aussi de la cartographie. Ce travail fera l’objet d’un futur blogpost.
Avec 4 millions de vues mensuelles, Wemap est la plateforme digitale made in France pour la création de cartes grand public. Ses travaux de recherche sur la réalité augmentée permettent à Wemap d’offrir une expérience d’exploration du monde incomparable et de créer un véritable navigateur du monde réel.
