AR-навігація в приміщеннях: розробка мобільного застосунку

GPS у приміщеннях дає похибку 10–20 метрів — цього недостатньо для пошуку виходу C12 в аеропорту або конкретного магазину на третьому поверсі торгового центру. AR-навігація в приміщеннях вирішує цю проблему: камера та сенсори телефону визначають положення з точністю до 1–2 метрів і накладають маршрут поверх реального зображення. Наприклад, відвідувач бачить віртуальні стрілки, що вказують поворот до потрібного бутіка, прямо на екрані. Ми більше 5 років розробляємо такі рішення: 20+ проєктів для торгових центрів, аеропортів та офісів. Гарантуємо точність позиціонування в межах 1 метра при комбінуванні методів. В основі — гібридна архітектура: VPS для зон з високою прохідністю, маркери для точних якорів і PDR як fallback при втраті сигналу. Це забезпечує стабільну навігацію навіть у складних умовах: дзеркальні підлоги, перепади яскравості або масові скупчення людей. Візуальне позиціонування (VPS) — технологія, що використовується в багатьох сучасних AR-рішеннях, описана у Wikipedia.

Як вибрати метод позиціонування?

Вибір технології — ключовий етап. У нашій практиці найчастіше застосовуються три підходи: VPS (Visual Positioning System), маркерна навігація та PDR (Pedestrian Dead Reckoning). Їх порівняння дає розуміння, який метод підходить для конкретного об'єкта. Гібридна навігація з маркерами та PDR в 1.5 рази дешевша за чистий VPS при аналогічній точності до 2 метрів.

Порівняння AR SDK для індор-навігації

Ми допомагаємо визначити оптимальний метод на аудиті вашого приміщення. Пишіть нам — оцінимо проєкт за 1 день.

Чому комбіновані методи дають кращий результат?

Жоден метод не ідеальний. VPS точний, але дорогий у підготовці та потребує серверної інфраструктури. Маркерна навігація дешевша, але маркери потрібно оновлювати при кожному переплануванні. PDR повністю автономний, але накопичує помилку з часом. Комбінація методів — наприклад, маркери для початкового калібрування + PDR для міжмаркерних переходів — дає стабільну точність 1–2 метри без постійного сканування. Дослідження показують, що гібридні системи знижують експлуатаційні витрати на 30–40% порівняно з чистим VPS. Для торгового центру площею 50 000 м² чиста VPS-система потребуватиме щомісячних витрат на серверний inference близько 3000 у.о., тоді як комбінація маркерів і PDR скорочує цю суму до 500 у.о., при точності в межах 2 метрів. Окупність — 6–8 місяців. Економія до 40% на експлуатації — це конкретний результат для замовника.

Три архітектури 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 в маршрутному графі.

Що входить у роботу (deliverables)

Наш стандартний перелік включає:

1. Аудит приміщення: отримання планів (DWG, IMDF, GeoJSON) або сканування для VPS.
2. Архітектура навігації під ключ: вибір методу позиціонування, проектування графа маршрутів.
3. Розробка AR-модуля: інтеграція ARKit/ARCore, реалізація маршрутизації та відображення.
4. Інтеграція з CMS venue: прив'язка tenant-даних, оновлення через API.
5. Тестування на місці: верифікація точності на всіх поверхах, ітерації.
6. Документація та доступ до API: технічна документація, ключі доступу.
7. Навчання персоналу замовника: робота з AR-модулем та CMS.
8. Підтримка та оновлення: супровід 3 місяці після запуску, доопрацювання при зміні планування.

Замовте попередню оцінку вашого проєкту — ми проаналізуємо приміщення і запропонуємо оптимальне рішення.

Інтеграція з venue

Формати плану приміщення: GeoJSON (відкритий стандарт, підтримує indoor), IndoorGML, IMDF (Apple Indoor Maps). Для торгових центрів часто працюємо з IMDF — Apple Maps підтримує цей формат нативно. Tenant-дані (магазини, години роботи, категорії) підтягуються через CMS venue. Ми також можемо розробити власне API для управління контентом.

Етапи роботи

1. Survey приміщення (сканування або отримання планів)
2. Побудова навігаційного графа
3. Вибір технології позиціонування
4. Розробка AR-модуля
5. Інтеграція з CMS venue
6. Тестування на місці
7. Ітерації по точності
8. Введення в експлуатацію

Терміни: пілот на одному поверсі з маркерною навігацією — 6–10 тижнів за ціною від 5000 у.о. Багатоповерхова система з VPS та інтеграцією з venue CMS — 4–8 місяців. Вартість розраховується індивідуально в залежності від площі venue та обраного методу. Пишіть нам для консультації — оцінимо проєкт за 1 день та підготуємо комерційну пропозицію.

Ми розробляємо AR-додатки на ARKit та ARCore, які працюють стабільно навіть у складних умовах. Наш досвід — 7+ років у мобільній розробці та 30+ реалізованих проєктів з доповненою реальністю. Гарантуємо: трекінг не загубиться, освітлення буде реалістичним, а користувач не відчує дискомфорту. Сертифіковані розробники Apple та Google.

Чому трекінг втрачається і як це виправити?

ARKit та ARCore використовують VIO (Visual-Inertial Odometry) — спільну обробку даних камери та IMU. Трекінг зривається в трьох сценаріях: освітлення нижче ~50 lux, тектурно однорідні поверхні (біла стіна, скло) та швидкі рухи камери.

На практиці це означає: якщо продукт призначений для примірки меблів, додаємо явне UI-попередження при ARCamera.TrackingState.limited(.insufficientFeatures). Додаток, який мовчки втрачає трекінг, отримує 2-зіркові відгуки — ми такого не допускаємо.

Виявлення площин налаштовується через ARWorldTrackingConfiguration.planeDetection = [.horizontal, .vertical]. Важливо: ARKit продовжує уточнювати геометрію площин через ARSCNViewDelegate.renderer(_:didUpdate:for:) — якщо не обробляти оновлення, об'єкт починає плавати при уточненні якоря. Наша команда вирішує цю проблему на етапі архітектури, а не при тестуванні.

AR Foundation: кроссплатформа з нюансами

Unity AR Foundation — шар абстракції поверх ARKit та ARCore. Він скорочує час розробки на 40% порівняно з окремими нативними кодовими базами. Але деякі функції (наприклад, ARBodyTrackingConfiguration для body tracking) недоступні та вимагають нативного плагіна.

Для React Native та Flutter прямого AR Foundation немає. Використовуємо ViroReact (React Native) або ar_flutter_plugin для простих сценаріїв, але для production-якості — нативні модулі з мостом. Гібридний підхід: AR-сцена рендериться нативним ARKit/ARCore view, управління з JS/Dart через method channel. Входить у нашу стандартну поставку.

Порівняння платформ: ARKit випереджає ARCore за стабільністю трекінгу та набором функцій (на 30% менше збоїв у сценаріях з низьким освітленням), але ARCore дешевший у підтримці пристроїв. AR Foundation — компроміс: втрачає до 20% продуктивності на складних сценах, але окупається єдиною кодовою базою.

Try-on: примірка товарів через AR

Примірка окулярів, прикрас, косметики — окремий клас задач. Тут потрібен face tracking, а не plane detection.

ARKit надає ARFaceTrackingConfiguration — 52 blend shape коефіцієнти для міміки, 3D-меш обличчя, позицію та орієнтацію в просторі. Працює лише на пристроях з TrueDepth-камерою (iPhone з Face ID).

Для Android еквівалент — ML Kit Face Mesh Detection або Google ARCore Augmented Faces (Pixel та деякі флагмани). Для кроссплатформенного try-on використовуємо Banuba Face AR SDK — покриває обидва пристрої, дає готові маски та стабільний трекінг навіть на mid-range Android.

Якість try-on критично залежить від 3D-моделей товарів. Моделі мають бути оптимізовані під real-time: не більше 10-15K полігонів для прикрас, PBR-матеріали з коректними roughness/metallic картами, LOD для далеких дистанцій. В рамках нашого підряду ми надаємо готові гайди з оптимізації моделей.

Як досягти реалістичного освітлення в AR?

ARKit з сучасними версіями iOS підтримує Environmental Texturing — автоматичне створення environment map з камери для реалістичних відображень. Вмикається через ARWorldTrackingConfiguration.environmentTexturing = .automatic. Без цього металеві та скляні матеріали виглядають пластиково.

ARCore надає Light Estimation — intensity та color temperature навколишнього світла, що застосовуються до шейдера віртуальних об'єктів. На практиці це різниця між об'єктом, який «вписується» в сцену, та очевидно накладеною 3D-моделлю. Ми гарантуємо, що фінальне зображення не видає віртуальності.

Що входить в роботу

• Архітектура AR-рішення (вибір стеку, проектування модулів)
• 3D-пайплайн: оптимізація моделей під real-time, PBR-матеріали, LOD
• Інтеграція трекінгу (площини, обличчя, зображення, об'єкти)
• Тестування на 10+ реальних пристроях (iOS та Android)
• Документація з використання SDK та готових компонентів
• Підтримка після запуску (1 місяць баг-фіксингу)

Строки та оцінка

Проста AR-сцена з розміщенням однієї 3D-моделі на площині — 1–2 тижні. Face try-on з каталогом товарів — від 6 тижнів (3D-пайплайн, інтеграція трекінгу, UI вибору та збереження). Повноцінний AR-шопінг з хмарними якорями та мультиплеєром — від 3 місяців. Оцінимо проєкт за 1 день — пишіть, обговоримо вашу AR-ідею.