Реализация 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. Corrects 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) для быстрого поиска похожих ключевых кадров.
Практический кейс
Для склада площадью 8000 кв. м строили 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 месяцев. Стоимость индивидуальна.