Intégrer des capteurs dans ATAK : des télémètres aux récepteurs SDR

Un télémètre connaît la distance jusqu'à une cible. Une radio sait qui est sur le réseau. Un récepteur SDR sait quelles fréquences sont actives et où se trouvent les émetteurs. Aucune de ces informations n'est utile tant qu'elle n'apparaît pas sur la carte de l'opérateur comme un objet partagé, horodaté, que le reste de l'équipe peut voir et exploiter. Cette traduction – d'une lecture brute de capteur à un marqueur dans l'image opérationnelle commune – est précisément ce que fait un plugin d'intégration de capteurs ATAK bien conçu. Cet article présente les modèles permettant de connecter des capteurs de terrain à ATAK, de normaliser leurs sorties très différentes et de publier des détections propres sur le COP sans le noyer sous les informations parasites.

Le problème d'intégration : de nombreux capteurs, une seule image

Les capteurs de terrain ne sont pas conçus pour interopérer. Un télémètre laser émet portée, azimut et inclinaison via un profil série Bluetooth dans son propre format de trame propriétaire. Une radio tactique expose des rapports de position et l'état du réseau via une interface à définition logicielle ou une passerelle série. Un récepteur SDR produit des relèvements de goniométrie et des classifications de signaux sous la forme d'un flux d'enregistrements structurés via une socket réseau. Chacun parle un transport différent, un tramage différent, un système d'unités différent et une convention de coordonnées différente.

ATAK fournit la seule chose dont ils ont tous besoin : un modèle de données spatio-temporel partagé. Chaque objet sur la carte ATAK est un événement Cursor on Target (CoT) — un message XML décrivant ce qui a été observé, où, quand et avec quelle confiance. La mission d'un plugin capteur est donc étroite et bien définie : recevoir la sortie native du capteur, la normaliser en une mesure canonique, convertir cette mesure en un ou plusieurs événements CoT, et injecter ces événements sur le bus interne d'ATAK. Une fois qu'une mesure est un événement CoT, ATAK l'affiche, la persiste et la fédère via TAK Server vers chaque client connecté, sans autre intervention du plugin.

Faire fonctionner correctement ce pipeline relève avant tout de la rigueur aux interfaces. Le côté capteur est chaotique et spécifique au périphérique ; le côté CoT est uniforme. Un bon plugin maintient ces deux mondes strictement séparés par une couche de normalisation, de sorte que prendre en charge un nouveau capteur revient à écrire un seul adaptateur plutôt qu'à retravailler tout le chemin de publication.

Architecture du plugin : les trois couches

Un plugin d'intégration de capteurs en production se divise clairement en trois couches, chacune ayant une responsabilité unique.

1. La couche service capteur. Cette couche possède la connexion physique ou logique au périphérique. Pour un télémètre Bluetooth, elle gère la socket du profil de port série ; pour un périphérique USB, elle utilise l'API USB host d'Android avec un pilote USB-série ; pour un pont SDR, elle maintient un client TCP vers un ordinateur compagnon. La règle fondamentale de cette couche est qu'elle ne touche jamais au thread UI. Toutes les E/S périphérique s'exécutent sur un thread d'arrière-plan dédié ou un Service Android, structuré comme une machine d'état explicite connexion / lecture / reconnexion / déconnexion. Les octets bruts sont tramés en lectures discrètes et transmis — jamais analysés pour leur signification ici, seulement pour leurs délimiteurs.

2. La couche de normalisation. Chaque type de capteur dispose d'un adaptateur qui convertit sa lecture brute en un modèle de mesure interne unique. Ce modèle utilise des unités fixes dans tout le système : degrés WGS84 pour la position, mètres pour la portée et l'altitude, degrés vrais nord pour l'azimut, et UTC pour les horodatages. L'adaptateur effectue la conversion d'unités (mils en degrés, cap magnétique en cap vrai à l'aide d'un modèle de déclinaison), les transformations de datum lorsque le périphérique rapporte dans un datum non-WGS84, et l'estimation de confiance. Tout ce qui est en aval ne consomme que le modèle normalisé, ce qui rend l'architecture extensible.

3. La couche de publication CoT. Cette couche mappe les mesures normalisées sur des événements Cursor on Target et les injecte dans ATAK. Elle détermine la géométrie de l'événement (point, ligne ou polygone), le code de type CoT, la stratégie UID pour les mesures suivies versus ponctuelles, et le délai de péremption. C'est la seule couche qui connaît les API d'ATAK, ce qui rend les couches capteur et normalisation portables et testables indépendamment.

Pourquoi la couche de normalisation mérite sa place

Il est tentant, lors de l'intégration d'un seul capteur, de passer outre la normalisation et de convertir directement la sortie du périphérique en CoT. Ce raccourci s'effondre dès qu'un second capteur arrive — et sur le terrain, il y a toujours un second capteur. Avec un modèle de mesure explicite, la correction de déclinaison, la gestion du datum et la logique de confiance résident en un seul endroit et sont testés unitairement une fois. Ajouter un nouveau modèle de télémètre se réduit à un adaptateur de 100 lignes, et une toute nouvelle classe de capteur devient un nouvel adaptateur plus une nouvelle règle de mapping CoT. Sans cela, chaque nouveau périphérique entraîne des modifications dans tout le chemin de publication et risque de régresser les capteurs qui fonctionnent déjà.

Télémètres : le capteur ponctuel canonique

Un télémètre laser est l'intégration de capteur ATAK la plus simple et la plus courante, et il sert de modèle à tout le reste. L'opérateur vise une cible ; le périphérique rapporte la portée oblique, l'azimut magnétique et l'angle d'inclinaison. Combinés avec la position propre de l'opérateur provenant du GPS d'ATAK, ces trois valeurs permettent de calculer une coordonnée de cible unique.

La géométrie est une projection polaire-cartésienne depuis la position de l'opérateur : convertir l'azimut magnétique en azimut vrai en appliquant la déclinaison locale, projeter la portée oblique sur l'angle d'inclinaison pour obtenir une distance au sol et un delta d'altitude, puis décaler depuis la position connue du capteur pour obtenir la coordonnée WGS84 de la cible. Le résultat est publié comme événement CoT ponctuel avec une affiliation hostile, amie ou inconnue choisie par l'opérateur, et un délai de péremption assez long pour être utile mais assez court pour qu'un tir abandonné ne reste pas sur la carte.

Deux détails d'implémentation causent la plupart des défaillances sur le terrain. Le premier est la déclinaison : un télémètre rapporte un cap magnétique, et l'utiliser comme cap vrai produit une erreur de cible qui croît avec la portée — à 5 km, quelques degrés de déclinaison non corrigée décalent le marqueur de plusieurs centaines de mètres. Le plugin doit appliquer un modèle de déclinaison pour la position et la date de l'opérateur. Le second est la boucle de lecture Bluetooth : les télémètres se couplent via le profil de port série et émettent une trame par tir, mais si la lecture s'exécute sur le thread UI, toute l'interface ATAK saccade à chaque reconnexion du périphérique. La lecture doit résider dans le service capteur d'arrière-plan.

Radios : rapports de position et état du réseau

Les radios tactiques contribuent deux types de données à l'image : les positions des radios elles-mêmes et l'état du réseau. Les radios à définition logicielle modernes et les appareils portables capables de données exposent des rapports de position via une passerelle série ou IP, et le modèle d'intégration reflète étroitement la pratique plus large de connexion des radios tactiques aux logiciels. Chaque rapport devient un événement CoT de position avec un UID stable dérivé de l'identifiant de la radio, de sorte qu'ATAK affiche un marqueur de force amie en mouvement plutôt qu'une série de points déconnectés.

L'état du réseau est la contribution la plus subtile. Si un nœud est joignable, sa qualité de lien et la date de son dernier rapport sont toutes opérationnellement significatives. Un plugin radio capable présente cela sous la forme d'un style de marqueur — un nœud qui n'a pas rapporté dans son intervalle attendu est visuellement vieilli ou grisé — et optionnellement comme champ de détail CoT afin que les outils en aval puissent raisonner sur la santé du lien. Le plugin ne doit jamais supprimer définitivement un nœud périmé ; il doit laisser le délai de péremption CoT exprimer l'incertitude afin que l'opérateur comprenne la différence entre « confirmé absent » et « pas entendu récemment ».

Récepteurs SDR : relèvements, localisations et le modèle de l'ordinateur compagnon

Les récepteurs radio à définition logicielle sont la classe de capteurs la plus exigeante à intégrer, car le traitement intensif du signal s'exécute rarement sur le périphérique Android lui-même. Le déploiement standard place la plateforme SDR et sa chaîne de détection ou de goniométrie sur un ordinateur compagnon, le plugin ATAK agissant comme un consommateur léger via une socket réseau locale.

La chaîne SDR produit trois types de produits utiles. Un relèvement de goniométrie unique se mappe sur une ligne CoT tracée depuis la position du capteur le long de l'azimut mesuré, optionnellement avec un secteur angulaire d'incertitude. Une localisation multi-capteurs ou à base mobile se mappe sur un point CoT avec une ellipse d'erreur exprimant la confiance de géolocalisation. Une classification de signal — type d'émetteur, modulation, fréquence — s'attache comme détail CoT afin que l'opérateur voie non seulement où se trouve un émetteur, mais ce qu'il est probablement. Parce que le côté SDR s'exécute de façon asynchrone et à haute cadence, le plugin doit limiter le débit et dédupliquer avant de publier ; un flux brut de relèvements à des dizaines de hertz submergerait à la fois la carte et la fédération TAK Server.

Publier sur le COP sans le noyer

Une fois les mesures normalisées, la discipline de la couche de publication détermine si le plugin aide ou nuit. Trois règles régissent un bon comportement. Premièrement, attribuer un UID stable à tout ce qui doit être suivi — une radio, un émetteur persistant — afin que les mises à jour remplacent le marqueur existant au lieu d'en créer de nouveaux ; n'attribuer un UID frais qu'aux événements ponctuels véritablement indépendants comme un tir unique. Deuxièmement, adapter le délai de péremption CoT à la confiance : une piste confirmée et observée de façon répétée peut persister une minute ou plus, tandis qu'une détection unique incertaine doit expirer en quelques secondes pour s'auto-effacer. Troisièmement, dédupliquer et limiter le débit à la source, avant que l'événement n'atteigne le bus, afin que la fédération transporte du signal plutôt que du bruit.

Tout aussi important est l'honnêteté sur l'état du lien. Un plugin capteur de terrain doit supposer que le réseau — et parfois le lien capteur lui-même — tombera. Les mesures sont écrites dans une file d'attente locale à l'instant où elles sont capturées, horodatées à l'heure de capture plutôt qu'à l'heure de publication, et transmises en CoT au retour de la connectivité. Le panneau du plugin doit toujours afficher l'état du lien capteur, l'âge de la dernière lecture et tout retard de publication. Un plugin qui s'arrête silencieusement de mettre à jour lors d'une déconnexion de capteur est pire qu'aucun plugin du tout, car il présente une image périmée comme si elle était en direct. La même discipline hors ligne s'applique que le flux soit un télémètre portable ou un flux de télémétrie drone.

Tests et validation sur le terrain

Les plugins capteurs échouent de façons que les tests en laboratoire détectent rarement. Les périphériques Bluetooth renégocient leurs connexions de façon imprévisible ; le GPS dérive sous couvert arboré ; la déclinaison varie avec la position ; les révisions de firmware modifient silencieusement les formats de sortie. Un passage de validation représentatif exécute le plugin sur le vrai matériel Android durci que l'unité déploie, avec le vrai capteur, sous connectivité intermittente, et avec le comportement tactile attendu de mains gantées. Capturer la sortie réelle du périphérique tôt — les fiches techniques mentent, et la seule source fiable de vérité pour une trame de sortie est le périphérique en main. Confirmer que les coordonnées de cible issues d'un tir de télémètre correspondent à l'emplacement d'un point de contrôle relevé, et que l'image se dégrade de façon gracieuse — non trompeuse — lorsqu'un capteur est perdu.