Dès qu'un UAV décolle, l'unité qui le contrôle obtient un avantage de renseignement asymétrique — à condition que cette information parvienne à tous les opérateurs concernés. L'échec opérationnel typique n'est pas un manque de couverture drone : c'est l'opérateur drone qui décrit verbalement par radio ce qu'il voit pendant que tous les autres travaillent en aveugle sur leurs écrans GCS ou ATAK. L'intégration de la télémétrie drone TAK comble cette lacune en alimentant la position de l'UAV, l'angle du gimbal et le flux vidéo directement dans l'image opérationnelle commune, de sorte que chaque client ATAK du réseau voit le drone comme une piste en direct aux côtés des forces amies.
Cet article décrit le pipeline technique complet : télémétrie MAVLink du drone à la station de contrôle au sol (GCS), conversion en Cursor on Target (CoT), transfert vers le serveur TAK, relais vidéo, encodage de l'empreinte du gimbal, synchronisation inverse des waypoints, optimisation de la bande passante pour les radios MANET et conventions de gestion multi-drones.
Pourquoi l'intégration drone-COP est importante : le problème de changement de contexte
Une opération UAV typique d'une petite unité implique au moins trois rôles distincts : le pilote drone surveillant le flux vidéo GCS, le commandant des forces terrestres travaillant avec la carte ATAK, et un opérateur capteur monitorant la caméra. Sans intégration, chaque rôle opère à partir d'une source de données différente. Le pilote sait où se trouve le drone ; le commandant, non, sauf si le pilote commente. Quand le pilote se concentre sur une manœuvre, le commentaire s'arrête.
L'intégration UAV ATAK remplace la coordination vocale par des données. Le drone apparaît comme une piste aérienne mobile sur la carte ATAK. L'empreinte du gimbal — un polygone montrant exactement ce que le capteur surveille — se met à jour en temps réel. Le flux vidéo est accessible en un tap dans ATAK Video Receiver. Un commandant peut envoyer un nouveau point de loitering depuis la carte sans chercher le pilote.
Pipeline de télémétrie MAVLink : du drone au serveur TAK
Le pipeline comporte cinq étapes : autopilote du drone → liaison radio de données → GCS (QGroundControl ou Mission Planner) → processus bridge MAVLink → serveur TAK.
Bases du protocole MAVLink. MAVLink est le protocole de télémétrie et de contrôle dominant pour les petits UAS. C'est un protocole binaire léger conçu pour les liaisons radio à faible bande passante. MAVLink 2 est la norme actuelle et ajoute la signature des paquets. Un stream MAVLink d'un autopilote typique (ArduPilot, PX4) comprend GLOBAL_POSITION_INT à 2–10 Hz, ATTITUDE à 10–50 Hz, HEARTBEAT à 1 Hz, MOUNT_ORIENTATION à 10–25 Hz et MISSION_ITEM_INT sur demande.
GCS comme routeur de télémétrie. La GCS reçoit le stream MAVLink via la liaison radio. QGroundControl et Mission Planner supportent le transfert MAVLink : configurer une sortie UDP secondaire sur localhost:14551 délivre le stream complet à tout processus sur la machine GCS.
Bridge MAVLink-to-CoT. Le processus bridge lit le stream MAVLink transféré et convertit chaque rapport de position en un événement XML CoT. Mapping clé : GLOBAL_POSITION_INT.lat / lon / alt → CoT <point> lat/lon/hae ; GLOBAL_POSITION_INT.hdg → CoT <detail><track course=... />. Des bridges open-source existent : MAVLink2TAK (Python), UASLINK (C++).
Livraison au serveur TAK. Le bridge se connecte au serveur TAK via TCP/TLS sur le port 8089 avec un certificat client et envoie les événements CoT en XML streaming. Le serveur TAK fédère immédiatement les événements à tous les clients ATAK, WinTAK et CloudTAK connectés.
Structure des messages CoT pour les pistes aériennes
Le code de type CoT correct est important — il contrôle l'icône rendue par ATAK et la couleur de la piste. Pour un UAV à voilure fixe ami, le type est a-f-A-M-F-Q. Décodage : a = atome, f = ami, A = air, M = militaire, F = voilure fixe, Q = non piloté. Pour un drone à voilure tournante ami : a-f-A-M-H-Q.
Le champ how doit être m-g (généré par machine, GPS). Le temps d'obsolescence doit être fixé à 20–30 secondes devant l'heure de l'événement.
<event version="2.0"
uid="DRONE-ALPHA-01"
type="a-f-A-M-F-Q"
how="m-g"
time="2026-05-29T10:00:00.000Z"
start="2026-05-29T10:00:00.000Z"
stale="2026-05-29T10:00:25.000Z">
<point lat="48.3794"
lon="31.1656"
hae="250.0"
ce="5.0"
le="10.0"/>
<detail>
<contact callsign="ALPHA-1"/>
<track course="045.0" speed="18.5"/>
<remarks>MAVLink sysid=1</remarks>
</detail>
</event>
Les valeurs ce (erreur circulaire) et le (erreur linéaire) doivent refléter la précision GPS réelle du message GLOBAL_POSITION_INT de l'autopilote.
Intégration du streaming vidéo : RTSP vers ATAK
La plupart des charges utiles de petits UAS encodent la vidéo en H.264 ou H.265 et l'exposent comme un stream RTSP. Chemin d'intégration : caméra drone → encodeur → RTSP via liaison de données → GCS → relais FFmpeg → ATAK Video Receiver.
Relais FFmpeg. Sur la machine GCS, FFmpeg reçoit le stream RTSP du drone et le re-diffuse. Pour UDP multicast : ffmpeg -i rtsp://192.168.1.100:554/stream -c copy -f mpegts udp://239.2.3.1:1234. Le paramètre clé est -c copy.
Configuration ATAK Video Receiver. Le bridge publie un événement CoT de type b-i-x-i (alias vidéo) contenant l'URL du stream et un alias lisible. Quand cet événement arrive à un client ATAK, le plugin Video Receiver ajoute automatiquement le stream à sa liste de sources.
Adaptation aux liaisons dégradées. À 500–800 kbps, H.264 fournit une vidéo de reconnaissance utilisable en 720p/15fps. En dessous de 300 kbps, passer à des snapshots JPEG.
Superposition gimbal et capteur : encodage du polygone FOV
Le polygone d'empreinte du gimbal indique aux opérateurs ce que le capteur couvre. Le bridge calcule les quatre coins à partir de la position du drone, de l'altitude, des angles pan/tilt du gimbal et du FOV de la caméra, et les encode comme polygone CoT GeoObject :
<event type="u-d-f" uid="DRONE-ALPHA-01-FOV" ...>
<detail>
<shape>
<polyline closed="true">
<vertex lat="48.3802" lon="31.1641"/>
<vertex lat="48.3802" lon="31.1671"/>
<vertex lat="48.3786" lon="31.1671"/>
<vertex lat="48.3786" lon="31.1641"/>
</polyline>
</shape>
<color argb="-2130706433"/>
<strokeColor value="-16711936"/>
<fillColor value="570556928"/>
<remarks>ALPHA-1 gimbal FOV</remarks>
</detail>
</event>
L'UID du polygone FOV est dérivé de l'UID du drone avec le suffixe -FOV. Mettre à jour le polygone avec chaque message MOUNT_ORIENTATION (10–25 Hz). Temps d'obsolescence : 5 secondes.
Synchronisation des waypoints : d'ATAK vers la GCS
L'intégration bidirectionnelle est la capacité opérationnelle la plus significative. Chemin inverse : l'opérateur ATAK dessine un itinéraire → ATAK publie un événement CoT route → le bridge reçoit l'itinéraire → convertit les waypoints CoT en MAVLink MISSION_ITEM_INT → charge la mission sur la GCS → GCS pousse vers le drone.
Protocole de chargement de mission MAVLink. Le chargement est un handshake requête-réponse : le bridge envoie MISSION_COUNT, le drone ACK, le drone demande chaque MISSION_ITEM_INT par numéro de séquence, le bridge envoie chaque élément, le drone envoie MISSION_ACK à la fin. Implémenter un timeout-et-retry à chaque étape.
Note sur le système de coordonnées. MAVLink MISSION_ITEM_INT utilise par défaut le cadre MAV_FRAME_GLOBAL_RELATIVE_ALT — altitude relative au point d'origine défini lors de l'armement du drone. CoT utilise HAE (hauteur au-dessus de l'ellipsoïde, WGS84). Le bridge doit convertir : HAE → (HAE − home_HAE).
Optimisation faible bande passante pour les radios MANET
Les radios MANET — Persistent Systems MPU5, Silvus StreamCaster, Harris FALCON IV — fournissent 1–20 Mbps de bande passante partagée. Une seule intégration drone peut consommer une part disproportionnée du budget.
Limitation du taux de mise à jour des pistes. À 1 Hz, un drone se déplaçant à 20 m/s parcourt 20 m entre les mises à jour — acceptable pour une piste aérienne. 1 Hz est une valeur par défaut raisonnable pour la plupart des applications ISR.
CoT binaire vs CoT XML. TAK Server 4.x supporte le CoT encodé en protobuf, qui réduit la taille des messages de 55–65% par rapport au CoT XML. À 1 Hz pour 4 drones, cela économise ~1 Mbps de bande passante radio.
Gestion de la qualité vidéo. La vidéo est de loin le plus grand consommateur. Utiliser RTSP unicast plutôt que multicast quand seulement un ou deux opérateurs ont besoin de la vidéo.
Observation clé : L'intégration drone-COP est autant un problème de budget radio qu'un problème logiciel. Modéliser le budget de liaison MANET avant le déploiement — prendre en compte la télémétrie, la vidéo, le CoT des forces terrestres, la voix et les surcharges.
Gestion multi-drones : conventions d'indicatifs et gestion des groupes
Opérer plus de deux drones simultanément crée des défis de déconfliction sur la carte ATAK.
Conventions UID CoT et indicatif. Chaque drone doit avoir un UID CoT globalement unique : UNITÉ-RÔLE-NUMÉRO (par ex. 3PLT-ISR-01). L'indicatif affiché sur l'étiquette de la carte ATAK doit suivre la même convention et correspondre aux indicatifs radio vocaux de l'unité.
Affectations de groupes CoT. Les groupes du serveur TAK contrôlent quels clients voient quelles pistes. Affecter les drones au même groupe que l'unité terrestre qu'ils soutiennent.
Registre de drones du bridge MAVLink. Quand plusieurs instances GCS reportent au même serveur TAK, le bridge sur chaque GCS doit utiliser un registre de drones — un mapping persistant des identifiants de système MAVLink vers les UIDs CoT.
Conscience essaim à grande échelle. Pour les opérations avec plus de 5–6 drones simultanément, envisager d'ajouter une superposition de gestion des drones dédiée — un plugin ATAK personnalisé ou composant WinTAK affichant toutes les pistes de drones avec l'état de la batterie, le statut de mission et la disponibilité vidéo sous forme de tableau.