Forum ENSG PPMD Projet CityVIP SIG embarqué et réalité virtuelle pour connaître les conditions de propagation et améliorer la précision GNSS D. Bétaille (IFSTTAR) 26 mars 2013 PREDIT, Transports Sécurisés, Fiables et Adaptés

Plan de la présentation Problématique de la Géolocalisation en ville Les objectifs du projet CityVIP Architecture logicielle du système de Géolocalisation CityVIP Le module de localisation par mise en correspondance d’images vidéo Le module de détection des signaux GPS NLOS Le module de localisation globale par fusion multi-capteurs L’intégration dans le véhicule VERT Présentation de la démonstration

Problématique de la Géolocalisation en ville Les VIP sont par définition des véhicules urbains Le milieu urbain cumule : l’intérêt d’un positionnement précis et intègre les difficultés… pour le positionnement GPS : les masquages de satellites les trajets multiples pour le positionnement par traitement d’images vidéo : les problèmes d’ombres et d’éblouissements les problèmes de réflexions Mais… le milieu urbain est fortement structuré et la connaissance de la carte peut être d’un précieux secours

Les objectifs du projet CityVIP et la réponse apportée par les partenaires Le projet CityVIP avait pour ambition de développer un système de localisation adapté aux VIP, c’est-à-dire : précis (erreur < 1 m à 95%) intègre (estimation sûre d’un majorant de l’erreur) bas coût, donc utilisant des capteurs bas de gamme Pour ce faire, le système de localisation CityVIP exploite : un récepteur GPS bas de gamme (u-blox) les 2 codeurs CAN des roues arrière du véhicule une caméra vidéo N&B standard (Marlin) une carte numérique 3D précise en tirant le meilleur parti de toutes les sources d’information

Concept général du système de Géolocalisation CityVIP Coopération de modules logiciels actualisant la pose : par intégration de mesures proprioceptives (odométrie ++) par mise en correspondance avec la carte numérique (map matching) par utilisation de données satellitaires en couplage lâche ou serré : test préalable de validité force du signal visibilité directe par fusion avec la localisation par vision Le module présenté actualise une pose défini par un domaine de validité dont la taille quantifie la précision. Cette mise à jour s’opère au gré de l’arrivée d’informations diverses par intégration de mesures proprioceptives (gyromètre, vitesse angulaire des roues) : c’est rapide mais la précision se dégrade par mise en correspondance avec la carte de l’espace roulable (map matching) : ca maintien la précision à l’échelle de la navigation sur une carte par utilisation de données satellitaires en couplage serré (c’est-à-dire par utilisation directe des données reçues de chaque satellite). C’est utile de pouvoir utiliser les données satellitaires individuellement car les données valides sont rares (peu de satellites en vision directe) par fusion avec la localisation par vision. Ce module donne des résultats très précis lorsqu’il fonctionne. Dans les cas où il ne fonctionne pas, la mise à jour d’une localisation même moins précise permet d’initialiser plus rapidement ce module de localisation mrécis

Architecture logicielle du système de Géolocalisation CityVIP Ordonnancement asynchrone des modules (environnement Aroccam) Les modules sont activés au gré de l’arrivée des données de façon asynchrone. Pour ce faire, l’application a été développée dans l’environnement ARROCAM. Cette image est à modifier mais je ne peux pas le faire ce soir (12 septembre 2011)

Localisation par vision (1) : construction de la base d'amers visuels Séquence vidéo de référence Base d'amers visuels géoréférencés (Points 3D + descripteurs associés) Trajectoire de référence

Localisation par vision (2) : algorithme temps réel Points d'intérêt sur l'image courante Pose du véhicule et incertitude associée Appariement 3D/2D Base d'amers visuels géoréférencés

Le module de détection des signaux GPS NLOS (1) Les satellites NLOS (non-line-of-sight) sont le "pire ennemi" du positionnement GNSS en ville ! La prise en compte d’une (ou de plusieurs) mesure(s) issue(s) d’un (de) satellite(s) NLOS peut décaler la position calculée de plusieurs mètres CityVIP a développé une méthode exploitant le SDK BeNomad pour détecter et éliminer les mesures contaminées

Le SDK BeNomad et son moteur de rendu 3D (1) Le Software Development Kit (SDK) de BeNomad est composé d’un ensemble d’interfaces de programmation pour relier les fonctions de navigation, de décodage d’adresses et de rendu. Pour CityVIP, il y a aussi des fonctionnalités spécifiques (moteur de rendu 3D, caméra virtuelle, calcul de distances dans le monde virtuel utilisé dans l’algorithme NLOS d’IFSTTAR, …). BeNomad fournit aussi la base de données géoréférencées directement exploitable par son SDK (données sources fournies par l’IGN).

Le SDK BeNomad et son moteur de rendu 3D (2)

Le module de détection des signaux GPS NLOS (2) Tri des satellites NLOS par vision artificielle Image virtuelle BeNomad selon l’azimuth de chaque satellite Preuve de concept publiée (ITST 2011) à partir d’une position vraie Validée aussi en boucle fermée, i.e. à partir d’une position prédite et map-matchée (IV 2012)

Le module de détection des signaux GPS NLOS (3) A partir d’une position vraie (issue de la tra- jectoire de réf.) Boucle ouverte Meilleure pré- cision pour 2 modèles u-blox haute sensibilité En boucle fermée, map matching nécessaire…

Le module de localisation globale par fusion multi-capteurs et carte Monde 3D Localisation 3D (x,y,z,ψ,θ,Φ) Configuration : dans (repère local ENU) Modèle d’évolution : La localisation su véhicule s’effectue dans le monde tel qu’il est : à 3 dimensions. On doit alors comprendre la localisation comme l’estimation de la configuration du véhicule dans ce monde : 3 coordonnées de translation et 3 rotations. Le repère choisi pour se repérer est le repère local tangent (East, North, Up) où les positions sont les plus intelligibles. Les angles de pente et de dévers étant petits, on a mis en évidence un modèle simplifié d’évolution

Le module de localisation globale par fusion multi-capteurs et carte Fusion de données : domaine ellipsoïdaux Mise en correspondance avec la carte (map matching) Segments de route : Contraintes linéaires La localisation précise et intègre s’articule autour de la mise à jour de domaines contenant la vraie configuration de façon garantie. On peut utiliser des sous pavages (unions de boites) ou des ellipsoïdes. La mise à jour des ellipsoïdes par intégration d’information proprioceptive est classique. Proposons de nous attarder sur l’exploitation de l’espace roulable. Considérons une ellipsoïde courante. Si on connaît le segment de route sur lequel on se trouve (2 paires de segments de droites qui correspondent à 2 paires d’hyperplan dans l’espace de dimension 6). On va calculer une nouvelle ellipsoïde qui contient l’intersection de ces 2 domaines où se trouve la vraie configuration. Voici pour illuster un résultat obtenu autour de la mairie du 12ème arrondissement. Ellipsoïde courant Résultat sur Paris Ellipsoïde mis à jour

Le module de détection des signaux GPS NLOS en boucle fermée (1) A partir d’une position map matchée Résultat final sur une position libre (en 2D) pour u-blox Progrès par rap- port au simple tri selon le SNR

Le module de détection des signaux GPS NLOS en boucle fermée (2) A partir d’une position map matchée Résultat final sur une position contrainte par la carte (en 2D) Progrès aussi par rapport au tri selon le SNR

Le module de localisation globale par fusion multi-capteurs Fusion lot 1 (map aided) / lot 2 (vision) Localisation Lot 2 Localisation après fusion Localisation Lot 1 Segment sélectionné dans le map matching Ce même principe est utilisé pour fusionner les résultats d’un module de localisation par vision et les notres. Chacun des modules fournissant un domaine admissible ellipsoïdal, la fusion est un domaine qui contient l’intersection des 2 précédents. Si cette intersection est vide, on est amené à dilater l’un ou l’autre de ces domaines en faisant par ce biais diminuer la confiance qu’on a dans le résultat. Je vais demander des images à Sébastien pour rendre ce transparent un peu moins vide.

L’intégration dans le véhicule de démonstration VERT Mesure de référence des trajectoires Récepteur GPS bas-coût Baie d’acquisition (RT-Maps, Aroccam…) Codeurs de roues

Architecture logicielle modulaire, basée sur du middleware aroccam

Présentation des démonstrations

Présentation des démonstrations

Merci pour votre attention…