End-to-End беспилотник на VLM в домашних условиях. Часть 1

Для привлечения внимания

Пара слов про End-to-End

В системах автономного вождения принято выделять два основных подхода — модульный и сквозной (end-to-end). Кратко напомню их суть.

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

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

На практике сегодня модульные архитектуры лежат в основе большинства рабочих и коммерческих систем автономного вождения, тогда как end-to-end-подход чаще встречается в исследовательских прототипах и демонстрациях. Однако bitter lesson напоминает, что методы, способные эффективно масштабироваться с ростом данных и вычислений (машинное обучение), со временем берут верх. А данных в индустрии со временем становится только больше. Поэтому за развитием сквозного подхода стоит как минимум следить.

Добавляем VLM

Сквозное обучение можно реализовать по-разному. Можно реализовать имитационное обучение на данных «наблюдение-действие» (классный наглядный пример: часть 1, часть 2.) Затем добавить симулятор - среду с которой можно взаимодействовать, чтобы покрыть сложные сценарии обучением с подкреплением. Можно улучшить симулятор, обучив модель мира, чтобы попытаться решить проблему переноса знаний (Sim to real domain adaptation). Все эти методы предполагают наличие данных в том или ином количестве и обучение на них.

Использование больших языковых (LLM) и визуально-языковых моделей (VLM) при этом не является обязательным компонентом end-to-end-автопилота. Сегодня их чаще рассматривают как вспомогательный слой — источник обобщенных знаний, инструмент интерпретации или интерфейс для объяснения поведения системы человеку.

Например, компания Wayve демонстрирует пробует применять визуально-языковые модели для пояснения решений своего автопилота и взаимодействия с ним: система способна не только ехать по маршруту, но и, например, объяснять свои действия на естественном языке, что частично приоткрывает «черный ящик» принятия решений.А

Автопилот Wayve, который болтает за рулем (о том что водит он только так, для души)

В предельном случае можно пойти еще дальше и попытаться использовать универсальную визуально-языковую модель в режиме zero-shot — без специализированных данных и обучения под задачу вождения. Такая система потенциально способна не только понимать сцену и делать её текстовое описание, но и принимать решения о дальнейших действиях в контексте поставленной задачи.

Взяв на вооружение существующие VLM можно сделать свой аналог приведенной выше демонстрации от Wayve. Это будет небольшой колесный робот-тележка с камерой и VLM на борту, чьи кадры с соответствующими «мыслями» модели можно будет увидеть в реальном времени. При этом если Wayve использовал VLM как дополнительный инструмент к своему тщательно обученному агенту-водителю, в нашем беспилотнике VLM будет “отдуваться за всех”. Безусловно, это лишь демонстрация без шансов на реальное применение: во-первых, универсальные VLM скорее всего не будут иметь достаточных для серьезного применения навыков, а во-вторых их авторегрессионный инференс слишком медленный для автономного вождения. Тем не менее такая демонстрация может быть весьма полезной и любопытной. Поехали…

Выбор архитектуры

Выбор архитектуры в первую очередь определяется ограничениями, которые накладывает модель. Для управления роботом недостаточно «видеть» сцену. Модель должна одновременно понимать изображение, интерпретировать инструкцию или цель и выдавать устойчивое, формализуемое решение. Большинство быстрых vision-моделей на это не рассчитаны: они способны описывать визуальную сцену, но не действовать в роли агента.

VLM, обученные в instruct-парадигме, эту проблему решают. Они способны проводить рассуждения в процессе ответа, например понять, что требуется остановиться, если впереди препятствие. Так же они способны следовать системным правилам, например нужно, чтобы модель всегда заканчивала свой ответ понятной командой управления. Однако за эту универсальность приходится платить вычислительной сложностью. И еще не каждая instruct модель обладает достаточной мощностью. Судя по моим тестам, модель должна иметь 7 и более миллиардов параметров для более-менее уверенной навигации. Для мобильного робота с ARM-процессором и жёсткими энергетическими рамками такой класс моделей оказывается практически недоступным.

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

Это не полноценный автономный робот, но зато доступный способ быстро проверить интересные гипотезы. Цена этого подхода — задержка сети и зависимость от соединения. В моих экспериментов было достаточно домашнего Wi-Fi, но при необходимости можно перейти даже на соединение по интернет-кабелю (патч-корду).

Важно подчеркнуть, что при физической распределённости система остаётся логически end-to-end. Поток данных начинается с изображения камеры и заканчивается командой движения, минуя классические промежуточные модули детекции, трекинга и планирования. VLM в этой архитектуре объединяет в себе восприятие, рассуждение, планирование и политику действий, пусть и размещённые вне корпуса робота.

Железо и начинка

Вот такой сетап использовался в эксперименте:

• игровой ноутбук с картой RTX4080 12Гб в качестве хоста

• миникомпьютер RaspberryPi5 с широкоугольной pi-камерой на колесном ровере

Простая иллюстрация

На хост-компьютере и роботе развернут ROS2. Робот отправляет на хост изображения с камеры с частотой 10 Гц и уменьшенным разрешением для ускорения передачи. На хосте помимо ROS2 запущен сервис ollama с визуально-языковой моделью. Специальная ros2-нода парсит ответ модели, находит одну из возможных команд и отправляет соответствующий управляющий сигнал роботу.

В качестве модели выбрана qwen2.5vl:latest — это уже квантизованная instruct VLM на 7 миллиардов параметров. В доступе также есть версия с 3 млдр., она может работать с хорошей скоростью, почти в реальном времени, но эксперименты показали, что эта версия плохо понимает изображения. Версия latest достаточно хорошо понимает сцену и следует указаниям промпта, но работает с частотой всего около одного кадра в секунду. Несмотря на то, что робот постоянно останавливается в ожидании обработки очередного кадра, этого достаточно для нашей демонстрации.

Работа с моделью

Задача для модели простая — увидеть в кадре объект и направить робота к нему. Скорость оставлена фиксированной. Повороты, для упрощения, дискретные — одна команда на поворот означает смену курса на фиксированный угол.

Ключевая идея в формировании управляющего промпта — сделать его максимально простым и универсальным, дать модели как можно большую свободу формирования логики управляющего сигнала, заложить как можно меньше так называемых inductive bias. Таким образом можно проверить, какие знания есть в модели и как их лучше использовать. Другое требование к промпту - требовать от модели думать перед ответом, но не слишком много, чтобы не пришлось ждать ответ слишком долго.

После множества тестов близкий к оптимальному управляющий промпт выглядит так:

Available commands to robot: <FORWARD> <RIGHT> <LEFT> <BACK> Your goal: Using available commands to correct your direction get close to WHITE BALL as much as possible. 1. Do you see WHITE BALL on the floor? 2. Where the WHITE BALL located: near the center of a frame, close to the left side or right side of image? 3. Turn left if WHITE BALL is near the left side of image 4. Turn right if WHITE BALL is near the right side of image 5. Move back if there is no WHITE BALL in order to find it 6. Think before give answer. What one available command to choise to achive the goal?

Пункт 5 в целом не является обязательным, но это очень полезная дополнительная способность.

Полностью избежать конструкций вида «если видишь А, то делай Б» к сожалению не получилось — пункты 3, 4 и 5 жестко навязывают логику движения. Хотелось бы, чтобы нейросеть сама придумывала эту логику, без подсказок. Но без этих инструкций на тестах модель слишком плохо понимала, куда нужно двигаться. Например, встречались ответы вида: «я вижу мяч, он находится справа, нужная команда — ‘повернуть налево’». Похоже, что модели не хватает мощности для более длинных логических цепочек рассуждений.

Тем не менее, весь промпт получился относительно компактным, довольно общего вида, без лишних уточнений о виде целевого объекта, окружающем мире, устройстве самого робота, оставляя модели «пространство для творчества» - например, в нестандартных ситуациях модель решает подумать более длинными ответами, пытаясь лучше понять кадр (не всегда это ей помогает 🥲). Также важно, что этот промпт легко адаптировать для других объектов.

Подробнее про эти и другие особенности работы с моделью расскажу в следующем посте.

Проверка в симуляции

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

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

Симуляция в Webots

Работа в реальном мире

Можно было остановиться на этапе симуляции, так как работа с VLM на реальных колёсах будет идентичной. Однако было интересно вывести робота в настоящий мир, посмотреть степень обобщаемости модели на новые данные своими глазами. Основные изменения носят скорее технический характер:

1. Переход на упомянутую выше схему хост-робот. Для этого на установленной на роботе RaspberryPi нужно настроить контейнер с Ubuntu для ARM-процессора. В нем так же как на хосте будет развернут ROS2. Одна нода читает и отправляет кадры с камеры, другая слушает команды хоста и отправляет их на приводы колес.

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

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

Результат выполнения задачи представлен на видео в начале статьи. Ниже — еще один пример. Тут хорошо видно, как робот целенаправленно преследует свою цель, отъезжает назад, чтобы снова увидеть потерянный из вида объект в соответствии с пунктом 5 инструкции:

Реальный заезд, почти как у Wayve

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

Подробнее про железо и софт всего проекта и то, как его запустить расскажу так же во второй части.

Идеи улучшений

Пара простых идей как улучшить результат.

1. Может быть вместо локально запущенной на хост-машине модели использовать API к chatGPT? Было бы действительно удобно: нужно закинуть кэш для пользования API и пусть управляющая нода отправляет запросы не к локальной ollama, а на сервера OpenAI. Однако, единственной подходящей моделью сейчас является визуально-языковая 4o, она умнее чем большинство открытых моделей, но она оказалась слишком медленной, даже для тестов. Так что не вариант.

2. Еще можно добавить историю прошлых рассуждений. В этом случае кроме текущей картинки и запроса модель получит свое же краткое описание нескольких прошлых кадров и своих действий в них. В теории это должно повысить общее качество принимаемых решений. Тем не менее, несколько моих тестов несложных реализаций подобной «памяти» для модели значительных улучшений не показали. Требуются чуть более глубокие эксперименты.

Выводы

В этом обзоре на мой взгляд удалось продемонстрировать возможность построить миниатюрный беспилотник пусть и с очень простым функционалом, управляемый end-to-end с помощью визуально-языковой модели. Подобный робот-тележка может быть использован для дальнейшего изучения особенностей применения универсальных VLM в задаче автономной навигации. Либо послужит хорошей отправной точкой для перехода на VLA (Visual-Language-Action model).

Продолжение в следующей части…

Источник