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

Почему вообще понадобилось переезжать?

Если вы в теме робототехники, то знаете: ROS 1 официально умер. End of Life. Больше нет обновлений, багфиксов, поддержки. Индустрия массово переходит на ROS 2, который заточен под реальную промышленность — реальное время, безопасность, распределённые системы.

Проблема в том, что в университетских лабораториях стоит куча оборудования на старом ROS1. И учат студентов... технологиям пятилетней давности. Которые уже никому не нужны на рынке.

К нам пришёл один из ведущих технических вузов: "У нас 30+ мобильных роботов и 10 манипуляторов, всё на ROS Melodic. Нужно перевести на ROS2 Humble. Не сломав при этом учебный процесс".

Ну что же, challenge accepted! 💪

С чем мы столкнулись (боль реальная)

Приехали на объект, сделали технический аудит... и ахнули. Классический "зоопарк легаси":

Проблема №1: Python 2.7 и древние библиотеки

Большая часть драйверов написана под Python 2.7, который вообще вымер в 2020 году. Зависимости как археологические слои — библиотеки тянут за собой другие библиотеки, которые уже не собираются на современных системах.

Проблема №2: ROS Master (единая точка отказа)

В ROS1 есть центральный узел — ROS Master. Если он падает — падает вся сеть. Вся лаборатория.

Представьте: 20 студентов на занятии, кто-то случайно убил Master на главном компе — и у всех роботы встали. Хаос, препод в стрессе, пара сорвана.

Проблема №3: Сетевой кошмар

Это была особая боль. Студенты приходят со своими ноутбуками (Windows, Mac, Linux — кто во что горазд). И потом полпары настраивают сеть: прописывают /etc/hosts, забывают экспортировать ROS_MASTER_URI, не могут законнектиться к роботу...

40% времени семинаров уходило не на программирование роботов, а на борьбу с настройками!

Что мы сделали: Переход на DDS

Главное отличие ROS2 — там нет центрального Master-узла. Вместо этого используется DDS (Data Distribution Service) — это стандарт для распределённых систем.

Автоматическое обнаружение (Discovery)

Поставили eProsima Fast DDS в качестве middleware. Теперь роботы сами находят друг друга в сети. Автоматически. Без настроек.

Запустил ноутбук → он сам нашёл всех роботов в сети → начал с ними общаться. Магия? Нет, просто современные технологии 🧙‍♂️

Решаем проблему "кто кем управляет"

Но тут возникла новая проблема: если 20 студентов в аудитории, и все видят всех роботов... начинается хаос. Один студент хочет управлять роботом №5, а другой в это же время шлёт команды на тот же топик /cmd_vel.

Решение: ROS_DOMAIN_ID.

Это как Wi-Fi каналы, только для ROS-сети. Каждая рабочая станция работает в своём изолированном домене. Студент видит только своего робота, а робот видит только своего студента.

А преподаватель может переключиться в режим "Global Observer" и видеть телеметрию со всех устройств сразу. Для контроля и помощи.

Переписываем код (тут было непросто)

Миграция — это не просто "найти-заменить" в коде. Это смена философии.

Lifecycle Nodes (управляемые узлы)

В ROS2 мы внедрили концепцию жизненного цикла узлов. Звучит сложно, но суть простая:

Узел (например, драйвер камеры) теперь не просто запускается и падает. Он проходит через состояния:

Unconfigured (не настроен)
Inactive (настроен, но не работает)
Active (работает)

Зачем это надо? Представьте: студент выдернул USB-камеру во время работы. Раньше всё падало с ошибкой. Теперь узел переходит в Inactive, ждёт переподключения, и сам стартует заново. Без перезагрузки всего робота.

Вот это resilience (отказоустойчивость)!

Мост для старого оборудования

У университета были несколько проприетарных манипуляторов, для которых драйверы существуют только под ROS1. Производитель тянет с обновлением.

Что делать? Выкинуть? Нет, дорого.

Мы настроили ros1_bridge — это специальный мост между ROS1 и ROS2. Манипулятор думает, что работает в ROS1, студент работает в ROS2, а мост в реальном времени переводит сообщения туда-сюда.

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

Docker-контейнеры (спасение от "Dependency Hell")

Помните, я писал про зоопарк зависимостей? Как студент тратит 3 часа, чтобы поставить себе нужную версию библиотеки, а она конфликтует с другой...

"Dependency Hell" — ад зависимостей. Классическая проблема в робототехнике.

Решение: упаковали всё в Docker.

Создали готовый образ на базе Ubuntu 22.04:

ROS 2 Humble (предустановлен)
Gazebo Fortress (симулятор)
VS Code Remote (IDE для разработки)
Все нужные библиотеки

Теперь студент приходит на первое занятие:

Устанавливает Docker (5 минут)
Запускает docker compose up
Всё работает!

Никаких "а у меня не собирается", "а почему у него работает, а у меня нет". У всех идентичное окружение.

Результаты (мы довольны)

3 месяца работы. Полностью обновлённая лаборатория.

✅ Производительность: Задержка передачи сообщений (latency) снизилась на 15% благодаря UDP-транспорту в DDS (вместо TCP в ROS1)

✅ Никаких сетевых плясок: Студенты больше не тратят время на настройку. Подключился — и работает

✅ Современные навыки: Теперь студенты изучают то, что реально используется в индустрии — Action Servers, Composition Nodes, Lifecycle Management. Это то, что спрашивают на собеседованиях!

✅ Масштабируемость: Купили новый робот? Включили в розетку — он сам появился в сети. Без переконфигурации системы

Вывод

Миграция на ROS2 — это не просто "обновление версии софта". Это переход на промышленный уровень надёжности и производительности.

Да, это больно. Да, придётся переписывать код. Но результат того стоит.

А ещё приятный бонус: после запуска нам написал один из студентов, что получил оффер в компанию именно благодаря знанию ROS2, которое указал в резюме. Вот это действительно круто! 🚀

Как мы за 3 месяца переселили целый университет с ROS1 на ROS2 (и почему это было непросто)

Похожие статьи

Поделиться в соц. сетях

Комментарии