Втрата 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
- Компіляція ORB-SLAM3 для iOS через CMake з Metal backend.
- Створення Objective-C++ wrapper для інтеграції зі Swift.
- Калібрування камери: матриця intrinsics, коефіцієнти дисторсії.
- Запуск трекінгу: налаштування параметрів ORB (кількість фіч, масштаб).
- Включення loop closure: прив'язка до DBoW2 словника.
- Оптимізація продуктивності: фільтрація кадрів (пропуск при малому русі), зниження роздільної здатності для 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-проєктів. Зв'яжіться з нами для консультації — оцінимо ваш проєкт. Замовте пілотний проєкт — ми покажемо точність на вашому об'єкті.