Où votre moteur de positionnement doit-il fonctionner ? Prendre une décision avant que cela ne coûte trop cher

Il s'agit du quatrième article d'une série consacrée à la conception de systèmes de localisation pour l'autonomie et la robotique. Les articles précédents ont abordé le modèle en V et les étapes d'un programme de conception, les six erreurs qui font le plus souvent échouer les programmes, ainsi que les trois exigences à définir avant d'évaluer le matériel. Chacun d'entre eux est issu d'une conversation réelle entre Tom Weeks et moi-même. Cet article reprend là où la phase de découverte s'achève.

La phase de découverte vous fournit un ensemble d'exigences propres à votre produit, plutôt qu'un simple chiffre issu d'une fiche technique. Elle vous propose également deux ou trois architectures candidates susceptibles de répondre à ces exigences.

C'est là que la partie gauche du modèle en V cesse d'être purement théorique. Il faut faire un choix. Et pour ce faire, il ne suffit pas de multiplier les analyses : il faut tester les options dans l'environnement où le produit sera réellement utilisé.

C'est la partie de mon travail que j'apprécie le plus.

La décision centrale : où s'exécute le moteur de positionnement

La plupart des récepteurs RTK disponibles sur le marché sont modulaires. Le moteur de positionnement fonctionne sur la puissance de calcul propre au module, qui est limitée. Pour de nombreuses applications, c'est la solution idéale, et il convient de le dire clairement : nous n'incitons pas les équipes à opter pour des architectures basées sur l'hôte. L'objectif est de s'assurer que la solution intégrée au module est réellement adaptée à ce que vous développez.

Le système atteint ses limites lorsque l'application nécessite plus qu'une solution RTK standard associée à un IMU. Une dynamique de plateforme non standard. Des environnements urbains dégradés où les réflexions multiples sont constantes. La fusion avec des caméras, un lidar ou l'odométrie sur roues. Dans ces cas-là, la capacité de calcul du module devient un obstacle insurmontable, et la solution réside dans une architecture basée sur l'hôte, où le moteur de positionnement s'exécute sur le processeur principal de la plateforme.

On observe actuellement une évolution : les équipes se demandent désormais plus tôt si elles peuvent exploiter la puissance de calcul déjà disponible sur la plateforme. Un robot équipé d'stack lidar dispose déjà d'une puissance de calcul nettement supérieure à celle d'un module GNSS. Souvent, la réponse est oui.

Une équipe qui constate ce problème lors des tests de validation de la conception (DVT) doit procéder à une refonte de la conception. Une équipe qui le constate lors de la sélection de l'architecture en discute.

Quatre questions qui permettent de cerner le reste de l'architecture

L'emplacement du moteur de positionnement est certes le facteur déterminant, mais quatre questions relatives au flux de données conditionnent tout ce qui en découle. Chaque réponse élimine certaines architectures.

1. GNSS seul ou fusion inertielle ? Il existe des cas d’utilisation où un moteur RTK seul est le meilleur choix : si vous souhaitez vous fier uniquement à la position lorsque vous disposez d’une solution par phase porteuse et que vous gérez la continuité à l’aide d’autres capteurs dans votre propre stack, c’est la réponse la plus claire. Si le système doit maintenir sa position pendant les interruptions GNSS, vous avez besoin d’une fusion inertielle, ce qui modifie la question de calcul évoquée plus haut. Cela soulève également le choix entre un couplage lâche et un couplage serré.

2. Quelle est la source de correction ? L'application peut-elle tolérer une précision légèrement moindre en échange d'une couverture plus homogène ? Les solutions SSR et VRS présentent des compromis différents de ceux du RTK à ligne de base unique, et la réponse appropriée dépend de l'endroit où le produit est utilisé et de sa distance par rapport à la station de référence la plus proche. La densité du réseau est la variable qui détermine l'ampleur de ce compromis que vous devrez effectivement accepter.

3. La position seule, ou un système PVT complet avec données d’attitude ? Un scanner de réseaux souterrains cherchant à déterminer sa position absolue a besoin de connaître sa position. C’est tout. Un véhicule qui doit connaître son lacet, son tangage et son roulis sur le virage d’un circuit automobile — ou son cap lorsqu’il s’apprête à se garer afin qu’un système en aval sache dans quelle direction il est orienté — répond à une exigence totalement différente et nécessite un flux de données distinct en arrière-plan. C’est un aspect qui passe souvent inaperçu, car le cap et l’assiette ne figurent pas dans les spécifications techniques d’un système GNSS.

   L’attitude doit également provenir d’une source physique. Deux antennes sur une ligne de base fixe fournissent directement le cap GNSS, ce qui explique l’existence des systèmes à double antenne — l’Atlas Duo est le nôtre. Une seule antenne couplée à une IMU peut également fournir le cap, mais uniquement lorsque la plate-forme se déplace suffisamment pour que celui-ci devienne observable, ce qui constitue précisément la contrainte qui pèse sur un véhicule nécessitant une orientation à l’arrêt. Le tangage et le roulis proviennent de la solution inertielle. Il est important de trancher rapidement sur ce point, car cela concerne le nombre d’antennes et leur montage, et non un paramètre logiciel que l’on peut modifier ultérieurement.

4. Quelles sont les exigences en matière de connectivité ? En fin de compte, les systèmes de gestion pénitentiaire nécessitent une connectivité. Comprendre où le produit fonctionne et quelles sont les conditions d'accès au réseau sur place fait partie intégrante de l'architecture, et non pas un détail de mise en œuvre à régler ultérieurement.

   Dans la pratique, il existe quatre options, et la plupart des systèmes finissent par utiliser une solution principale et une solution de secours. La téléphonie mobile est la solution par défaut pour les plateformes au sol : les corrections sont transmises via NTRIP, au prix de lacunes de couverture. Le Wi-Fi fonctionne lorsque la plateforme opère à l’intérieur d’une zone de couverture connue, comme un entrepôt ou un chantier fixe. Une liaison radio locale vers une station de base que vous possédez élimine totalement la dépendance au réseau, ce qui explique pourquoi cette solution persiste dans l’agriculture et la topographie — mais elle ne s’étend pas au-delà des zones géographiques où vous avez installé des stations de base. Le satellite en bande L fournit des corrections là où il n’y a aucun réseau terrestre, avec une précision inférieure à celle du RTK terrestre.

   Le plan de secours détermine ce qui se passe dans cette fraction de pour cent qui épuise l'intégralité de votre budget de disponibilité. Cela mérite d'être décidé de manière réfléchie.

Élaborer une démonstration de faisabilité : représentative, mais pas identique

Une fois que nous disposons de deux ou trois architectures de référence, il s'agit de les reproduire le plus fidèlement possible et de les mettre en œuvre sur le terrain.

Concrètement, voici à quoi cela pourrait ressembler : pour un robot mobile d’extérieur de taille moyenne, les trois options envisageables pourraient être : (1) une solution RTK associée à une IMU, basée sur des modules, avec corrections via NTRIP sur réseau cellulaire et transmission de la position par port série — coût le plus bas, puissance de calcul la plus faible ; (2) le même matériel de réception, avec le moteur de positionnement fonctionnant sur le calculateur hôte du robot, en ajoutant l’odométrie des roues à la fusion pour les tronçons où le signal GNSS est dégradé ; et (3) un accélérateur matériel intégré fournissant une position PVT complète avec information d’attitude via Ethernet, présentant le moins d’inconnues d’intégration mais le coût unitaire le plus élevé. Sur le papier, ces trois solutions pourraient répondre aux exigences de précision. Elles diffèrent considérablement quant à leur comportement sous la canopée et quant à la composition de la nomenclature (BOM) pour une production de 5 000 unités.

La norme prévoit un matériel représentatif, et non un matériel identique. Idéalement, la démonstration de faisabilité utilise le même matériel que celui que le client prévoit de commercialiser, mais cela dépend de son calendrier et de la disponibilité des composants. Lorsque ce n'est pas possible, c'est l'architecture du chemin du signal qui importe.

Par exemple : une équipe a choisi un module dont les échantillons ne seront disponibles que dans trois mois. Plutôt que de perdre tout le trimestre, nous réalisons le développement avec un récepteur dont nous disposons déjà, configuré pour émettre le même ensemble de messages via la même interface série, au même débit que celui que leur hôte recevra en production. Leur travail d’intégration est un travail concret. Les données de performance sont des données réelles. La référence du composant sera modifiée ultérieurement.

Si un client a déjà opté pour un module qui transmet en série vers son hôte — c'est-à-dire que le module calcule la position en bord et transmet la solution au calculateur principal via une interface série, plutôt que de fournir des observations brutes que l'hôte doit traiter —, je construirai un dispositif qui transmet en série vers un hôte, même si le récepteur utilisé est différent. S’il utilise un récepteur haut de gamme, je peux concevoir un dispositif de structure similaire à l’aide d’un kit d’évaluation (EVK) différent, c’est-à-dire la carte de développement fournie par le fabricant et utilisée pour tester un récepteur avant de valider une conception. Ce que nous validons, c’est l’architecture, pas la nomenclature.

C'est précisément cette distinction qui rend possible le prototypage rapide. Si vous devez attendre des mois avant de recevoir vos premières cartes pour pouvoir effectuer des tests significatifs, vous aurez épuisé votre marge de manœuvre avant même d'avoir tiré la moindre conclusion. Et si les tests que vous effectuez pendant cette période portent sur un composant isolé plutôt que sur le système dans son ensemble, c'est là que les problèmes commencent.

Étude de cas : la technologie RTK sur des lunettes connectées

Les lunettes connectées équipées de caméras et d’unités inertielles sont désormais omniprésentes. Un client qui développait un système VIO (odométrie visuelle-inertielle, qui permet de suivre la position en combinant les images de la caméra avec les données de l’IMU) nous a contactés car il souhaitait y intégrer le GNSS.

Ils avaient déjà écarté le GPS. Ils l'avaient testé, ça n'avait pas marché, et ils étaient passés à autre chose.

Lorsque nous avons examiné ce qu’ils avaient réellement testé, le problème venait de l’emplacement de l’antenne. La qualité du signal obtenue avec un appareil porté sur la poitrine ou fixé sur le côté de la tête n’est tout simplement pas suffisante. L’obstruction par le corps et les variations d’orientation créent un environnement de signal fondamentalement différent de celui d’une antenne montée sur le toit d’une voiture. Ce n’était pas un problème lié au GPS. Il s’agissait d’un problème de conception dont on faisait porter la responsabilité au GPS.

Nous avons donc construit un prototype testable. Ils nous ont envoyé un kit d’évaluation de leur propre plateforme informatique — le même processeur que celui qui équiperait leur produit, monté sur une carte de développement que nous pouvions câbler. Nous avons branché le même récepteur que celui avec lequel ils travaillaient et avons construit un petit dispositif modulaire pouvant être porté par un être humain réel dans des environnements réels. Il existe des photos de moi portant ce dispositif : l’unité de calcul à la hanche, l’antenne en place, et une antenne portée sur la tête à côté, servant de système de référence.

Ce dispositif de référence porté sur la tête est volontairement rudimentaire et fonctionne depuis longtemps. Il est à la disposition de quiconque en aurait besoin.

Une fois cela mis en place, nous pourrions collecter des données réelles avec ces appareils et répondre à des questions concrètes. Dans quelle mesure chaque environnement dégrade-t-il la qualité du signal ? Comment le moteur de localisation parvient-il, malgré un signal dégradé, à fournir une solution exploitable ? Dans quelle mesure l'IMU est-elle capable de maintenir la position en cas de perte du signal GNSS?

Cela leur a ouvert une voie à laquelle ils n’avaient pas pensé : ils disposaient déjà d’une plateforme de calcul exécutant un système VIO. La solution inertielle généralisée du module n’est pas optimisée pour la dynamique humaine, mais rien n’empêche que la fusion GNSS puisse fonctionner sur la plateforme de calcul déjà en place.

Le produit est passé d’une situation où « le GPS ne fonctionnait pas pour nous » à une architecture viable. Non pas grâce à un meilleur algorithme, mais parce que nous avons testé ce qu’il fallait.

Le prototypage est un outil de définition des besoins, et pas seulement un outil de validation.

Les appareils portables constituent la règle, et non l'exception. Les applications qui font leur apparition dans le domaine de la localisation de précision — appareils portables destinés aux premiers intervenants, équipements de sécurité, capteurs portés sur le corps — font émerger, lors de la phase de prototypage, des exigences qui ne figuraient pas dans le cahier des charges initial.

Parfois, cela implique de revenir en arrière, à l'étape de la découverte. Du côté gauche du modèle en V, cette étape ne coûte pas cher : il suffit de modifier un document et de reconstruire une plate-forme. Du côté droit, cette même étape se traduit par une refonte, un retard et, dans le pire des cas, une annulation.

La version itérative de cette phase pourrait se résumer ainsi : « Ce matériel ne fonctionne pas, mettons en place une solution avec du matériel haut de gamme et voyons si les résultats évoluent. » Ou encore : « Revenons en arrière et réexaminons ce que vous essayez réellement d’accomplir. » Ces deux options sont peu coûteuses à ce stade. Elles ne le sont plus une fois que vous avez fabriqué des dizaines, des centaines, voire des milliers de cartes et que vous découvrez un dysfonctionnement à ce moment-là.

Le rôle des accélérateurs matériels

Il existe une solution intermédiaire qu’il est utile de connaître. Notre processus s’appuie notamment sur du matériel de qualité industrielle qui regroupe tout le nécessaire — récepteur, IMU, moteur RTK et fusion des capteurs — au sein d’un seul et même appareil. Nous appelons cela des « accélérateurs matériels ». L’Atlas INS et l’Atlas Duo constituent la génération actuelle.

À 10 ou 50 unités, vous n’aurez peut-être pas besoin d’une conception modulaire. Vous pouvez vous contenter d’un accélérateur matériel représentatif de l’architecture que vous validez. À 1 000 unités, une conception modulaire développée en interne s’impose. À 10 000 ou 20 000 unités, vous devrez envisager une conception « chip-down » : l’intégration directe du chipset récepteur sur votre propre circuit imprimé, plutôt que l’achat d’un module pré-assemblé. La conception « chip-down » nécessite un effort d’ingénierie initial, mais elle est rentabilisée en termes de nomenclature (BOM) et de surface de carte lorsque la production atteint un certain volume.

La méthode de validation de principe s'applique toujours à chacune de ces transitions. On ne se contente pas d'intégrer un nouveau récepteur dans un produit commercialisé et d'en rester là. Chaque génération passe par les mêmes phases — c'est d'ailleurs là que s'effectue le travail intéressant de réduction des coûts. En repensant la conception au niveau de la puce pour la prochaine génération, on peut obtenir davantage de bandes, davantage de constellations et un coût des composants (BOM) réduit, car on supprime les composants du module qui n'étaient pas utilisés.

Le véritable résultat attendu

Cette phase aboutit à une architecture unique, sélectionnée à partir des données.

Mais l’objectif réel est plus précis que cela. Au moment où une conception passe à la phase de fabrication, le risque d’une omission catastrophique d’une exigence — une défaillance dans la conception du système qui oblige à revenir vers la partie gauche du V ou qui met fin au programme — doit être aussi proche de zéro que le processus le permet.

C’est ce que permettent les tests. Pas la certitude, que personne ne possède. Mais la confiance que ce à quoi vous vous engagez a déjà fait ses preuves dans les conditions réelles d’utilisation.

Le prochain article explique ce qui se passe lorsque l'on passe à la phase de tests de validation technique (EVT) — et à quoi ressemble la partie droite du modèle en V lorsque la partie gauche a été correctement réalisée.

Si vous êtes en train d'évaluer différentes options architecturales et que vous souhaitez les tester en conditions réelles avec des données concrètes avant de vous engager, prenez rendez-vous pour un atelier de découverte avec un ingénieur de Point One.

Regardez l'intégralité de la conversation — Épisode 2 de « Catalyst »

Foire aux questions

En quoi consistent la phase d'architecture et de prototypage dans la conception d'un système de localisation ?

C'est l'étape qui fait le lien entre les exigences et le choix définitif du matériel. On commence par sélectionner deux ou trois architectures candidates issues de la phase de découverte, on construit des prototypes représentatifs de chacune d'entre elles, on les teste dans l'environnement d'exploitation réel, puis on utilise ces données pour en choisir une. L'objectif est d'éliminer les architectures sur la base de données concrètes plutôt que d'analyses théoriques.

Le moteur de positionnement doit-il fonctionner sur le module GNSS ou sur l'hôte ?

Cela dépend des besoins en puissance de calcul. La plupart des récepteurs RTK modulaires exécutent le moteur de positionnement directement sur le module, ce qui est suffisant pour les applications bénéficiant d’une bonne visibilité vers le ciel et nécessitant un RTK standard associé à un IMU. Les applications nécessitant une fusion complexe de capteurs — dynamique de plate-forme non standard, environnements urbains dégradés ou fusion avec des caméras, un lidar ou l’odométrie — dépassent souvent la capacité de calcul maximale du module et nécessitent une architecture basée sur un hôte. Il est peu coûteux de prendre cette décision dès la phase d’analyse des besoins ; s’en rendre compte au stade de la validation du prototype de développement (DVT) implique une refonte de la conception.

Que signifie l'expression « matériel représentatif » dans le cadre d'une démonstration de faisabilité GNSS ?

Matériel reproduisant le cheminement du signal et le flux de données de la conception visée, même si les composants exacts diffèrent. Si la conception de série est un module transmettant des données en série vers un hôte, le prototype doit être un module transmettant des données en série vers un hôte — le récepteur spécifique peut toutefois différer. C’est l’architecture qui est validée, et non la nomenclature.

Comment obtenir le cap et l'assiette à partir d'un système GNSS ?

Il existe deux méthodes. Une configuration à deux antennes sur une ligne de base fixe permet d’obtenir directement le cap GNSS et fonctionne même à l’arrêt. Une antenne unique couplée à une IMU peut également fournir le cap, mais uniquement lorsque la plate-forme se déplace suffisamment pour que celui-ci soit observable. Le tangage et le roulis proviennent de la solution inertielle. Comme cela détermine le nombre d’antennes et leur montage, cette décision doit être prise lors du choix de l’architecture plutôt que d’être traitée comme une configuration logicielle.

Quelles sont les options de connectivité disponibles pour la transmission des corrections RTK ?

La connexion cellulaire via NTRIP est le mode par défaut pour la plupart des plateformes terrestres, au prix toutefois de lacunes de couverture. Le Wi-Fi convient aux plateformes dont la zone d’activité est limitée à une zone connue. Une liaison radio locale vers votre propre station de base élimine la dépendance au réseau, mais ne s’étend pas au-delà des zones géographiques où vous avez installé des stations de base. Le satellite en bande L fournit des corrections là où aucun réseau terrestre n’existe, avec une précision inférieure à celle du RTK terrestre. La plupart des systèmes de production utilisent un chemin principal et un chemin de secours ; c’est ce dernier qui détermine le comportement pendant la période d’indisponibilité qui rompt l’exigence de haute disponibilité.

Pourquoi l'emplacement de l'antenne est-il si important sur les appareils portables ?

Une antenne montée sur le toit d’un véhicule bénéficie d’une vue dégagée vers le ciel et d’un plan de masse qui jouent en sa faveur. Une antenne portée sur la poitrine ou montée sur le côté est soumise à l’obstruction du corps et à des changements d’orientation constants, ce qui crée un environnement de signal fondamentalement différent. Les équipes concluent souvent que le GNSS ne fonctionne pas avec leur appareil portable, alors que la véritable contrainte réside en réalité dans son emplacement. Des tests réalisés à l’aide d’un banc d’essai représentatif permettent de distinguer ces deux cas.

Comment mesure-t-on la référence pour un système de localisation porté sur le corps ?

En utilisant un deuxième système de référence, de meilleure qualité, porté sur la même plateforme. Pour les appareils portables, nous utilisons un dispositif d’antennes porté sur la tête comme référence de référence — une solution délibérément simple et efficace. Sans référence de référence, on peut collecter des données, mais on ne peut pas mesurer l’erreur, ce qui rend les tests bien moins utiles.

Qu'est-ce que le SSR et dans quels cas faut-il l'utiliser à la place du RTK à ligne de base unique ?

La méthode SSR (représentation dans l'espace d'états) corrige les sources d'erreur à l'échelle d'une région plutôt que de transmettre les observations provenant d'une seule station de référence. Les solutions SSR et VRS offrent généralement une couverture plus homogène sur des zones plus étendues, au prix d'une précision maximale légèrement inférieure à celle d'une solution RTK à base courte utilisant une seule station. Le choix approprié dépend de la zone d'utilisation du produit et de la densité des stations de référence. La densité du réseau détermine l'importance de ce compromis.

Qu'est-ce qu'un accélérateur matériel dans la conception d'un système de localisation ?

Un appareil de qualité industrielle regroupant un récepteur, une unité de mesure inerte (IMU), un moteur RTK et une fusion de capteurs au sein d’un système intégré unique. Il permet à une équipe de commercialiser des produits en petites séries sans avoir à concevoir elle-même des modules, et sert de matériel de référence lors de la validation de l’architecture. Atlas INS et Atlas Duo sont les accélérateurs matériels de Point One.

Qu'est-ce qu'une conception « chip-down » ?

Intégrer directement un chipset de récepteur GNSS sur votre propre circuit imprimé plutôt que d’utiliser un module prêt à l’emploi. Cela demande davantage d’efforts d’ingénierie en amont et nécessite des compétences en conception RF, mais cela s’avère rentable en termes de coût de la nomenclature et d’encombrement de la carte lorsque les volumes de production sont élevés. Cela peut également offrir des fonctionnalités supplémentaires, puisque vous n’êtes plus limité à la bande et à la configuration de constellation choisies par le fournisseur du module.

Comment l'architecture de localisation évolue-t-elle lorsque le volume passe de 100 à 100 000 unités ?

Une architecture qui convient pour 100 unités ne convient souvent plus pour 100 000. À faible volume, un accélérateur matériel intégré constitue généralement la solution la plus rapide. À mesure que le volume augmente, une conception modulaire développée en interne devient rentable, tandis qu’à très grand volume, c’est une conception « chip-down » qui s’impose. Chaque transition doit passer par le même processus de validation de concept — et chacune représente une opportunité, car les conceptions « chip-down » permettent d’ajouter des bandes et des constellations tout en réduisant les coûts grâce à la suppression des composants modulaires inutilisés.

Comment puis-je en savoir plus sur le processus Catalyst ?

Catalyst est la méthodologie de Point One pour la conception de systèmes de localisation. L'article consacré au modèle en V présente les différentes étapes et explique pourquoi les décisions prises dans la partie gauche du modèle ont une incidence prépondérante sur les coûts de la partie droite. L'article sur les six erreurs courantes aborde les choix spécifiques qui entraînent le plus souvent des modifications de conception. L'article sur la phase de découverte traite des trois éléments d'exigences qui précèdent le choix de l'architecture. Les prochains articles approfondiront l'EVT, la partie droite du modèle en V, et la manière dont les exigences de positionnement évoluent à grande échelle. Vous pouvez également explorer directement le moteur de positionnement ou prendre rendez-vous avec un ingénieur de terrain.