Nawigacja piechoty pieszej: mapy offline, bez GPS, planowanie tras

Żołnierz pieszy działa w warunkach, które podważają niemal każde założenie leżące u podstaw konsumenckiego oprogramowania nawigacyjnego. Łączność jest sporadyczna lub nieobecna. Sygnały GPS są zagłuszane, fałszowane lub tłumione przez konstrukcje miejskie. Wyświetlacz musi być czytelny w bezpośrednim świetle słonecznym w rękawiczkach. Bateria musi wystarczyć na pełny okres operacyjny bez zaopatrzenia. Aplikacja musi nadal dostarczać użyteczne szacunki pozycji, gdy wszystkie sygnały zewnętrzne znikną — i musi jasno komunikować operatorowi, jak pewny jest ten szacunek. Artykuł omawia decyzje inżynierskie stojące za wojskowymi aplikacjami nawigacyjnymi dla piechoty: ograniczenia sprzętowe kształtujące każdy wybór projektowy, formaty pakietów map obsługujące mapowanie offline w operacjach wojskowych, algorytmy fuzji czujników utrzymujące pozycję przy awarii GPS oraz wzorce integracji łączące ręczne urządzenie nawigacyjne z wyświetlaczami nadgarstkowymi, optyką hełmową i siecią mesh drużyny.

Wymagania nawigacji dla piechoty pieszej

Zakres wymagań dla nawigacji piechoty pieszej różni się od nawigacji pojazdowej lub lotniczej niemal w każdym wymiarze. Wymagania dokładności dla operacji w skali piechoty to zazwyczaj 10–30 m CEP (błędne prawdopodobne koło) przy dostępności GPS, z dopuszczalną płynną degradacją do 50–100 m CEP w przedziałach bez GPS do 10 minut. Na poziomie drużyny dokładność pozycji względnej — gdzie każdy żołnierz znajduje się względem innych — bywa operacyjnie krytyczniejsza niż dokładność pozycji bezwzględnej, ponieważ decyzje taktyczne zależą od geometrii drużyny, nie od współrzędnych siatki.

Ograniczenia masy i baterii kształtują każdą decyzję sprzętową i programową. Całkowite obciążenie żołnierza przekracza już 30 kg w typowej konfiguracji bojowej; urządzenie nawigacyjne musi dodać mniej niż 300 g wraz z baterią. Ta bateria musi zasilać urządzenie przez cały okres operacyjny — powszechnie 8–12 godzin — co, przy jasności wyświetlacza wystarczającej do czytelności w świetle dziennym (minimum 600 nitów; 800–1000 nitów w warunkach bezpośredniego słońca), limituje projekt sprzętowy do wyświetlaczy zużywających nie więcej niż 300–600 mW. Sam stos fuzji czujników musi mieścić się w budżecie mocy 150–400 mW, co oznacza, że techniki łaknące mocy, takie jak ciągła odometria wizualna oparta na kamerze, są trudne do utrzymania przez pełny okres operacyjny i muszą być traktowane jako ukierunkowane uzupełnienia, a nie podstawowe metody pozycjonowania.

Czytelność ekranu w świetle dziennym to niepodlegający negocjacji wymóg, który bezpośrednio ogranicza paletę kolorów i projekt renderowania oprogramowania. Warstwy map oparte na niskokontrastowych pastelowych schematach kolorów, nakładki siatki cienkimi liniami lub tekst mniejszy niż 14 pt efektywnie będą nieczytelne w bezpośrednim świetle słonecznym na wyświetlaczu 600-nitowym. Wojskowe aplikacje nawigacyjne używają wysokokontrastowych schematów renderowania — białe lub cyjanowe ikony na ciemnych tłach map, grube linie nakładek tras oraz duże cele dotykowe zgodne z dłońmi w rękawiczkach (średnica celu dotykowego minimum 8 mm zgodnie z wytycznymi MIL-STD). Zgodność z noktowizją — zazwyczaj tryb renderowania wyłącznie w czerwieni, który nie oślepia nocnego widzenia żołnierza światłem białym — musi być przełączana jednym dotknięciem.

Pakiety map offline do użytku piechoty

Łączność w operacjach pieszych jest wyjątkiem, nie normą. Kafle map muszą być przechowywane lokalnie przed misją. Dwa dominujące formaty taktycznych pakietów map offline to MBTiles (rastrowe) oraz pakiety kafli wektorowych w formacie kontenera MBTiles lub PMTiles, a wybór między nimi decyduje o śladzie magazynowym, wydajności renderowania i elastyczności dostępnej operatorowi w terenie.

Pakiety rastrowe MBTiles przechowują wstępnie renderowane kafle PNG lub JPEG na wielu poziomach przybliżenia w kontenerze SQLite. Każdy kafel to obraz o stałym rozmiarze (zwykle 256 × 256 pikseli) pokrywający prostokątny obszar geograficzny na określonym poziomie przybliżenia. Renderowanie to prosta operacja pobrania i wyblitowania kafli, nakładająca minimalne obciążenie CPU — każde urządzenie zdolne do uruchomienia Androida może renderować kafle rastrowe z pełną liczbą klatek. Kosztem jest magazyn: rastrowy pakiet w skali 1:25 000 dla obszaru działań 100 km × 100 km pokrywającego poziomy przybliżenia 10–16 (zakres potrzebny od planowania po nawigację w skali budynku) wymaga 500 MB do 3 GB zależnie od szczegółowości obrazów terenu i kompresji kafli. Dla urządzenia z 64 GB magazynu podzielonego między system operacyjny, aplikację nawigacyjną i oprogramowanie komunikacyjne to znacząca ułamkowa część dostępnej przestrzeni. Pobieranie selektywne obszaru — ograniczenie pakietu do wielokąta zamiast prostokątnego pola ograniczającego — może zmniejszyć wymaganie magazynowe o 30–70% dla nieprostokątnych obszarów działań. Większość platform mapowania offline w operacjach wojskowych obsługuje generowanie kafli przycinanych wielokątem po stronie serwera przed dystrybucją do urządzeń terenowych.

Pakiety kafli wektorowych przechowują obiekty geograficzne jako skompresowaną geometrię protobuf i dane atrybutów, a nie renderowane obrazy. Ten sam obszar 100 km × 100 km w pakiecie wektorowym zajmuje typowo 30–200 MB — redukcja 10–15× w porównaniu z rastrem przy równoważnym pokryciu poziomów przybliżenia. Redukcja wynika ze ściśliwości geometrycznej obiektów liniowych i poligonowych w porównaniu z obrazowaniem fotograficznym. Kafle wektorowe renderują się na urządzeniu z reguł stylów: silnik renderujący stosuje bieżący arkusz stylów do geometrii w chwili wyświetlania, co umożliwia dynamiczne przebudowanie stylów (przełączanie między paletami dzień i noc, pokazywanie lub ukrywanie określonych klas obiektów, dostosowanie gęstości etykiet) bez pobierania nowego zestawu kafli. Kompromisem jest obliczenie renderowania: renderowanie kafli wektorowych na mobilnym procesorze średniej klasy wymaga wydajnego GPU i dodaje 15–40% do wykorzystania CPU w porównaniu z wyświetlaniem kafli rastrowych, co ma odpowiadający wpływ na baterię. Praktyczne zalecenie dla aplikacji nawigacyjnych piechoty to używanie kafli wektorowych jako domyślnego formatu offline na nowoczesnych taktycznych urządzeniach Android, z rastrowymi MBTiles jako opcją zapasową dla sprzętu starszego lub o niskiej mocy.

Pozycjonowanie bez GPS: rachuba drogi i PDR

Gdy sygnały GPS są zagłuszane, fałszowane lub tłumione poniżej progu ustalenia, pierwszym dostępnym fallbackiem na każdym urządzeniu klasy smartfona jest piesza rachuba drogi (PDR) z wbudowanego IMU. PDR szacuje pozycję przez całkowanie przesunięć krok po kroku w kierunku szacowanego kursu, bez wymagania jakiegokolwiek sygnału zewnętrznego lub infrastruktury. Zrozumienie osiągalnej dokładności i charakterystyki narastania błędów PDR jest niezbędne do zaprojektowania aplikacji nawigacyjnej, która daje operatorom realistyczną pewność co do ich pozycji w okresach bez GPS.

Algorytm PDR zaczyna się od wykrywania kroków. Chód żołnierza wytwarza charakterystyczny sygnał okresowy w pionowym kanale akcelerometru: gdy stopa uderza o ziemię, a środek masy ciała unosi się i opada z każdym krokiem, mierzone pionowe przyspieszenie oscyluje w tempie marszu (zwykle 1,0–1,8 Hz dla piechoty z obciążeniem). Detektor kroków identyfikuje każdy szczyt tempa z użyciem przekroczenia progu lub algorytmu wyszukiwania szczytów zastosowanego do sygnału akcelerometru odfiltrowanego dolnoprzepustowo. Każdy wykryty krok wnosi szacunek przemieszczenia: długość kroku obliczana jest z amplitudy przyspieszenia szczyt-do-dołu przez model empiryczny skalibrowany do wzrostu, chodu i obciążenia żołnierza — powszechnie model postaci L = K · √(a_max − a_min), gdzie K to indywidualna stała kalibracyjna, a a_max i a_min to wartości szczytowe i dolne przyspieszenia w cyklu kroku. Kurs każdego kroku pobierany jest z azymutu kompasu wyznaczonego przez magnetometr, a żyroskop dostarcza krótkoterminowego odniesienia kursu w przedziałach zakłóceń magnetycznych od niesionego wyposażenia lub pobliskich pojazdów.

W warunkach kontrolowanych PDR osiąga błędy szacowania długości kroku 2–5% oraz tempa dryfu kursu 1–5 stopni na minutę. Przekładając na warunki operacyjne: po 5 minutach ruchu patrolowego pokrywającego około 400 m błąd pozycji wynosi zwykle 20–50 m. Po 15 minutach (1200 m) błąd rośnie do 80–200 m — na tyle dużo, by wyświetlaną pozycję umieścić na niewłaściwym kwartale. PDR jest więc zdolnością mostową dla luk GPS rzędu kilku minut, nie rozwiązaniem pozycjonowania długoterminowego. Oprogramowanie musi uczciwie wyświetlać rosnącą niepewność, jasno dając operatorowi do zrozumienia, kiedy wyświetlana pozycja jest szacunkiem rachuby drogi i jak długo działa bez korekty GPS.

ZUPT (zero-velocity update, aktualizacja zerowej prędkości) to najskuteczniejsza technika spowalniania narastania błędów PDR. Podczas fazy podparcia każdego kroku — krótkiego przedziału, gdy stopa płasko leży na ziemi — stopa ma dokładnie zerową prędkość w układzie świata. Filtr z ZUPT wykrywa ten przedział z płaskiej sygnatury akcelerometru i stosuje pseudopomiar zerowej prędkości do stanu filtra Kalmana, który wykorzystuje to ograniczenie do oszacowania i częściowego anulowania skumulowanych obciążeń akcelerometru i żyroskopu. Stosowany przy każdym kroku ZUPT może zmniejszyć tempo dryfu pozycji nawet o 40% w porównaniu z PDR w pętli otwartej. Dla IMU mocowanego na stopie (w przeciwieństwie do urządzenia noszonego w kieszeni) ZUPT jest znacznie skuteczniejszy, ponieważ stopa gwarantowanie jest nieruchoma w fazie podparcia; urządzenie kieszeniowe może nadal wykazywać ruch czujnika w nominalnej fazie podparcia z powodu ruchu odzieży.

Fuzja czujników dla poprawy pozycjonowania

Produkcyjny stos nawigacji wojskowej nie polega na żadnym pojedynczym czujniku. Architektura to silnik fuzji wielu źródeł — zazwyczaj rozszerzony filtr Kalmana (EKF) — który ciągle łączy pomiary ze wszystkich dostępnych czujników, ważąc każdy jego bieżącą dokładnością, i wytwarza ujednolicony szacunek pozycji i prędkości z towarzyszącą macierzą kowariancji niepewności. Czujniki zasilające silnik fuzji w typowym urządzeniu piechoty to: GPS (gdy dostępny), akcelerometr i żyroskop IMU, wysokościomierz barometryczny oraz magnetometr. Wejścia zewnętrzne — szacunki pozycji oparte na RF, pseudopomiar ZUPT oraz kolaboracyjne aktualizacje pozycji od członków drużyny przez radiostację mesh — są doprowadzane jako dodatkowe wejścia pomiarowe do tego samego filtra.

Model pomiarowy GPS wnosi ustalenie pozycji 3D z dokładnością poziomą (zgłaszaną jako CEP ważone HDOP) i dokładnością pionową (ważoną VDOP). Gdy GPS jest dostępny i HDOP poniżej 2,0, GPS dominuje w szacunku pozycji filtra. W miarę wzrostu HDOP (zdegradowana geometria satelitów w kanionach miejskich) filtr naturalnie zmniejsza wagę pomiaru GPS i pozwala predykcji IMU nieść więcej szacunku. Przejście z dominacji GPS na dominację IMU jest płynne i ciągłe, a nie nagłym przełączeniem, co zapobiega skokom wyświetlania pozycji przy degradacji jakości GPS.

Wysokościomierz barometryczny wnosi pomiary wysokości z wysoką częstotliwością aktualizacji (10–50 Hz), o charakterystykach szumu fundamentalnie innych niż wysokość GPS: błędy wysokości GPS są w przybliżeniu gaussowskie ze odchyleniem standardowym 5–15 m; błędy wysokości barometrycznej są zdominowane przez temperaturowy dryf ciśnienia, który ewoluuje powoli w ciągu dziesiątek minut i może być modelowany jako ruch losowy. Filtr traktuje wysokość barometryczną jako pomiar o wysokiej częstotliwości aktualizacji, precyzyjnie dostarczający tempa zmiany wysokości, opierając się na wysokości GPS dla bezwzględnego odniesienia. Połączenie osiąga dokładność pionową 2–5 m przy dostępnym GPS — znacznie lepiej niż sama wysokość GPS — i utrzymuje użyteczne szacunki wysokości (dokładność na poziomie piętra w budynkach) przez 5–15 minut po utracie GPS, ograniczone dryfem barometrycznym.

Magnetometr wnosi pomiary kursu dokładne w otwartych środowiskach, ale degradujące się w obecności zakłóceń ferromagnetycznych. Filtr fuzji modeluje niezawodność magnetometru z użyciem detektora zakłóceń magnetycznych: jeśli zmierzona wielkość pola magnetycznego odbiega o więcej niż próg od oczekiwanej siły pola Ziemi, pomiar magnetometru jest odrzucany, a szacunek kursu opiera się wyłącznie na całkowaniu żyroskopu, aż zakłócenie ustąpi. Zapobiega to fałszowaniu rozwiązania nawigacyjnego przez obiekty ferromagnetyczne — lufy broni, ramy pojazdów, konstrukcje ze zbrojonego betonu — błędnymi odczytami kursu.

Zarządzanie punktami trasy i trasami

Zarządzanie punktami trasy i trasami w aplikacji nawigacji pieszej musi obsługiwać pełny cykl życia planowania misji: import wcześniej zaplanowanych tras z komórki operacyjnej, modyfikację na urządzeniu podczas ruchu oraz eksport zaktualizowanych tras z powrotem do systemu C2. Trzy uniwersalne formaty wymiany danych punktów trasy to XML CoT (Cursor on Target), KML (Keyhole Markup Language) i GPX (GPS Exchange Format).

XML CoT to natywny format ekosystemu TAK i standard wymiany danych pozycji i misji w czasie rzeczywistym między klientami ATAK a TAK Server. Punkt trasy CoT to zdarzenie punktowe z uid (uniwersalnym identyfikatorem), typem (hierarchia typów TAK, np. b-m-p-w dla znacznika punktu trasy), polami time i stale oraz danymi współrzędnych w elemencie point. Dane trasy kodowane są jako zdarzenie trasy CoT łączące uporządkowaną sekwencję uid punktów trasy. Parser importu musi obsługiwać XML CoT w wersji 2.0 i normalizować współrzędną HAE (wysokość ponad elipsoidą) do odniesienia WGS84 używanego przez stos nawigacyjny. Dla wtyczek ATAK do operacji pieszych CoT jest formatem natywnym i konwersja nie jest potrzebna; wtyczka uzyskuje dostęp do punktów trasy bezpośrednio przez API ATAK MapView.

Planowanie tras na urządzeniu z terenem offline umożliwia obliczanie ETA i optymalizację trasy bez łączności. Silnik planowania uzyskuje dostęp do lokalnie przechowywanego NMT (cyfrowego modelu terenu) — zazwyczaj SRTM 30 m lub produktu o wyższej rozdzielczości 10 m lub 1 m wstępnie spakowanego z pobraniem mapy — i stosuje funkcję marszową Toblera do oszacowania prędkości marszu wzdłuż każdego segmentu na podstawie pochylenia. ETA dla trasy to suma czasów per segment: czas = dystans / prędkość(pochylenie). Modyfikatory dla ciężaru wyposażenia, typu nawierzchni (roślinność, piasek, gruz) i trybu ruchu (skoki taktyczne vs ruch ciągły) są konfigurowalne w profilu misji. W praktyce szacunki ETA oparte na Toblerze zgadzają się z mierzonymi czasami ruchu w granicach 15–20% dla ruchu bez obciążenia na znanym terenie, z większymi błędami w złożonych środowiskach miejskich, gdzie topologia trasy (schody, zamknięte drzwi, wąskie gardła) dominuje nad pochyleniem terenu.

Modyfikacja trasy podczas ruchu — dodanie punktu trasy, pominięcie punktu trasy, obejście przeszkody — musi być możliwa do wykonania jednym lub dwoma dotknięciami dłoni w rękawiczce na wyświetlaczu mapy. Standardowy wzorzec interakcji to: długie przytrzymanie na mapie, aby umieścić nowy punkt trasy; przeciągnięcie istniejących punktów trasy w celu dostosowania ich pozycji; dotknięcie punktu trasy i wybór „pomiń”, aby usunąć go z aktywnej trasy bez usuwania z zestawu danych misji. Wszystkie modyfikacje są logowane ze znacznikiem czasu i źródłem modyfikacji (działanie operatora vs aktualizacja zsynchronizowana przez mesh z komórki operacyjnej), aby utrzymać ślad audytowy do przeglądu po działaniach.

Integracja z systemami noszonymi żołnierza

Żołnierz nawigujący w środowisku taktycznym nie może trzymać telefonu na wysokości oczu, aby sprawdzić mapę — obie dłonie mogą być zajęte bronią lub wyposażeniem, a patrzenie na urządzenie ręczne odsłania twarz operatora i przerywa świadomość sytuacyjną. Systemy noszone żołnierza — wyświetlacze nadgarstkowe i hełmowe — przenoszą wyjście nawigacji do operatora bez konieczności angażowania dłoni lub wzroku. Integracja programowa dla każdego typu wyświetlacza narzuca odrębne ograniczenia.

Wyświetlacze nadgarstkowe (WMD) to bardziej popularna i tańsza opcja. Wzmocniony smartwatch oparty na Androidzie lub nadgarstkowa płytka odbiera dane nawigacyjne z urządzenia głównego przez BLE, renderując uproszczony widok nawigacji na ekranie 1,4–2,4 cala. Połączenie BLE używa własnego profilu usługi GATT niosącego kompaktowy pakiet aktualizacji nawigacji: kurs do następnego punktu trasy (2 bajty), odległość do następnego punktu trasy (3 bajty), wskaźnik źródła GPS/INS (1 bajt), promień niepewności pozycji w metrach (2 bajty) i stan baterii (1 bajt). Całkowity rozmiar pakietu poniżej 32 bajtów, znacznie poniżej ograniczeń MTU BLE. Aplikacja nawigacji WMD renderuje mini-mapę z kursiem do góry, pozycją żołnierza wyśrodkowaną, punktami trasy na ich relatywnych azymutach oraz paskiem statusu pokazującym źródło i baterię. Interakcja ogranicza się do kilku przycisków sprzętowych: potwierdzenie przybycia do punktu trasy, żądanie awaryjnego nadawania pozycji i przełączenie trybu noktowizji.

Wyświetlacze hełmowe (HMD) projektują przezroczystą nakładkę head-up display (HUD) na pole widzenia operatora. Oprogramowanie wytwarza nakładkę HUD, a nie mapę pełnoekranową: łuk kompasu na górze pola, wskaźnik azymutu i odczyt odległości dla następnego punktu trasy oraz mały wskaźnik źródła GPS/INS. Integracja HMD zazwyczaj używa Android HMD SDK lub interfejsu nakładki wideo (HDMI lub MIPI-DSI). Pobór mocy jest wyższy niż WMD — projektor wyświetlacza dodaje 200–600 mW — ale HMD łączy się z główną baterią urządzenia, zamiast mieć własną, więc planowanie baterii korzysta z budżetu mocy urządzenia głównego.

Beaconing BLE do śledzenia bliskości drużyny działa równolegle z połączeniem wyświetlacza noszonego. Każde urządzenie nadaje własny pakiet reklamowy BLE w interwałach 100–500 ms, kodując skompresowaną aktualizację pozycji (lat/lon/hae w 12 bajtach w rozdzielczości 1 cm), 4-bajtowy znacznik czasu i 4-bajtowy identyfikator urządzenia. Urządzenia członków drużyny odbierają te transmisje i wyświetlają pozycję każdego członka na mapie nawigacji jako ikonę z kolorem wskazującym jakość źródła pozycji (zielony dla GPS, bursztynowy dla mieszanego, czerwony wyłącznie dla rachuby drogi). BLE zapewnia autentyczną świadomość spójności drużyny w zasięgu 10–80 m bez wymagania taktycznej radiostacji mesh, oszczędzając przepustowość radiową dla głosu i ruchu CoT wyższego poziomu. Architektura integracji czujników noszonych w aplikacjach polowych szczegółowo omawia pełny stos protokołu BLE i wzorce zarządzania zasilaniem.

Nawigacja piesza w środowiskach miejskich

Środowiska miejskie prezentują najbardziej wymagający technicznie scenariusz nawigacji pieszej: GPS jest zdegradowany lub nieobecny wewnątrz budynków, pionowa pozycja na poziomie piętra ma znaczenie dla decyzji taktycznych, konstrukcje budynków wytwarzają zakłócenia wielodrożności zniekształcające nawet częściowe ustalenia GPS, a przestrzeń nawigacyjna jest trójwymiarowa w sposób, którego oprogramowanie nawigacji terenowej nie uwzględnia. Aplikacja nawigacyjna zaprojektowana do operacji miejskich musi adresować wszystkie te wyzwania jednocześnie.

Plany pięter budynków rozszerzają mapę 2D o wymiar pionowy. Dane planów pięter pakowane są jako warstwy Geopackage, po jednej warstwie na piętro, indeksowane numerem piętra i identyfikatorem budynku. Aplikacja nawigacyjna renderuje plan piętra jako półprzezroczystą nakładkę na mapie bazowej, automatycznie przełączając piętra, gdy wysokościomierz barometryczny wykryje zmianę wysokości żołnierza o pełną wysokość piętra (zwykle 3–4 m). Wykrywanie schodów używa sygnału złożonego detektora kroków (potwierdzającego lokomocję) i utrzymanej dodatniej lub ujemnej prędkości pionowej barometrycznej (potwierdzającej zmianę wysokości): sekwencja kroków towarzysząca spójnemu wznoszeniu barometrycznemu 3–4 m/min wyzwala inkrementację piętra i przełącza nakładkę na następną warstwę planu piętra. Wykrywanie windy stosuje heurystykę: szybka zmiana wysokości (>0,5 m/s tempa barometrycznego) bez potwierdzenia aktywności chodzenia przez detektor kroków wyzwala zdarzenie windy i odpowiednio aktualizuje licznik pięter, choć z niższą pewnością niż wykrywanie schodów i z opóźnieniem potwierdzenia.

Degradacja GPS w kanionach miejskich to stan ciągły i zmienny. W miarę ruchu żołnierza przez gęsty obszar miejski jakość GPS waha się z kwartału na kwartał: otwarte skrzyżowanie może zapewnić HDOP 1,5 z ośmioma satelitami w polu widzenia; wąska ulica flankowana sześciopiętrowymi budynkami może dać HDOP 12 z trzema satelitami i znaczącym zanieczyszczeniem wielodrożnościowym. Aplikacja nawigacyjna monitoruje HDOP, liczbę satelitów, stosunek sygnał-szum dla każdego śledzonego satelity oraz spójność pozycji między kolejnymi ustaleniami. Nagły skok pozycji ponad 15 m między kolejnymi ustaleniami 1 Hz to silny wskaźnik wielodrożności; aplikacja reaguje zwiększeniem szacunku niepewności pozycji, mieszając ustalenie GPS z szacunkiem rachuby drogi IMU w odwrotnej proporcji do ich odpowiednich niepewności i logując anomalię do analizy po misji.

Dokładność pozycjonowania wielopiętrowego zależy silnie od jakości i aktualności kalibracji barometrycznej. Bezwzględne odniesienie wysokościowe wysokościomierza dryfuje wraz ze zmianą ciśnienia atmosferycznego w trakcie misji — zmiana ciśnienia 3 hPa (powszechna w ciągu 6 godzin) odpowiada w przybliżeniu 25 m pozornej zmiany wysokości, co w systemie nieskorygowanym dałoby błąd wielopiętrowy. Standardowe złagodzenie to rekalibracja odniesienia barometrycznego przy każdym ustaleniu GPS (używając wartości HAE GPS, skorygowanej o model geoidy, jako odniesienia wysokościowego) oraz akceptacja ręcznego wprowadzenia piętra przez operatora przy wchodzeniu do budynku, gdzie ustalenie GPS wejścia dostarcza punktu kalibracyjnego parteru. Wewnętrzna nawigacja wielopiętrowa z dokładnością poniżej piętra wymaga tej dyscypliny kalibracji; bez niej barometryczna identyfikacja piętra degraduje się do dokładności ±1 piętra dla okresów bez GPS przekraczających 15–20 minut.