Кастомний SLAM для AR-навігації: точне відстеження

TRUETECH займається розробкою, підтримкою та обслуговуванням мобільних додатків iOS, Android, PWA. Маємо великий досвід та експертизу для публікації мобільних додатків до популярних маркетів Google Play, App Store, Amazon, AppGallery та інші.

Розробка та підтримка будь-яких видів мобільних додатків:

Інформаційні та розважальні мобільні програми
Новинки, ігри, довідники, онлайн-каталоги, погодні, фітнес та здоров'я, туристичні, освітні, соціальні мережі та месенджери, квіз, блоги та подкасти, форуми, агрегатори
Мобільні програми електронної комерції
Інтернет-магазини, B2B-додатки, маркетплейси, онлайн-обмінники, кешбек-сервіси, біржі, дропшиппінг-платформи, програми лояльності, доставка їжі та товарів, платіжні системи
Мобільні програми для управління бізнес-процесами
CRM-системи, ERP-системи, управління проектами, інструменти для команди продажів, облік фінансів, управління виробництвом, логістика та доставка, управління персоналом, системи моніторингу даних
Мобільні програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, платформи надання електронних послуг, платформи кешбеку, відеохостинги, тематичні портали, платформи онлайн-бронювання та запису, платформи онлайн-торгівлі

Це лише деякі з типів мобільних додатків, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 1734 послуг
Кастомний SLAM для AR-навігації: точне відстеження
Складний
від 2 тижнів до 3 місяців
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_mobile-applications_feedme_467_0.webp
    Розробка мобільного додатка для компанії FEEDME
    861
  • image_mobile-applications_xoomer_471_0.webp
    Розробка мобільного додатку для компанії XOOMER
    747
  • image_mobile-applications_rhl_428_0.webp
    Розробка мобільного додатку для компанії RHL
    1163
  • image_mobile-applications_zippy_411_0.webp
    Розробка мобільного додатку для компанії ZIPPY
    1036
  • image_mobile-applications_affhome_429_0.webp
    Розробка мобільного додатку для компанії Affhome
    970
  • image_mobile-applications_flavors_409_0.webp
    Розробка мобільного додатку для компанії FLAVORS
    564

Втрата tracking в AR-додатку на монотонних стелажах або в довгому коридорі — це проблема консистентності SLAM-карти. SLAM (Simultaneous Localization and Mapping) одночасно будує карту невідомого простору та визначає положення пристрою в цій карті. Стандартний ARKit використовує Visual-Inertial Odometry (VIO), який чудово працює при хорошому освітленні та текстурі, але критично збоїть на білих стінах, у великих просторах (дрейф до 5 метрів на 100 метрів шляху) та при динамічних сценах. Якщо вбудованого трекінгу недостатньо, ми впроваджуємо кастомний SLAM на базі ORB-SLAM3, LiDAR+IMU або ArUco-маркерів. Наш досвід — понад 50 проєктів з AR-навігацією в складних умовах: складські приміщення, торговельні центри, промислові об'єкти. Кастомні алгоритми в п'ять разів точніші за стандартний VIO у великих просторах, що підтверджено метриками ATE (Absolute Trajectory Error). Ми використовуємо сучасний стек: Swift 5.9, Kotlin, Flutter, C++. Економія часу на розробку трекінгу становить до 40%, що дозволяє суттєво скоротити time-to-market і зосередитися на бізнес-логіці додатку. При цьому ми гарантуємо стабільність трекінгу в 95% часу роботи.

Обмеження стандартного ARKit у складних умовах

ARKit використовує VIO: feature points з камери + IMU-дані. Це чудово працює при хорошому освітленні та багатій текстурі. Але збої виникають у чотирьох типових сценаріях:

  • Динамічні сцени: люди створюють хибні feature points, дрейф зростає.
  • Монотонні поверхні: довгий білий коридор без зачіпок.
  • Великі простори: на 200+ метрах накопичена помилка VIO стає неприйнятною.
  • Низька освітленість: нічні склади, темні коридори.

Для таких сценаріїв ми застосовуємо кастомні алгоритми або додаткові сенсори.

Основні SLAM-варіанти для мобільного AR

Технологія Точність Складність Термін впровадження
ORB-SLAM3 (C++ Monocular/Stereo/RGB-D) 0.1–0.5 м Висока (NDK/JNI) 8–16 тижнів
ARKit + Core Location (GPS+IMU+Barometer) 1–5 м Середня 4–6 тижнів
LiDAR + IMU (iOS Depth+RGB+ICP loop closure) 0.05–0.2 м Середня 6–10 тижнів
ArUco-маркери + PDR (Indoor, offline) 0.5–1.5 м Низька 2–4 тижні

ORB-SLAM3 — open-source, компілюється через CMake для iOS (Metal) та Android (NDK). На iPhone 13 Pro досягаємо 25–30 FPS, що прийнятно для AR. Вимагає C++ bridging: ObjectiveC++ wrapper під iOS, JNI під Android. Використовуємо, коли потрібен повний контроль над алгоритмом.

ARKit + Core Location fusion — для outdoor/large-scale indoor: інтегруємо GPS (CLLocationManager), компас та барометр з ARKit-tracking через Extended Kalman Filter. Дрейф коригується кожні N метрів при появі GPS-сигналу. Фільтр реалізуємо на C++ через Eigen або на Swift через Accelerate framework.

LiDAR + IMU SLAM (iOS) — ARWorldTrackingConfiguration з sceneReconstruction дає depth data з LiDAR. Комбінація depth + RGB + IMU — це RGB-D SLAM. Будуємо dense map з ARMeshAnchor, використовуємо ICP для loop closure. Це дає сантиметрову точність в indoor.

Як loop closure вирішує проблему дрейфу?

Головна проблема VIO без loop closure: користувач обходить зал по колу і повертається до старту, а SLAM думає, що start та finish — різні місця. Drift накопичився. Loop closure детектує повернення в знайоме місце (за feature descriptors — ORB, SIFT, SuperPoint) і закриває петлю, коригуючи всю карту. В ARKit loop closure відбувається автоматично через relocalization — якщо tracking втрачений і відновлений у відомому місці. Для кастомних систем застосовуємо bag-of-words (DBoW2, FBoW) для швидкої індексації ключових кадрів.

Що таке visual-inertial odometry і коли вона не справляється?

VIO об'єднує візуальні дані камери з інерціальними вимірами IMU. Це основа ARKit та ARCore. VIO чудово працює при достатній кількості feature points і стабільній освітленості. Але вона не справляється в трьох випадках: повна відсутність текстури (білі стіни), різкі рухи (blur), і тривале переміщення без повернення (накопичений drift). У цих ситуаціях кастомний SLAM з loop closure та додатковими сенсорами дає стійкість.

Практичний кейс: AR-навігація на складі 8000 кв. м

Для складу площею 8000 кв. м ми будували AR-навігацію для комплектувальників. Стандартний ARCore втрачав tracking на монотонних стелажах через 40–60 секунд. Наше рішення: сітка ArUco-маркерів кожні 15 м як relocalization anchors + PDR між маркерами через Android Step Counter API. Точність позиціонування — 0.5–1.5 м, достатньо для вказівки конкретного стелажа. Система працює в offline без сервера — карта маркерів зашита в додаток і оновлюється при зміні планування через внутрішній CMS.

Порівняння точності: кастомне рішення ArUco+PDR в 3 рази стабільніше за VIO на площі понад 1000 кв. м.

Покрокове налаштування ORB-SLAM3 на iOS

  1. Компіляція ORB-SLAM3 для iOS через CMake з Metal backend.
  2. Створення Objective-C++ wrapper для інтеграції зі Swift.
  3. Калібрування камери: матриця intrinsics, коефіцієнти дисторсії.
  4. Запуск трекінгу: налаштування параметрів ORB (кількість фіч, масштаб).
  5. Включення loop closure: прив'язка до DBoW2 словника.
  6. Оптимізація продуктивності: фільтрація кадрів (пропуск при малому русі), зниження роздільної здатності для RGB.

Порівняння точності різних SLAM-підходів

Підхід ATE (середня помилка) Дрейф на 100 м Необхідні сенсори
VIO (ARKit) 0.5–2 м 2–5 м Камера + IMU
ORB-SLAM3 (mono) 0.1–0.5 м 0.2–1 м Камера (монокуляр)
ORB-SLAM3 (stereo) 0.05–0.2 м 0.1–0.5 м Дві камери
LiDAR + IMU 0.02–0.1 м 0.05–0.2 м LiDAR + IMU
ArUco + PDR 0.5–1.5 м 1–3 м Маркери + IMU

Докладніше про SLAM можна прочитати на Wikipedia.

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

Ми проводимо аналіз умов експлуатації та обираємо SLAM-архітектуру. Реалізуємо або інтегруємо алгоритм (ORB-SLAM3, OpenVSLAM, кастомний), забезпечуємо fusion з додатковими сенсорами (GPS, UWB, barometer). Налаштовуємо параметри трекінгу під конкретне середовище та оцінюємо точність за метриками ATE та RPE (Relative Pose Error).

Терміни: інтеграція готового SLAM SDK з кастомізацією — 4–8 тижнів. Кастомний SLAM-модуль з нуля + налаштування під середовище — 3–6 місяців. Вартість розраховується індивідуально.

Ми використовуємо сучасний стек (Swift, Kotlin, Flutter, C++) та проводимо навантажувальне тестування в реальних умовах. Всі рішення проходять перевірку на стабільність при динамічних сценах та низькій освітленості. Понад 5 років на ринку — понад 50 успішних AR-проєктів. Зв'яжіться з нами для консультації — оцінимо ваш проєкт. Замовте пілотний проєкт — ми покажемо точність на вашому об'єкті.

Ми розробляємо 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. Входить у нашу стандартну поставку.

Задача iOS Android Кроссплатформа
Plane detection ARKit ARCore AR Foundation, Unity
Face tracking ARKit (TrueDepth) ARCore Augmented Faces Banuba, Snap Camera Kit
Image tracking ARKit (Vision) ARCore Augmented Images AR Foundation
Object detection ARKit 3D Object Scanning ARCore немає єдиного SDK
Persistence (збереження якорів) ARKit World Map ARCore Cloud Anchors

Порівняння платформ: 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-ідею.