Dead reckoning UAV

Dead reckoning, czyli nawigacja zliczeniowa, wyznacza bieżący stan przez propagację poprzedniej pozycji z użyciem prędkości, kierunku i modelu ruchu. W UAV termin obejmuje kilka bardzo różnych architektur: czyste całkowanie INS po utracie wszystkich odniesień, INS wspomagany optical flow lub visual odometry, płatowiec wykorzystujący airspeed i model wiatru, a nawet krótkotrwały failsafe wracający w kierunku home. Bez wskazania sensorów i limitu czasu samo hasło „dead reckoning” nie opisuje zdolności systemu.

Tryb powinien być projektowany jak maszyna stanów z rosnącą niepewnością, a nie bezterminowy zamiennik GNSS. Każde źródło aiding ma własne degeneracje. Gdy pozycja przestaje spełniać wymaganie, system ogranicza misję, przechodzi do attitude/altitude control, ląduje albo wykonuje inną wcześniej zweryfikowaną procedurę.

Spis treści#

• Znaczenia dead reckoning
• Czysty INS a aided dead reckoning
• Trzy różne scenariusze
• Stan i origin
• Warunki wejścia
• Warunki wyjścia
• Budżet błędu
• Time-to-limit
• Covariance i integrity
• Alternatywne źródła aiding
• Optical flow i rangefinder
• VIO i external vision
• Airspeed i model wiatru
• Barometr, terrain i wysokość
• Constraints ruchu
• Wykrycie degradacji GNSS
• Source switching
• Continuity controller
• Różnice multirotor i fixed-wing
• Failsafe i ograniczenie misji
• Odzyskanie GNSS
• Architektura oprogramowania
• Obserwowalność i degeneracje
• Logi i metryki
• SITL, HIL i loty próbne
• Typowe błędy
• Kryteria odbioru
• Powiązane tematy
• Przypisy

Znaczenia dead reckoning#

Historycznie dead reckoning aktualizuje pozycję ze znanej pozycji początkowej, kursu, prędkości i czasu. W systemie elektronicznym źródłem może być:

• INS: akcelerometry i żyroskopy;
• enkodery kół w UGV;
• airspeed + heading + model wiatru w samolocie;
• prędkość z Dopplera/radaru;
• optical flow z wysokością;
• visual/lidar/radar odometry;
• model dynamiki i komendy aktuatorów;
• kombinacja powyższych w EKF.

W dokumentacji autopilotów „dead-reckoning mode” może oznaczać szczególną politykę fuzji oraz resetów po degradacji GNSS, nie wyłącznie mechanizację INS. PX4 w eksperymentalnym trybie wymaga alternatywnego źródła pozycji lub prędkości i początkowo dobrego GNSS. ArduPilot ma osobno non-GPS navigation oraz dead-reckoning failsafe o ograniczonym czasie.

Dlatego karta zdolności powinna podawać:

initialization source + aiding sources + environment + duration + error bound

Przykład: „po utracie GNSS system utrzymuje poziomy błąd 95% < 5 m przez 20 s przy działającym flow/range, wysokości 1–10 m i wymaganej teksturze”.

Czysty INS a aided dead reckoning#

Czysty INS po utracie wszystkich obserwacji propaguje:

IMU → attitude → specific force in nav frame → velocity → position

Bias akcelerometru daje błąd pozycji ~t², a gyro bias przez błąd tilt może dawać krótkookresowo ~t³. Dla taniego MEMS użyteczny czas jest zwykle krótki i zależy od ruchu.

Aided dead reckoning nadal nie używa globalnej pozycji GNSS, ale ma względne obserwacje:

IMU propagation
   + flow velocity
   + VIO relative pose
   + airspeed/wind
   + baro/range height
   + vehicle constraints
→ ograniczony dryf wybranych osi

Flow może ograniczyć poziomą prędkość, lecz nie absolutną pozycję. VIO ogranicza lokalny ruch, ale dryfuje globalnie i może stracić tracking. Barometr stabilizuje pion względnie, a nie north/east. System musi raportować, które stopnie swobody są ograniczone.

Trzy różne scenariusze#

Krótki dropout#

GNSS znika na kilka sekund pod mostem. Biasy są dobrze oszacowane przed wejściem, inne sensory działają, a celem jest ciągłość bez resetu. To najłatwiejszy scenariusz.

Przejście GNSS → non-GNSS#

UAV wlatuje do hali i korzysta z flow/VIO. Potrzebna jest transformacja origin, time sync, sprawdzenie jakości alternatywnego źródła przed utratą GNSS oraz kontrolowane przełączenie.

Start bez GNSS#

System inicjalizuje lokalny origin i yaw z vision/mocap/magnetometru. To nie jest tylko „dropout od zera”; wymaga osobnej procedury alignment i definicji układu lokalnego. PX4 opisany tryb dead-reckoning nie jest przeznaczony do czystego indoor startu, natomiast ArduPilot ma konfiguracje non-GPS navigation z ręcznym/zapisanym origin.

Testy i certyfikacja tych scenariuszy nie są zamienne.

Stan i origin#

Dead reckoning potrzebuje poprawnego stanu początkowego:

• pozycji/origin lokalnego;
• prędkości;
• attitude i heading;
• biasów IMU oraz covariance;
• modelu wiatru, jeśli używany;
• transformacji sensorów;
• czasu i opóźnień.

Origin globalny pozwala przeliczyć local NED na latitude/longitude, ale zapisany origin nie gwarantuje, że platforma fizycznie znajduje się w tej samej pozycji po przeniesieniu. ArduPilot umożliwia zapis/odtworzenie origin dla non-GPS, co jest wygodne, lecz operacja musi zapewnić poprawne położenie startu.

Jeśli VIO uruchamia własny układ map, potrzebna jest transformacja map→local navigation. Translation i yaw są kalibrowane podczas okresu wspólnej dostępności GNSS/VIO albo przez znany punkt. Skok resetu VIO zmienia tę transformację, nie może zostać potraktowany jako ruch UAV.

Warunki wejścia#

Tryb nie powinien aktywować się tylko dlatego, że GNSS ma mniej satelitów. Warunki wejścia obejmują:

• estimator aligned i healthy;
• biasy IMU poniżej limitu;
• covariance pozycji/prędkości poniżej progu;
• alternatywne źródło aktywne przez minimalny czas;
• jego innovation/quality w normie;
• poprawne timestampy i transformacje;
• wysokość/tekstura/światło w envelope flow/vision;
• bateria i czas misji pozwalające na procedurę wyjścia;
• brak krytycznej awarii aktuatorów.

W przejściu planowanym alternatywny sensor jest fuzjonowany przed utratą GNSS. Filtr porównuje oba i estymuje offset. Włączenie VIO dopiero po zniknięciu GNSS utrudnia wykrycie błędnej skali/yaw.

Wejście automatyczne ma debounce i histerezę. Krótki outlier GNSS jest odrzucany bez zmiany całej polityki, a trwała degradacja przełącza stan.

Warunki wyjścia#

Wyjście następuje, gdy:

• GNSS odzyska spójność przez określone okno;
• alternative aiding traci jakość;
• covariance przekracza limit misji;
• upływa maksymalny czas;
• środowisko wychodzi poza envelope;
• operator wybiera bezpieczny tryb;
• pojawia się inna awaria wymagająca lądowania.

Nie każde wyjście oznacza powrót do GNSS. Utrata flow na małej wysokości może prowadzić do altitude/attitude mode, a przekroczenie timeoutu podczas failsafe — do lądowania.

Maszyna stanów ma jawny stan recovery. Nowy GNSS nie jest od razu authority; najpierw przechodzi consistency gate.

Budżet błędu#

Wymaganie pozycji wynika z misji i marginesu przeszkód:

E_total = E_initial + E_propagation(t) + E_aiding + E_map + E_latency

Składniki nie zawsze sumuje się arytmetycznie; dla niezależnych losowych błędów używa się covariance/RSS, ale systematyczne biasy i wspólne źródła wymagają worst-case.

Budżet obejmuje:

• initial GNSS/VIO offset;
• INS bias/noise;
• flow scale i range error;
• VIO drift oraz relocalization;
• heading error;
• wind model/airspeed;
• baro drift;
• lever arms;
• opóźnienia;
• błąd mapy/transformacji;
• błąd controller tracking.

Limit nawigacyjny musi być mniejszy od wolnej przestrzeni. Jeśli korytarz ma 3 m szerokości, covariance 2 m nie jest wystarczająca mimo „pozycji dostępnej”.

Time-to-limit#

time-to-limit jest przewidywanym czasem do przekroczenia maksymalnego błędu. Można go oszacować z covariance growth oraz konserwatywnego modelu niezmodelowanych biasów.

t_limit = min t: metric(P_position(t), bias_bound, environment) >= E_limit

Nie wystarczy ekstrapolować liniowo bieżącej covariance, gdy aiding właśnie zniknął. Model propagacji zmienia się ze stanem źródeł. Czysty INS rośnie szybciej niż INS+flow.

Controller misji używa time_to_limit do decyzji: czy kontynuować przez strefę, zawrócić, czy lądować. Wymaga marginesu na czas manewru. Jeśli powrót zajmuje 15 s, a limit przewidywany za 10 s, decyzja jest spóźniona.

Metryka jest weryfikowana Monte Carlo i lotami dropout. Jeżeli covariance historycznie niedoszacowuje błędu, stosuje się inflation lub dodatkowy deterministic bound.

Covariance i integrity#

Filtr propaguje covariance nawet bez pomiarów. W aided mode aktualizacje zmniejszają wybrane stany. Ważne jest rozróżnienie:

• covariance poziomej pozycji;
• covariance prędkości;
• yaw uncertainty;
• wysokości;
• biasów IMU;
• jakości poszczególnych źródeł.

Jedna liczba position valid jest niewystarczająca. Local position może być ważna do hover, global position nie. Velocity może być dobra przy rosnącej position error.

Integrity monitor porównuje innovation, redundantne źródła i physical constraints. Sensor o stale zbyt małej zadeklarowanej covariance może dominować filtr. Gating oraz minimalne noise floors chronią przed overconfidence.

Dead reckoning nie może ukrywać rosnącej niepewności przed planistą. UI pokazuje tryb, age ostatniego absolute fix, estimated error i remaining time.

Alternatywne źródła aiding#

Najlepszy zestaw ma różne zasady fizyczne. Kamera i optical flow na tej samej kamerze nie są niezależną redundancją wobec braku światła.

Optical flow i rangefinder#

Flow mierzy znormalizowany ruch obrazu. Przy znanej odległości h można wyznaczyć prędkość poziomą w przybliżeniu:

v ≈ angular_flow · h

po kompensacji rotacji gyro i geometrii. Błąd wysokości jest błędem skali prędkości. Jeśli range wskazuje 20% za dużo, prędkość flow może być 20% za duża.

Warunki health:

• quality powyżej progu;
• range valid i w przedziale;
• tilt nie powoduje utraty footprint;
• angular rate poniżej motion-blur limit;
• flow innovation spójna z INS;
• czas flow/range zsynchronizowany;
• brak saturacji pikselowej.

Na jednolitej podłodze, wodzie, śniegu lub przy migotaniu oświetlenia flow może zawieść. Testy muszą obejmować rzeczywiste powierzchnie.

VIO i external vision#

VIO publikuje pozycję, prędkość, attitude lub ich kombinację wraz z covariance i timestampem. Transformacje:

camera frame → body frame
VIO map/odom → local navigation frame

Extrinsics kamera–IMU wymagają kalibracji 6-DoF. Błąd time offset podczas szybkiego obrotu wygląda jak błąd orientacji/extrinsics.

System rozróżnia:

• continuous odometry drift;
• tracking lost;
• relocalization jump;
• map reset;
• loop closure correction;
• confidence/covariance.

Loop closure jest dobra dla mapy, ale może skokowo zmienić pozę. Do kontrolera używa się ciągłej ramki odometrycznej, a globalną korektę wprowadza przez osobną transformację/smoothing.

External vision z mocap ma mały dryf, lecz ograniczony obszar i może stracić markery. Utrata pakietów sieciowych nie może utrzymywać ostatniej pozycji jako świeżej.

Airspeed i model wiatru#

Płatowiec może propagować groundspeed z attitude, true airspeed i oszacowanego wiatru:

v_ground = R_b^n v_air_body + v_wind

Jeśli wiatr zmienia się po utracie GNSS, błąd rośnie liniowo. Sideslip, angle of attack i manewry utrudniają prosty model. Drag fusion w multirotorze także może estymować wiatr, ale jest zależna od kalibracji aerodynamicznej.

ArduPilot dead-reckoning failsafe wymaga przygotowania estymacji wiatru i ma typowe timeouty rzędu 10–30 s dla wielu platform. Jest to przykład ograniczonej procedury awaryjnej, nie dowód bezterminowej nawigacji.

Pitot blockage lub icing może podać spójnie błędny airspeed. Redundancja, plausibility i porównanie z dynamiką silnika/INS są potrzebne.

Barometr, terrain i wysokość#

Dead reckoning poziome nie rozwiązuje pionu. Barometr ma bias zależny od pogody, temperatury i prop wash. Rangefinder stabilizuje AGL w swoim zasięgu, ale nad pochyłym terenem mierzy ukośną odległość.

Terrain following potrzebuje mapy lub aktywnego sensora. Utrata range przy krawędzi dachu może nagle zmienić height source. Source switching wysokości ma offset alignment i rate limiter.

Wymagania rozdzielają:

• altitude względem elipsoidy/MSL;
• local z/height datum;
• AGL nad terenem;
• clearance do przeszkody.

Jedno źródło nie gwarantuje wszystkich czterech. Barometr pozwala utrzymać względną wysokość, ale nie zna podnoszącego się terenu.

Constraints ruchu#

Model pojazdu daje pseudo-obserwacje:

• UGV zwykle ma małą prędkość boczną i pionową;
• płatowiec ma określony zakres sideslip/airspeed;
• multirotor w kontakcie z ziemią ma zero velocity;
• tethered UAV ma ograniczenie geometrii kabla;
• znana wysokość/planar surface ogranicza z.

Constraint działa tylko, gdy warunek jest prawdziwy. Zero-velocity update podczas lekkiego kołysania albo z włączonymi śmigłami może uczyć błędny bias. Wheel no-slip zawodzi na lodzie.

Detektor warunku ma własne false-positive/false-negative. Pseudo-pomiar otrzymuje covariance zgodną z rzeczywistą zmiennością, a nie zero.

Wykrycie degradacji GNSS#

Nie polega się na jednym fix_type. Monitoruje się:

• innovation position/velocity;
• reported accuracy i DOP;
• satelity/constellations;
• residual pseudorange/Doppler, jeśli dostępne;
• skoki czasu/pozycji;
• multipath indicators;
• zgodność redundantnych GNSS;
• zgodność z VIO/flow/airspeed;
• age i rate danych.

GNSS degraded oznacza, że dane mogą nadal przychodzić, lecz są niespójne. Filtr odrzuca je lub zwiększa noise. GNSS lost to brak świeżych danych. GNSS recovered wymaga ponownej spójności przez okno.

Fałszywe odrzucenie pogarsza ciągłość, fałszywe przyjęcie może przesunąć state. Progi wynikają z testów środowiska, nie tylko danych producenta.

Source switching#

Źródła mogą być fuzjonowane równocześnie lub wybierane w zestawach. Przełączenie musi zachować:

• wspólny timestamp;
• transformację frame;
• offset pozycji/yaw/height;
• covariance;
• reset counter i continuity;
• warunek powrotu.

ArduPilot EKF3 udostępnia zestawy źródeł i przejścia GPS/non-GPS. PX4 decyduje o fuzji/resetach zależnie od aktywnego aiding. W obu przypadkach konfiguracja źródeł jest częścią architektury pojazdu, nie uniwersalnym profilem.

Jeśli source B jest dostępny, ale ma inną origin, najpierw estymuje się transformację podczas overlap. Hard switch bez overlap może dać skok.

Lane switching między EKF z różnymi IMU także zmienia bias/stan. Controller musi otrzymać informację o reset delta.

Continuity controller#

Nawet poprawna korekta estimator może być problemem dla kontrolera pozycji. Jeśli stan przesunie się o 10 m, setpoint w starej ramce tworzy natychmiastowy błąd 10 m.

Rozwiązania:

• estimator publikuje delta_position_reset i counter;
• controller przesuwa wewnętrzny setpoint o ten sam delta;
• globalny mission target pozostaje, lecz lokalny transition jest limitowany;
• velocity/acceleration commands mają slew limits;
• w trybie recovery najpierw stabilizuje się prędkość, potem pozycję.

Continuity nie może ukryć prawdziwej zmiany origin przed mapą przeszkód. Wszystkie konsumenty stanu — controller, planner, geofence, payload — muszą obsłużyć reset.

Różnice multirotor i fixed-wing#

Multirotor może zawisnąć i zmniejszyć prędkość, co ogranicza ryzyko oraz ułatwia flow. Ma jednak mały zapas czasu energetycznego i silne wibracje/prop wash.

Fixed-wing musi utrzymać airspeed i stale się przemieszcza. Nawet mały błąd heading/wind szybko przesuwa pozycję. Nie może zatrzymać się przed wejściem w strefę. Za to pitot i model aerodynamiczny dają dodatkowe constraints.

VTOL przełącza dynamikę. Sensor flow przydatny w hover może wyjść poza wysokość/rate w locie skrzydłowym. Wind estimator z fixed-wing niekoniecznie działa identycznie w multirotor mode.

Plan dead reckoning określa fazę lotu. Procedura bezpieczna dla Coptera nie jest automatycznie poprawna dla samolotu.

Failsafe i ograniczenie misji#

Przykładowa maszyna:

GLOBAL_HEALTHY
  → GNSS_DEGRADED (gating, alternative aiding confirmed)
  → LOCAL_AIDED_DR (mission constrained)
  → PURE_INERTIAL_GRACE (krótki timer, jeśli dopuszczony)
  → POSITION_INVALID
  → ALTITUDE_ATTITUDE / LAND / preplanned action

Każdy stan ma:

• wymagane sensory;
• dozwolone flight modes;
• max speed/tilt/area;
• time/error limit;
• action po przekroczeniu;
• warunki recovery.

RTL na dead reckoning ma sens tylko, jeśli przewidywany błąd i czas powrotu mieszczą się w limicie. ArduPilot po określonym timeout może przejść do Land. W ciasnym środowisku lot w kierunku home na niepewnej pozycji może być gorszy niż lokalne lądowanie.

Operator dostaje jednoznaczny alert oraz estimated uncertainty, nie tylko „GPS lost”.

Odzyskanie GNSS#

Nowy fix przechodzi:

1. walidację czasu i formatów;
2. quality oraz accuracy checks;
3. innovation względem predicted state;
4. porównanie velocity/yaw z alternatywnym aiding;
5. stabilne okno wielu próbek;
6. decyzję fuse/reject/reset;
7. kontrolę continuity.

Jeśli różnica jest mała, GNSS może być miękko fuzjonowany. Jeśli duża, nie wiadomo od razu, czy dryfował DR, czy GNSS ma multipath/spoof. Redundantne źródła i trend pomagają.

Hard reset position wymaga reset delta dla controllerów. Powrót do GNSS może pozostać zablokowany do disarm w niektórych failsafe, jeśli zapewnia to przewidywalność.

Histereza zapobiega flap między GNSS i DR na granicy zasięgu. Repeated transitions są osobnym scenariuszem testowym.

Architektura oprogramowania#

sensor health + measurement adapters
              ↓
        estimator / EKF
              ↓ state + covariance + innovations + reset deltas
     navigation integrity manager
              ↓ mode capability + time_to_limit
 mission manager / failsafe / controller continuity

Estimator nie podejmuje całej decyzji misji. Publikuje jakość i stany. Integrity manager mapuje je na capabilities: attitude_valid, local_velocity_valid, local_position_valid, global_position_valid, terrain_valid.

Mission manager zna geometrię i czas. Failsafe ma priorytet nad planem. Controller obsługuje reset deltas i ograniczenia prędkości.

Konfiguracja zawiera manifest źródeł, transformacji, timeoutów i envelope. Parametr „enable dead reckoning” bez tego zestawu jest niewystarczający.

Obserwowalność i degeneracje#

Tabela stanów:

Degeneracja może być kierunkowa. Lidar w długim korytarzu dobrze ogranicza poprzeczną, słabo wzdłużną pozycję. Covariance powinna być anizotropowa, a planner uwzględniać ellipsoidę błędu.

Quality flag sensora może nie wykryć wszystkich degeneracji. Innovation i własna analiza geometrii są potrzebne.

Logi i metryki#

Log powinien zawierać:

• mode state i przyczynę każdego przejścia;
• age/quality każdego źródła;
• fused/rejected status;
• innovations/test ratios;
• position/velocity/yaw covariance;
• biasy IMU i wiatr;
• predicted time-to-limit;
• reset deltas/counters;
• controller setpoint compensation;
• actual error względem truth/reference w teście;
• failsafe action i timestamps.

Metryki partii testowej:

• error CDF po 5/10/30/60 s dropout;
• false transition rate;
• detection latency degradacji;
• recovery time i overshoot;
• max controller jerk po reset;
• coverage covariance;
• availability local/global position;
• success/abort per environment.

Bez truth source nie można ocenić błędu DR. W testach używa się mocap, RTK, total station lub dokładnego reference, lecz nie fuzjonuje go do badanego estymatora.

SITL, HIL i loty próbne#

SITL#

• nagły brak GNSS;
• rosnący bias/multipath zamiast braku;
• recovery z offsetem;
• utrata flow/VIO w różnych chwilach;
• repeated transitions;
• wind change i pitot fault;
• baro drift oraz terrain step;
• Monte Carlo sensor noise/bias.

HIL/replay#

Realne opóźnienia, jitter, logi kamery i IMU, out-of-order packets, relocalization VIO. Te same dane przechodzą wersje firmware w regresji.

Lot#

Najpierw szeroki obszar, dobra pogoda i zewnętrzny truth. Dropout jest programowy i odwracalny. Operator ma niezależny tryb attitude/altitude. Stopniowo zwiększa się czas i prędkość.

Nie zaczyna się od fizycznego zakłócania GNSS. Jest to niepotrzebne do walidacji logiki, może być nielegalne i wpływać na innych użytkowników. Emulator RF w ekranowanym laboratorium wymaga specjalistycznej procedury; dla większości testów wystarczy fault injection danych.

Typowe błędy#

Kryteria odbioru#

Dead reckoning jest użyteczne wtedy, gdy jego granice są bardziej precyzyjne niż hasło „bez GPS”. Projekt powinien potrafić odpowiedzieć: które osie są obserwowalne, jaki jest błąd po określonym czasie, co wykrywa degradację, ile trwa bezpieczny manewr i co następuje po przekroczeniu limitu. Dopiero taki system jest kontrolowanym trybem nawigacji, a nie tylko kontynuacją ostatniej liczby pozycji.

Powiązane tematy#

• INS w UAV
• GNSS w UAV
• Filtr Kalmana i EKF w UAV
• Optical flow w UAV
• Visual odometry w UAV
• Failsafe jako maszyna stanów
• Diagnostyka problemów GNSS
• Układy współrzędnych w UAV

Przypisy#

1. PX4, GNSS-Degraded & Denied Flight (Dead-Reckoning Mode), https://docs.px4.io/main/en/advanced_config/gnss_degraded_or_denied_flight (dostęp: 15 sierpnia 2026).
2. PX4, Using PX4's Navigation Filter (EKF2), https://docs.px4.io/main/en/advanced_config/tuning_the_ecl_ekf (dostęp: 15 sierpnia 2026).
3. PX4, Optical Flow, https://docs.px4.io/main/en/sensor/optical_flow (dostęp: 15 sierpnia 2026).
4. ArduPilot, Non-GPS Navigation, https://ardupilot.org/copter/docs/common-non-gps-navigation-landing-page.html (dostęp: 15 sierpnia 2026).
5. ArduPilot, Dead Reckoning Failsafe, https://ardupilot.org/copter/docs/deadreckoning-failsafe.html (dostęp: 15 sierpnia 2026).
6. ArduPilot, EKF Source Selection and Switching, https://ardupilot.org/plane/docs/common-ekf-sources.html (dostęp: 15 sierpnia 2026).
7. ArduPilot, Extended Kalman Filter overview, https://ardupilot.org/copter/docs/common-apm-navigation-extended-kalman-filter-overview.html (dostęp: 15 sierpnia 2026).
8. US Coast Guard Navigation Center, GPS User Equipment — Inertial Navigation Systems, https://navcen.uscg.gov/sites/default/files/pubs/gps/gpsuser/gpsuser.pdf (dostęp: 15 sierpnia 2026).
9. NASA, Integrated INS/GPS Navigation from a Popular Perspective, https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20020041935.pdf (dostęp: 15 sierpnia 2026).

Powiązane tematy

INS w UAVINS w UAV od siły właściwej i całkowania delta-angle/delta-velocity przez kwaterniony, grawitację, Coriolisa, coning/sculling oraz układy NED/ECEF do inicjalizacji, biasów MEMS, wzrostu błędu, luźnej/ścisłej integracji GNSS i innych źródeł aiding, obserwowalności oraz testów integralności.GNSS w UAVOd pseudoodległości do rozwiązania RTK: integracja odbiornika, antena, opóźnienie, układy odniesienia i walidacja z innymi sensorami.Filtr Kalmana i EKF w UAVPraktyczna anatomia filtra nawigacyjnego: model stanu i błędów, macierze Q/R, opóźnione obserwacje, bramkowanie innowacji, Joseph form i diagnostyka.Optical flow w UAVOptical flow jako pomiar kątowego ruchu obrazu: model projekcyjny, skala z dalmierza, kompensacja obrotu, rolling shutter, tekstura i oświetlenie, układy osi, timestamp, opóźnienie, kalibracja oraz walidacja w EKF.Visual odometry i VIO w UAVArchitektura visual odometry i visual-inertial odometry dla UAV: geometria projekcyjna, frontend cech, estymacja ruchu, skala monocularna, preintegracja IMU, filtry i optymalizacja sliding-window, układy odom/map/body/camera, kalibracja czasu i ekstrynsyki, metryki jakości, resety oraz bezpieczne podanie wyniku do autopilota.Failsafe jako maszyna stanówFailsafe jako deterministyczny system decyzji: źródła faultów, persistence i hysteresis, priorytety reakcji, konflikty RC/GNSS/baterii, latch, recovery oraz macierz testowa.Diagnostyka problemów GNSS w UAVMetodyczna diagnostyka toru GNSS od anteny i LNA przez interfejs odbiornika po fuzję w EKF: czas do fixa, C/N0 per sygnał, geometria satelitów, accuracy estimates, update rate i latency, multipath i self-jamming, stan korekt RTK, różnice między raw fix a pozycją estymowaną, innowacje pozycji/prędkości, porównanie dwóch odbiorników oraz bezpieczne reakcje na zakłócenia i podejrzenie spoofingu.Układy współrzędnych w UAVŁańcuch transformacji od współrzędnych geodezyjnych przez ECEF i lokalną płaszczyznę do body/sensor frame, z pułapkami wysokości, originu, osi i kowariancji.

Źródła z centralnego rejestru

1. PX4: GNSS-Degraded and Denied Flight — Dead-Reckoning Mode [dokumentacja projektu]
2. PX4: Using PX4 Navigation Filter EKF2 [dokumentacja projektu]
3. PX4 Guide: Optical Flow — setup, conventions and estimator integration [dokumentacja projektu]
4. ArduPilot: Non-GPS Navigation [dokumentacja projektu]
5. ArduPilot Copter: Dead Reckoning Failsafe [dokumentacja projektu]
6. ArduPilot: EKF Source Selection and Switching [dokumentacja projektu]
7. ArduPilot: Extended Kalman Filter overview [dokumentacja projektu]
8. US Coast Guard Navigation Center: GPS User Equipment — Inertial Navigation Systems [podręcznik instytucji państwowej]
9. NASA: Integrated INS/GPS Navigation from a Popular Perspective [publikacja techniczna]