Поскольку для разработки и отладки интеллектуальной системы навигации требуется постоянная интеграция доработок алгоритмов на рабочем прототипе - разрабатывается минимальная работающая реализация платформы, реализующей интеллектуальную навигацию.
Первый этап разработки предусматривает создание мобильной платформы которая собирает весь спектр информации необходимый для построения разного типа карт. Далее на основе собранных данных производится отладка и доработка системы.
Для доработки системы до уровня стабильной высокопроизволительной системы навигации производится оценка требований и приводится стратегия по развитию каждого компонента системы до необходимого для дальнейшей интеграции уровня.
Для набора алгоритмов и аппаратной реализации производится оценка метрик и оценивается правильность выбора технологии.
Порядок разработки системы предполагает предоставление демонстратора системы, далее доработку системы до готовой к интеграции инфраструктуры и набора алгоритмов.
Демонстратором является мобильная платформа, реализующая навигацию используя начальное GPS решение и далее только набор локальных датчиков для построения карты и локализации.
При низких общих требованиях к физической платформе, система должна демонстрировать весь основной функционал и базовые технологии работы интеллекутуальной системы навигации с инпользованием нейросетевых технологий.
Демонстрация должна показать работу следующих компонентов системы:
- Мобильная платформа (датчики, элементы управление и платформа) - рабочий прототип
- Слияние датчиков и выбор конфигурации
- Сбор картографических данных (LiDAR (LOAM) + воксельная карта)
- Расчет карты (методы нейронной локализации + вспомогательные методы)
- Автономная локализация (начальное GPS >> lidar + IMU + 1 Hz)
- Оценка навигации + глобальная релокализация
- Система для визуализация решения
- Анализ передачи данных на сервер (передача потока изображений и облака точек)
- Демонстрация + отчет по выполнению поставленных задач
Для понимания требований к аппаратной реализации системы, необходимо рассмотреть архитектуру интеллектуальной платформы навигации
Система интеллектуальной навигации включает в себя несколько независимых модулей вычисления координаты пользователя.
Для работы системы в условиях недостаточной или шумной информации из определенных источников, интеллектуальная система навигации проектируется с возможностью максимального совместного исполльзования независимых источников информации.
Архитектура платформы интеллектуальной навигации определяется процедурой сбора и использования данных.
В зависимости от задачи и платформы варьируется набор доступных датчиков и производительность основного вычислительного модуля.
Исходим из принципа увеличения качества информации в системе. Маскимальная точность алгоритма навигации будет при наличии всех возможных данных для каждой конкретной платформы в системе. При этом реализация всегда ограничена конкретной платформой.
Например для смартфона невозможно использование специальных графических ускорителей, следовательно алгоритм должен выполняться на оригинальном процессоре.
Поскольку необходимо организовать выполнение задач по подготовке карты и передачи карты на клиентское устройство (смартфон) - рассмотрим клиент-серверную модель организации системы.
Необходимо определить какие процессы выполняются локально, какие на сервере. В случае разных конфигураций - мобильной платформы робота и телефона реализация будет частично различаться.
При сборе данных необходимо учитывать ограничения на сетевую пропускную способность системы.
Например
| Название стандарта видео | Разрешение | Размер часа видео |
|---|---|---|
| 720p | 1280 x 720 | 800 – 900MB |
| 1080p | 1920 x 1080 | 1.2 – 1.4GB |
| 2K | 2048 x 1080 | 2.8 – 3GB |
| 4K | 3840 x 2160 | 20 – 22GB |
Рассчитаем размер карты для одной локации:
- Площадь 2000 м2
Длина маршрута для покрытия площади:
Для локации прямоугольной площади размером
Поскольку съемка может вестись с разных стророн и для валидации решения необходимо оказаться в одной и той же локации несколько раз, записываем этот маршрут
Если записывается только видео качества
Учитываем что битрейт может отличаться для различных камер и реализации алгоритма.
Итоговый размер файла карты в 4 Гб - один запуск для одного пользователя. Количество информации в минуту для одного пользователя равно соответственно битрейту (1 - 1.4 Gb/s). Поскольку при локализации не происходит обновления карты, можно не задумываться о потоковой передаче карты на сервер для случае обычного пользователя.
Если карту требуется создать и распространить, ее соответственно требуется передать на сервер и обработать. Конечный файл карты в идеале не должен занимать более 100 мб для пользователя смартфонов.
Если представить что набор изображений которые представляют карту сделаны с частотой 1 Hz, для 5 минут видео это примерно 300 изображений. Итоговая дискретизация пространства карты для скорости движения в 3 м/с составляет примерно одно изобрадение каждые 0.3 метра. Примерные значения поулчаются, поскольку маршрут пользователя не является прямой и изображения соответственно не распределены по пространству идеально равномерно.
С учетом коэффициента запаса (2.4) и широкоугольной линзы, считаем что в карте есть изображения в нескольких направлениях. Для частоты выбор аключевых кадров в 1 Hz, итоговый вес файла будет равен отношению исходной частоты съемки к частоте сэмплирования (1/30) и итоговый файл карты будет 136 Мб в максимальном случае.
Представим, что карта может загружаться на пользовательское устройство постепенно - 50 Мб начальная карта на 1000 квадратных метров - окружность радиусом примерно в 16 м. Для скорости в 3 м/с, за 5 секунд пользователь должен скачать дополниительную часть карты в 50 Мб. Скорость мобильного интернета должна составлять 10 Мб/с - нереалистичный сценарий.
Следовательно, для худшего сценария сжатия карты и скорости выхода пользователя из текущей локации может существовать проблема размера карты.
Более реальный сценарий: карта с меньшей дискретизацией которая покрывает большую площадь - 50мб / 2000 м^2 - дискретизация меньше в два раза, но карта покрывает всю площадь локации. При нахождении пользователя в определенной точке локации - подгружаются ближайшие участки карты.
При использовании нейросетевых методов для кодирования карты - итоговый файл карты будет весить значительно меньше и позволит использование в ограниченных сетевых условиях как и однократную загрузку карты и дальнейшую работу в автономном режиме.
Конечное решение программной реализации на мобильном объекте навигации (смартфоне): Нейронная локализация, сжатая, квантованная и компрессированная до возможностей смартфона. Частота будет менее 1 Гц.
Cжатая, квантованная и компрессированная до возможностей смартфона система нейронной локализации обеспечивает стабильное решение навигации.
Программное обеспечение - это код на языке python со сжатой нейронной сетью.
Получение высокочастотной координаты производится на основе интеграции IMU от последней рассчитанной локализации (3D-позиции).
Для точного решения с использованием IMU производится постоянная перекалибровка параметров интеграции измерений IMU.
Частота обновления системы может достигать до 100 Гц, задается требованиями приложения визуализации. Поскольку для скорости движения пешехода порядка 3м/с - при размере экрана в 6см в ширину, если показывается площадь локации порядка 10 м. Смещение пользователя на 1 м составляет 0.6 см на экране. В случае применения адаптивного сглаживания траектории пользователя на экране, реально достаточно частоты 3 Hz для визуализации решения. Для качественного обновления карты, сравнимо с максимально производительными системами навигации - достаточно частоты 25 Hz обновления решения системы + адаптивное сглаживание. Частота визуализации может составлять 25, 30, 50 и более кадров в секунду.
Большая частота обновления обозначает в первую очередь большую гладкость перемещения курсора на карте а не большую скорость перемещения.
Невозможно использовать реальную частоту обновления системы в интерфейсе пользователя - при шумном движении карты с частотой 25 кадров в секунду будет невозможно читать карту. Для большей отзывчивости системы настраиваются параметры сглаживания. Для разных реализаций существуют разные принципы параметров сглаживания: для системы помощи водителя - система должна работать максимально стабильно и не отвлекать водителя. Для реализации навигации со смартфоном актуальна высокая частота поворота - пользователь может определить свое направление на карте в реальном времени.
Возможны случаи движения пользователя с высокой скоростью: локальная система навигации установлена в автомобиле.
Для скорости движения в 100км/ч (27 м/с), частота решения в 100 Hz означает новое решение каждые 3.6 метра. С условием размера экрана в 10 см в высоту и показывающего 150 метров карты (аналогично автомобильному навигатору для движения с аналогичной скоростью) получаем движение на 18% экрана в секунду. Новое решение на перемещение на каждые 2.4% экрана позволяет получить гладкое и стабильное решение.
В общем случае, для качественного решения навигации - существует запас по частоте вычисления. В случае определения ситуации плохого решения навигации - возможно использовать адаптивное сглаживание для получения плавного решения.
Мера доверия к качеству локализации. Эта мера будет зависеть от результата выравнивания по отношению к карте. Мера используется на разных этапах использования итоговой координаты. В общем случае, нет необходимости вычисления этой меры в общем цикле вычислений. Для такого рода сигналов можно задаться апертурой - когда невязка решения увеличивается более чем на определенную величину, производится перерасчет ошибки локализации. В итоге расчет произволится только при определенных значениях невязки решения / каждый интервал времени. При значительной ошибке решения можно попытаться осуществить глобальную релокализацию.
Например, мы вышли за границу скачанной карты - можно получить новое решение и новый участок карты с сервера. В случае полного отсутсвия решения по причине отсутствия информации в карте, отсутствия информации с датчиков или другой причины - необходимо попытаться классифицировать ошибку, далее логировать ошибку и определенную причину ошибки.
В различных датасетах используемых для бенчмаркинга отмечаются простые и сложные последовательности для локализации. В дальнейшем можно использовать сохраненные последовательности записанные с клиентов для анализа и улучшения работы системы.
Конечная реализация интерфейса платформы локализации:
На основе опыта существующих решений пользовательской навигации, решением выбирается приложение для смартфона.
В такой реализации решение навигации начинается с получения данных от датчиков, затем запускается решение сжатого алгоритма для нейронной локализации.
Для стабильной работы системы в максимально широком диапазоне локаций рассматриваем следующий дублирующий формат реализации системы: Быстрая локализация за счет интеграции IMU/одометрии и радиочастотного позиционирования. Такое относительное позиционирование обеспечит более высокую частоту, начиная с последней предоставленной достоверной локализации.
При отсутствии данных с камеры, возможно продолжать стабильную локализацию пользователя в высокой частотой. Для реальных сценариев применения системы такое актуально для случаев когда человек входит в комнату - тереяется обзор камеры. Подобное поведение также характерно для высокодинамичесткого окружения - движение со смартфоном в толпе.
Программное обеспечение решения: код на для интеграции измерений IMU и перекалибровки датчиков.
Решение динамической системы - в общем случае это единственная координата или набор предполагаемых координат. В случае система не может сойтись к единственному решению или просто решение отсутсвует, существует модуль глобальной релокализации на случай сбоя системы.
Решением глобальной локализации может являться еще одна нейронная сеть, которая более равномерно покрывает все возможные локации пользователя.
Программное обеспечение модуля релокализации: код на cpp/python, на структуре, аналогичной системе локализации, но на большем пространстве состояний для проблемы глобальной локализации.
В общем случае решение может отсутвовать по причине отсутствия данных - в этом случае релокализация не поможет. Необходимо оценить работу системы сбор а и обработки данных, границы применимости каждой системы. Далее по результатам экспериментов производится подстройка системы и оптимизация гиперпараметров. По итогам экспериментов определяется область применимости системы - возможные потенциальные применения, профиль использования.
Конечная аппаратная реализация включает ....