ROS 2: Robot Operating System

2019 год. Amazon Scout - первый автономный робот-курьер на тротуарах Snohomish County, Washington. 20+ одновременных программ: 6 камер, LIDAR, IMU, GPS, детекция препятствий, маршрут, моторы, батарея. Обмен данными - 100 раз в секунду, без единого сбоя. Основа - ROS 2, стандарт де-факто для робототехнического ПО с 2020 года.

• **NASA**: марсоход использует ROS 2 для координации камер, бура и манипулятора - каждая подсистема работает как отдельная нода, общаясь через topics
• **Autoware**: открытый стек автономного вождения на ROS 2 - десятки нод для восприятия, планирования и управления, связанных через topics, services и actions
• **Amazon Robotics**: тысячи складских роботов Kiva управляются через ROS 2, координируя навигацию через actions и обмениваясь картами через topics

От Willow Garage до Open Robotics

ROS создан в 2007 году в Willow Garage - стартапе, финансированном основателем Google Скоттом Хассаном. Первый робот на ROS - PR2 - мог складывать полотенца и открывать двери холодильника. ROS 1 использовал центральный roscore и не имел поддержки real-time. ROS 2, разработанный Open Robotics с 2014 года, переосмыслил архитектуру: DDS вместо roscore, управляемый жизненный цикл нод, нативная многороботность. К 2025 году ROS 2 используют NASA, Boston Dynamics и Amazon Robotics.

Предварительные знания

• Kinematics: Forward and Inverse

Ноды - вычислительные процессы

Amazon Scout - робот-курьер, 2019 год. 6 камер, LIDAR, IMU, GPS, детектор препятствий, планировщик маршрута, контроллер моторов - всё одновременно. Один монолит на 200 000 строк? Кошмар сопровождения. **ROS 2** (Robot Operating System 2) решает это через архитектуру **нод** - независимых процессов, каждый из которых отвечает ровно за одну задачу.

**Node** (нода) - минимальная вычислительная единица в ROS 2. Каждая нода - отдельный процесс (или поток), выполняющий одну функцию: чтение камеры, управление мотором, планирование пути. Ноды общаются через три механизма: topics, services и actions.

Ключевое отличие от ROS 1: в **ROS 2** нет центрального сервера (roscore). Ноды обнаруживают друг друга через **DDS** (Data Distribution Service) - промышленный стандарт middleware с автоматическим discovery. Если одна нода падает, остальные продолжают работать. Нет roscore - нет единой точки отказа.

Topics - асинхронные сообщения

Камера - 30 кадров/сек. LIDAR - 10 облаков точек/сек. IMU - 200 измерений/сек. Три потока данных, три разных consumer-а. Как передать всё это без блокировок и без зависимости источника от получателя? **Topics** в ROS 2 - именованные каналы pub/sub-коммуникации. Publisher не знает о subscribers. Fire-and-forget.

**Topic** - именованный канал сообщений определённого типа. Нода-**publisher** публикует данные в topic, а одна или несколько нод-**subscribers** их получают. Publisher не знает, кто подписан (и подписан ли вообще). Полная развязка.

В ROS 2 каждое сообщение в topic имеет строго определённый **тип** - IDL (Interface Definition Language). Стандартные типы собраны в пакеты: `std_msgs`, `sensor_msgs`, `geometry_msgs`, `nav_msgs`. Кастомные типы создаются через `.msg` файлы.

**QoS (Quality of Service)** - критически важная настройка в ROS 2. Для камеры подходит `BEST_EFFORT` (потеря кадра не страшна), а для команд управления нужен `RELIABLE` (каждая команда должна дойти). Если QoS publisher и subscriber несовместимы - они не увидят друг друга.

Services - синхронный запрос-ответ

Topics - для потоков. Но иногда нужно **попросить ноду сделать что-то конкретное и дождаться ответа**. Переключить камеру в ночной режим. Запросить текущую карту. Сохранить конфигурацию. Для этого в ROS 2 есть **services** - синхронный request/response.

**Service** - именованный канал «запрос - ответ». Клиент отправляет Request и **блокируется** до получения Response. Сервер обрабатывает запрос и возвращает результат. В отличие от topic, service - это point-to-point: один сервер, один или несколько клиентов.

Services **блокируют** вызывающую ноду до получения ответа. Если сервер завис или упал - клиент зависнет тоже. Для долгих операций (навигация, сканирование) используйте **actions**, а не services. Правило: service должен выполняться **быстро** (миллисекунды, максимум секунды).

Actions - долгие задачи с обратной связью

«Поехай в точку (3.5, 7.2)» - это 30 секунд езды. Service тут не подходит - клиент зависнет на полминуты. Topic тоже мимо - нужен конкретный результат. В ROS 2 для таких задач есть **actions** - гибрид service и topic с тремя каналами: goal, feedback и result.

**Action** - механизм для долгих задач с тремя фазами: 1. **Goal** - клиент отправляет цель, сервер принимает или отклоняет 2. **Feedback** - сервер периодически сообщает прогресс (расстояние до цели, % завершения) 3. **Result** - сервер возвращает финальный результат (успех/неудача + данные)

Ключевое преимущество actions - возможность **отмены**. Если робот едет к точке и получает новую цель (или обнаружил опасность), клиент отменяет текущий action через `cancel_goal()`. Сервер получает уведомление и корректно останавливается. Без паники, без брошенных ресурсов.

Под капотом action реализован через **3 скрытых topics и 2 services**: topic для feedback, topic для статуса goal, service для отправки goal, service для отмены. ROS 2 скрывает эту сложность - работа идёт с удобным API ActionServer/ActionClient.

Ключевые идеи

• **Node** - минимальная вычислительная единица ROS 2. Один процесс = одна задача. Ноды обнаруживают друг друга через DDS без центрального сервера.
• **Topic** - асинхронный pub/sub канал для потоковых данных (камера, LIDAR, одометрия). Один publisher, множество subscribers. Fire-and-forget.
• **Service** - синхронный request/response для быстрых однократных запросов (переключить режим, запросить конфигурацию). Блокирует клиента.
• **Action** - механизм для долгих задач с feedback и возможностью отмены (навигация, сканирование). Комбинирует topics и services под капотом.

Связанные темы

ROS 2 объединяет многие концепции из программной инженерии и робототехники:

• Кинематика — Библиотека MoveIt в ROS 2 реализует FK/IK и планирование движений манипуляторов через actions
• Параллельные вычисления — Ноды ROS 2 - это параллельные процессы, а DDS использует механизмы межпроцессного взаимодействия
• Системы реального времени — ROS 2 поддерживает real-time через DDS QoS, приоритеты executor и managed nodes

Вопросы для размышления

• Вернёмся к роботу-курьеру Amazon Scout: какие данные передавались бы через topics, какие операции через services, а какие через actions? Попробуйте распределить все 20+ компонентов.
• Почему ROS 2 отказался от центрального сервера (roscore из ROS 1)? Какие проблемы это решает для роботов, работающих в группе?
• Если бы проектировалась система управления дроном-доставщиком, какие ноды были бы созданы и как бы связали их через topics, services и actions?

Связанные уроки

• rob-02 — Кинематика манипуляторов реализована через MoveIt actions в ROS 2
• rob-04 — SLAM и навигация Nav2 строятся поверх topics/actions ROS 2
• par-01 — Ноды ROS 2 - параллельные процессы с DDS как IPC-механизмом
• rts-01 — ROS 2 поддерживает real-time через DDS QoS и executor приоритеты
• ds-01 — Pub/sub в ROS 2 аналогичен distributed messaging в микросервисах
• emb-03 — Физический уровень: I2C/SPI датчики поставляют данные в ROS 2 topics
• os-13-ipc