Как Venti Technologies ушли с ROS 1 на ROS 2 за 10 месяцев

Разбор новинки простыми словами: что это, кому нужно и брать ли.

Кейс задаёт рабочий паттерн для любой legacy-миграции: одна кодовая база и две параллельные сборки позволяют менять платформу, не останавливая поставку продукта.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

В сентябре 2024 года команда Software Infrastructure из Venti Technologies закончила переезд с ROS 1 Kinetic и Ubuntu 16.04 на ROS 2 Humble Hawksbill и Ubuntu 22.04. Машины компании в это время продолжали возить контейнеры на терминалах. Вот это и есть главная новость: платформу меняли на живой продуктовой кодовой базе, а не на замороженной копии, которую потом героически вливают обратно.

Сроки и объёмы: около десяти месяцев работы, старт в конце 2023-го, порядка 1,5 млн строк в репозитории с тестами, сгенерированным кодом и сторонними зависимостями, почти шесть месяцев валидации. Компания честно оговаривает: полтора миллиона строк никто руками не переписывал.

Что это по сути, если убрать техническую шелуху

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

К 2023 году Kinetic больше двух лет была вне официальной поддержки. Симптомы накопились бытовые: старые версии PCL и Boost, сложности с обновлением NVIDIA-драйверов, CUDA и TensorRT, привязка к давно устаревшему окружению Ubuntu 16.04. Для автономного транспорта это не вопрос удобства разработчиков. Это потолок по производительности: новые компиляторы и GPU-инструментарий дают доступ к оптимизациям и современным моделям, а старая платформа этот доступ закрывает.

Перевод на язык бизнеса: продукт упирается не в идеи и не в спрос, а в версии зависимостей. Заказчику это объяснить трудно, потому что в договоре написано «функциональность», а не «TensorRT».

Почему отказались от промежуточной ступеньки

Самый дешёвый на вид сценарий — не прыгать через пропасть, а обновиться до ROS 1 Noetic. Прикладной API почти тот же, шока меньше.

Разбор показал другое. Официальная целевая ОС для Noetic — Ubuntu 20.04, а терминалы работали на 16.04. Значит, всё равно обновлять ОС, компиляторы, библиотеки и зависимости. Собрать Noetic на неподдерживаемом дистрибутиве технически можно, но тогда команда берёт на себя обязательства по сборке и сопровождению нестандартной конфигурации.

Дальше главное. Для автономной системы даже консервативное обновление окружения требует полного регрессионного прогона: поведение компонентов, стыки между ними, симуляции, реальные машины. Оставаясь на ROS 1, команда не экономила на проверке. При этом конец поддержки Noetic был назначен на май 2025 года — из конца 2023-го это читалось как «завтра». Вывод: если серьёзная модернизация и долгая валидация всё равно неизбежны, вкладывать их в ROS 2 логичнее.

Был и денежный аргумент. Жить дальше на старой платформе означало серьёзные вложения в обновление вычислительного оборудования. Сначала проверили, насколько вопрос решается софтом.

Как это сделали: одна кодовая база, два пути сборки

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

Решение сформулировали принципиально:

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

Механика. Старый catkin/CMake продолжал собирать продукт на ROS 1, новый Bazel параллельно собирал тот же прикладной код на ROS 2. Bazel выбрали не из любви к спорам о системах сборки — нужен был способ построить альтернативную сборку, не ломая действующую. Сами авторы подчёркивают: это не претензия к CMake.

Мы не переходили на Bazel потому, что CMake принципиально неспособен собирать большой C++-проект.

Вместо ros1_bridge написали свой слой абстракции: реализация (roscpp или rclcpp) выбирается на этапе компиляции. Прикладная логика осталась почти нетронутой — её не заставляли участвовать в замене платформы.

Колесо сансары, или почему такие миграции откладывают годами

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

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

Кому подходит этот паттерн

Кейс полезен не только робототехникам. Любая замена фундамента под работающим продуктом — биллинг, платёжный шлюз, ядро CRM, слой работы с данными — упирается в те же три вопроса: как не остановить поставку, как не развести две версии продукта, как доказать, что новая платформа не хуже.

Где подвох

Две сборки — это двойное содержание. Пока идёт миграция, у вас живут два набора зависимостей, две конфигурации CI и два способа получить грабли. Почти шесть месяцев валидации в этом кейсе — не бюрократия, а цена обещания «машины продолжат ездить». И ещё: параллельная сборка не отменяет регрессионное тестирование, она лишь позволяет делать его на своей скорости.

Трезвая оценка ресурсов до старта обязательна. Если у вас нет человека, который будет владеть новой сборкой и днями напролёт разбираться с расхождениями окружений, схема развалится на третьем месяце.

Брать или подождать: вердикт за 30 секунд

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

Вердикт

Это не история про волшебные свойства ROS 2. Это история про инженерную дисциплину: сначала строится второй путь сборки, потом платформа меняется под ним, а продукт продолжает поставляться. Для 2026 года кейс особенно полезен тем, кто всё ещё держит что-то на давно закрытых ветках: ROS 1 окончательно ушла из поддержки, и «пока работает» превращается в «работает до первого обновления драйвера».

Вопросы, которые задают чаще всего

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

Можно ли обойтись без своего слоя абстракции? Можно, тогда мост между ROS 1 и ROS 2 становится частью продакшена. Авторы выбрали компиляцию с выбором реализации и мост им не понадобился.

Подойдёт ли подход для не-робототехники? Да, если у вас есть платформенный слой, за которым прикладная логика. Две сборки — универсальная схема, а не робототехническая экзотика.

Что было бы, если бы остались на Noetic? Обновление ОС и полный регресс всё равно случились бы, а поддержка заканчивалась в мае 2025-го. Отсрочка, не решение.

Что сделать на этой неделе

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