Перенос CUDA-ядер из пакета Elevation Mapping cupy помог автору проекта ровера заметно очистить карту проходимости, но не отменил главный вывод эксперимента: RGB-D камера остаётся слишком шумным источником данных для уверенной автономной езды. По данным Habr / Новости, даже после фильтрации камера продолжала создавать фантомные препятствия, тогда как лидар давал существенно более стабильную картину.
Автор начал с проблемы, знакомой многим командам, которые строят навигацию мобильного робота на недорогих сенсорах. Простое проецирование точек глубинной камеры на карту высот выглядит логично ровно до первого движения платформы. Шум измерений накладывается на дрейф одометрии, особенно по вертикальной оси Z, и поверхность пола превращается в набор ложных бугров, ям и случайных препятствий. Для человека это просто дрожащий меш в визуализаторе; для планировщика маршрута — повод затормозить перед несуществующей стеной.
Чтобы исправить ситуацию, разработчик перенёс на CUDA логику из Elevation Mapping cupy. В основе подхода — одномерный фильтр Калмана для каждой ячейки сетки: он не воспринимает очередное измерение как окончательную истину, а накапливает наблюдения во времени. Алгоритм также компенсирует дрейф карты. В результате данные перестают «прыгать» после каждого кадра, а высоты становятся пригоднее для расчёта стоимости движения. Это важная деталь: в робототехнике качество алгоритма часто упирается не в красивую модель препятствий, а в дисциплинированную работу с ошибками датчиков и координатных систем.
Отдельно проявилась проблема с потолками и другими объектами над платформой. В предыдущем варианте ровер пытался найти поверхность под собой, отмерить от неё высоту и удалить всё, что находится выше допустимого уровня. Схема ломалась, если нужную поверхность не удавалось определить: потолок мог попасть на карту высот и перекрыть реальный рельеф. В Elevation Mapping cupy решение проще — отбрасывать точки выше заданной высоты относительно датчика. Такой фильтр не зависит от найденного пола и надёжнее работает в помещении, но требует аккуратной настройки под габариты робота.
У этого компромисса есть цена. При въезде на подъём верхняя граница зоны наблюдения может буквально срезать вершину горки: рельеф оказывается выше допустимой высоты в системе координат сенсора. Автор отмечает, что эффект можно частично уменьшить, если учитывать крен и тангаж платформы либо работать с незарегистрированным облаком точек в системе координат корпуса. Но полностью заменить обзор датчика математикой не получится. Если вершина не попала в скан или измерена с низким разрешением, алгоритму просто не из чего строить безопасную траекторию.
В тестах в помещении карта, построенная по одному лидару, выглядела достаточно чистой даже без предварительной очистки облака от движущихся точек. Это не означает, что фильтрация больше не нужна: у используемого лидара отрицательные углы склонения не позволяли нормально видеть пол, а ровер для эксперимента приходилось держать под углом около 45 градусов. Зато опыт показал, что перенос ядер способен сгладить часть типичных выбросов и сделать высотную модель пригодной для дальнейшей обработки.
После объединения облаков лидара и RGB-D камеры выбросов стало больше уже в помещении. Визуально карта стоимости могла казаться почти идеальной, но лишь потому, что чувствительность к уклонам была занижена: при таких настройках система не считала значительным препятствием даже человека перед ровером. Камера генерировала мусор и после фильтрации, а редкие экстремальные точки портили не только геометрию, но и раскраску высотной карты — шкала растягивалась из-за значений, которых в реальном помещении не было.
Уличный тест оказался лучше: число артефактов, по наблюдению автора, снизилось примерно вдвое, и по полученной модели уже можно было ехать. Однако фильтр Калмана не сделал RGB-D поток гладким: на дороге периодически оставались фантомные препятствия. Часть ошибок связана с тем, что карта строилась по обычным лидарным сканам, а не по ключевым кадрам, очищенным от динамических объектов. Для продакшн-системы это означает вполне приземлённый набор задач: отделять подвижные объекты от статичной сцены в реальном времени, контролировать качество одометрии и не подменять настройками карты стоимости реальную оценку риска.
Эксперимент хорошо очерчивает границу между демонстрацией и навигационным стеком: карта проходимости может работать на RGB-D камере в пределах одного удачного скана, но для устойчивого движения ей нужен лидар и качественная обработка облаков до этапа построения карты. Следующий практический вопрос — насколько лёгким окажется такой пайплайн для конкретной платформы: вычислительный выигрыш GPU ничего не даст, если входной поток всё ещё несёт в планировщик дрейф, шум и неотфильтрованных людей.
