Реалізація SLAM-алгоритмів для AR-навігації в мобільному додатку
SLAM (Simultaneous Localization and Mapping) — це те, що робить ARKit та ARCore "під капотом". Система одночасно будує карту невідомого простору та визначає власне положення в цій карті. Коли ARKit "втрачає tracking" — він втратив консистентність SLAM-карти. Коли потребно AR-додаток з більш точною, стійкою або спеціалізованою навігацією, ніж дає стандартний ARKit/ARCore — впроваджуємо кастомний SLAM або розширюємо існуючий.
Чому стандартного ARKit бувает недостатньо
ARKit реалізує Visual-Inertial Odometry (VIO): feature points з камери + IMU-дані. Працює чудово у хорошо освітленому просторі з багатою текстурою. Справляє в:
- Динамічних сценах: люди ходять, створюють "помилкові" feature points, система плутається
- Монотонних поверхнях: довгий білий коридор — feature points нема до чого зацепитись, drift росте
- Великих просторах: на 200+ метрах накопична помилка VIO стає неприйнятною
- Умовах низької освітленості: ночні склади, темні коридори
Ці сценарії потребують або додаткових сенсорів, або кастомних алгоритмів поверх стандартного фреймворку.
Основні SLAM-варіанти для мобільного AR
ORB-SLAM3 на мобільному. Open-source реалізація, підтримує monocular, stereo, RGB-D. Компілюємо через CMake для iOS (Metal) / Android (через NDK). Продуктивність: iPhone 13 Pro — близько 25–30 FPS з повним tracking, що на межі прийнятного для AR. Потребує C++ bridging: ObjectiveC++ wrapper для iOS, JNI для Android. Використовуємо коли потребно контроль над алгоритмом та стандартний ARKit неприйнятний по точності.
ARKit + Core Location fusion. Для outdoor/large-scale indoor: інтегруємо GPS (CLLocationManager), компас та барометр з ARKit-tracking через Extended Kalman Filter. Коригує drift кожні N метрів при появі GPS-сигналу. Реалізуємо фільтр на C++ через Eigen або на Swift через Accelerate framework.
LiDAR + IMU SLAM (iOS). ARWorldTrackingConfiguration з sceneReconstruction дає depth data з LiDAR. Комбінація depth + RGB + IMU — це RGB-D SLAM. Для точної indoor навігації: будуємо dense map з ARMeshAnchor, використовуємо ICP (Iterative Closest Point) для loop closure при поверненні до відвіданих зон.
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) для швидкого пошуку подібних ключових кадрів.
Практичний кейс
Для складу площею 8 000 кв. м будували AR-навігацію для комплектувальників. Стандартний ARCore втрачав tracking на монотонних стелажах через 40–60 секунд. Рішення: сітка ArUco-маркерів кожні 15 м як relocalization anchors + PDR між маркерами через Android Step Counter API. Точність позиціонування — 0.5–1.5 м, достатньо для указання конкретного стелажу. Система працює в offline без сервера — карта маркерів зашита у додатку та оновлюється при зміні планування складу через внутрішній CMS.
Що входить у роботу
- Аналіз умов експлуатації та вибір SLAM-архітектури
- Реалізація або інтеграція SLAM-алгоритму (ORB-SLAM3, OpenVSLAM, кастомний)
- Fusion з додатковими сенсорами (GPS, UWB, barometer)
- Tune параметрів трекінгу під конкретне окруження
- Метрики точності: ATE (Absolute Trajectory Error), RPE (Relative Pose Error)
Терміни: інтеграція готового SLAM SDK з кастомізацією — 4–8 тижнів. Кастомний SLAM-модуль з нуля + tune під конкретне окруження — 3–6 місяців. Вартість індивідуальна.