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

Потеря 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 — 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-подходов

Подробнее о 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. Входит в нашу стандартную поставку.

Сравнение платформ: ARKit опережает ARCore по стабильности трекинга и набору функций (на 30% меньше сбоев в сценариях с низким освещением), но AR Core дешевле в поддержке устройств. 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 (Banuba Face AR SDK documentation) — покрывает оба устройства, даёт готовые маски и стабильный трекинг даже на 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-идею.