Navigation apps for dismounted soldiers: offline maps, GPS-denied positioning and route planning

A dismounted soldier operates in conditions that defeat nearly every assumption underlying consumer navigation software. Connectivity is intermittent or absent. GPS signals are jammed, spoofed, or attenuated by urban structures. The display must be readable in direct sunlight with gloves on. Battery life must cover a full operational period without resupply. The application must continue providing useful position estimates when all external signals disappear — and it must communicate clearly to the operator how confident that estimate actually is. This article covers the engineering decisions behind military navigation apps designed for dismounted infantry use: the hardware constraints that shape every design choice, the map package formats that support offline mapping military operations, the sensor fusion algorithms that maintain position when GPS fails, and the integration patterns that connect a handheld navigation device to wrist-mounted displays, helmet-mounted optics, and the squad's mesh communications network.

Navigation requirements for dismounted soldiers

The requirements envelope for dismounted soldier navigation differs from vehicular or aviation navigation in almost every dimension. Accuracy requirements for infantry-scale operations are typically 10–30 m CEP (circular error probable) during GPS-available conditions, with graceful degradation to 50–100 m CEP acceptable during GPS-denied intervals of up to 10 minutes. At the squad level, relative position accuracy — where each soldier is relative to the others — is often more operationally critical than absolute position accuracy, because tactical decisions depend on squad geometry rather than grid coordinates.

Weight and battery constraints shape every hardware and software decision. A soldier's total load already exceeds 30 kg in a typical combat configuration; the navigation device must add less than 300 g including its battery. That battery must power the device for an entire operational period — commonly 8–12 hours — which, at a display brightness sufficient for daylight readability (600 nits minimum; 800–1000 nits for direct-sun conditions), limits the hardware design to displays consuming no more than 300–600 mW. The sensor fusion stack itself must fit within a 150–400 mW power budget, meaning that power-hungry techniques such as continuous camera-based visual odometry are difficult to sustain for a full operational period and must be treated as targeted supplements rather than primary positioning methods.

Screen readability in daylight is a non-negotiable requirement that directly constrains the software's color palette and rendering design. Map layers that rely on low-contrast pastel color schemes, fine-line grid overlays, or text smaller than 14pt effective size will be unreadable in direct sunlight on a 600-nit display. Military navigation apps use high-contrast rendering schemes — white or cyan icons on dark map backgrounds, heavy line weights for route overlays, and large touch targets compatible with gloved hands (minimum 8 mm touch target diameter per MIL-STD guidance). Night-vision compatibility — typically a red-only rendering mode that does not white-light-wash a soldier's night-adapted vision — must be switchable in a single tap.

Offline map packages for dismounted use

Connectivity in dismounted operations is the exception, not the norm. Map tiles must be stored locally before the mission. The two dominant formats for offline tactical map packages are MBTiles (raster) and vector tile packages in MBTiles or PMTiles container format, and the choice between them determines the storage footprint, rendering performance, and flexibility available to the operator in the field.

MBTiles raster packages store pre-rendered PNG or JPEG tile images at multiple zoom levels in an SQLite container. Each tile is a fixed-size image (typically 256 × 256 pixels) covering a geographic bounding box at a specific zoom level. Rendering is a straightforward tile fetch-and-blit operation that imposes minimal CPU load — any device capable of running Android can render raster tiles at full frame rate. The cost is storage: a 1:25,000-scale raster package for a 100 km × 100 km operational area covering zoom levels 10–16 (the range needed for planning to building-scale navigation) requires 500 MB to 3 GB depending on terrain imagery detail and tile compression. For a device with 64 GB of storage allocated between the OS, navigation app, and comms software, this represents a significant fraction of available space. Selective area download — restricting the package to a bounding polygon rather than a rectangular bounding box — can reduce the storage requirement by 30–70% for non-rectangular operational areas. Most offline mapping military operations platforms support polygon-clipped tile generation at the server side before distribution to field devices.

Vector tile packages store geographic features as compressed protobuf geometry and attribute data rather than rendered images. The same 100 km × 100 km area in a vector package typically occupies 30–200 MB — a 10–15× reduction compared to raster at equivalent zoom coverage. The reduction comes from the geometric compressibility of line and polygon features compared to photographic imagery. Vector tiles render on-device from style rules: the rendering engine applies the current style sheet to the geometry at display time, which enables dynamic restyling (switching between day and night palettes, showing or hiding specific feature classes, adjusting label density) without downloading a new tile set. The trade-off is rendering computation: vector tile rendering on a mid-range mobile processor requires a capable GPU and adds 15–40% to CPU utilization compared to raster tile display, which has a corresponding battery impact. The practical recommendation for dismounted soldier navigation apps is to use vector tiles as the default offline format on modern tactical Android devices, with raster MBTiles as the fallback option for legacy or low-power hardware.

GPS-denied positioning: dead reckoning and PDR

When GPS signals are jammed, spoofed, or attenuated below the fix threshold, the first fallback available on any smartphone-class device is pedestrian dead reckoning (PDR) from the built-in IMU. PDR estimates position by integrating step-by-step displacements in the estimated heading direction, without requiring any external signal or infrastructure. Understanding the achievable accuracy and error growth characteristics of PDR is essential for designing a navigation app that gives operators realistic confidence in their position during GPS-denied periods.

The PDR algorithm begins with step detection. The soldier's walking gait produces a characteristic periodic signal in the vertical accelerometer channel: as the foot strikes the ground and the body's center of mass rises and falls through each stride, the measured vertical acceleration oscillates at the walking cadence (typically 1.0–1.8 Hz for loaded infantry). The step detector identifies each cadence peak using a threshold crossing or peak-finding algorithm applied to a low-pass-filtered accelerometer signal. Each detected step contributes a displacement estimate: the step length is computed from the peak-to-peak acceleration magnitude through an empirical model calibrated to the soldier's height, gait, and load — commonly a model of the form L = K · √(a_max − a_min), where K is a person-specific calibration constant and a_max and a_min are the peak and trough acceleration values within the step cycle. Heading for each step is taken from the magnetometer-derived compass bearing, with the gyroscope providing short-term heading reference during intervals of magnetic disturbance from carried equipment or nearby vehicles.

Under controlled conditions, PDR achieves step length estimation errors of 2–5% and heading drift rates of 1–5 degrees per minute. Translating to operational terms: after 5 minutes of patrol movement covering approximately 400 m, position error is typically 20–50 m. After 15 minutes (1200 m), error grows to 80–200 m — large enough to place the displayed position on the wrong block. PDR is therefore a bridge capability for GPS gaps of a few minutes, not a long-duration positioning solution. The software must display the growing uncertainty honestly, making it clear to the operator when the displayed position is a dead reckoning estimate and how long it has been running without a GPS correction.

ZUPT (zero-velocity update) is the most effective technique for slowing PDR error accumulation. During the stance phase of each walking step — the brief interval when the foot is flat on the ground — the foot has exactly zero velocity in the world frame. A ZUPT-enabled filter detects this interval from the accelerometer's flat signature and applies a zero-velocity pseudo-measurement to the Kalman filter state, which uses this constraint to estimate and partially cancel the accumulated accelerometer and gyroscope biases. Applied at every step, ZUPT can reduce position drift rates by up to 40% compared to open-loop PDR. For a foot-mounted IMU (as opposed to a pocket-carried device), ZUPT is substantially more effective because the foot is guaranteed to be stationary during stance phase; a pocket device may still exhibit sensor motion during the nominal stance phase due to clothing movement.

Sensor fusion for improved positioning

A production military navigation stack does not rely on any single sensor. The architecture is a multi-source fusion engine — typically an Extended Kalman Filter (EKF) — that continuously combines measurements from all available sensors, weighting each by its current accuracy, and produces a unified position and velocity estimate with an associated uncertainty covariance. The sensors feeding the fusion engine in a typical dismounted soldier device are: GPS (when available), the IMU accelerometer and gyroscope, the barometric altimeter, and the magnetometer. External inputs — RF-based position estimates, ZUPT pseudo-measurements, and collaborative position updates from squad members over the mesh radio — are fed as additional measurement inputs to the same filter.

The GPS measurement model contributes a 3D position fix with horizontal accuracy (reported as HDOP-weighted CEP) and vertical accuracy (VDOP-weighted). When GPS is available and HDOP is below 2.0, GPS dominates the filter's position estimate. As HDOP rises (degraded satellite geometry in urban canyons), the filter naturally reduces the GPS measurement weight and allows the IMU prediction to carry more of the estimate. The transition from GPS-dominated to IMU-dominated operation is smooth and continuous rather than a sudden switch, which prevents the position display from jumping when GPS quality degrades.

The barometric altimeter contributes altitude measurements at high update rates (10–50 Hz), with noise characteristics that are fundamentally different from GPS altitude: GPS altitude errors are approximately Gaussian with a standard deviation of 5–15 m; barometric altitude errors are dominated by temperature-induced pressure drift that evolves slowly over tens of minutes and can be modeled as a random walk. The filter treats barometric altitude as a high-update-rate measurement that provides altitude rate of change accurately, while relying on GPS altitude for absolute altitude reference. The combination achieves vertical accuracy of 2–5 m when GPS is available — significantly better than GPS altitude alone — and maintains useful altitude estimates (floor-level accuracy in buildings) for 5–15 minutes after GPS loss, limited by barometric drift.

The magnetometer contributes heading measurements that are accurate in open environments but degrade in the presence of ferromagnetic disturbance. The fusion filter models magnetometer reliability using a magnetic disturbance detector: if the measured magnetic field magnitude deviates more than a threshold from the expected Earth field strength, the magnetometer measurement is rejected and the heading estimate relies solely on gyroscope integration until the disturbance clears. This prevents ferromagnetic objects — weapon barrels, vehicle frames, reinforced concrete structures — from corrupting the navigation solution with false heading readings.

Waypoint and route management

Waypoint and route management in a dismounted navigation app must support the full mission planning lifecycle: import of pre-planned routes from the operations cell, on-device modification during movement, and export of updated routes back to the C2 system. The three universal interchange formats for military waypoint data are CoT (Cursor on Target) XML, KML (Keyhole Markup Language), and GPX (GPS Exchange Format).

CoT XML is the native format of the TAK ecosystem and the standard for real-time position and mission data exchange between ATAK clients and TAK Server. A CoT waypoint is a point event with a uid (universally unique identifier), type (the TAK type hierarchy, e.g. b-m-p-w for a waypoint marker), time and stale fields, and coordinate data in the point element. Route data is encoded as a CoT route event linking an ordered sequence of waypoint uids. The import parser must handle CoT version 2.0 XML and normalize the HAE (height above ellipsoid) coordinate to the WGS84 reference used by the navigation stack. For ATAK plugins for dismounted operations, CoT is the native format and no conversion is needed; the plugin accesses waypoints directly through the ATAK MapView API.

On-device route planning with offline terrain enables ETA calculation and route optimization without connectivity. The planning engine accesses the locally stored DEM (digital elevation model) — typically SRTM 30m or a higher-resolution 10m or 1m product pre-packaged with the map download — and applies Tobler's hiking function to estimate travel speed along each segment based on slope. The ETA for a route is the sum of per-segment times: time = distance / speed(slope). Modifiers for load-bearing weight, surface type (vegetation, sand, rubble), and movement mode (tactical bounds vs continuous movement) are configurable in the mission profile. In practice, Tobler-based ETA estimates agree with measured movement times within 15–20% for unencumbered movement on known terrain, with larger errors in complex urban environments where route topology (stairs, locked doors, choke points) dominates over terrain slope.

Route modification during movement — adding a waypoint, skipping a waypoint, rerouting around an obstacle — must be completable with one or two gloved-hand taps on the map display. The standard interaction pattern is: long-press on the map to place a new waypoint; drag existing waypoints to adjust their position; tap a waypoint and select "skip" to remove it from the active route without deleting it from the mission data set. All modifications are logged with a timestamp and the modification source (operator action vs mesh-synchronized update from the operations cell) to maintain an audit trail for after-action review.

Integration with wearable soldier systems

A soldier navigating in a tactical environment cannot hold a phone at eye level to check the map — both hands may be occupied with a weapon or equipment, and looking at a handheld device exposes the operator's face and breaks situational awareness. Wearable soldier systems — wrist-mounted displays and helmet-mounted displays — bring the navigation output to the operator without requiring a hand or a gaze break. The software integration for each display type imposes distinct constraints.

Wrist-mounted displays (WMDs) are the more common and lower-cost option. A ruggedized Android-based smartwatch or wrist-board receives navigation data from the primary device over BLE, rendering a simplified navigation view on a 1.4–2.4 inch screen. The BLE connection uses a custom GATT service profile that carries a compact navigation update packet: heading to next waypoint (2 bytes), distance to next waypoint (3 bytes), GPS/INS source indicator (1 byte), position uncertainty radius in metres (2 bytes), and battery state (1 byte). Total packet size is under 32 bytes, well within BLE MTU constraints. The WMD navigation app renders a heading-up mini-map with the soldier's position centered, waypoints at their relative bearings, and a status bar showing source and battery. Interaction is limited to a few hardware buttons: confirm waypoint arrival, request emergency position broadcast, and toggle night-vision mode.

Helmet-mounted displays (HMDs) project a transparent heads-up display (HUD) overlay onto the operator's field of view. The software produces a HUD overlay rather than a full-screen map: a compass arc at the top of the field, a bearing pointer and distance readout for the next waypoint, and a small GPS/INS source indicator. HMD integration typically uses an Android HMD SDK or a video overlay interface (HDMI or MIPI-DSI). Power draw is higher than WMD — the display projector adds 200–600 mW — but the HMD connects to the main device battery rather than carrying its own, so battery planning uses the primary device's power budget.

BLE beaconing for squad proximity tracking runs in parallel with the wearable display connection. Each device broadcasts a custom BLE advertisement packet at 100–500 ms intervals, encoding a compressed position update (lat/lon/hae in 12 bytes at 1 cm resolution), a 4-byte timestamp, and a 4-byte device identifier. Squad members' devices receive these broadcasts and display each member's position on the navigation map as an icon with a color indicating position source quality (green for GPS, amber for mixed, red for dead reckoning only). BLE provides genuine squad cohesion awareness at 10–80 m range without requiring the tactical mesh radio, conserving radio bandwidth for voice and higher-level CoT traffic. Wearable sensor integration field apps architecture covers the full BLE protocol stack and power management patterns in detail.

Dismounted navigation in urban environments

Urban environments present the most technically demanding dismounted navigation scenario: GPS is degraded or absent inside buildings, the floor-level vertical position matters for tactical decisions, building structures create multipath interference that corrupts even partial GPS fixes, and the navigable space is three-dimensional in a way that outdoor terrain navigation software does not account for. A navigation app designed for urban operations must address all of these challenges simultaneously.

Building floor plans extend the 2D map into the vertical dimension. Floor plan data is packaged as GeoPackage layers, with one layer per floor indexed by floor number and building identifier. The navigation app renders the floor plan as a semi-transparent overlay on the base map, switching floors automatically as the barometric altimeter detects the soldier's altitude changing by a full floor height (typically 3–4 m). Staircase detection uses the combined signal of the step detector (confirming locomotion) and a sustained positive or negative barometric vertical rate (confirming altitude change): a sequence of steps accompanied by a consistent 3–4 m/min barometric ascent rate triggers a floor increment and switches the overlay to the next floor plan layer. Elevator detection applies a heuristic: a rapid altitude change (>0.5 m/s barometric rate) without the step detector confirming walking activity triggers an elevator event and updates the floor counter accordingly, though with lower confidence than stair detection and subject to a confirmation delay.

Urban canyon GPS degradation is a continuous and variable condition. As the soldier moves through a dense urban area, GPS quality fluctuates from block to block: an open intersection may provide HDOP 1.5 with eight satellites in view; a narrow street flanked by six-story buildings may produce HDOP 12 with three satellites and significant multipath contamination. The navigation app monitors HDOP, satellite count, signal-to-noise ratio on each tracked satellite, and position consistency across successive fixes. A sudden position jump of more than 15 m between consecutive 1 Hz fixes is a strong multipath indicator; the app responds by increasing the position uncertainty estimate, blending the GPS fix with the IMU dead reckoning estimate in inverse proportion to their respective uncertainties, and logging the anomaly for post-mission analysis.

Multi-floor positioning accuracy depends heavily on the quality and currency of the barometric calibration. The altimeter's absolute altitude reference drifts with changing atmospheric pressure over the course of a mission — a 3 hPa pressure change (common over a 6-hour period) corresponds to approximately 25 m of apparent altitude change, which would produce a multi-floor error in an uncorrected system. The standard mitigation is to recalibrate the barometric reference at each GPS fix (using the GPS HAE value, corrected for the geoid model, as the altitude reference) and to accept a manual floor entry from the operator when entering a building where the entrance GPS fix provides the ground-floor calibration point. Indoor multi-floor navigation with sub-floor accuracy requires this calibration discipline; without it, barometric floor identification degrades to ±1 floor accuracy for GPS-denied periods exceeding 15–20 minutes.