Піхотинець діє в умовах, які руйнують майже кожне припущення, що лежить в основі споживчого навігаційного програмного забезпечення. Зв'язок переривчастий або відсутній. Сигнали GPS глушаться, підробляються або послаблюються міськими спорудами. Екран має бути читабельним у прямому сонячному світлі в рукавицях. Час роботи батареї має покривати повний операційний період без поповнення запасів. Застосунок має продовжувати давати корисні оцінки позицій, коли всі зовнішні сигнали зникають — і чітко повідомляти оператору, наскільки впевненою є ця оцінка насправді. Ця стаття охоплює інженерні рішення за військовими застосунками навігації, спроєктованими для піхоти: апаратні обмеження, які формують кожен вибір дизайну, формати пакетів карт, що підтримують офлайн-картографію у військових операціях, алгоритми злиття сенсорів, які підтримують позицію, коли GPS відмовляє, та шаблони інтеграції, що з'єднують ручний навігаційний пристрій із наручними дисплеями, шоломною оптикою та mesh-мережею зв'язку відділення.

Конверт вимог для навігації піхотинця відрізняється від транспортної чи авіаційної навігації майже за кожним виміром. Вимоги до точності для операцій піхотного масштабу зазвичай 10–30 м CEP (ймовірне кругове відхилення) за наявності GPS із прийнятним плавним погіршенням до 50–100 м CEP під час інтервалів без GPS тривалістю до 10 хвилин. На рівні відділення відносна точність позицій — де перебуває кожен боєць відносно інших — часто операційно критичніша за абсолютну точність позиції, бо тактичні рішення залежать від геометрії відділення, а не від координат сітки.

Обмеження ваги та батареї формують кожне апаратне й програмне рішення. Загальне навантаження бійця вже перевищує 30 кг у типовій бойовій конфігурації; навігаційний пристрій має додавати менш як 300 г разом із батареєю. Ця батарея має живити пристрій протягом усього операційного періоду — зазвичай 8–12 годин — що за яскравості екрана, достатньої для читабельності вдень (мінімум 600 ніт; 800–1000 ніт для умов прямого сонця), обмежує апаратний дизайн дисплеями, що споживають не більш як 300–600 мВт. Сам стек злиття сенсорів має вміщуватися в бюджет потужності 150–400 мВт, що означає: енергоємні методи, такі як безперервна візуальна одометрія на основі камери, складно підтримувати повний операційний період, і їх треба розглядати як цільові доповнення, а не основні методи позиціонування.

Читабельність екрана вдень — беззаперечна вимога, яка безпосередньо обмежує палітру кольорів і дизайн рендерингу програмного забезпечення. Шари карти, що покладаються на низькоконтрастні пастельні колірні схеми, тонкі лінійні сітки-нашарування або текст менш як 14 пт ефективного розміру, будуть нечитабельними в прямому сонячному світлі на дисплеї 600 ніт. Військові застосунки навігації використовують висококонтрастні схеми рендерингу — білі або блакитні піктограми на темному фоні карти, товсті лінії для маршрутних нашарувань і великі зони дотику, сумісні з рукавицями (мінімальний діаметр зони дотику 8 мм за настановами MIL-STD). Сумісність із нічним баченням — зазвичай режим рендерингу лише червоним, який не засліплює нічний зір бійця білим світлом — має перемикатися одним дотиком.

Офлайн-пакети карт для пішого використання

Зв'язність у піших операціях — виняток, а не норма. Тайли карти мають зберігатися локально перед місією. Два основні формати офлайн-тактичних пакетів карт — MBTiles (растр) і векторні пакети тайлів у контейнерному форматі MBTiles або PMTiles, а вибір між ними визначає слід у сховищі, продуктивність рендерингу та гнучкість, доступну оператору в полі.

Растрові пакети MBTiles зберігають заздалегідь відрендерені зображення тайлів PNG або JPEG на кількох рівнях масштабу в контейнері SQLite. Кожен тайл — зображення фіксованого розміру (зазвичай 256 × 256 пікселів), що охоплює географічну обмежувальну рамку на певному рівні масштабу. Рендеринг — проста операція отримання та відображення тайла, яка накладає мінімальне навантаження на процесор — будь-який пристрій, здатний запускати Android, може рендерити растрові тайли на повній частоті кадрів. Ціна — сховище: растровий пакет у масштабі 1:25 000 для оперативного району 100 км × 100 км, що охоплює рівні масштабу 10–16 (діапазон, потрібний від планування до навігації в масштабі будівель), потребує 500 МБ до 3 ГБ залежно від деталізації знімків місцевості та стиснення тайлів. Для пристрою з 64 ГБ сховища, розподіленими між ОС, застосунком навігації та програмним забезпеченням зв'язку, це суттєва частка доступного простору. Вибіркове завантаження районів — обмеження пакета многокутником, а не прямокутною обмежувальною рамкою — може зменшити потребу в сховищі на 30–70% для непрямокутних оперативних районів. Більшість платформ офлайн-картографії у військових операціях підтримують генерацію тайлів з обрізанням за многокутником на боці сервера перед розповсюдженням польовим пристроям.

Векторні пакети тайлів зберігають географічні об'єкти як стиснуту геометрію protobuf і дані атрибутів, а не відрендерені зображення. Той самий район 100 км × 100 км у векторному пакеті зазвичай займає 30–200 МБ — скорочення в 10–15 разів порівняно з растром за еквівалентного покриття масштабів. Скорочення походить від геометричної стисливості лінійних і полігональних об'єктів порівняно з фотографічними знімками. Векторні тайли рендеряться на пристрої за правилами стилів: рушій рендерингу застосовує поточну таблицю стилів до геометрії в момент відображення, що дозволяє динамічну зміну стилів (перемикання між денними та нічними палітрами, показ або приховування окремих класів об'єктів, регулювання щільності міток) без завантаження нового набору тайлів. Компроміс — обчислення рендерингу: рендеринг векторних тайлів на мобільному процесорі середнього класу потребує потужного GPU і додає 15–40% до використання процесора порівняно з відображенням растрових тайлів, що має відповідний вплив на батарею. Практична рекомендація для застосунків навігації піхотинців — використовувати векторні тайли як типовий офлайн-формат на сучасних тактичних Android-пристроях, а растрові MBTiles — як резервний варіант для застарілого або малопотужного обладнання.

Позиціонування без GPS: курсове прокладання та PDR

Коли сигнали GPS глушаться, підробляються або послаблюються нижче порога визначення, перший резерв на будь-якому пристрої класу смартфона — піхотне курсове прокладання (PDR) від вбудованого IMU. PDR оцінює позицію, інтегруючи зміщення крок за кроком у напрямку оціненого курсу, без потреби в будь-якому зовнішньому сигналі чи інфраструктурі. Розуміння досяжної точності та характеристик росту помилок PDR необхідне для проєктування застосунку навігації, який дає операторам реалістичну впевненість у їхній позиції під час періодів без GPS.

Алгоритм PDR починається з виявлення кроків. Хода бійця створює характерний періодичний сигнал у вертикальному каналі акселерометра: коли стопа торкається землі, а центр мас тіла підіймається й опускається протягом кожного кроку, виміряне вертикальне прискорення коливається в темпі ходьби (зазвичай 1,0–1,8 Гц для навантаженої піхоти). Детектор кроків визначає кожен пік темпу за перетином порога або алгоритмом пошуку піків, застосованим до сигналу акселерометра з низькочастотним фільтром. Кожен виявлений крок дає оцінку зміщення: довжину кроку обчислюють за різницею піків прискорення через емпіричну модель, відкалібровану під зріст, ходу та навантаження бійця — зазвичай модель форми L = K · √(a_max − a_min), де K — калібрувальна константа для конкретної людини, а a_max і a_min — значення піку та западини прискорення в межах циклу кроку. Курс для кожного кроку беруть із азимуту компаса, виведеного з магнітометра, а гіроскоп забезпечує короткострокову курсову орієнтацію під час інтервалів магнітних завад від спорядження або близьких транспортних засобів.

За контрольованих умов PDR досягає помилок оцінки довжини кроку 2–5% і швидкостей дрейфу курсу 1–5 градусів за хвилину. Перекладаючи на оперативні терміни: після 5 хвилин руху патруля на відстань приблизно 400 м помилка позиції зазвичай становить 20–50 м. Після 15 хвилин (1200 м) помилка зростає до 80–200 м — достатньо, щоб відображена позиція опинилася не в тому кварталі. Тому PDR — місткова можливість для прогалин GPS у кілька хвилин, а не рішення для тривалого позиціонування. Програмне забезпечення має чесно відображати зростаючу невизначеність, даючи зрозуміти оператору, коли відображена позиція є оцінкою курсового прокладання і як довго воно працює без корекції GPS.

ZUPT (оновлення з нульовою швидкістю) — найефективніша техніка уповільнення накопичення помилок PDR. Під час фази опори кожного кроку — короткого інтервалу, коли стопа щільно стоїть на землі, — стопа має рівно нульову швидкість у світовій системі відліку. Фільтр із підтримкою ZUPT виявляє цей інтервал за плоским сигналом акселерометра і застосовує псевдовимірювання нульової швидкості до стану фільтра Калмана, який використовує це обмеження для оцінки та часткового скасування накопичених зсувів акселерометра і гіроскопа. Застосовуючись на кожному кроці, ZUPT може знизити швидкості дрейфу позиції до 40% порівняно з PDR у розімкненому контурі. Для IMU, встановленого на стопі (на відміну від пристрою в кишені), ZUPT значно ефективніший, бо стопа гарантовано нерухома під час фази опори; пристрій у кишені може все ще проявляти рух сенсора під час номінальної фази опори через рух одягу.

Злиття сенсорів для покращеного позиціонування

Продакшн-стек військової навігації не покладається на жоден окремий сенсор. Архітектура — двигун злиття з багатьох джерел, зазвичай розширений фільтр Калмана (EKF), — який безперервно поєднує вимірювання від усіх доступних сенсорів, зважуючи кожне за його поточною точністю, і виробляє єдину оцінку позиції та швидкості з пов'язаною коваріацією невизначеності. Сенсори, що живлять двигун злиття в типовому пристрої піхотинця: GPS (за наявності), акселерометр і гіроскоп IMU, барометричний альтиметр і магнітометр. Зовнішні входи — оцінки позицій на основі РЧ, псевдовимірювання ZUPT та спільні оновлення позицій від членів відділення через mesh-радіостанцію — подаються як додаткові вимірювальні входи до того самого фільтра.

Модель вимірювання GPS дає 3D-визначення позиції з горизонтальною точністю (повідомляється як CEP зі зважуванням HDOP) та вертикальною точністю (зі зважуванням VDOP). Коли GPS доступний і HDOP нижче 2,0, GPS домінує в оцінці позиції фільтра. Коли HDOP зростає (деградована геометрія супутників у міських каньйонах), фільтр природно знижує вагу вимірювання GPS і дозволяє передбаченню IMU нести більшу частину оцінки. Перехід від домінування GPS до домінування IMU плавний і безперервний, а не раптове перемикання, що запобігає стрибкам відображення позиції при погіршенні якості GPS.

Барометричний альтиметр дає вимірювання висоти з високою частотою оновлень (10–50 Гц), з характеристиками шуму, що принципово відрізняються від висоти GPS: помилки висоти GPS приблизно гаусівські зі стандартним відхиленням 5–15 м; помилки барометричної висоти зумовлені температурним дрейфом тиску, який повільно еволюціонує протягом десятків хвилин і може моделюватися як випадкове блукання. Фільтр розглядає барометричну висоту як вимірювання з високою частотою оновлень, яке точно дає швидкість зміни висоти, покладаючись на висоту GPS як абсолютний еталон висоти. Поєднання досягає вертикальної точності 2–5 м за наявності GPS — значно краще, ніж сама висота GPS — і підтримує корисні оцінки висоти (точність на рівні поверхів у будівлях) протягом 5–15 хвилин після втрати GPS, обмежено барометричним дрейфом.

Магнітометр дає вимірювання курсу, які точні у відкритих середовищах, але погіршуються за наявності феромагнітних завад. Фільтр злиття моделює надійність магнітометра через детектор магнітних завад: якщо виміряна величина магнітного поля відхиляється більш як на поріг від очікуваної сили поля Землі, вимірювання магнітометра відкидається, і оцінка курсу покладається лише на інтегрування гіроскопа, доки завада не мине. Це запобігає тому, щоб феромагнітні об'єкти — стволи зброї, рами транспортних засобів, залізобетонні конструкції — псували навігаційне рішення хибними показниками курсу.

Керування маршрутними точками та маршрутами

Керування маршрутними точками та маршрутами в застосунку пішої навігації має підтримувати повний життєвий цикл планування місії: імпорт заздалегідь запланованих маршрутів від оперативної групи, зміну на пристрої під час руху та експорт оновлених маршрутів назад у систему C2. Три універсальні формати обміну даними військових маршрутних точок — CoT (Cursor on Target) XML, KML (Keyhole Markup Language) і GPX (GPS Exchange Format).

CoT XML — рідний формат екосистеми TAK і стандарт обміну даними про позиції та місії в реальному часі між клієнтами ATAK і TAK Server. Маршрутна точка CoT — це подія-точка з uid (універсальним унікальним ідентифікатором), type (ієрархія типів TAK, наприклад b-m-p-w для маркера маршрутної точки), полями time і stale та даними координат в елементі point. Дані маршруту кодуються як подія маршруту CoT, що з'єднує впорядковану послідовність uid маршрутних точок. Парсер імпорту має обробляти XML CoT версії 2.0 і нормалізувати координату HAE (висоту над еліпсоїдом) до еталона WGS84, який використовує навігаційний стек. Для плагінів ATAK для піших операцій CoT — рідний формат, і перетворення не потрібне; плагін отримує доступ до маршрутних точок безпосередньо через API MapView ATAK.

Планування маршрутів на пристрої з офлайн-місцевістю дозволяє обчислення ETA та оптимізацію маршруту без зв'язку. Планувальний рушій отримує доступ до локально збереженої цифрової моделі рельєфу (DEM) — зазвичай SRTM 30 м або продукту з вищою роздільною здатністю 10 м чи 1 м, заздалегідь упакованого із завантаженням карти, — і застосовує функцію ходьби Тоблера для оцінки швидкості руху вздовж кожного сегмента на основі ухилу. ETA маршруту — сума часів по сегментах: час = відстань / швидкість(ухил). Модифікатори для ваги навантаження, типу покриття (рослинність, пісок, руїни) і режиму руху (тактичні пересування стрибками проти безперервного руху) налаштовуються в профілі місії. На практиці оцінки ETA на основі Тоблера збігаються з виміряними часами руху в межах 15–20% для ненавантаженого руху на відомій місцевості, з більшими помилками в складних міських середовищах, де топологія маршруту (сходи, замкнені двері, вузькі місця) домінує над ухилом місцевості.

Зміна маршруту під час руху — додавання маршрутної точки, пропуск маршрутної точки, перепланування навколо перешкоди — має виконуватися одним-двома дотиками в рукавицях до відображення карти. Стандартний шаблон взаємодії: довге натискання на карті для розміщення нової маршрутної точки; перетягування наявних точок для коригування їхніх позицій; дотик до маршрутної точки та вибір «пропустити», щоб видалити її з активного маршруту, не видаляючи з набору даних місії. Усі зміни фіксуються з міткою часу та джерелом зміни (дія оператора чи оновлення, синхронізоване через mesh від оперативної групи) для підтримання аудиторського сліду для розбору після дій.

Інтеграція з носимими системами бійця

Боєць, що орієнтується в тактичному середовищі, не може тримати телефон на рівні очей, щоб перевірити карту — обидві руки можуть бути зайняті зброєю або спорядженням, а погляд на ручний пристрій викриває обличчя оператора і розриває ситуаційну обізнаність. Носимі системи бійця — наручні дисплеї та шоломні дисплеї — підносять навігаційний вихід оператору без потреби звільняти руку чи відводити погляд. Програмна інтеграція для кожного типу дисплея накладає різні обмеження.

Наручні дисплеї (WMD) — поширеніший і дешевший варіант. Загартований Android-смартгодинник або наручна плата отримує навігаційні дані від основного пристрою через BLE і рендерить спрощений навігаційний вигляд на екрані 1,4–2,4 дюйма. BLE-з'єднання використовує спеціалізований профіль служби GATT, який несе компактний пакет навігаційного оновлення: курс до наступної маршрутної точки (2 байти), відстань до наступної маршрутної точки (3 байти), індикатор джерела GPS/INS (1 байт), радіус невизначеності позиції в метрах (2 байти) і стан батареї (1 байт). Загальний розмір пакета — менш як 32 байти, що цілком у межах обмежень MTU BLE. Застосунок навігації WMD рендерить міні-карту в напрямку курсу з позицією бійця в центрі, маршрутними точками за їхніми відносними азимутами та рядком стану, що показує джерело й батарею. Взаємодія обмежена кількома апаратними кнопками: підтвердити прибуття до маршрутної точки, запросити екстрене транслювання позиції та перемкнути режим нічного бачення.

Шоломні дисплеї (HMD) проєктують прозоре нашарування проєкційного дисплея (HUD) на поле зору оператора. Програмне забезпечення створює нашарування HUD, а не повноекранну карту: дугу компаса вгорі поля, покажчик азимуту та показник відстані до наступної маршрутної точки і невеликий індикатор джерела GPS/INS. Інтеграція HMD зазвичай використовує Android HMD SDK або інтерфейс відео-нашарування (HDMI або MIPI-DSI). Споживання енергії вище, ніж у WMD — проєктор дисплея додає 200–600 мВт, — але HMD підключається до батареї основного пристрою, а не має власної, тож планування батареї використовує бюджет потужності основного пристрою.

BLE-маякування для відстеження близькості відділення працює паралельно зі з'єднанням носимого дисплея. Кожен пристрій транслює спеціалізований пакет оголошення BLE з інтервалами 100–500 мс, кодуючи стиснуте оновлення позиції (lat/lon/hae у 12 байтах з роздільною здатністю 1 см), 4-байтну мітку часу та 4-байтний ідентифікатор пристрою. Пристрої членів відділення отримують ці трансляції та відображають позицію кожного учасника на навігаційній карті як піктограму з кольором, що вказує на якість джерела позиції (зелений для GPS, жовтий для змішаного, червоний лише для курсового прокладання). BLE забезпечує справжню обізнаність про згуртованість відділення на дальності 10–80 м без потреби в тактичній mesh-радіостанції, бережучи смугу радіомережі для голосу та трафіку CoT вищого рівня. Архітектура польових застосунків інтеграції носимих сенсорів детально охоплює весь стек протоколу BLE і шаблони керування живленням.

Піша навігація в міських середовищах

Міські середовища дають найскладніший з погляду техніки сценарій пішої навігації: GPS деградує або відсутній усередині будівель, вертикальна позиція на рівні поверху важлива для тактичних рішення, конструкції будівель створюють багатошляхові завади, які псують навіть часткові визначення GPS, а простір для пересування тривимірний так, як програмне забезпечення навігації на відкритій місцевості не враховує. Застосунок навігації, спроєктований для міських операцій, має долати всі ці виклики одночасно.

Поверхові плани будівель розширюють 2D-карту у вертикальний вимір. Дані поверхових планів пакують як шари GeoPackage, по одному шару на поверх, індексований за номером поверху та ідентифікатором будівлі. Застосунок навігації рендерить поверховий план як напівпрозоре нашарування на базовій карті, автоматично перемикаючи поверхи, коли барометричний альтиметр виявляє, що висота бійця змінилася на повну висоту поверху (зазвичай 3–4 м). Виявлення сходів використовує комбінований сигнал детектора кроків (що підтверджує пересування) і тривалого додатного або від'ємного барометричного вертикального градієнта (що підтверджує зміну висоти): послідовність кроків із узгодженою швидкістю барометричного підіймання 3–4 м/хв спричиняє збільшення поверху і перемикає нашарування на наступний шар поверхового плану. Виявлення ліфта застосовує евристику: швидка зміна висоти (барометрична швидкість >0,5 м/с) без підтвердження ходьби детектором кроків спричиняє подію ліфта і відповідно оновлює лічильник поверхів, хоча з нижчою впевненістю, ніж виявлення сходів, і з затримкою підтвердження.

Деградація GPS у міських каньйонах — безперервна і змінна умова. Коли боєць рухається щільним міським районом, якість GPS коливається від кварталу до кварталу: відкрите перехрестя може давати HDOP 1,5 з вісьмома супутниками в полі зору; вузька вулиця, облямована шестиповерховими будівлями, може давати HDOP 12 із трьома супутниками та суттєвою багатошляховою засміченістю. Застосунок навігації моніторить HDOP, кількість супутників, відношення сигнал/шум для кожного відстежуваного супутника та узгодженість позиції між послідовними визначеннями. Раптовий стрибок позиції більш як на 15 м між послідовними визначеннями 1 Гц — сильний індикатор багатошляховості; застосунок реагує, збільшуючи оцінку невизначеності позиції, змішуючи визначення GPS з оцінкою курсового прокладання IMU обернено пропорційно їхнім відповідним невизначеностям і фіксуючи аномалію для аналізу після місії.

Точність позиціонування на кількох поверхах сильно залежить від якості та актуальності барометричного калібрування. Абсолютний еталон висоти альтиметра дрейфує зі зміною атмосферного тиску протягом місії — зміна тиску 3 гПа (типова протягом 6 годин) відповідає приблизно 25 м уявної зміни висоти, що дало б помилку в кілька поверхів у нескоригованій системі. Стандартне пом'якшення — перекалібрування барометричного еталона на кожному визначенні GPS (використовуючи значення HAE GPS, скориговане за моделлю геоїда, як еталон висоти) та прийняття ручного введення поверху від оператора під час входу в будівлю, де визначення GPS на вході дає калібрувальну точку першого поверху. Навігація на кількох поверхах у приміщенні з точністю нижче рівня поверху потребує цієї дисципліни калібрування; без неї барометричне визначення поверху погіршується до точності ±1 поверх для періодів без GPS, що перевищують 15–20 хвилин.

Проблема тихої деградації в міській навігації: Найнебезпечніший з погляду операцій режим відмови в міській навігації бійця — тиха помилка позиції: пристрій показує правдоподібну позицію, але курсове прокладання зсунулося на 100–200 м, тоді як оператор припускав точність рівня GPS, бо попередження не показувалося. Добре спроєктований застосунок навігації має робити джерело позиції та коло невизначеності видимими завжди й активно попереджувати оператора, коли невизначеність перевищує налаштовуваний поріг місії. Відображена позиція без індикатора впевненості небезпечніша, ніж відсутня позиція.

TAKpilot: інтеграція навігації для застосунків піхотинців

TAKpilot інтегрує багатоджерельну навігацію — офлайн-пакети карт, курсове прокладання PDR, злиття сенсорів, керування маршрутними точками та зв'язність носимих дисплеїв — з екосистемою TAK, даючи підрозділам у пішому порядку повний навігаційний стек, який плавно деградує, коли GPS недоступний.

Дослідити TAKpilot → Замовити брифінг

Цей аналіз підготували інженери Corvus Intelligence, які створюють критично важливі для місій польові застосунки та програмне забезпечення екосистеми TAK для оборонних і державних організацій. Дізнайтеся про нашу команду →