Ein zu Fuß eingesetzter Soldat wirkt unter Bedingungen, die nahezu jede Annahme zunichtemachen, die der zivilen Navigationssoftware zugrunde liegt. Die Konnektivität ist unterbrochen oder gar nicht vorhanden. GPS-Signale werden gestört, gespooft oder durch städtische Bauwerke abgeschwächt. Die Anzeige muss bei direktem Sonnenlicht und mit Handschuhen lesbar sein. Die Akkulaufzeit muss einen vollen Einsatzzeitraum ohne Nachschub abdecken. Die Anwendung muss auch dann nützliche Positionsschätzungen liefern, wenn alle externen Signale verschwinden – und sie muss dem Bediener klar vermitteln, wie verlässlich diese Schätzung tatsächlich ist. Dieser Artikel behandelt die technischen Entscheidungen hinter militärischen Navigations-Apps für den Einsatz zu Fuß: die Hardware-Einschränkungen, die jede Designentscheidung prägen, die Kartenpaketformate für Offline-Kartierung bei militärischen Operationen, die Sensorfusionsalgorithmen, die die Position halten, wenn GPS ausfällt, und die Integrationsmuster, die ein handgeführtes Navigationsgerät mit handgelenk- und helmfesten Anzeigen sowie dem Mesh-Kommunikationsnetz des Trupps verbinden.

Das Anforderungsprofil für die Navigation von Soldaten zu Fuß unterscheidet sich von der Fahrzeug- oder Luftfahrtnavigation in nahezu jeder Dimension. Die Genauigkeitsanforderungen im infanteristischen Maßstab liegen typischerweise bei 10–30 m CEP (Circular Error Probable) bei verfügbarem GPS; bei GPS-Ausfällen bis zu 10 Minuten ist eine sanfte Degradierung auf 50–100 m CEP akzeptabel. Auf Truppenebene ist die relative Positionsgenauigkeit – die Lage jedes Soldaten gegenüber den anderen – oft operativ kritischer als die absolute Positionsgenauigkeit, denn taktische Entscheidungen hängen von der Truppengeometrie ab, nicht von Gitterkoordinaten.

Gewichts- und Akkubeschränkungen prägen jede Hardware- und Softwareentscheidung. Die Gesamtlast eines Soldaten überschreitet in einer typischen Gefechtskonfiguration bereits 30 kg; das Navigationsgerät darf einschließlich Akku weniger als 300 g zusetzen. Dieser Akku muss das Gerät über einen vollen Einsatzzeitraum betreiben – üblicherweise 8–12 Stunden – was bei einer für Tageslicht lesbaren Bildschirmhelligkeit (mindestens 600 nits; 800–1000 nits bei direkter Sonneneinstrahlung) das Hardwaredesign auf Displays mit höchstens 300–600 mW begrenzt. Der Sensorfusions-Stack selbst muss in ein Energiebudget von 150–400 mW passen; energieintensive Verfahren wie durchgehende kamerabasierte Visual Odometry lassen sich daher schwer über einen vollen Einsatzzeitraum aufrechterhalten und gelten als gezielte Ergänzung, nicht als primäre Ortungsmethode.

Die Lesbarkeit des Bildschirms bei Tageslicht ist eine unverhandelbare Anforderung, die die Farbpalette und das Rendering-Design der Software direkt begrenzt. Kartenebenen mit kontrastarmen Pastellfarben, feinen Gitterrasterungen oder Text mit weniger als 14pt effektiver Größe sind bei direktem Sonnenlicht auf einem 600-Nit-Display nicht lesbar. Militärische Navigations-Apps nutzen kontraststarke Renderingschemata – weiße oder cyanfarbene Symbole auf dunklem Kartenhintergrund, kräftige Linienstärken für Routenüberlagerungen und große Touch-Flächen, die mit Handschuhen bedienbar sind (mindestens 8 mm Touch-Flächen-Durchmesser gemäß MIL-STD-Empfehlung). Die Kompatibilität zur Nachtsicht – typischerweise ein rein rotes Rendering, das die dunkeladaptierte Sicht des Soldaten nicht mit Weißlicht auswäscht – muss mit einem Tipp umschaltbar sein.

Offline-Kartenpakete für den Einsatz zu Fuß

Konnektivität ist bei Operationen zu Fuß die Ausnahme, nicht die Regel. Kartenkacheln müssen vor dem Einsatz lokal gespeichert sein. Die beiden vorherrschenden Formate für Offline-Kartenpakete sind MBTiles (Raster) und Vektorkachelpakete im MBTiles- oder PMTiles-Containerformat; die Wahl zwischen ihnen bestimmt Speicherbedarf, Rendering-Leistung und die Flexibilität für den Bediener im Feld.

MBTiles-Rasterpakete speichern vorgerenderte PNG- oder JPEG-Kachelbilder bei mehreren Zoomstufen in einem SQLite-Container. Jede Kachel ist ein Bild fester Größe (typischerweise 256 × 256 Pixel) für eine geografische Bounding Box bei einer bestimmten Zoomstufe. Das Rendering ist eine einfache Kachelabruf- und Zeichenoperation mit minimaler CPU-Last – jedes Gerät, das Android ausführen kann, kann Rasterkacheln mit voller Bildrate darstellen. Der Preis ist der Speicher: ein Rasterpaket im Maßstab 1:25,000 für ein Einsatzgebiet von 100 km × 100 km über die Zoomstufen 10–16 (der Bereich von der Planung bis zur Navigation im Gebäude-Maßstab) benötigt je nach Detailgrad des Geländebildes und Kachelkompression 500 MB bis 3 GB. Bei einem Gerät mit 64 GB Speicher, der zwischen Betriebssystem, Navigations-App und Kommunikationssoftware aufgeteilt ist, ist das ein erheblicher Anteil des verfügbaren Platzes. Der selektive Gebiets-Download – das Paket auf ein Begrenzungspolygon statt auf ein rechteckiges Bounding Box zu beschränken – kann den Speicherbedarf bei nicht rechteckigen Einsatzgebieten um 30–70% senken. Die meisten Plattformen für Offline-Kartierung bei militärischen Operationen unterstützen die polygonbeschnittene Kachelgenerierung serverseitig vor der Verteilung an die Feldgeräte.

Vektorkachelpakete speichern geografische Objekte als komprimierte Protobuf-Geometrie- und Attributdaten statt als gerenderte Bilder. Dasselbe Gebiet von 100 km × 100 km belegt im Vektorpaket typischerweise 30–200 MB – eine Reduktion um den Faktor 10–15 gegenüber Raster bei gleicher Zoomabdeckung. Die Reduktion folgt aus der geometrischen Komprimierbarkeit von Linien- und Polygonobjekten im Vergleich zu fotografischem Bildmaterial. Vektorkacheln werden auf dem Gerät aus Stilregeln gerendert: die Rendering-Engine wendet das aktuelle Stylesheet bei der Darstellung auf die Geometrie an, was dynamisches Restyling erlaubt (Wechsel zwischen Tages- und Nachtpalette, Ein- und Ausblenden bestimmter Objektklassen, Anpassen der Beschriftungsdichte) ohne Download eines neuen Kachelsatzes. Der Preis ist die Rendering-Rechenleistung: Vektorkacheln auf einem Mittelklasse-Mobilprozessor benötigen eine leistungsfähige GPU und erhöhen die CPU-Auslastung gegenüber der Rasterdarstellung um 15–40%, was sich entsprechend auf den Akku auswirkt. Die praktische Empfehlung für Navigations-Apps zu Fuß ist, Vektorkacheln als Standard-Offlineformat auf modernen taktischen Android-Geräten zu nutzen, mit Raster-MBTiles als Rückfalloption für ältere oder stromsparende Hardware.

Ortung ohne GPS: Dead Reckoning und PDR

Wenn GPS-Signale gestört, gespooft oder unter die Fix-Schwelle abgeschwächt werden, ist der erste Rückfall auf jedem Smartphone-Gerät das Pedestrian Dead Reckoning (PDR) aus dem eingebauten IMU. PDR schätzt die Position durch Integration der schrittweisen Verschiebungen in die geschätzte Bewegungsrichtung und benötigt kein externes Signal und keine Infrastruktur. Die erreichbare Genauigkeit und das Fehlerwachstum von PDR zu verstehen, ist für eine Navigations-App unverzichtbar, die dem Bediener während GPS-Ausfällen ein realistisches Vertrauen in die eigene Position gibt.

Der PDR-Algorithmus beginnt mit der Schritterkennung. Der Gehrhythmus des Soldaten erzeugt im vertikalen Beschleunigungskanal ein charakteristisches periodisches Signal: während der Fuß aufsetzt und der Körperschwerpunkt im Schritt auf und ab geht, schwingt die gemessene vertikale Beschleunigung im Gehtempo (typischerweise 1.0–1.8 Hz für beladene Infanterie). Der Schrittdetektor erkennt jeden Rhythmuspeak über eine Schwellenwertüberschreitung oder einen Peak-Finding-Algorithmus auf einem tiefpassgefilterten Beschleunigungssignal. Jeder erkannte Schritt liefert eine Verschiebungsschätzung: die Schrittlänge wird aus der Peak-to-Peak-Beschleunigungsamplitude über ein empirisches Modell berechnet, das auf Größe, Gangart und Last des Soldaten kalibriert ist – üblicherweise ein Modell der Form L = K · √(a_max − a_min), wobei K eine personenbezogene Kalibrierkonstante ist und a_max und a_min die Spitzen- und Tiefstwerte der Beschleunigung im Schrittzyklus sind. Die Richtung jedes Schritts wird aus dem magnetometerbasierten Kompasspeilwert übernommen; das Gyroskop liefert kurzzeitig die Richtungsreferenz bei magnetischen Störungen durch mitgeführte Ausrüstung oder nahe Fahrzeuge.

Unter kontrollierten Bedingungen erreicht PDR Schrittlängenfehler von 2–5% und Richtungsdriftraten von 1–5 Grad pro Minute. In operative Begriffe übersetzt: nach 5 Minuten Patrouillenbewegung über rund 400 m liegt der Positionsfehler typischerweise bei 20–50 m. Nach 15 Minuten (1200 m) wächst der Fehler auf 80–200 m – groß genug, um die angezeigte Position auf dem falschen Häuserblock zu platzieren. PDR ist daher eine Überbrückungsfähigkeit für GPS-Lücken von wenigen Minuten, keine Lösung für dauerhafte Ortung. Die Software muss die wachsende Unsicherheit ehrlich anzeigen und dem Bediener klar machen, wann die angezeigte Position eine Dead-Reckoning-Schätzung ist und wie lange sie ohne GPS-Korrektur läuft.

ZUPT (Zero-Velocity Update) ist die wirksamste Technik, um die Fehleransammlung von PDR zu verlangsamen. In der Standphase jedes Gehschritts – dem kurzen Intervall, in dem der Fuß flach auf dem Boden steht – hat der Fuß im Weltkoordinatensystem exakt die Geschwindigkeit null. Ein ZUPT-fähiger Filter erkennt dieses Intervall an der flachen Signatur des Beschleunigungsmessers und wendet eine Nullgeschwindigkeits-Pseudomessung auf den Kalman-Filterzustand an; dieser nutzt die Einschränkung, um die angesammelten Bias-Werte von Beschleunigungsmesser und Gyroskop zu schätzen und teilweise zu kompensieren. Bei jedem Schritt angewendet kann ZUPT die Positionsdriftrate gegenüber offenem PDR um bis zu 40% senken. Für eine IMU am Fuß (im Gegensatz zu einem Gerät in der Tasche) ist ZUPT deutlich wirksamer, da der Fuß in der Standphase garantiert stillsteht; ein Taschengerät kann durch Kleiderbewegung auch in der nominellen Standphase Sensorbewegung zeigen.

Sensorfusion für bessere Ortung

Ein produktives militärisches Navigations-System stützt sich nicht auf einen einzelnen Sensor. Die Architektur ist eine Multi-Source-Fusions-Engine – typischerweise ein Extended Kalman Filter (EKF) –, die Messungen aller verfügbaren Sensoren fortlaufend kombiniert, jeden nach seiner aktuellen Genauigkeit gewichtet und eine vereinheitlichte Positions- und Geschwindigkeitsschätzung mit zugehöriger Unsicherheits-Kovarianz liefert. Die Sensoren, die die Fusions-Engine in einem typischen Gerät für Soldaten zu Fuß speisen, sind: GPS (falls verfügbar), der IMU-Beschleunigungsmesser und das Gyroskop, der barometrische Höhenmesser und das Magnetometer. Externe Eingaben – funkgestützte Positionsschätzungen, ZUPT-Pseudomessungen und kollaborative Positionsaktualisierungen von Truppenteilnehmern über den taktischen Mesh-Funk – werden demselben Filter als zusätzliche Messungseingaben zugeführt.

Das GPS-Messmodell liefert einen 3D-Positions-Fix mit horizontaler Genauigkeit (angegeben als HDOP-gewichtetes CEP) und vertikaler Genauigkeit (VDOP-gewichtet). Wenn GPS verfügbar ist und der HDOP unter 2.0 liegt, dominiert GPS die Positionsschätzung des Filters. Wenn der HDOP steigt (verschlechterte Satellitengeometrie in städtischen Schluchten), senkt der Filter die GPS-Messgewichtung und lässt die IMU-Vorhersage mehr von der Schätzung tragen. Der Übergang von GPS- zu IMU-dominierter Operation ist fließend und kontinuierlich statt ein abrupter Wechsel; so springt die Positionsanzeige nicht, wenn die GPS-Qualität abfällt.

Der barometrische Höhenmesser liefert Höhenmessungen mit hoher Aktualisierungsrate (10–50 Hz) und Rauschmerkmalen, die sich grundlegend von der GPS-Höhe unterscheiden: GPS-Höhenfehler sind annähernd gaußverteilt mit einer Standardabweichung von 5–15 m; barometrische Höhenfehler werden von der temperaturbedingten Drift des Luftdrucks dominiert, die sich über Dutzende von Minuten langsam entwickelt und als Random Walk modelliert werden kann. Der Filter behandelt die barometrische Höhe als Messung mit hoher Aktualisierungsrate, die die Höhenänderungsrate präzise liefert, und stützt sich für die absolute Höhenreferenz auf die GPS-Höhe. Die Kombination erreicht bei verfügbarem GPS eine vertikale Genauigkeit von 2–5 m – deutlich besser als GPS-Höhe allein – und hält nützliche Höhenschätzungen (Stockwerksgenauigkeit in Gebäuden) nach GPS-Verlust für 5–15 Minuten, begrenzt durch die barometrische Drift.

Das Magnetometer liefert Richtungsmessungen, die in offener Umgebung genau sind, bei ferromagnetischen Störungen jedoch nachlassen. Der Fusionsfilter modelliert die Magnetometerzuverlässigkeit mit einem magnetischen Störungsdetektor: weicht die gemessene Magnetfeldstärke stärker als ein Schwellenwert von der erwarteten Erdfeldstärke ab, wird die Magnetometermessung verworfen und die Richtungsschätzung stützt sich allein auf die Gyroskopintegration, bis die Störung abklingt. So verhindert die Software, dass ferromagnetische Objekte – Waffenläufe, Fahrgestelle, Stahlbetonbauten – die Navigationslösung mit falschen Richtungswerten verfälschen.

Wegpunkt- und Routenverwaltung

Die Wegpunkt- und Routenverwaltung in einer Navigations-App zu Fuß muss den gesamten Einsatzplanungszyklus unterstützen: Import vorab geplanter Routen aus der Gefechtsstandszelle, Änderung auf dem Gerät während der Bewegung und Export aktualisierter Routen zurück ins C2-System. Die drei universellen Austauschformate für militärische Wegpunktdaten sind CoT (Cursor on Target) XML, KML (Keyhole Markup Language) und GPX (GPS Exchange Format).

CoT XML ist das native Format des TAK-Ökosystems und der Standard für den Echtzeit-Austausch von Positions- und Einsatzdaten zwischen ATAK-Clients und TAK Server. Ein CoT-Wegpunkt ist ein Point-Event mit uid (Universally Unique Identifier), type (die TAK-Typ-Hierarchie, z. B. b-m-p-w für eine Wegpunktmarkierung), time- und stale-Feldern sowie Koordinatendaten im point-Element. Routendaten werden als CoT-Route-Event kodiert, das eine geordnete Folge von Wegpunkt-uids verknüpft. Der Import-Parser muss CoT-Version 2.0 XML verarbeiten und die HAE-Koordinate (Height Above Ellipsoid) auf die vom Navigations-Stack genutzte WGS84-Referenz normieren. Für ATAK-Plugins für Operationen zu Fuß ist CoT das native Format, eine Umwandlung ist nicht nötig; das Plugin greift über die ATAK MapView API direkt auf die Wegpunkte zu.

Die Routenplanung auf dem Gerät mit Offline-Geländedaten ermöglicht ETA-Berechnung und Routenoptimierung ohne Verbindung. Die Planungs-Engine greift auf das lokal gespeicherte DEM (Digital Elevation Model) zu – typischerweise SRTM 30m oder ein höherauflösendes 10m- oder 1m-Produkt, das mit dem Kartendownload vorverpackt ist – und wendet Toblers Gehfunktion an, um die Bewegungsgeschwindigkeit jedes Segments anhand des Gefälles zu schätzen. Die ETA einer Route ist die Summe der Zeiten pro Segment: time = distance / speed(slope). Modifikatoren für Traglast, Untergrundart (Vegetation, Sand, Schutt) und Bewegungsart (taktisches Sprungverhalten vs. kontinuierliche Bewegung) sind im Einsatzprofil konfigurierbar. In der Praxis stimmen Tobler-basierte ETA-Schätzungen bei unbehinderter Bewegung auf bekanntem Gelände innerhalb von 15–20% mit den gemessenen Bewegungszeiten überein; in komplexen städtischen Umgebungen sind die Fehler größer, weil die Routentopologie (Treppen, verschlossene Türen, Engstellen) das Geländegefälle überlagert.

Routenänderungen während der Bewegung – einen Wegpunkt hinzufügen, einen Wegpunkt überspringen, um ein Hindernis herum neu führen – müssen mit ein oder zwei Tipps mit behandschuhter Hand auf der Kartenanzeige abschließbar sein. Das Standard-Interaktionsmuster ist: langes Drücken auf der Karte setzt einen neuen Wegpunkt; bestehende Wegpunkte lassen sich per Ziehen verschieben; ein Tippen auf einen Wegpunkt und die Auswahl von „skip“ entfernt ihn aus der aktiven Route, ohne ihn aus dem Einsatzdatensatz zu löschen. Alle Änderungen werden mit Zeitstempel und Änderungsquelle (Bedieneraktion vs. Mesh-synchronisierte Aktualisierung aus der Gefechtsstandszelle) protokolliert, um eine Prüfspur für die Nachbesprechung zu behalten.

Integration mit tragbaren Soldatensystemen

Ein Soldat in taktischer Umgebung kann kein Telefon auf Augenhöhe halten, um die Karte zu prüfen – beide Hände können mit Waffe oder Ausrüstung belegt sein, und der Blick auf ein Handgerät legt das Gesicht des Bedieners frei und bricht die Lagebewusstheit. Tragbare Soldatensysteme – handgelenkfeste Displays und helmfeste Anzeigen – bringen die Navigationsausgabe an den Bediener, ohne Hand oder Blick abzuziehen. Die Softwareintegration für jeden Anzeigetyp bringt eigene Einschränkungen mit sich.

Handgelenkfeste Displays (WMDs) sind die häufigere und günstigere Option. Eine robuste Android-basierte Smartwatch oder Wrist-Board empfängt Navigationsdaten vom Primärgerät über BLE und rendert eine vereinfachte Navigationsansicht auf einem 1.4–2.4-Zoll-Bildschirm. Die BLE-Verbindung nutzt ein benutzerdefiniertes GATT-Serviceprofil, das ein kompaktes Navigationsaktualisierungspaket trägt: Richtung zum nächsten Wegpunkt (2 bytes), Entfernung zum nächsten Wegpunkt (3 bytes), GPS/INS-Quellenindikator (1 byte), Positionsunsicherheitsradius in Metern (2 bytes) und Akkuzustand (1 byte). Die Gesamtpaketgröße liegt unter 32 bytes, gut innerhalb der BLE-MTU-Grenzen. Die WMD-Navigations-App rendert eine heading-up-Minikarte mit zentrierter Soldatenposition, Wegpunkten in ihren relativen Peilwerten und einer Statusleiste für Quelle und Akku. Die Interaktion beschränkt sich auf einige Hardware-Tasten: Wegpunktankunft bestätigen, Notfall-Positionssendung anfordern und Nachtsichtmodus umschalten.

Helmfeste Displays (HMDs) projizieren eine transparente Head-up-Display-Überlagerung (HUD) ins Blickfeld des Bedieners. Die Software erzeugt eine HUD-Überlagerung statt einer Vollbildkarte: einen Kompassbogen am oberen Rand des Feldes, einen Peilzeiger und eine Entfernungsanzeige für den nächsten Wegpunkt sowie einen kleinen GPS/INS-Quellenindikator. Die HMD-Integration nutzt typischerweise ein Android-HMD-SDK oder eine Video-Overlay-Schnittstelle (HDMI oder MIPI-DSI). Der Energieverbrauch ist höher als bei WMD – der Displayprojektor fügt 200–600 mW hinzu –, aber das HMD wird an die Hauptgeräte-Batterie angeschlossen und trägt keine eigene; die Akku-Planung nutzt daher das Energiebudget des Primärgeräts.

BLE-Beaconing für die Truppennäheverfolgung läuft parallel zur Verbindung der tragbaren Anzeige. Jedes Gerät sendet in Intervallen von 100–500 ms ein benutzerdefiniertes BLE-Advertisement-Paket, das eine komprimierte Positionsaktualisierung (lat/lon/hae in 12 bytes bei 1 cm Auflösung), einen 4-byte-Zeitstempel und einen 4-byte-Geräte-Identifier kodiert. Die Geräte der Truppenteilnehmer empfangen diese Aussendungen und zeigen die Position jedes Mitglieds auf der Navigationskarte als Symbol mit einer Farbe an, die die Qualität der Positionsquelle angibt (grün für GPS, orange für gemischt, rot nur für Dead Reckoning). BLE liefert echte Truppenschluss-Erkennung über 10–80 m, ohne den taktischen Mesh-Funk zu benötigen, und schont so die Funkbandbreite für Sprache und höherstufigen CoT-Verkehr. Die Architektur von Wearable-Sensor-Integration in Feld-Apps behandelt den vollen BLE-Protokollstack und die Energiemanagement-Muster im Detail.

Navigation zu Fuß in städtischer Umgebung

Städtische Umgebungen stellen das technisch anspruchsvollste Szenario für Navigation zu Fuß dar: In Gebäuden ist GPS verschlechtert oder nicht vorhanden, die vertikale Position auf Stockwerksebene ist für taktische Entscheidungen wichtig, Baustrukturen erzeugen Mehrwegeeffekte, die selbst partielle GPS-Fixes verfälschen, und der begehbare Raum ist dreidimensional – in einer Weise, die Gelände-Navigationssoftware im Freien nicht berücksichtigt. Eine für den städtischen Einsatz konzipierte Navigations-App muss all diese Herausforderungen gleichzeitig angehen.

Gebäudegrundrisse erweitern die 2D-Karte in die vertikale Dimension. Grundrissdaten sind als GeoPackage-Ebenen verpackt, mit einer Ebene pro Stockwerk, indexiert nach Stockwerksnummer und Gebäudeidentifier. Die Navigations-App rendert den Grundriss als halbtransparente Überlagerung auf der Basiskarte und wechselt automatisch das Stockwerk, sobald der barometrische Höhenmesser eine Höhenänderung des Soldaten um eine volle Stockwerkshöhe feststellt (typischerweise 3–4 m). Die Treppenerkennung nutzt das kombinierte Signal aus Schrittdetektor (bestätigt Fortbewegung) und anhaltender positiver oder negativer barometrischer Vertikalrate (bestätigt Höhenänderung): eine Folge von Schritten bei konstanten 3–4 m/min barometrischer Steigrate löst eine Stockwerkserhöhung aus und schaltet die Überlagerung auf die nächste Grundrissebene. Die Aufzugerkennung wendet eine Heuristik an: eine schnelle Höhenänderung (>0.5 m/s barometrische Rate), ohne dass der Schrittdetektor Gehaktivität bestätigt, löst ein Aufzugs-Ereignis aus und aktualisiert den Stockwerkszähler entsprechend – allerdings mit geringerer Sicherheit als die Treppenerkennung und mit einer Bestätigungsverzögerung.

Die GPS-Verschlechterung in städtischen Schluchten ist ein ständiger und wechselnder Zustand. Wenn sich der Soldat durch ein dichtes städtisches Gebiet bewegt, schwankt die GPS-Qualität von Häuserblock zu Häuserblock: eine offene Kreuzung kann HDOP 1.5 mit acht sichtbaren Satelliten liefern; eine schmale Straße mit sechsgeschossigen Gebäuden zu beiden Seiten kann HDOP 12 mit drei Satelliten und erheblicher Mehrwegekontamination erzeugen. Die Navigations-App überwacht HDOP, Satellitenanzahl, Signal-Rausch-Abstand jedes verfolgten Satelliten und die Positionskonsistenz über aufeinanderfolgende Fixes. Ein plötzlicher Positionssprung von mehr als 15 m zwischen aufeinanderfolgenden 1 Hz-Fixes ist ein starkes Mehrwege-Indiz; die App reagiert mit einer erhöhten Positionsunsicherheitsschätzung, verschmilzt den GPS-Fix mit der IMU-Dead-Reckoning-Schätzung im umgekehrten Verhältnis ihrer Unsicherheiten und protokolliert die Anomalie für die Einsatznachbereitung.

Die Positionsgenauigkeit über mehrere Stockwerke hängt stark von Qualität und Aktualität der barometrischen Kalibrierung ab. Die absolute Höhenreferenz des Höhenmessers driftet mit dem wechselnden Luftdruck im Lauf eines Einsatzes – eine Druckänderung von 3 hPa (über einen 6-Stunden-Zeitraum üblich) entspricht rund 25 m scheinbarer Höhenänderung und würde in einem unkorrigierten System einen Mehrstockwerksfehler erzeugen. Die Standardmaßnahme ist, die barometrische Referenz bei jedem GPS-Fix neu zu kalibrieren (mit dem GPS-HAE-Wert, geoidmodellkorrigiert, als Höhenreferenz) und beim Betreten eines Gebäudes eine manuelle Stockwerkseingabe durch den Bediener zu akzeptieren, wobei der GPS-Fix am Eingang den Kalibrierpunkt für das Erdgeschoss liefert. Die Indoor-Mehrfachstockwerksnavigation mit Genauigkeit unterhalb einer Stockwerkshöhe erfordert diese Kalibrierdisziplin; ohne sie fällt die barometrische Stockwerkserkennung bei GPS-Ausfällen von mehr als 15–20 Minuten auf ±1 Stockwerk Genauigkeit.

Das Problem der stillen Degradierung bei städtischer Navigation: Der operativ gefährlichste Ausfallmodus bei der Navigation von Soldaten in der Stadt ist der stille Positionsfehler – das Gerät zeigt eine plausible Position, doch das Dead Reckoning ist um 100–200 m abgedriftet, während der Bediener von GPS-Qualität ausging, weil keine Warnung erschien. Eine gut gestaltete Navigations-App muss die Positionsquelle und den Unsicherheitskreis jederzeit sichtbar machen und den Bediener aktiv alarmieren, wenn die Unsicherheit einen konfigurierbaren Einsatzschwellenwert überschreitet. Eine angezeigte Position ohne Vertrauensanzeige ist gefährlicher als gar keine Position.

TAKpilot: Navigationsintegration für Apps zu Fuß

TAKpilot integriert Multi-Source-Navigation – Offline-Kartenpakete, PDR-Dead-Reckoning, Sensorfusion, Wegpunktverwaltung und die Anbindung tragbarer Anzeigen – in das TAK-Ökosystem und gibt Einheiten zu Fuß einen vollständigen Navigations-Stack, der bei nicht verfügbarem GPS sanft degradiert.

TAKpilot entdecken → Briefing buchen

Diese Analyse wurde von Ingenieuren von Corvus Intelligence erstellt, die einsatzkritische Feldanwendungen und Software für das TAK-Ökosystem für Verteidigungs- und Regierungsorganisationen bauen. Unser Team kennenlernen →