6 erreurs liées au GNSS qui compromettent la conception des systèmes de localisation (et comment les détecter à temps)

En bref : la plupart des programmes de localisation ne posent pas de problème en raison d’une difficulté technique insurmontable. Ils prennent du retard à cause d’une décision de conception prise en amont, qui semblait correcte sur la fiche technique mais qui s’est avérée catastrophique sur le terrain. Voici les six erreurs que nous observons le plus souvent : déterminer la précision après coup, copier-coller les spécifications du récepteur, choisir une classe de matériel inadaptée, sous-estimer l’antenne, sélectionner une IMU incapable de combler l’écart, et partir du principe que le réseau est toujours disponible, sans oublier le test sur parking qui masque toutes ces erreurs.

Dans notre dernier article, nous avons passé en revue le modèle en V pour la conception de systèmes de localisation en robotique. La partie gauche du modèle en V correspond à la phase de définition et de conception, tandis que la partie droite correspond à la phase de validation et de mise à l'échelle ; le coût lié à la correction d'une décision est multiplié par environ 10 à chaque étape vers la droite.

Cet article traite des décisions qui tournent mal du côté gauche. La majeure partie de ce que nous avons appris dans le domaine de l'ingénierie de terrain concerne les phases de conception et de validation de la conception, car c'est là que se produisent les erreurs les plus coûteuses. Il s'agit de choix courants, qui semblent raisonnables, mais qui ne résistent pas à la réalité du terrain.

Erreur n° 1 : se préoccuper de la précision après coup

La plupart des équipes vous diront qu'elles savent déjà quel niveau de précision leur est nécessaire. Le problème, c'est que cette exigence n'est généralement pas assez précise.

Un système est mis au point avec une précision d’« environ un mètre », mais l’application s’avère nécessiter des limites bien plus strictes. Prenons l’exemple de la cartographie par drone. Sans corrections RTK, que ce soit en temps réel ou en post-traitement, on se retrouve avec une marge d’incertitude d’un mètre. Cela semble gérable si l’on imagine un décalage constant d’un mètre sur l’ensemble de la carte. Mais ce n’est pas ainsi que l’erreur se comporte. Il ne s’agit pas d’un décalage uniforme que l’on peut simplement soustraire ; elle varie d’un endroit à l’autre de la carte, et c’est précisément ce qui compromet la qualité d’un travail de niveau topographique.

Le piège le plus insidieux est de se dire : « Je n’ai pas besoin d’un tel niveau de précision. » C’est parfois vrai. Mais dès lors que vous avez besoin que le système fonctionne partout, la barre se place plus haut. C’est justement une plus grande précision qui vous offre les contraintes nécessaires pour développer des applications précises et pour garantir leur précision à mesure que vous évoluez vers des environnements plus exigeants.

Définissez les exigences de précision en fonction de ce que l'application doit faire, dans les conditions dans lesquelles elle doit le faire, avant tout autre choix.

Erreur n° 2 : copier-coller les caractéristiques techniques du récepteur

C'est une erreur très courante, et on comprend facilement pourquoi. Vous achetez un récepteur compatible RTK, la fiche technique indique « 1 cm + 1 ppm » (un centimètre plus une partie par million multipliée par la distance de référence), et vous inscrivez cette précision dans votre cahier des charges.

Ce chiffre est réaliste… dans un monde idéal. Un centimètre lorsque vous êtes assis juste au-dessus de votre station de base, à ciel ouvert, sans aucune interférence. Mais ce n’est pas ainsi que fonctionnent la plupart des applications.

Dans les environnements réels, il existe des obstacles, et il est littéralement impossible de concevoir un système ne présentant aucune interférence avec le signal GNSS, car ces interférences proviennent souvent de l'intérieur même de votre propre produit. La simple présence d'un autre ordinateur ou sous-système à proximité du récepteur peut suffire à en altérer les performances.

Une valeur indiquée dans une fiche technique, mesurée dans des conditions idéales, correspond à une valeur maximale, et non à une spécification que vous observerez en situation réelle. Considérez-la comme le meilleur scénario possible et concevez votre système en fonction des conditions réelles d'utilisation.

Erreur n° 3 : choisir une catégorie de matériel inadaptée

Tous les récepteurs GNSS ne sont pas conçus pour la même utilisation. Il existe différentes catégories de récepteurs, et leurs performances varient considérablement en fonction de leur destination d'utilisation.

Par exemple, les équipements de topographie utilisent des récepteurs et des antennes haut de gamme et coûteux, précisément pour garantir précision et fiabilité. En revanche, un appareil portable fait appel à des composants issus d’une catégorie totalement différente. Aucune de ces deux approches n’est erronée ; elles sont conçues pour répondre à des exigences différentes. L’erreur consiste à choisir la mauvaise catégorie pour votre application et à ne vous rendre compte qu’ensuite que la précision n’est pas au rendez-vous.

Cela va également au-delà de la simple liste des composants. Certains récepteurs intègrent un logiciel de calcul de position sophistiqué et une intégration poussée de l’IMU qui leur permet de bien gérer les environnements difficiles ; d’autres non. Un environnement à fortes interférences par trajets multiples les distinguera rapidement, et les « trajets multiples » ne constituent pas un phénomène unique : il en existe différents types. La diffusion des signaux sous les buissons est un problème totalement différent de celui des signaux qui rebondissent sur les vitres du centre-ville de San Francisco.

Définissez dès le départ la catégorie qui vous convient, en fonction de la précision et de la fiabilité requises par l'application, et non en fonction de ce qui vous est familier ou de ce qui est bon marché au départ.

Erreur n° 4 : sous-estimer l'importance de l'antenne

Vous seriez surpris de voir à quel point l'antenne est souvent le seul obstacle entre un système et une précision de localisation au centimètre près.

Nous constatons cela sans cesse lors de nos démonstrations en direct. Nous apportons à un client un banc d’essai simple, composé d’un récepteur et d’une antenne, et nous commençons à lui montrer une localisation au centimètre près. Puis, lorsque nous installons l’antenne sur le robot lui-même, le signal GPS disparaît, car il y a trop d’interférences RF à l’intérieur de la plateforme, provenant du Bluetooth, du réseau cellulaire et de tous les autres composants qui s’y trouvent. Il suffit d’éloigner l’antenne du robot pour que la localisation au centimètre près réapparaisse immédiatement.

Les choix importants concernant l'antenne : son type et sa taille, les bandes qu'elle prend en charge (elle doit couvrir toutes les bandes utilisées par votre récepteur) et son emplacement physique par rapport au reste de votre équipement électronique. La bonne nouvelle, c'est que vous pouvez tester tous ces éléments avant même de concevoir un circuit imprimé (PCB).

Le matériel modulaire installé sur le banc d'essai permettra de mettre en évidence, à moindre coût et de manière itérative, les problèmes liés aux antennes et aux interférences RF, ce qui correspond exactement au type de validation précoce et peu coûteuse à laquelle sont destinées les phases de conception situées « à gauche » du modèle en V de la localisation.

Erreur n° 5 : choisir une unité de mesure de l'inertie (IMU) qui ne permet pas de compenser l'écart

La fourchette de prix des IMU (unités de mesure inertielle) est très large, allant de quelques dollars à des dizaines, voire des centaines de milliers de dollars (voire plus !). La caractéristique qui importe généralement n’est pas la précision annoncée, mais la durée pendant laquelle l’IMU peut vous guider en cas de perte de signal GNSS.

Dans une solution couplée GNSS/IMU, les IMU d'entrée de gamme sont souvent conçues pour fonctionner en navigation à l'estime pendant dix à trente secondes. Cela peut suffire. Mais plus une IMU d'entrée de gamme doit fonctionner seule en dérive, plus la précision de votre solution diminue. Si vous devez naviguer à l'estime pendant une longue période sous un parking, vous aurez besoin d'une IMU haut de gamme ou d'autres capteurs (vitesses des roues, caméras) alimentant la fusion de capteurs pour compenser cette perte de précision.

Il existe également plusieurs options en matière de configuration. Un module intégré doté d’une IMU intégrée constitue une solution inertielle généralisée, prête à l’emploi. Elle fonctionne, et en cas de perte du signal GPS, c’est mieux que rien. Cependant, une solution généralisée n’est pas adaptée à votre plateforme. Pour les plateformes nouvelles ou exigeantes, une approche sur mesure, associant une IMU adaptée et un moteur de positionnement modélisant votre dynamique, offrira de meilleures performances.

Choisissez ce dont vous avez besoin en fonction du scénario de panne le plus grave, et non en fonction de ce qui était le plus facile à intégrer.

Erreur n° 6 : partir du principe que le réseau est toujours disponible

On oublie facilement que le monde n'est pas un environnement de test. Ici, aux États-Unis, il existe encore des zones sans couverture mobile significatives ; la situation est meilleure en Europe, mais les lacunes sont bien réelles et sont rarement prises en compte lors de la conception des réseaux.

Les chiffres ne mentent pas. Si votre exigence est une précision d’un centimètre dans 99,9 % des cas, même une interruption de réseau mobile de 0,1 % pendant que vous roulez suffira à faire échouer le test, instantanément. La solution ne consiste généralement pas à éliminer toutes les zones sans couverture. Il s’agit plutôt d’en comprendre l’impact et d’en tenir compte dans la programmation.

Si vous perdez les corrections pendant dix secondes, un moteur RTK bien conçu ne s’écarte pas de la carte ; il perd un peu de précision, puis se rétablit. Ce comportement fluide est un choix de conception que vous faites dès le début, et non une surprise que vous découvrez en production.

Le test du parking

Les essais en plein ciel constituent un excellent point de départ. Ils sont prévisibles et permettent de confirmer que le système fonctionne dans les grandes lignes. Le piège, c’est d’en faire votre référence de validation, car les conditions en plein ciel sont proches du scénario idéal que votre système rencontrera jamais. Vous vous fiez à peine aux autres capteurs, car les données GPS sont si abondantes, les performances semblent excellentes et vous avez l’impression que le travail est terminé.

Ensuite, le produit est acheminé dans les rues de banlieue, les quais de chargement, les lisières d'arbres et les canyons urbains, et les chiffres s'effondrent. Les chiffres relatifs aux parkings ne constituent pas votre référence de conception.

Ce que nous préconisons dès le début, c’est un plan de test qui reflète fidèlement le comportement réel du système en conditions réelles, et qui soit exécuté dans vos environnements les plus exigeants avant la validation finale (DVT), et non après. Validez les points où vous devez réussir, et non ceux où vous savez déjà que vous réussirez.

On retrouve le même schéma dans les six principales erreurs…

Il ne s'agit pas de problèmes isolés pouvant être résolus de manière isolée. Comme nous l'avons souligné plus haut dans notre discussion sur la conception du système de localisation: un système doté de tous les composants adéquats, mais mal configuré ou testé dans un environnement inadapté, ne fonctionnera tout de même pas. Il s'agit d'une interaction entre les différents éléments du système. Le récepteur, l'antenne, l'IMU, les corrections et l'environnement déterminent tous ensemble le résultat.

C’est là tout l’intérêt de développer une approche axée sur le prototypage rapide et l’itération « du côté gauche du modèle en V ». Si l’on met en évidence ces interactions dès le début, à l’aide d’un matériel représentatif et dans des conditions représentatives, cela ne coûte qu’une brève discussion. Si elles apparaissent au stade de la validation de la conception (DVT) ou en production, elles entraînent une refonte de la conception.

Dans le prochain article, nous aborderons le processus de découverte que nous menons avec nos clients dans le cadre de Catalyst : comment nous passons d’une page blanche à deux ou trois architectures de référence prêtes à être validées en parallèle, afin que ces erreurs soient détectées avant tout engagement en matière de matériel.

Si vous en êtes aux premières étapes d'un projet de conception de système de localisation et que vous souhaitez bénéficier d'un deuxième avis avant de finaliser l'architecture, cela pourrait être l'occasion d'un échange très fructueux entre nous.

Prenez rendez-vous pour un atelier de découverte avec un ingénieur de Point One

Foire aux questions

Quelles sont les erreurs de conception les plus courantes en matière de localisation GNSS ?

Les six erreurs les plus courantes : définir la précision de manière trop vague, reproduire les caractéristiques techniques du récepteur telles qu’elles figurent dans la fiche technique dans les spécifications, choisir une classe de récepteur inadaptée à l’application, sous-estimer l’antenne et son environnement RF, opter pour une IMU incapable d’assurer une navigation à l’estime suffisamment longtemps en cas de coupure de signal, et partir du principe que la couverture mobile est omniprésente. Une validation effectuée uniquement à ciel ouvert masque toutes ces erreurs.

Pourquoi les spécifications de précision RTK indiquées dans les fiches techniques ne correspondent-elles pas aux performances réelles ?

Les chiffres indiqués dans les fiches techniques, tels que « 1 cm + 1 ppm », sont mesurés dans des conditions idéales : ciel dégagé, courte distance par rapport à la station de base et absence d'interférences. Or, les plateformes réelles présentent des obstacles et subissent des interférences RF internes provenant de leurs propres composants électroniques ; les performances sur le terrain sont donc presque toujours inférieures aux valeurs maximales indiquées dans les fiches techniques.

Pendant combien de temps un système GNSS/IMU peut-il naviguer par estimation de position sans signal ?

Cela dépend de l'IMU. Les IMU d'entrée de gamme utilisées dans une solution couplée sont généralement conçues pour fonctionner en navigation à l'estime pendant dix à trente secondes avant que la dérive ne dégrade la précision de la solution. Les applications qui doivent fonctionner plus longtemps sans GNSS (par exemple, sous un parking) nécessitent une IMU de meilleure qualité ou des capteurs supplémentaires, tels que des capteurs de vitesse de roue ou des données provenant d'une caméra.

Pourquoi l'emplacement de l'antenne a-t-il une telle incidence sur la précision du GNSS ?

L'antenne constitue le point d'entrée du signal, et les plateformes modernes génèrent en interne d'importantes interférences RF provenant des réseaux cellulaires, du Bluetooth et des composants informatiques. Une antenne placée à l'intérieur de cette zone d'interférences peut perdre complètement le signal, même lorsque le récepteur est capable d'une précision de l'ordre du centimètre. La couverture en bandes de l'antenne doit également correspondre aux bandes du récepteur. Ces deux aspects peuvent être testés à l'aide de matériel modulaire avant la conception du circuit imprimé.

Que se passe-t-il avec le RTK lorsque la connexion mobile est interrompue ?

Un moteur RTK bien conçu ne perd pas immédiatement sa position lorsque les corrections cessent. En cas d’interruption de courte durée, il perd un peu de précision, mais se rétablit dès le rétablissement de la connexion. L’essentiel est de prévoir ce comportement dès la conception, car même de brèves interruptions peuvent empêcher de respecter des exigences strictes en matière de disponibilité (telles qu’une précision d’un centimètre dans 99,9 % des cas).

Table des matières

Essayez gratuitement notre réseau RTK

Une précision de niveau mondial à un prix abordable, sans les tracas

Gabe Amancio
Gabe dirige l'équipe d'ingénierie d'application chez Point One Navigation, où il collabore avec les clients pour intégrer le positionnement de précision dans la robotique, les véhicules autonomes et les plateformes logistiques.