Traitement de nuages de points LiDAR en environnement militaire de bord : cartographie 3D du terrain et détection d'obstacles sur matériel embarqué

Un capteur LiDAR rotatif à 32 canaux produit environ 700 000 points par seconde. Chaque point encode une mesure de portée précise, un angle azimutal et d'élévation, ainsi qu'une valeur d'intensité de réflectance. À partir de ce flux de données brutes, une plateforme autonome militaire doit dériver -- en temps réel et sans connectivité -- une carte de terrain navigable, un ensemble de détections d'obstacles, et une représentation compressée adaptée à la transmission sur une liaison radio tactique contrainte. Tel est le problème d'ingénierie du traitement de nuages de points LiDAR en environnement militaire de bord : extraire une conscience situationnelle 3D opérationnellement utile à partir d'un capteur à haut débit sur du matériel qui peut être limité à un budget d'énergie de 15 W, sans chemin de déchargement vers le cloud, et dans les contraintes de latence de la navigation autonome en temps réel.

Pourquoi le traitement de nuages de points LiDAR en bordure de réseau est crucial pour l'autonomie militaire

Les véhicules terrestres autonomes, les systèmes aériens sans pilote opérant sous l'ombre GPS des canyons urbains, et les plateformes robotiques démontées partagent tous la même dépendance fondamentale : ils ont besoin d'une compréhension en temps réel de la géométrie 3D qui les entoure pour naviguer en sécurité et accomplir leurs missions. Le LiDAR est le capteur primaire privilégié pour cela, car il produit des mesures de portée métriquement précises (typiquement 1 à 3 cm de précision à des portées allant jusqu'à 100 m) indépendantes des conditions d'éclairage, ne nécessitant pas de texture de scène et se dégradant progressivement en cas de pluie légère et de poussière. L'estimation de profondeur par caméra peut compléter le LiDAR mais ne peut pas le remplacer dans les conditions visuelles dégradées qui sont courantes dans les environnements opérationnels militaires.

La contrainte de bord n'est pas un choix -- c'est une exigence physique et opérationnelle. Les données brutes de nuage de points d'un capteur rotatif à 32 canaux à 10 Hz génèrent environ 20 à 40 Mo/s, ce qui dépasse largement le débit de toute liaison radio tactique pratique (typiquement 512 kbit/s à 5 Mbit/s dans une configuration MANET sous charge). Même si la liaison était disponible, la latence aller-retour vers un processeur cloud consommerait des dizaines à des centaines de millisecondes -- bien trop long pour les décisions d'évitement de collision sur un véhicule en mouvement. Pour un véhicule terrestre autonome se déplaçant à 20 km/h, 100 ms de latence supplémentaire correspond à 55 cm de distance de déplacement supplémentaire avant que le système puisse réagir, une marge inacceptable à proximité d'obstacles. Le traitement sur la plateforme n'est pas un atout optionnel ; c'est une exigence stricte de latence et de bande passante.

Les déploiements LiDAR militaires en bordure exigent donc des algorithmes à la fois computationnellement efficaces et robustes aux conditions dégradées de l'opération sur le terrain : vibrations, inclinaison du capteur, occultation partielle par la végétation, et absence des caractéristiques structurelles nettes (murs, plafonds, sols) dont dépendent les systèmes LiDAR SLAM intérieurs. Les algorithmes présentés dans cet article sont spécifiquement sélectionnés pour leurs performances démontrées dans des environnements extérieurs non structurés.

SLAM pour la cartographie du terrain : construction de cartes 3D en temps réel depuis des plateformes mobiles

Le SLAM (Simultaneous Localization and Mapping) est l'épine dorsale algorithmique de la cartographie de terrain basée sur LiDAR dans les environnements où le GPS est refusé ou dégradé. Un système LiDAR SLAM maintient deux estimations en interaction : la pose actuelle de la plateforme (position et orientation dans l'espace 3D) et une carte de l'environnement accumulée à partir de tous les balayages passés. Chaque nouveau balayage du LiDAR est mis en correspondance avec le balayage précédent ou une sous-carte locale pour calculer le mouvement incrémental de la plateforme, ce qui met à jour l'estimation de pose. Le balayage horodaté est ensuite intégré dans la carte en cours de construction, formant une représentation 3D en nuage de points du terrain parcouru par la plateforme.

Les algorithmes LiDAR SLAM les plus largement déployés pour les plateformes militaires extérieures sont LOAM (LiDAR Odometry and Mapping), LIO-SAM (LiDAR-Inertial Odometry via Smoothing and Mapping) et KISS-ICP (Keep it Small and Simple ICP). LOAM extrait des caractéristiques d'arêtes et planes de chaque balayage et les met en correspondance entre les images, atteignant une faible dérive sur terrain structuré mais nécessitant des processeurs relativement puissants pour maintenir un débit à 10 Hz. LIO-SAM couple étroitement la mise en correspondance de balayages LiDAR avec les données d'une unité de mesure inertielle (IMU) à l'aide d'un backend d'optimisation par graphe de facteurs, fournissant une odométrie robuste sur les plateformes soumises à des vibrations et des changements d'attitude rapides -- des conditions qui neutralisent l'odométrie LiDAR pure. KISS-ICP réduit l'algorithme à son noyau ICP essentiel avec un seuil dynamique point-à-point, atteignant des performances en temps réel sur un ARM Cortex-A55 au prix d'une dérive légèrement plus élevée sur terrain sans caractéristiques.

La détection de fermeture de boucle est le mécanisme qui empêche la dérive du SLAM de s'accumuler indéfiniment. Lorsque la plateforme revient à un emplacement précédemment visité, l'optimiseur back-end détecte le chevauchement entre le balayage actuel et la sous-carte stockée, ajoute une contrainte de fermeture de boucle au graphe de poses et ré-optimise l'ensemble de la trajectoire. Pour les missions de reconnaissance militaires où un UGV ou un robot parcourt un itinéraire et revient, la fermeture de boucle réduit la dérive finale de la carte de potentiellement plusieurs mètres (accumulation ICP en boucle ouverte sur un parcours de 500 m) à des centimètres. Le compromis est le coût computationnel : la détection complète de fermeture de boucle à l'aide de descripteurs de contexte de balayage ou d'histogramme d'intensité nécessite 50 à 200 ms par tentative de détection, et l'étape d'optimisation du graphe s'échelonne super-linéairement avec le nombre de poses dans le graphe pour les grands environnements.

Détection et classification d'obstacles sur matériel LiDAR embarqué

La cartographie du terrain et la détection d'obstacles sont des tâches algorithmiquement distinctes qui s'exécutent de manière concurrente sur le même flux de nuage de points. La cartographie du terrain accumule des balayages pour construire un modèle 3D persistant ; la détection d'obstacles traite chaque balayage indépendamment pour identifier les objets que la plateforme doit éviter ou qui ont une signification tactique. Le pipeline standard commence par la segmentation du plan sol : séparer les points appartenant à la surface praticable des points représentant les objets au-dessus du sol. L'ajustement de plan RANSAC (Random Sample Consensus) est l'approche classique, sélectionnant un sous-ensemble aléatoire de points, ajustant un modèle de plan et itérant jusqu'à ce que le plus grand ensemble de points conformes soit trouvé. Pour les terrains extérieurs non plats, les filtres morphologiques progressifs ou les méthodes d'estimation du sol basées sur des images de portée donnent de meilleurs résultats, s'adaptant à la pente et à l'ondulation.

Les points au-dessus du sol sont ensuite regroupés en régions candidates d'obstacles à l'aide d'un clustering euclidien ou d'un clustering spatial basé sur la densité (DBSCAN). Le clustering euclidien regroupe les points à l'intérieur d'un seuil de distance configurable en composantes connexes, chacune représentant un objet distinct. Pour les scénarios militaires extérieurs typiques, le clustering avec un seuil de distance de 0,5 à 1,0 m regroupe le corps d'une personne en un seul cluster et un véhicule en un ou quelques clusters, tout en séparant les troncs d'arbres et les buissons individuels. Chaque cluster est ensuite décrit par sa boîte englobante (dimensions et orientation) et sa distribution normalisée de points, qui est alimentée à un réseau de classification. PointNet et son successeur PointNet++ sont les architectures standard pour cette tâche : ils opèrent directement sur les coordonnées brutes (x, y, z) des points du cluster, appliquent un MLP partagé à chaque point pour extraire des caractéristiques par point, et agrègent avec une pooling max global pour produire un embedding de taille fixe invariant à l'ordre des points. Un classificateur MLP final associe l'embedding aux probabilités de classe d'objet.

Le déploiement de classificateurs de style PointNet sur matériel embarqué nécessite le même workflow de quantification et d'optimisation qui s'applique au déploiement de modèles TensorFlow Lite sur matériel militaire embarqué. La quantification INT8 d'un modèle PointNet réduit le stockage des paramètres d'environ 3,5 Mo (FP32) à moins de 1 Mo, et la latence d'inférence sur un Jetson Orin NX passe de 18 ms à moins de 5 ms par cluster. Les clusters étant traités indépendamment, la latence totale de détection d'obstacles pour un balayage avec 20 à 30 clusters au-dessus du sol est typiquement de 50 à 100 ms sur un Jetson Orin NX -- bien dans le budget de bout en bout de 200 ms pour la détection d'obstacles à un taux de balayage de 10 Hz.

Algorithmes de sous-échantillonnage : grilles de voxels, échantillonnage par point le plus éloigné et compromis militaires

Les nuages de points bruts d'un LiDAR rotatif à 32 canaux contiennent 50 000 à 150 000 points par balayage. Traiter chaque point à travers un algorithme SLAM ou un pipeline de détection d'obstacles est computationnellement inutile et souvent contre-productif : la densité de points à courte portée est bien supérieure à ce qui est nécessaire pour l'une ou l'autre tâche, tandis que la densité à longue portée est trop faible pour apporter des informations significatives au-delà de ce qu'une représentation plus grossière capturerait. Le sous-échantillonnage réduit le nombre de points à un niveau adapté à l'exigence de traitement, échangeant la résolution spatiale contre l'efficacité computationnelle.

Le sous-échantillonnage par grille de voxels est l'approche la plus courante dans les déploiements militaires en bordure. L'espace 3D est divisé en une grille régulière de voxels cubiques, et tous les points de chaque voxel sont remplacés par leur centroïde. Le paramètre de taille de voxel contrôle directement le compromis résolution-calcul : une taille de voxel de 0,1 m réduit un balayage de 120 000 points à environ 5 000 à 10 000 points pour les scènes extérieures typiques, une réduction de 10 à 20 fois, tout en préservant la géométrie métrique nécessaire au SLAM. Une taille de voxel de 0,2 m réduit à 2 000 à 4 000 points avec une réduction correspondante de la résolution de carte. Le sous-échantillonnage par voxels est computationnellement trivial (une recherche de table de hachage par point) et s'exécute en moins de 2 ms sur un processeur ARM, le rendant adapté à l'étape de pré-traitement en temps réel qui alimente tous les algorithmes en aval.

L'échantillonnage par point le plus éloigné (FPS) est la méthode de sous-échantillonnage standard utilisée comme préparation d'entrée pour les classificateurs de style PointNet. Étant donné un cluster de N points, FPS sélectionne itérativement le point le plus éloigné de l'ensemble actuellement sélectionné jusqu'à ce que K points soient sélectionnés. Cela produit un échantillon spatialement uniforme qui préserve la distribution géométrique du cluster -- essentielle pour PointNet, qui repose sur la structure de forme globale. Le coût computationnel est O(N * K), ce qui est acceptable pour les petits clusters (50 à 500 points) alimentés au classificateur d'obstacles, mais serait prohibitif pour le sous-échantillonnage de balayages bruts complets. En pratique, le sous-échantillonnage par voxels gère l'étape de pré-traitement du balayage complet, et le FPS gère la normalisation par cluster immédiatement avant l'inférence du classificateur.

Compression de nuages de points pour transmission tactique à bande passante limitée

Même après le sous-échantillonnage par voxels, la transmission de nuages de points traités complets sur une liaison radio tactique est rarement viable. Un balayage extérieur sous-échantillonné à une résolution de voxel de 0,1 m avec 5 000 points, chacun encodé comme trois coordonnées FP32 et une valeur de réflectance, occupe environ 64 Ko. À un taux de balayage de 10 Hz, le flux brut est de 640 Ko/s -- dépassant le débit disponible de la plupart des configurations MANET opérant sous interférence. La solution pratique consiste à transmettre des produits de données dérivés plutôt que des nuages de points bruts ou sous-échantillonnés : grilles d'occupation, tuiles de Modèle Numérique d'Élévation (MNE), et messages de détection d'obstacles structurés.

Une grille d'occupation 2,5D encode le terrain comme une grille de cellules, chacune stockant la hauteur du retour LiDAR le plus élevé et un indicateur de franchissabilité. Pour une zone de 100 m × 100 m à une résolution de 0,25 m, la grille contient 160 000 cellules. Stocker chaque cellule comme un entier signé 16 bits pour la hauteur plus un bit pour la franchissabilité, et appliquer une compression LZ4, réduit la tuile de 100 m à environ 15 à 30 Ko selon la complexité du terrain. À un taux de mise à jour de 1 Hz par tuile, la charge de diffusion de carte est de 15 à 30 Ko/s -- gérable même sur une liaison MANET fortement chargée. La plateforme réceptrice peut reconstruire un modèle de terrain de qualité suffisante pour la planification d'itinéraire à partir de ces tuiles sans jamais recevoir un seul paquet de nuage de points brut.

Les événements de détection d'obstacles sont encore plus compacts. Un message structuré encodant la position (3 FP32), la classe (1 octet), la boîte englobante (3 dimensions FP32 plus 1 FP32 lacet), le score de confiance (1 FP32), l'ID de piste (4 octets) et l'estimation de vitesse (3 FP32) occupe environ 60 octets par obstacle. Transmettre 30 obstacles par balayage à 10 Hz génère un flux de détection de 18 Ko/s -- négligeable sur toute liaison pratique. Pour les budgets de liaison inférieurs à 64 kbit/s, la transmission du seul flux d'événements de détection (supprimant entièrement les mises à jour de tuiles de carte) fournit à l'opérateur récepteur une conscience des obstacles en temps réel à moins de 25 % de la bande passante disponible.

Plateformes matérielles : déploiement contraint en GPU sur Jetson, FPGA et SBC militaires

Le NVIDIA Jetson AGX Orin est la référence de performance actuelle pour les charges de travail LiDAR militaires en bordure. Son GPU Ampere à 2048 cœurs avec 64 unités Tensor Core offre 275 TOPS de débit INT8 dans une enveloppe TDP configurable de 15 à 60 W. L'exécution d'un pipeline de traitement LiDAR complet -- sous-échantillonnage par voxels, SLAM LIO-SAM, segmentation du sol, clustering euclidien et classification PointNet INT8 -- sur un capteur à 32 canaux à 10 Hz consomme environ 8 à 12 W sur le Jetson AGX Orin, laissant une marge pour les pilotes de communication, les logiciels de mission et les frais généraux système dans un budget d'énergie de plateforme de 20 W. Pour les plateformes avec des allocations d'énergie moins généreuses, le Jetson Orin NX (10–25 W) gère le même pipeline à 10 Hz si l'optimisation back-end SLAM est limitée à 5 Hz, et l'Orin Nano (5–15 W) est suffisant pour les charges de travail plus simples qui sautent le SLAM complet en faveur de l'odométrie balayage par balayage uniquement.

Les plateformes FPGA jouent un rôle différent dans la chaîne de traitement LiDAR. Les opérations front-end -- ingestion du nuage de points depuis le port Ethernet du capteur, hachage de grille de voxels, RANSAC du plan sol et génération d'image de portée -- ont des exigences de latence déterministe et bénéficient du parallélisme pipeliné qu'offrent les FPGA. Un Xilinx Zynq UltraScale+ MPSoC exécutant le sous-échantillonnage par voxels et la segmentation du sol en logique programmable peut offrir une latence inférieure à la milliseconde avec un débit garanti, alimentant le nuage sous-échantillonné et débarrassé du sol vers le sous-système CPU ARM pour le SLAM et vers le GPU pour la classification. Cette architecture hétérogène -- FPGA pour le pré-traitement front-end, GPU pour la classification basée sur l'apprentissage, CPU pour le back-end SLAM -- est de plus en plus standard dans les programmes militaires UGV haute performance. Les ordinateurs monocarte militaires homologués MIL-STD-810G pour les chocs et vibrations et aux normes TEMPEST pour le contrôle des émanations intègrent généralement un processeur ARM multicœur avec un slot PCIe acceptant soit un module système sur puce Jetson, soit un module FPGA Xilinx selon les exigences de latence et de certification du programme.

La gestion thermique est une contrainte pratique que les équipes logicielles sous-estiment fréquemment lors de l'intégration du traitement LiDAR dans une plateforme militaire. Le Jetson AGX Orin à 60 W TDP produit 60 W de chaleur qui doit être évacuée du module dans un boîtier scellé aux spécifications militaires. Les solutions de refroidissement passif utilisant des caloducs et des empilements de ailettes externes sont réalisables jusqu'à environ 30 W de charge continue ; au-delà, une boucle de refroidissement par liquide pompé est généralement requise. Régler le TDP du Jetson à 15 à 20 W à l'aide de la configuration du mode d'alimentation nvpmodel satisfait la plupart des budgets de refroidissement passif tout en offrant un débit suffisant pour un pipeline LiDAR à 32 canaux. Les contraintes thermiques affectent tous les déploiements d'inférence militaires en bordure, pas seulement le traitement LiDAR, et le budget thermique doit faire partie de la conception de la plateforme dès la première itération matérielle plutôt que d'être traité comme un problème d'intégration tardif.

Intégration avec les systèmes autonomes et le suivi des forces amies pour la conscience situationnelle

Un pipeline de traitement LiDAR qui opère en isolation -- produisant des cartes de terrain et des détections d'obstacles qui ne sont consommées que par la pile de navigation de la plateforme elle-même -- fournit une autonomie locale mais pas une conscience situationnelle partagée. La valeur opérationnelle se multiplie lorsque les produits de données dérivés de chaque plateforme autonome sont partagés sur le réseau tactique et fusionnés dans une image opérationnelle commune accessible à chaque opérateur, commandant et système connecté. L'architecture d'intégration pour cela nécessite trois éléments : un format de données géoréférencées pour les produits cartographiques, un format de message structuré pour les événements de détection, et un middleware de publication-abonnement qui livre les deux aux consommateurs au taux de mise à jour et à la priorité appropriés.

Les tuiles de carte de terrain de chaque plateforme autonome sont géoréférencées à l'aide de la position et de l'orientation actuelles estimées par SLAM de la plateforme, fusionnées avec tout fix GPS disponible. La tuile est projetée dans un référentiel de coordonnées global (grille UTM ou MGRS) et étiquetée avec l'ID de suivi des forces amies de la plateforme génératrice et un horodatage. La couche de données géospatiales du serveur TAK accepte ces tuiles comme pièces jointes de Mission Package ou comme superpositions de géométrie vectorielle, les rendant visibles à chaque client ATAK connecté comme une couche de carte en direct qui se met à jour à mesure que la plateforme autonome avance. Les opérateurs voient la structure du terrain des zones explorées par les systèmes autonomes pendant que ces systèmes les parcourent, plutôt que d'attendre un transfert de données post-mission.

Les détections d'obstacles du classificateur LiDAR sont publiées comme événements CoT vers le serveur TAK, suivant le même schéma d'intégration que la détection acoustique de coups de feu par IA et d'autres systèmes de capteurs de bord. L'événement CoT porte la classe de l'obstacle (véhicule, personne, structure), les dimensions et l'orientation de la boîte englobante, le score de confiance, et l'estimation de vitesse du filtre de suivi. Les plateformes autonomes à portée de communication les unes des autres peuvent également partager des événements de détection en pair-à-pair, permettant de maintenir une carte d'obstacles partagée au sein d'une flotte sans nécessiter un serveur central. Ce partage d'obstacles pair-à-pair est particulièrement précieux dans les opérations urbaines où plusieurs systèmes autonomes dégagent une structure et ont besoin de maintenir une image partagée des pièces dégagées et des menaces détectées sans dépendre d'une liaison de retour potentiellement dégradée vers le poste de commandement.