ROS 1 против ROS 2: почему выбирают ROS 2

Почему существует две версии ROS и почему новые проекты пишут на ROS 2.

ROS 2 — переписанная с нуля версия ROS, использующая промышленный стандарт связи DDS вместо центрального master-узла и пригодная для продакшна, реального времени и систем из нескольких роботов.

Откуда взялись две версии

Первый ROS (теперь его называют ROS 1) создавался в исследовательской лаборатории в 2007 году как инструмент для экспериментов. Он отлично подошёл для прототипов и науки, но при попытках вывести роботов в реальную эксплуатацию вскрылись фундаментальные ограничения архитектуры. Переделать их «на лету» было невозможно, поэтому ROS 2 написали заново, сохранив идеи (узлы, топики, сервисы), но поменяв фундамент.

Главное отличие: master против DDS

В ROS 1 был центральный процесс roscore (master). Все узлы сначала регистрировались у него, и master подсказывал, кто с кем должен связаться. Проблема очевидна: master — единая точка отказа. Если он падает или теряется по сети, система разваливается. Для лабораторного робота это терпимо, для склада с десятком тележек — нет.

В ROS 2 master убрали полностью. Связь построена на DDS (Data Distribution Service) — промышленном стандарте обмена данными, который применяют в авиации, обороне и финансах. Узлы находят друг друга сами через механизм discovery: они рассылают по сети объявления «я публикую такой-то топик» и сами договариваются о соединениях. Нет центра — нет единой точки отказа.

Качество обслуживания (QoS)

DDS приносит мощную фичу — политики QoS (Quality of Service). Для данных лидара, который шлёт 30 кадров в секунду, нам не страшно потерять один кадр — важна свежесть (политика best effort). А вот команду «аварийная остановка» терять нельзя ни в коем случае — для неё выбирают надёжную доставку (reliable) с сохранением последнего значения. В ROS 1 такой тонкой настройки практически не было.

Как работает под капотом

Когда вы запускаете узел ROS 2, под ним работает RMW (ROS Middleware) — прослойка, которая переводит вызовы ROS на язык конкретной реализации DDS (Fast DDS, Cyclone DDS и др.). Это позволяет менять «движок» связи, не переписывая код узла. Discovery по умолчанию использует мультикаст в локальной сети: новый узел кричит «всем привет», существующие отвечают, и они договариваются о прямых соединениях.

ROS 1:   [узел] --> [ roscore / master ] <-- [узел]   (центр обязателен)

ROS 2:   [узел] <===DDS discovery===> [узел]          (центра нет)

Частые ошибки

• Искать roscore в ROS 2. Его нет и не должно быть — discovery работает сам.
• Учить ROS 1 для нового проекта. ROS 1 в статусе завершения поддержки; новые проекты начинают с ROS 2.
• Игнорировать QoS. Несовпадение политик у издателя и подписчика — частая причина «сообщения не доходят, хотя топик есть».

Итоги

• ROS 2 переписан с нуля на основе DDS и убрал центральный master.
• Нет единой точки отказа, есть поддержка реального времени и нескольких роботов.
• QoS даёт тонкую настройку надёжности и свежести данных.
• Для любого нового проекта правильный выбор — ROS 2.