Карта проходимости на GPU помогает наземному роботу видеть не только стены, но и ямы

3 мин чтения 0
Карта проходимости на GPU помогает наземному роботу видеть не только стены, но и ямы

Разработчик описал практический способ строить карту проходимости для наземного робота из данных RGB-D камеры и лидара. Вместо тяжёлого планирования по всему трёхмерному объёму система заранее сводит окружение к 2,5D-карте высот и рассчитывает пригодность маршрута на GPU.

Суть события

Исходная задача звучит просто: робот должен понимать, где он физически проедет в помещении и на пересечённой местности. Но обычный горизонтальный срез хорошо замечает стены и при этом может объявить свободными яму или неровную поверхность. Вертикальная проекция показывает землю, зато потолок или навес способен перекрыть нужный участок.

Автор прошёл путь от универсальной воксельной карты к двухмерной карте проходимости, полностью вычисляемой на GPU. Такой формат заранее учитывает уклон, перепад высот, ямы и габариты робота, снимая часть работы с планировщика маршрута.

Детали

Воксельная карта размером 400×400×100 движется вместе с роботом как скользящее окно. Алгоритм начинает с высоты поверхности под машиной, затем перебирает вертикальные слои по приоритету и схлопывает объём в единую 2,5D-поверхность. После этого локальный и глобальный уклоны и размах высот превращаются в стоимость ячеек — от свободных до непроходимых.

Переход к 2D принципиален для производительности: у карты 400×400×100 вычислительная нагрузка примерно в сто раз выше, чем у 400×400. Кроме того, трёхмерный объём в основном пуст: около 90% пространства не несёт полезных данных, а передача между CPU и GPU добавляет накладные расходы.

Сенсоры дополняют друг друга. RGB-D камера быстро даёт плотное облако точек по курсу, но шумит без текстуры и при солнечном свете. Лидар устойчивее как основной источник, однако медленнее сканирует сцену, страдает от эффекта rolling shutter и замечает пыль или насекомых. Поэтому камера направлена к земле, а лидарные облака проходят обработку одометрией.

Контекст

CPU-версия оконного метода на Core i7 строила первый участок около 50 секунд, а обновления занимали от одной до шести секунд при частоте лидара 10 Гц. Для движущегося робота это слишком медленно. CUDA-реализация приблизила обновление карты к темпу поступления лидарных данных и устранила ошибки раннего ядра, чувствительного к шуму камеры и скачкам одометрии по высоте.

Практический вывод для разработчиков робототехники: универсальность трёхмерной модели не всегда окупает её цену. Если конечная задача — безопасный путь наземной платформы, компактное представление с заранее рассчитанной проходимостью может быть полезнее полного объёма. Это тот случай, когда разумное упрощение делает систему не беднее, а применимее. В более широком контексте стоимость вычислений остаётся важным ограничением AI-систем — об инфраструктурной стороне можно прочитать в материале о кредитном обеспечении дата-центра OpenAI.

Что дальше

Следующий шаг — проверять связку на разных скоростях, покрытиях, уклонах и при переходе из помещения на улицу. Особого внимания требуют синхронизация сенсоров, задержка очищенных лидарных кадров и пограничные случаи под навесами. Для команд, собирающих автономную платформу, полезный ориентир здесь не максимальная детализация карты, а стабильное время обновления и предсказуемые ошибки.

Материал был полезен?
AI-инструменты без границ

Получите доступ к нужному AI-сервису уже сегодня

ChatGPT, Claude, Gemini, MiniMax и агенты для кода — предложения проверенных продавцов по доступным ценам. Оплата российскими картами, через СБП или криптовалютой.

Проверенные продавцы Быстрая выдача Доступные цены
Прокрутить вверх