Mapowanie lidarowe UAV zaczyna się od surowych returnów i trajektorii sensora, a kończy produktem o znanym układzie odniesienia, niepewności i kompletności. Sama wizualizacja gęstej chmury nie dowodzi poprawnego mapowania. Ściany mogą być podwójne wskutek błędu czasu, pasy przesunięte przez boresight, wysokość obciążona niezgodnym datum, a efektowne wygładzenie może usunąć cienkie przewody i gałęzie.
Trzeba rozróżnić mapę nawigacyjną czasu rzeczywistego od produktu pomiarowego. Pierwsza preferuje świeżość, ograniczoną pamięć i konserwatywne free/occupied. Drugi wymaga georeferencji, udokumentowanej kalibracji, zachowania atrybutów punktów, wyrównania pasów i niezależnej kontroli dokładności. Ten sam lidar może zasilać oba tory, ale ich kryteria odbioru są inne.
Spis treści#
- Dwa różne produkty
- Łańcuch danych
- Surowy punkt i jego atrybuty
- Czas każdego punktu
- Deskew
- Układy i transformacje
- Lever arm i boresight
- Direct georeferencing GNSS INS
- Georeferencja przez SLAM
- Interpolacja trajektorii
- Filtracja przed rejestracją
- Rejestracja lokalna ICP
- Multiway registration i pose graph
- Strip adjustment
- Gęstość i geometria nalotu
- Intensywność i returny
- Klasyfikacja gruntu
- Modele pochodne
- Format LAS i LAZ
- CRS i vertical datum
- Jakość i niepewność
- Wykrywanie błędów systematycznych
- Plan misji
- Przetwarzanie czasu rzeczywistego
- Logowanie i reprodukowalność
- Walidacja terenowa
- Kryteria odbioru
- Typowe błędy
- Powiązane tematy
- Przypisy
Dwa różne produkty#
Mapa nawigacyjna#
Służy lokalizacji, omijaniu przeszkód i planowaniu. Najważniejsze są:
- opóźnienie oraz age mapy;
- jawne free, occupied i unknown;
- konserwatywne zachowanie cienkich przeszkód;
- ograniczony koszt pamięci;
- ciągłość układu
odom; - reakcja na dynamiczne obiekty;
- status zdrowia i resetów.
Chmura może być rzadsza i mniej dokładna globalnie, jeśli lokalny clearance jest wiarygodny.
Produkt pomiarowy#
Służy inwentaryzacji, modelowi terenu, kubaturom lub porównaniu epok. Wymaga:
- określonego CRS i vertical datum;
- udokumentowanej dokładności bezwzględnej oraz względnej;
- kalibracji lever arm, boresight i czasu;
- kontroli między pasami;
- zachowania klasyfikacji, return number i innych atrybutów;
- metadanych misji oraz wersji przetwarzania;
- niezależnych punktów kontrolnych.
SLAM może stworzyć bardzo spójną mapę lokalną, lecz bez anchorów nie gwarantuje geodezyjnego położenia. RTK GNSS/INS może zapewnić georeferencję, ale błędny boresight nadal tworzy różnice między pasami.
Łańcuch danych#
Kompletny pipeline:
laser returns + per-point time + status
IMU samples + GNSS observations + clocks
calibration: intrinsics + lever arm + boresight + time offset
↓
trajectory estimation / smoothing
↓
deskew and sensor→body→navigation transform
↓
local registration / strip adjustment / pose graph
↓
filtering + classification + products
↓
LAS/LAZ + CRS + metadata + QA report
Każdy etap powinien zachować możliwość powrotu do wejścia. Jeżeli zapisano wyłącznie końcowe XYZ, nie da się ponownie wykonać deskew po wykryciu błędu zegara ani zmienić georeferencji bez utraty informacji.
Minimalny zestaw archiwalny obejmuje surowe pakiety lidaru, raw IMU/GNSS, mapę czasów, kalibrację, konfigurację sterowników, plik trajektorii i log jakości.
Surowy punkt i jego atrybuty#
Punkt to więcej niż x,y,z. Może zawierać:
sensor xyz or range/azimuth/elevation
timestamp or relative time
channel/ring
return number / number of returns
intensity or reflectivity
quality/status/confidence
sensor id
scan/frame/packet id
Odrzucenie atrybutów na wejściu utrudnia późniejszą filtrację. Ring pomaga analizować błąd kanału; intensity może ujawnić zależność biasu od reflektancji; status pozwala odróżnić brak echa od ważnego maksymalnego zasięgu.
Współrzędne producenta muszą mieć definicję osi i jednostek. Nie wolno zakładać, że każdy driver publikuje ROS FLU albo body FRD. Test polega na ustawieniu znanego celu kolejno na dodatnich osiach oraz sprawdzeniu azymutu, elewacji i znaku.
Wiele urządzeń stosuje niepowtarzalny wzór skanowania zamiast regularnych pierścieni. Algorytm oczekujący ring i stałej liczby punktów na obrót może nie pasować do solid-state lidar.
Czas każdego punktu#
Podczas jednego skanu UAV przesuwa się i obraca. Timestamp pakietu nie opisuje wszystkich punktów. Dla punktu i potrzebny jest czas:
t_i = t_packet_reference + delta_t_i + clock_offset(t_i)
delta_t_i wynika z kolejności emisji/odbioru, a clock offset z synchronizacji sensora z czasem trajektorii. Dokumentacja Livox opisuje pola czasu i tryby synchronizacji; dokładna interpretacja zależy od modelu i protokołu.
Typowe zegary:
- licznik wewnętrzny od startu;
- UTC/GPS time;
- PTP/IEEE 1588;
- PPS + komunikat czasu;
- timestamp hosta przy odebraniu pakietu.
Timestamp hosta obejmuje buforowanie sieci i scheduler. Może być wystarczający do wizualizacji statycznej, ale nie do precyzyjnej mapy dynamicznej. Offset stały powoduje błąd zależny od prędkości; drift powoduje zmianę błędu w czasie.
Test synchronizacji powinien wykreślać różnicę zegarów, jitter, utracone pakiety oraz residual mapy w funkcji przesunięcia czasu.
Deskew#
Deskew przelicza każdy punkt z pozy sensora w t_i do wspólnej pozy referencyjnej t_ref:
p_ref = T_ref_sensor^-1 · T_sensor(t_i) · p_i
Bez deskew pionowa ściana może stać się falą, słup elipsą, a krawędzie podwójne. Efekt rośnie z prędkością kątową, liniową i czasem skanu.
Trajectory do deskew może pochodzić z:
- integracji IMU z korekcją GNSS;
- LIO/SLAM;
- odometrii autopilota;
- wygładzonej trajektorii post-processingu.
Interpolacja tylko pozycji liniowo i Eulerów osobno jest ryzykowna. Orientację interpoluje się na SO(3), np. przez slerp dla krótkiego przedziału, a wysokodokładny post-processing może użyć spline trajectory.
Deskew nie powinien używać trajektorii obliczonej z już źle zdeformowanej chmury bez iteracji. LIO-SAM używa IMU do deskew, następnie lidar update poprawia stan. W post-processingu można powtórzyć deskew po wygładzeniu całej trajektorii.
Układy i transformacje#
Występują:
- lidar frame
L; - IMU/body frame
B; - antenna frame
G; - local navigation NED/ENU;
- ECEF;
- projected map CRS;
- ewentualny
mapiodomSLAM.
Punkt globalny:
p_N = p_B^N(t) + R_B^N(t) [r_BL + R_L^B p_L]
gdzie r_BL jest położeniem początku lidaru względem body, a R_L^B obraca osie lidaru do body. Konwencję trzeba zapisać słowami: „macierz przekształca współrzędne punktu z L do B”. Sam symbol R_BL jest dwuznaczny między bibliotekami.
Transformacja GNSS antenna→IMU również wymaga lever arm. Estymator może raportować pozycję anteny lub IMU; brak wiedzy o punkcie odniesienia przenosi offset do całej chmury.
Lever arm i boresight#
Lever arm to translacja między sensorami. Boresight to mała rotacja rzeczywistego układu lidaru względem body/IMU. Obie są parametrami kalibracji, nie wymiarami „na oko”.
Wpływ błędu boresight rośnie z odległością:
delta ≈ R · delta_theta
Błąd 0,1° daje około 1,7 cm na 10 m i 8,7 cm na 50 m. Na zachodzących pasach może pojawić się systematyczne rozwarcie zależne od kierunku lotu.
Lever arm error ujawnia się przy zmianie attitude. Jeśli lidar jest daleko od IMU, obrót tworzy rzeczywiste przesunięcie jego origin. Ignorowanie omega × r i transformacji pozy prowadzi do zależności mapy od manewru.
Kalibrację wykonuje się na scenie z płaszczyznami o różnych orientacjach i pasach w przeciwnych kierunkach. Jedna płaska powierzchnia nie obserwuje wszystkich kątów. Parametry powinny mieć covariance, temperaturę i identyfikator montażu.
Direct georeferencing GNSS INS#
Direct georeferencing używa trajektorii GNSS/INS bez dopasowania każdego pasa do ground control. Typowy stan obejmuje pozycję, prędkość, attitude i biasy IMU. RTK/PPK poprawia pozycję, lecz attitude wymaga IMU, dynamiki i czasem wieloantenowego heading.
Łańcuch błędów:
GNSS position error
+ attitude error × range
+ lever arm/boresight error
+ timing error × motion
+ lidar range/angular error
→ point error
Przykład przybliżony dla komponentu poprzecznego:
sigma_point² ≈ sigma_position²
+ R² sigma_angle²
+ v² sigma_time²
+ sigma_range²
To nie jest pełny model covariance, ale pokazuje, że centymetrowy GNSS nie gwarantuje centymetrowej chmury przy słabym attitude lub czasie.
PPK może wykorzystać dane po locie i wygładzenie forward/backward. Wynik powinien zawierać status rozwiązania GNSS, covariance, liczbę satelitów, baseline do stacji i przerwy. Punkty z okresów float/single nie powinny być niezauważalnie mieszane z fixed.
Georeferencja przez SLAM#
Lidar SLAM estymuje spójną trajektorię z geometrii. LOAM rozdziela szybki tor odometrii i wolniejsze mapowanie; LIO-SAM łączy lidar, IMU i opcjonalne czynniki GNSS/loop closure w grafie.
Zalety:
- praca w GNSS-denied;
- poprawa lokalnej spójności pasów;
- deskew i trajectory w układzie lokalnym;
- loop closure redukujący dryf.
Ograniczenia:
- gauge i brak absolutnego CRS bez anchorów;
- degeneracja w tunelu, nad płaszczyzną lub przy małej geometrii;
- globalne skoki po loop closure;
- możliwość fałszywego dopasowania;
- deformacja skali/heading zależnie od systemu.
Do produktu geodezyjnego SLAM zwykle wiąże się z GCP/GNSS i kontroluje niezależnymi punktami. Dopasowanie końcowej chmury do kilku control points nie ujawnia lokalnego rozciągnięcia między nimi.
Interpolacja trajektorii#
Trajectory ma rzadsze stany niż punkty. Potrzebna jest interpolacja T(t). Minimalne wymagania:
- monotoniczny czas;
- brak interpolacji przez nieoznaczoną przerwę;
- orientacja na grupie obrotów;
- zgodność pozycji i prędkości;
- jawne zachowanie poza zakresem.
Ekstrapolacja przed pierwszym lub po ostatnim stanie może dać punkty pozornie poprawne. Pipeline powinien oznaczyć je invalid albo mieć bounded prediction z covariance.
Spline continuous-time jest użyteczny dla asynchronous sensors i rolling scan, ale knot spacing oraz regularization muszą odzwierciedlać dynamikę. Zbyt gładki spline usuwa rzeczywisty manewr; zbyt elastyczny dopasowuje szum.
Filtracja przed rejestracją#
Filtracja ma zachować geometrię potrzebną do alignment. Typowe kroki:
- usunięcie punktów ze statusem invalid;
- ograniczenie min/max range;
- filtrowanie według confidence/intensity tylko po kwalifikacji;
- voxel downsampling;
- statistical/radius outlier removal;
- maska kadłuba i śmigieł;
- deskew;
- opcjonalne normals/features.
Voxel size powinien być związany z szumem i wymaganą rozdzielczością. Downsampling przed zachowaniem raw archive jest nieodwracalny. Filtr radius może usunąć przewody i gałęzie — dokładnie te elementy, które są ważne dla safety.
Dynamiczne obiekty pogarszają rejestrację. Można stosować robust kernels, temporal consistency albo semantic masking. Nie należy jednak usuwać obiektu z produktu pomiarowego tylko dlatego, że nie pasuje do statycznej mapy; powinien mieć osobną klasę/status.
Rejestracja lokalna ICP#
ICP iteracyjnie dobiera korespondencje i minimalizuje residual. Point-to-point:
E(T) = sum ||p_i - T q_i||²
Point-to-plane:
E(T) = sum [n_i^T (p_i - T q_i)]²
Open3D dokumentuje oba warianty, fitness i inlier RMSE. Wysoki fitness oraz niski RMSE nie dowodzą globalnie poprawnego alignment: optimizer może zbiec do sąsiedniej identycznej fasady.
ICP wymaga initial guess i overlap. Parametry:
- max correspondence distance;
- voxel scale;
- normals radius;
- robust loss;
- liczba iteracji i convergence;
- odrzucanie krawędzi/dynamic points;
- minimalny overlap.
Information matrix/Hessian powinna ujawnić degenerację. Na jednej płaszczyźnie część ruchów jest słabo ograniczona. Taki wynik nie może otrzymać sztywnej izotropowej wagi w pose graph.
Multiway registration i pose graph#
Wiele fragmentów łączy pose graph. Krawędzie są dwóch klas:
- odometry edges między sąsiednimi fragmentami;
- loop/overlap edges między dalszymi fragmentami.
Open3D rozróżnia krawędzie pewne i niepewne oraz przypisuje information matrix. Pairwise false alignments mogą być liczne, dlatego global registration i geometric verification poprzedzają optymalizację.
Pose graph koryguje pozy fragmentów. Jeśli punkty zostały scalone w jeden plik bez identyfikatora fragmentu, aktualizacja wymaga ponownego przetworzenia. Warto zachować point→scan→keyframe/submap.
Po optymalizacji trzeba sprawdzić nie tylko globalny cost, ale residual każdego overlap, zmianę trajectory, control points i czy nie pojawiły się lokalne foldy.
Strip adjustment#
Nalot pomiarowy składa się z pasów zachodzących. Strip adjustment minimalizuje różnice między powierzchniami, czasem estymując poprawki trajektorii, boresight lub offsety pasa.
Kontrola overlap powinna analizować:
- signed distance na płaskich dachach/ziemi;
- różnice wysokości w siatce;
- fasady z przeciwnych kierunków;
- residual w funkcji scan angle;
- residual w funkcji czasu i temperatury;
- osobno pasy cross-flight.
Wzory błędów:
| Wzór | Podejrzenie |
|---|---|
| stały offset XYZ | datum/lever arm/translation |
| różnica zmienia znak z kierunkiem | boresight lub timing |
| rośnie z range | angle error |
| rośnie w czasie | clock drift/thermal |
| zakrzywienie w skanie | brak deskew |
| lokalne dopasowanie, globalny dryf | trajectory/SLAM anchors |
Nie należy dopasowywać każdego pasa niezależnie do poprzedniego bez kontroli globalnej; błąd łańcuchowy może przesuwać końcowy obszar.
Gęstość i geometria nalotu#
Nominalna liczba punktów na sekundę nie jest gęstością gruntu. Zależy od wysokości, prędkości, wzoru skanu, FOV, scan rate, overlap i odrzuceń.
Przybliżona gęstość:
density ≈ valid_points_over_area / mapped_area
lecz musi być raportowana także jako rozkład/percentyle. Średnia może ukryć dziury.
Plan misji powinien zapewnić:
- overlap wzdłuż i między pasami;
- pasy cross-flight do kalibracji;
- kąty widzenia fasad, jeśli wymagane;
- prędkość zgodną z deskew i gęstością;
- margines GNSS/łączności;
- przeloty nad control surfaces;
- unikanie długiej stałej geometrii degeneracyjnej.
Niski lot zwiększa gęstość, ale zmniejsza footprint i może wymagać więcej pasów. Wysoki lot zwiększa range error, spot size i wpływ angle error.
Intensywność i returny#
Intensity nie jest automatycznie skalibrowaną reflektancją. Zależy od range, kąta, gain, kanału, temperatury i firmware. Porównanie epok wymaga radiometric calibration lub przynajmniej stałej konfiguracji.
Multiple returns mogą opisywać koronę, gałęzie i grunt. Pola return number i number of returns są potrzebne klasyfikacji. First return często reprezentuje najwyższą powierzchnię, last return może docierać niżej, lecz nie zawsze jest gruntem.
Filtr „zostaw tylko strongest return” upraszcza chmurę i usuwa informację pionową. Decyzja zależy od produktu. Do DTM ważne są returny docierające do gruntu; do obstacle map ważny może być pierwszy cienki obiekt.
Klasyfikacja gruntu#
Ground classification oddziela teren od roślinności, budynków i obiektów. Algorytmy korzystają z lokalnej slope, progresywnego zagęszczania TIN, filtrów morfologicznych lub modeli uczonych.
Pułapki:
- stromy stok może zostać uznany za budynek;
- dach o małym nachyleniu za teren;
- niski krzew za ground;
- most tworzy dwie powierzchnie;
- skarpa zostaje wygładzona;
- dziury w wodzie interpolowane jako teren.
Klasyfikacja jest hipotezą i powinna zachować confidence. DTM nie może być walidowany tylko przez wizualną gładkość. Potrzebne są punkty kontrolne w różnych klasach terenu.
Modele pochodne#
Z chmury tworzy się:
- DSM — najwyższa/obserwowana powierzchnia;
- DTM — model gruntu po klasyfikacji;
- nDSM — różnica DSM–DTM;
- CHM — canopy height model;
- mesh;
- contours/slope/aspect;
- przekroje i kubatury;
- occupancy/TSDF/ESDF dla nawigacji.
Rozdzielczość rastra powinna odpowiadać spacing i dokładności, nie być arbitralnie mniejsza. Raster 1 cm z punktów co 20 cm zawiera interpolowane piksele, a nie centymetrową informację.
Każdy model dziedziczy błędy georeferencji, klasyfikacji i interpolacji. Raport powinien wskazywać source point classes, cell statistic, nodata policy i uncertainty.
Format LAS i LAZ#
LAS jest standardowym formatem wymiany danych lidarowych; LAZ jest jego bezstratnie skompresowaną postacią używaną przez wiele narzędzi. Specyfikacja LAS 1.4 definiuje nagłówek, point data records, scale/offset, klasyfikacje, returny, GPS time i dodatkowe rekordy.
Ważne pola:
- wersja LAS i point format;
- scale factors i offsets;
- bounding box;
- point source ID;
- return number;
- classification + flags;
- intensity;
- scan angle;
- GPS time;
- RGB/NIR, jeśli dostępne;
- CRS w VLR/EVLR;
- extra bytes dla własnych atrybutów.
XYZ w LAS są przechowywane jako liczby całkowite przeskalowane. Zbyt duży scale traci rozdzielczość; zbyt mały przy złym offset może przekroczyć zakres. Nie należy wybierać scale na podstawie liczby miejsc po przecinku bez odniesienia do accuracy.
Eksport do prostego PLY/XYZ może usunąć returny, klasy i CRS. Jest użyteczny do wizualizacji, nie jako jedyny master.
CRS i vertical datum#
Chmura musi określać:
horizontal CRS + epoch if relevant
vertical datum/geoid model
units
axis order
geoid/ellipsoid transformation version
projected grid and scale effects
GNSS naturalnie dostarcza ECEF/ellipsoidal height. Produkt może wymagać wysokości ortometrycznej. Transformacja przez model geoidy musi być udokumentowana.
Lokalny ENU/NED jest dobry obliczeniowo, ale eksport do projected CRS wymaga kontrolowanej transformacji. Dla dużego obszaru jedna płaska local tangent plane może mieć zauważalne różnice względem grid.
Nie wolno wywnioskować CRS z zakresu liczb. Plik o x≈500000 może pasować do wielu stref. Brak metadanych oznacza nieweryfikowalny produkt.
Jakość i niepewność#
Osobno raportuje się:
- relative accuracy — zgodność sąsiednich pasów i lokalnej geometrii;
- absolute accuracy — zgodność z niezależnym układem odniesienia;
- precision/noise — rozrzut na powierzchni;
- completeness — pokrycie i dziury;
- density — rozkład punktów;
- classification quality — precision/recall klas.
Metryki:
signed mean error
RMSE
median and NMAD
95th percentile absolute error
strip-to-strip plane residual
point density percentiles
void fraction
RMSE jest wrażliwy na outliery, median nie pokazuje biasu. Raport powinien zawierać kilka miar i mapę przestrzenną residuali.
Control points/surfaces muszą być niezależne od adjustment. Punkt użyty do dopasowania nie jest check pointem. Rozmieszczenie tylko przy starcie nie testuje dryfu na końcu trasy.
Wykrywanie błędów systematycznych#
Błąd czasu#
Przesunięcie wzdłuż kierunku ruchu, zmiana znaku przy przeciwnym kierunku, wzrost z prędkością. Testuje się sweep offsetu i residual.
Boresight roll#
Różnica wysokości rośnie z poprzeczną odległością od osi skanu, często ma przeciwny wzór na pasach.
Boresight pitch#
Błąd wzdłuż kierunku lotu i range, zależny od kierunku.
Heading/yaw#
Poprzeczne rozwarcie fasad i krawędzi rośnie z odległością.
Lever arm#
Offset zależny od attitude i manewrów, szczególnie na zakrętach.
Range bias#
Przesunięcie wzdłuż wiązki zależne od kanału, temperatury, intensity lub odległości.
Vertical datum#
Duży, przestrzennie wolnozmienny offset przy poprawnej zgodności pasów.
Automatyczna rejestracja może ukryć te błędy w finalnej chmurze, ale parametry pozostają złe i problem wróci w innej geometrii. Najpierw identyfikuje się przyczynę, potem stosuje residual adjustment.
Plan misji#
Przed lotem definiuje się:
- produkt i required accuracy;
- expected reflectance/vegetation;
- wysokość, speed i scan geometry;
- overlap i cross strips;
- GNSS satellite visibility oraz base data;
- control/check points;
- czas i pojemność storage;
- thermal warm-up;
- maksymalne roll/pitch/yaw rate;
- pogodę: mgła, deszcz, pył, wiatr;
- procedurę po utracie RTK/IMU/lidaru.
Budżet danych:
bytes_per_point × point_rate × flight_time
+ packet/log overhead
+ duplicate raw streams
Pamięć musi mieć margines i monitorowanie write latency. Utrata fragmentu pliku bez alarmu tworzy dziurę w produkcie.
Pasy cross-flight i powierzchnie pionowe zwiększają obserwowalność boresight. Sam równoległy nalot nad płaskim polem może wyglądać dobrze mimo błędnych kątów.
Przetwarzanie czasu rzeczywistego#
On-board mapping wymaga priorytetów:
- ingest i zapis surowych pakietów;
- synchronizacja/trajectory/deskew;
- local obstacle map;
- lokalizacja LIO;
- global map/loop closure;
- wizualizacja i transmisja decimated cloud.
Telemetria nie powinna próbować przesyłać pełnej chmury kosztem logowania. Wysyła się preview/tiles/statystyki, zachowując master lokalnie.
Kolejki są ograniczone. Dla nawigacji stara chmura jest gorsza niż brak nowej; dla produktu pomiarowego nie wolno jej po cichu porzucić. Te dwa tory potrzebują osobnych polityk i liczników.
Thermal throttling może zwiększyć latency deskew i mapy. Monitoruje się CPU/GPU, pamięć, temperaturę, packet loss, disk throughput oraz end-to-end age.
Logowanie i reprodukowalność#
Manifest misji powinien zawierać:
vehicle/payload/sensor serials
firmware and driver versions
calibration hashes
clock mode and sync status
CRS/datum/geoid
GNSS base/RINEX source
flight plan and actual trajectory
weather and surface notes
raw file checksums
processing software/container/config hash
QA results and exclusions
Każdy punkt finalny powinien być możliwy do powiązania z source file/flight/strip. point_source_id lub extra attribute ułatwia traceability.
Pipeline powinien być deterministycznie uruchamialny albo raportować nondeterminism. Ręczna edycja w GUI musi tworzyć zapis operacji, nie tylko nowy plik bez historii.
Walidacja terenowa#
Stanowisko statyczne#
Cele o znanych odległościach, jasne/ciemne, różne kąty i temperatury. Mierzy range bias, noise, kanały, intensity i strefę martwą.
Kalibracja dynamiczna#
Płaszczyzny poziome/pionowe, loty w przeciwnych kierunkach, różne wysokości i prędkości. Estymuje czas, boresight i lever arm oraz sprawdza korelacje.
Nalot testowy#
Pasy równoległe i cross, independent check surfaces, obiekty cienkie, roślinność, dachy i slope. Przetwarzanie bez oraz z adjustment pokazuje wielkość korekty.
Replay i fault injection#
Sztuczny offset czasu, błędny boresight, drop packets, GNSS outage, IMU bias, reset zegara i zła geoid. Walidator powinien wykryć pogorszenie lub oznaczyć dane.
Kontrola produktu#
Automatyczna: header LAS, bounds, CRS, point counts, returns, klas, invalid values, time monotonicity i spatial tiles. Geometryczna: check points, strip residuals, density/void i cross-sections.
Kryteria odbioru#
- Surowe punkty zachowują timestamp, status, kanał, return i intensity.
- Zegary mają zmierzony offset, drift i jitter.
- Deskew używa czasu każdego punktu i zweryfikowanej trajectory.
- Wszystkie transformacje mają kierunek, jednostki i frame IDs.
- Lever arm i boresight mają raport kalibracji oraz uncertainty.
- GNSS/INS solution status jest zachowany per interval.
- SLAM degeneracy i loop resets są oznaczone.
- Local registration raportuje overlap, fitness, RMSE i conditioning.
- Strip adjustment nie wykorzystuje check points jako constraints.
- Pasy cross-flight przechodzą limit residualu.
- CRS i vertical datum są jawne i osadzone w produkcie/metadanych.
- LAS point format zachowuje potrzebne atrybuty.
- Scale/offset LAS nie tracą wymaganej rozdzielczości ani zakresu.
- Density i void fraction spełniają wymaganie w całym obszarze, nie tylko średnio.
- Absolute i relative accuracy są raportowane osobno.
- Klasyfikacja ma próbkę kontrolną i confusion metrics.
- Raw data, manifest i pipeline pozwalają odtworzyć wynik.
- Fault injection wykrywa timing, calibration i GNSS failures.
Typowe błędy#
- Georeferencja całego pakietu jednym timestampem.
- Brak deskew podczas ruchu.
- Timestamp hosta traktowany jako czas emisji.
- Zamiana kierunku transformacji lidar–IMU.
- Lever arm zmierzony do obudowy zamiast sensor origin.
- Boresight ustawiony „na poziomicę” bez kalibracji pasów.
- Uznanie RTK fixed za gwarancję dokładnej chmury.
- ICP bez dobrego initial guess i testu conditioning.
- Użycie fitness jako jedynego kryterium poprawności.
- Sklejenie punktów przed zachowaniem fragmentów/pose graph.
- Adjustment ukrywający przyczynę błędu czasu.
- Brak cross strips.
- Średnia gęstość ukrywająca dziury.
- Odfiltrowanie cienkich obiektów jako outliers.
- Intensity traktowana jako porównywalna reflektancja.
- Eksport XYZ bez CRS i returnów jako master.
- Mieszanie wysokości ellipsoid i orthometric.
- Check points użyte wcześniej do dopasowania.
- Raster o rozdzielczości znacznie drobniejszej niż informacja wejścia.
- Brak checksum i wersji kalibracji.
Powiązane tematy#
- Lidar w UAV — fizyka pomiaru, returny i ograniczenia sensora.
- IMU w dronie — timing, bias i drgania.
- INS w UAV — trajectory i propagacja błędów.
- GNSS w UAV — georeferencja i covariance.
- Układy współrzędnych UAV — ECEF, ENU/NED i datum.
- SLAM dla UAV — LIO, pose graph i loop closure.
- Terrain following UAV — wykorzystanie modelu terenu w sterowaniu.
- Fotogrametria UAV — alternatywny i uzupełniający pipeline pomiarowy.
- Bilans cieplny elektroniki UAV — throttling komputera i payloadu.
Przypisy#
Bibliografia jest generowana z centralnego rejestru. Format pól i zasady czasu sensora zweryfikowano w dokumentacji Livox. Deskew, lidar-inertial trajectory i factor graph oparto na publikacji oraz repozytorium LIO-SAM, a rozdzielenie szybkiej odometrii i mapowania na pracy LOAM. ICP, multiway registration, krawędzie pose graph, fitness, RMSE i information matrix porównano z dokumentacją Open3D. Strukturę LAS, point data records, scale/offset, klasyfikację i GPS time oparto na specyfikacji ASPRS LAS 1.4 R15. Układy geodezyjne zestawiono z dokumentacją WGS84 NGA i transformacjami ECEF/ENU ESA. Dokładność końcowa musi zostać wykazana dla konkretnego sensora, trajectory, wysokości, powierzchni i misji.
Źródła z centralnego rejestru
- Livox Mid-360 — official specifications [dokumentacja producenta]
- Livox Mid-360 User Manual [dokumentacja producenta]
- Livox Mid Series User Manual — point data and time synchronization [dokumentacja producenta]
- LIO-SAM: Tightly-coupled Lidar Inertial Odometry via Smoothing and Mapping [repozytorium open source]
- Shan et al.: LIO-SAM — Tightly-coupled Lidar Inertial Odometry via Smoothing and Mapping [publikacja naukowa]
- Zhang, Singh: LOAM — Lidar Odometry and Mapping in Real-time [publikacja naukowa]
- Open3D: ICP registration [dokumentacja projektu]
- Open3D: Multiway registration and pose graph [dokumentacja projektu]
- ASPRS: LAS Specification 1.4 — R15 [specyfikacja formatu danych]
- ROS REP 105: Coordinate Frames for Mobile Platforms [standard projektu open source]
- NGA Geomatics: World Geodetic System 1984 [standard geodezyjny]
- ESA Navipedia: Transformations between ECEF and ENU coordinates [materiał techniczny ESA]