Разработка мобильного AR-приложения для навигации внутри помещений (Indoor Navigation)
GPS внутри зданий не работает. Пользователь в аэропорту Хитроу стоит у выхода C12 и пытается найти зал прилёта через приложение с картой — карта показывает синюю точку где-то в районе терминала, погрешность 10–20 метров. AR indoor navigation решает это принципиально по-другому: камера телефона читает окружающую среду и строит маршрут поверх реального изображения с точностью до 1–2 метров.
Три архитектуры indoor AR-навигации
VPS (Visual Positioning System)
Самое точное, самое дорогое в подготовке. Помещение предварительно сканируется (лидар, фотограмметрия), строится 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 chain на высоте 1.5 м над полом по точкам маршрута.
IMU + PDR (Pedestrian Dead Reckoning)
Без маркеров, без сервера. CMMotionManager (iOS) или SensorManager (Android) читает акселерометр + гироскоп + барометр. Алгоритм PDR считает шаги (step detection через пороговый анализ нормы акселерации), направление из гироскопа, этаж из барометра. Накапливается дрейф — 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 и выбранного метода позиционирования.