Przetwarzanie chmury punktów LiDAR na wojskowym skraju sieci: wykrywanie terenu 3D i przeszkód na wbudowanym sprzęcie

Obrotowy czujnik LiDAR z 32 kanałami generuje około 700 000 punktów na sekundę. Każdy punkt koduje precyzyjny pomiar zasięgu, kąt azymutu i elewacji oraz wartość intensywności odbicia. Z tego surowego strumienia danych wojskowa platforma autonomiczna musi wyprowadzić -- w czasie rzeczywistym i bez łączności -- nawigacyjną mapę terenu, zestaw detekcji przeszkód oraz skompresowaną reprezentację odpowiednią do transmisji przez ograniczone taktyczne łącze radiowe. To jest problem inżynierski przetwarzania chmury punktów LiDAR na wojskowym skraju sieci: ekstrakcja operacyjnie użytecznej trójwymiarowej świadomości sytuacyjnej z czujnika o wysokiej przepustowości na sprzęcie, który może być ograniczony do budżetu mocy 15 W, bez możliwości przeniesienia obliczeń do chmury i w obliczu wymagań czasowych autonomicznej nawigacji w czasie rzeczywistym.

Dlaczego przetwarzanie chmury punktów LiDAR na skraju sieci jest ważne dla wojskowej autonomii

Autonomiczne pojazdy naziemne, bezzałogowe systemy latające operujące poniżej osłony GPS w miejskich wąwozach oraz piesze platformy robotyczne mają tę samą fundamentalną zależność: potrzebują zrozumienia geometrii 3D otoczenia w czasie rzeczywistym, aby bezpiecznie nawigować i realizować swoje zadania. LiDAR jest preferowanym czujnikiem podstawowym do tego celu, ponieważ generuje metryczne pomiary zasięgu (typowo z dokładnością 1–3 cm przy zasięgach do 100 m), niezależne od warunków oświetlenia, niewymagające tekstury sceny do działania i degradujące się łagodnie w lekkim deszczu i kurzu. Kamerowe szacowanie głębokości może uzupełniać LiDAR, lecz nie może go zastąpić w zdegradowanych warunkach wizualnych, które są powszechne w wojskowych środowiskach operacyjnych.

Ograniczenie skraju sieci nie jest wyborem -- jest fizycznym i operacyjnym wymogiem. Surowe dane chmury punktów z obrotowego czujnika 32-kanałowego przy 10 Hz generują około 20–40 MB/s, co znacznie przekracza przepustowość jakiegokolwiek praktycznego taktycznego łącza radiowego (typowo 512 kbit/s do 5 Mbit/s w konfiguracji MANET pod obciążeniem). Nawet gdyby łącze było dostępne, opóźnienie w obie strony do procesora w chmurze i z powrotem pochłonęłoby dziesiątki do setek milisekund -- o wiele za długo dla decyzji o unikaniu kolizji na poruszającym się pojeździe. Dla autonomicznego pojazdu naziemnego jadącego z prędkością 20 km/h 100 ms dodatkowego opóźnienia odpowiada 55 cm dodatkowego przejechanego dystansu przed reakcją systemu -- margines nieakceptowalny w pobliżu przeszkód. Przetwarzanie na platformie nie jest opcjonalną funkcją; jest twardym wymogiem dotyczącym opóźnienia i przepustowości.

Wojskowe wdrożenia LiDAR na skraju sieci wymagają zatem algorytmów zarówno efektywnych obliczeniowo, jak i odpornych na zdegradowane warunki operacji polowej: wibracje, przechyły czujnika, częściowe przesłonięcie przez roślinność i brak wyraźnych cech strukturalnych (ścian, sufitów, podłóg), od których zależą systemy SLAM LiDAR w pomieszczeniach. Algorytmy omówione w tym artykule zostały wybrane ze względu na udowodnioną wydajność w niezorganizowanym terenie zewnętrznym.

SLAM do mapowania terenu: budowanie map 3D w czasie rzeczywistym z mobilnych platform

Jednoczesna lokalizacja i mapowanie (SLAM) jest algorytmicznym kręgosłupem mapowania terenu opartego na LiDAR w środowiskach z odmową GPS lub degradacją GPS. System SLAM LiDAR utrzymuje dwa wzajemnie oddziałujące estymaty: aktualną pozę platformy (pozycja i orientacja w przestrzeni 3D) oraz mapę otoczenia skumulowaną ze wszystkich poprzednich skanów. Każdy nowy skan z LiDAR jest dopasowywany do poprzedniego skanu lub lokalnej podmapy, aby obliczyć przyrostowy ruch platformy, który aktualizuje estymację pozy. Skan otagowany pozą jest następnie integrowany z rosnącą mapą, budując trójwymiarową reprezentację chmury punktów terenu, po którym platforma przemierza.

Najszerzej stosowane algorytmy SLAM LiDAR dla wojskowych platform zewnętrznych to LOAM (LiDAR Odometry and Mapping), LIO-SAM (LiDAR-Inertial Odometry via Smoothing and Mapping) i KISS-ICP (Keep it Small and Simple ICP). LOAM ekstrahuje cechy krawędziowe i płaszczyznowe z każdego skanu i dopasowuje je między klatkami, osiągając niski dryf na zorganizowanym terenie, lecz wymagając stosunkowo mocnych procesorów do utrzymania przepustowości 10 Hz. LIO-SAM ściśle łączy dopasowanie skanów LiDAR z danymi z inercyjnej jednostki pomiarowej (IMU) za pomocą backendu optymalizacji grafu czynnikowego, zapewniając solidną odometrię na platformach poddanych wibracjom i szybkim zmianom orientacji -- warunki, które pokonują czystą odometrię LiDAR. KISS-ICP redukuje algorytm do jego zasadniczego rdzenia ICP z dynamicznym progiem punkt-punkt, osiągając wydajność w czasie rzeczywistym na ARM Cortex-A55 kosztem nieco wyższego dryfu na terenie pozbawionym cech charakterystycznych.

Wykrywanie zamknięcia pętli to mechanizm zapobiegający nieograniczonemu narastaniu dryfu SLAM. Gdy platforma powraca do wcześniej odwiedzonej lokalizacji, optimizer back-endowy wykrywa nakładanie się między bieżącym skanem a przechowywaną podmapą, dodaje ograniczenie zamknięcia pętli do grafu pozycji i ponownie optymalizuje całą trajektorię. Dla wojskowych misji rozpoznawczych, gdzie pojazd bezzałogowy lub robot przemierza trasę i wraca, zamknięcie pętli redukuje finalny dryf mapy z potencjalnie kilku metrów (akumulacja otwartego ICP przez trasę 500 m) do centymetrów. Kompromisem jest koszt obliczeniowy: pełne wykrywanie zamknięcia pętli za pomocą deskryptorów kontekstu skanowania lub histogramu intensywności wymaga 50–200 ms na próbę detekcji, a krok optymalizacji grafu skaluje się super-liniowo z liczbą pozycji w grafie dla dużych środowisk.

Wykrywanie i klasyfikacja przeszkód na wbudowanym sprzęcie LiDAR

Mapowanie terenu i wykrywanie przeszkód to algorytmicznie odrębne zadania działające jednocześnie na tym samym strumieniu chmury punktów. Mapowanie terenu akumuluje skany w celu budowania trwałego modelu 3D; wykrywanie przeszkód przetwarza każdy skan niezależnie, identyfikując obiekty, których platforma musi unikać lub które mają znaczenie taktyczne. Standardowy potok zaczyna się od segmentacji płaszczyzny gruntu: oddzielenia punktów należących do przejezdnej nawierzchni od punktów reprezentujących obiekty naziemne. Dopasowanie płaszczyzny RANSAC (Random Sample Consensus) jest klasycznym podejściem, wybierając losowy podzbiór punktów, dopasowując model płaszczyzny i iterując do znalezienia największego zestawu elementów pasujących. W przypadku terenu zewnętrznego z nieplaskimi powierzchniami lepiej sprawdzają się progresywne filtry morfologiczne lub metody szacowania gruntu oparte na obrazie zasięgowym, adaptujące się do nachylenia i falistości.

Punkty naziemne są następnie grupowane w obszary kandydatów na przeszkody za pomocą klastrowania euklidesowego lub przestrzennego klastrowania opartego na gęstości (DBSCAN). Klastrowanie euklidesowe grupuje punkty w configurowalnym progu odległości w połączone składowe, z których każda reprezentuje odrębny obiekt. W typowych scenariuszach wojskowych na zewnątrz, klastrowanie przy progu odległości 0,5–1,0 m grupuje ciało osoby w jeden klaster, a pojazd w jeden lub kilka klastrów, rozdzielając jednocześnie poszczególne pnie drzew i krzewy. Każdy klaster jest następnie opisany przez jego prostokąt ograniczający (wymiary i orientację) oraz znormalizowany rozkład punktów, który jest podawany do sieci klasyfikacyjnej. PointNet i jego następca PointNet++ to standardowe architektury dla tego zadania: działają bezpośrednio na surowych współrzędnych (x, y, z) punktów klastra, stosują współdzielony MLP do każdego punktu w celu ekstrakcji cech per-punkt i agregują za pomocą globalnego max-pool w celu uzyskania osadzenia o stałym rozmiarze, niezmiennego względem kolejności punktów. Finalny klasyfikator MLP mapuje osadzenie na prawdopodobieństwa klasy obiektu.

Wdrożenie klasyfikatorów w stylu PointNet na sprzęcie wbudowanym wymaga tego samego przepływu kwantyzacji i optymalizacji, który stosuje się do opartego na obrazach wdrożenia modeli TensorFlow Lite na wbudowanym sprzęcie wojskowym. Kwantyzacja INT8 modelu PointNet zmniejsza przechowywanie parametrów z około 3,5 MB (FP32) do poniżej 1 MB, a opóźnienie wnioskowania na Jetson Orin NX spada z 18 ms do poniżej 5 ms na klaster. Ponieważ klastry są przetwarzane niezależnie, całkowite opóźnienie wykrywania przeszkód dla skanu z 20–30 klastrami naziemnymi wynosi typowo 50–100 ms na Jetson Orin NX -- dobrze mieszcząc się w budżecie end-to-end 200 ms dla wykrywania przeszkód przy częstotliwości skanowania 10 Hz.

Algorytmy próbkowania w dół: siatki vokseli, próbkowanie najdalszego punktu i wojskowe kompromisy

Surowe chmury punktów z obrotowego LiDAR 32-kanałowego zawierają 50 000–150 000 punktów na skan. Przetwarzanie każdego punktu przez algorytm SLAM lub potok wykrywania przeszkód jest obliczeniowo zbędne i często przeciwskuteczne: gęstość punktów na bliskim zasięgu jest znacznie wyższa niż potrzebna do któregokolwiek zadania, podczas gdy gęstość na dalekim zasięgu jest zbyt niska, aby dodawać istotne informacje poza tym, co uchwyli rzadsza reprezentacja. Próbkowanie w dół redukuje liczbę punktów do poziomu dostosowanego do wymagań przetwarzania, wymieniając rozdzielczość przestrzenną na efektywność obliczeniową.

Próbkowanie siatką vokseli jest najczęstszym podejściem we wdrożeniach wojskowych na skraju sieci. Przestrzeń 3D jest dzielona na regularną siatkę sześciennych vokseli, a wszystkie punkty w każdym vokselu są zastępowane ich centroidem. Parametr rozmiaru voksela bezpośrednio kontroluje kompromis rozdzielczość-obliczenia: rozmiar voksela 0,1 m redukuje skan 120 000 punktów do około 5 000–10 000 punktów dla typowych scen zewnętrznych, co stanowi redukcję 10–20-krotną, zachowując geometrię metryczną potrzebną dla SLAM. Rozmiar voksela 0,2 m redukuje do 2 000–4 000 punktów przy odpowiednim zmniejszeniu rozdzielczości mapy. Próbkowanie vokselami jest obliczeniowo trywialne (wyszukiwanie w tablicy haszującej na punkt) i działa w czasie poniżej 2 ms na procesorze ARM, co czyni je odpowiednim dla etapu wstępnego przetwarzania w czasie rzeczywistym zasilającego wszystkie dalsze algorytmy.

Próbkowanie najdalszego punktu (FPS) jest standardową metodą próbkowania w dół stosowaną jako przygotowanie wejścia dla klasyfikatorów w stylu PointNet. Dla klastra N punktów, FPS iteracyjnie wybiera punkt najdalszy od aktualnie wybranego zestawu, dopóki nie zostanie wybranych K punktów. Daje to przestrzennie jednolity próbkę, który zachowuje geometryczne rozmieszczenie klastra -- krytyczne dla PointNet, który opiera się na globalnej strukturze kształtu. Koszt obliczeniowy wynosi O(N * K), co jest akceptowalne dla małych klastrów (50–500 punktów) podawanych do klasyfikatora przeszkód, ale byłoby prohibicyjne dla próbkowania w dół pełnych surowych skanów. W praktyce próbkowanie vokselami obsługuje etap wstępnego przetwarzania pełnych skanów, a FPS obsługuje normalizację per-klaster bezpośrednio przed wnioskowania klasyfikatora.

Kompresja chmury punktów dla taktycznej transmisji przy ograniczonej przepustowości

Nawet po próbkowaniu vokselami, transmisja pełnych przetworzonych chmur punktów przez taktyczne łącze radiowe jest rzadko wykonalna. Próbkowany skan zewnętrzny przy rozdzielczości voksela 0,1 m z 5 000 punktami, z których każdy jest zakodowany jako trzy współrzędne FP32 i jedna wartość odbicia, zajmuje około 64 KB. Przy częstotliwości skanowania 10 Hz surowy strumień wynosi 640 KB/s -- przekraczając dostępną przepustowość większości konfiguracji MANET działających pod interferencjami. Praktycznym rozwiązaniem jest transmisja pochodnych produktów danych, a nie surowych lub próbkowanych chmur punktów: siatek zajętości, kafelków Numerycznego Modelu Terenu (DEM) i ustrukturyzowanych wiadomości detekcji przeszkód.

Siatka zajętości 2,5D koduje teren jako siatkę komórek, z których każda przechowuje wysokość najwyższego zwrotu LiDAR i flagę przejezdności. Dla obszaru 100 m x 100 m przy rozdzielczości 0,25 m siatka zawiera 160 000 komórek. Przechowywanie każdej komórki jako 16-bitowej liczby całkowitej ze znakiem dla wysokości plus jeden bit dla przejezdności i zastosowanie kompresji LZ4 redukuje kafelek 100 m do około 15–30 KB w zależności od złożoności terenu. Przy szybkości aktualizacji 1 Hz na kafelek, obciążenie strumieniowania mapy wynosi 15–30 KB/s -- zarządzalne nawet na silnie obciążonym łączu MANET. Przyjmująca platforma może zrekonstruować model terenu jakości planowania tras z tych kafelków bez otrzymania ani jednego surowego pakietu chmury punktów.

Zdarzenia detekcji przeszkód są jeszcze bardziej kompaktowe. Ustrukturyzowana wiadomość kodująca pozycję (3 FP32), klasę (1 bajt), prostokąt ograniczający (3 wymiary FP32 plus 1 FP32 yaw), współczynnik ufności (1 FP32), identyfikator śladu (4 bajty) i szacunek prędkości (3 FP32) zajmuje około 60 bajtów na przeszkodę. Transmisja 30 przeszkód na skan przy 10 Hz generuje strumień detekcji 18 KB/s -- pomijalny na jakimkolwiek praktycznym łączu. Przy budżetach łącza poniżej 64 kbit/s, transmisja tylko strumienia zdarzeń detekcji (z całkowitym wstrzymaniem aktualizacji kafelków map) zapewnia operatorowi odbierającemu świadomość przeszkód w czasie rzeczywistym przy mniej niż 25% dostępnej przepustowości łącza.

Platformy sprzętowe: wdrożenie z ograniczonym GPU na Jetson, FPGA i wojskowych SBC

NVIDIA Jetson AGX Orin jest aktualną referencją wydajnościową dla wojskowych obciążeń LiDAR na skraju sieci. Jego 2048-rdzeniowy GPU Ampere z 64 jednostkami Tensor Core dostarcza 275 TOPS przepustowości INT8 w konfigurowalnej kopercie TDP 15–60 W. Uruchomienie kompletnego potoku przetwarzania LiDAR -- próbkowanie vokselami, SLAM LIO-SAM, segmentacja gruntu, klastrowanie euklidesowe i klasyfikacja INT8 PointNet -- na czujniku 32-kanałowym przy 10 Hz zużywa około 8–12 W na Jetson AGX Orin, pozostawiając margines dla sterowników komunikacyjnych, oprogramowania misji i narzutu systemowego w budżecie mocy platformy 20 W. Dla platform z mniej hojnymi alokacjami mocy, Jetson Orin NX (10–25 W) obsługuje ten sam potok przy 10 Hz, jeśli optymalizacja back-endu SLAM jest ograniczona do 5 Hz, a Orin Nano (5–15 W) wystarczy dla prostszych obciążeń pomijających pełny SLAM na rzecz tylko odometrii skan-do-skanu.

Platformy FPGA pełnią odmienną rolę w łańcuchu przetwarzania LiDAR. Operacje front-end -- pobieranie chmury punktów z portu Ethernet czujnika, haszowanie siatki vokseli, RANSAC płaszczyzny gruntu i generowanie obrazu zasięgowego -- mają deterministyczne wymagania opóźnienia i korzystają z potokowego paralelizmu oferowanego przez FPGA. Xilinx Zynq UltraScale+ MPSoC uruchamiający próbkowanie vokselami i segmentację gruntu w logice programowalnej może dostarczyć opóźnienie poniżej milisekunda z gwarantowaną przepustowością, zasilając próbkowaną, pozbawioną gruntu chmurę do podsystemu CPU ARM dla SLAM i do GPU dla klasyfikacji. Ta heterogeniczna architektura -- FPGA dla wstępnego przetwarzania front-end, GPU dla klasyfikacji opartej na uczeniu, CPU dla back-endu SLAM -- jest coraz bardziej standardem w wysokowydajnych wojskowych programach bezzałogowych pojazdów naziemnych. Wojskowe komputery jednopłytowe certyfikowane do MIL-STD-810G dla wstrząsów i wibracji oraz do standardów TEMPEST w zakresie kontroli emisji zazwyczaj integrują wielordzeniowy procesor ARM z gniazdem PCIe, które akceptuje moduł Jetson system-on-module lub moduł FPGA Xilinx w zależności od wymagań programu dotyczących opóźnienia i certyfikacji.

Zarządzanie ciepłem to praktyczne ograniczenie, które zespoły programistyczne często niedoceniają podczas integracji przetwarzania LiDAR z platformą wojskową. Jetson AGX Orin przy TDP 60 W wytwarza 60 W ciepła, które musi być odprowadzone z modułu w szczelnej obudowie wojskowej. Pasywne rozwiązania chłodzące wykorzystujące rury cieplne i zewnętrzne żebra są wykonalne do około 30 W ciągłego obciążenia; powyżej tego zazwyczaj wymagana jest pompowana pętla chłodzenia cieczą. Ustawienie TDP Jetsona na 15–20 W za pomocą konfiguracji trybu zasilania nvpmodel spełnia większość budżetów chłodzenia pasywnego, zapewniając jednocześnie wystarczającą przepustowość dla potoku LiDAR 32-kanałowego. Ograniczenia termiczne wpływają na wszystkie wojskowe wdrożenia wnioskowania brzegowego, nie tylko na przetwarzanie LiDAR, a budżetowanie termiczne powinno być częścią projektowania platformy od pierwszej iteracji sprzętowej, a nie być traktowane jako problem integracji na późnym etapie.

Integracja z systemami autonomicznymi i śledzeniem sił własnych dla świadomości sytuacyjnej

Potok przetwarzania LiDAR działający w izolacji -- generujący mapy terenu i detekcje przeszkód konsumowane wyłącznie przez własny stos nawigacyjny platformy -- zapewnia lokalną autonomię, ale nie wspólną świadomość sytuacyjną. Wartość operacyjna mnoży się, gdy pochodne produkty danych z każdej platformy autonomicznej są współdzielone w sieci taktycznej i łączone w wspólny obraz operacyjny, dostępny dla każdego operatora, dowódcy i podłączonego systemu. Architektura integracji wymaga trzech elementów: georeferencyjonowanego formatu danych dla produktów mapowych, ustrukturyzowanego formatu wiadomości dla zdarzeń detekcji oraz oprogramowania pośredniczącego publikuj-subskrybuj, które dostarcza oboje do konsumentów z odpowiednią szybkością aktualizacji i priorytetem.

Kafelki map terenu z każdej platformy autonomicznej są georeferencyjonowane przy użyciu aktualnej pozycji szacowanej przez SLAM i orientacji platformy, połączonej z dostępną pozycją GPS. Kafelek jest rzutowany do globalnego układu współrzędnych (siatka UTM lub MGRS) i otagowany identyfikatorem śledzenia sił własnych platformy generującej oraz znacznikiem czasu. Warstwa danych geoprzestrzennych serwera TAK akceptuje te kafelki jako załączniki pakietu misji lub jako nakładki geometrii wektorowej, czyniąc je widocznymi dla każdego połączonego klienta ATAK jako warstwa mapy na żywo aktualizowaną w miarę postępu platformy autonomicznej. Operatorzy widzą strukturę terenu obszarów rozpoznawanych przez systemy autonomiczne w trakcie ich przemierzania, zamiast czekać na zrzut danych po misji.

Detekcje przeszkód z klasyfikatora LiDAR są publikowane jako zdarzenia CoT do serwera TAK, zgodnie z tym samym wzorcem integracji co AI detekcji strzałów akustycznych i innych systemów sensorów brzegowych. Zdarzenie CoT zawiera klasę przeszkody (pojazd, osoba, budowla), wymiary i orientację prostokąta ograniczającego, współczynnik ufności oraz szacunek prędkości z filtra śledzenia. Platformy autonomiczne w zasięgu komunikacji wzajemnej mogą również wymieniać zdarzenia detekcji w trybie peer-to-peer, umożliwiając utrzymanie wspólnej mapy przeszkód w całej flocie bez konieczności centralnego serwera. To wzajemne udostępnianie przeszkód peer-to-peer jest szczególnie cenne w operacjach miejskich, gdzie wiele systemów autonomicznych oczyszcza budynek i musi utrzymywać wspólny obraz oczyszczonych pomieszczeń i wykrytych zagrożeń bez polegania na potencjalnie zdegradowanym łączu zwrotnym do stanowiska dowodzenia.