Розробка мобільного AR-додатку для навігації всередину приміщень (Indoor Navigation)
GPS всередину будівель не працює. Користувач в аеропорту Хітроу стоїть у виході C12 та намагається знайти залу прильотів через додаток з картою — карта показує синю крапку десь у районі терміналу, похибка 10–20 метрів. AR indoor navigation вирішує це принципово по-іншому: камера телефону читає навколишнє середовище та будує маршрут поверх реального зображення з точністю до 1–2 метрів.
Три архітектури indoor AR-навігації
VPS (Visual Positioning System)
Найбільш точна, найдорожча в підготовці. Простір попередньо сканується (LiDAR, фотограмметрія), будується point cloud або visual map. Телефон відправляє кадр з камери на сервер → сервер матчить проти visual map → повертає позицію та орієнтацію. Google Maps Indoor (для крупних venue), Immersal SDK, Sturfee — робочі рішення. Immersal надає Unity-плагін та REST API для локалізації; ми інтегруємо їх SDK в нативний iOS/Android код через FFI.
Обмеження: потрібно переснімати при перестановці меблів або ремонту. Плюс серверні витрати на inference.
Marker-based + Floor Map
Швидше в деплое. По приміщенню розставляються QR-коди або ArUco-маркери з відомими координатами в системі плану поверху. ARImageTrackingConfiguration (iOS) / AugmentedImageDatabase (ARCore) визначає найближчий маркер → обчислює позицію користувача → прокладає маршрут за графом приміщення.
Алгоритм маршрутизації: граф з вузлами (маркери, точки повороту, двері, ліфти) та ребрами (коридори). Dijkstra або A* для пошуку найкоротшого шляху. AR-стрілка малюється як ланцюг ARAnchor на висоті 1.5 м над підлогою по точкам маршруту.
IMU + PDR (Pedestrian Dead Reckoning)
Без маркерів, без сервера. CMMotionManager (iOS) або SensorManager (Android) читає акселерометр + гіроскоп + барометр. Алгоритм PDR лічить кроки (step detection через пороговий аналіз норми прискорення), напрямок з гіроскопу, поверх з барометра. Накопичується drift — 2–3% від пройденої відстані. Використовуємо як fallback або в комбінації з маркерною корекцією.
Відображення AR-маршруту
Поширена помилка: малювати стрілку на екрані в 2D поверх камери. Це не AR — це примітивний HUD. Справжній AR-маршрут — це 3D об'єкти, закріплені в світових координатах, які слідують за рухом камери. Реалізація:
// iOS: створюємо ланцюг ARAnchor вздовж маршруту
routePoints.forEach { point in
let anchor = ARAnchor(transform: point.transform)
sceneView.session.add(anchor: anchor)
}
// RealityKit: вішаємо ModelEntity стрілки на кожен anchor
Стрілка гладко повертається до наступної точки через simdLook(at:). При проходженні точки — видаляємо її з сесії, додаємо наступну групу. Дистанція до мети оновлюється через ARCamera.transform → обчислюємо Euclidean distance до destination anchor.
Переходи між поверхами — окрема логіка: детектуємо вхід до ліфту/ескалатора через barometer (CMAltimeter) та floor-change в маршрутному графі.
Інтеграція з venue
Формати плану приміщення: GeoJSON (відкритий стандарт, підтримує indoor), IndoorGML, IMDF (Apple Indoor Maps). Для торговельних центрів часто працюємо з IMDF — Apple Maps підтримує цей формат нативно. Tenant-дані (магазини, години роботи, категорії) витягуються через CMS venue.
Етапи роботи
Survey приміщення (сканування або отримання планів) → побудова навігаційного графу → вибір технології позиціонування → розробка AR-модуля → інтеграція з CMS venue → тестування на місці → ітерації по точності.
Терміни: пілот на одному поверсі з маркерною навігацією — 6–10 тижнів. Багатоповерхова система з VPS та інтеграцією з venue CMS — 4–8 місяців. Вартість залежить від площі venue та вибраного методу позиціонування.