Узлы, топики, сервисы и действия ROS 2

Robot Operating System 2 (ROS 2) позволяет независимо работающим программам обмениваться типизированными данными. Драйвер камеры, контроллер двигателей, планировщик и пользовательский интерфейс могут быть отдельными узлами, соединёнными через граф ROS. Важное решение проектирования заключается не только в типе сообщения, а в том, является ли взаимодействие потоком, коротким запросом или долгой целью.

Это руководство не зависит от дистрибутива. Команды и основные концепции стабильны, но сведения об установке и версии пакетов следует брать из документации для используемого релиза ROS 2.

Моделируйте одну ответственность на узел

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

Имена делают граф понятным. Используйте описательные имена узлов и интерфейсов, например /front_lidar, /wheel_odometry и /cmd_vel. Пространства имён позволяют двум роботам использовать эквивалентные графы без конфликтов.

Исследуйте работающую систему перед изменением:

ros2 node list
ros2 node info /wheel_odometry
ros2 topic list -t
ros2 service list -t
ros2 action list -t

node info показывает публикаторов, подписчиков, серверы и клиенты сервисов, а также действия, связанные с узлом. Часто это самый быстрый способ найти отсутствующий или неверно названный интерфейс.

Используйте топики для непрерывных потоков

Топик — асинхронный обмен по модели «публикация/подписка». Издатели отправляют типизированные сообщения, не ожидая прямого ответа, а любое число подписчиков может их получать. Топики подходят для данных, изменяющихся со временем:

• изображений камеры и сканов лидара;
• состояний суставов и одометрии колёс;
• состояния аккумулятора;
• заданной скорости;
• диагностических событий.

Проверьте поток из командной строки:

ros2 topic echo /scan --once
ros2 topic hz /scan
ros2 topic info /scan --verbose

Тип сообщения является частью контракта. Системы координат, единицы измерения, метки времени и ковариация важны не меньше имён полей. Подписчик не может безопасно интерпретировать положение, если не знает, задано значение в map в метрах или в системе координат камеры в миллиметрах.

Настройки качества обслуживания (QoS) влияют на доставку. Потоки датчиков часто предпочитают свежие данные повторной передаче устаревших отсчётов, тогда как состояние, похожее на конфигурацию, может требовать надёжной доставки или поведения transient-local. Издатель и подписчик с несовместимыми политиками QoS могут присутствовать в графе, но не обмениваться данными.

Используйте сервисы для коротких запросов и ответов

Клиент сервиса отправляет запрос и ожидает ответ сервера. Сервисы подходят для быстрых операций с определённым результатом:

• чтение или изменение конфигурации;
• сброс одометрии;
• очистка карты;
• запрос готовности компонента.

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

Исследуйте сервис и вызовите его командой:

ros2 service type /reset_odometry
ros2 interface show example_interfaces/srv/Trigger
ros2 service call /reset_odometry example_interfaces/srv/Trigger "{}"

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

Используйте действия для долгих задач

Действие моделирует цель, выполнение которой занимает время. Оно поддерживает приём цели, периодическую обратную связь, итоговый результат, отмену или вытеснение другой задачей. Навигация к позе и перемещение манипулятора по траектории естественно реализуются действиями.

Взаимодействие состоит из трёх семантических частей:

• Цель: чего хочет клиент, например целевой позы.
• Обратная связь: ход выполнения, например оставшееся расстояние.
• Результат: конечный исход и возвращённые данные.

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

Из командной строки:

ros2 action info /navigate_to_pose
ros2 action send_goal /navigate_to_pose <action_type> '<goal_yaml>' --feedback

Замените заполнители типом и полями, которые сообщает работающий граф. Используйте команду для исследования поведения, а не как жёстко заданный производственный интерфейс.

Выберите с помощью одной таблицы решений

Топик не обязательно «быстрый», а сервис не обязательно «надёжный». Временные характеристики и доставка зависят от QoS, промежуточного ПО, сред выполнения ROS, нагрузки и сети. Сначала выбирайте по семантике взаимодействия.

Одно поведение может использовать все три интерфейса. Узел навигации подписывается на топики сканов и одометрии, принимает действие навигации и предоставляет короткий сервис для очистки карты стоимости. Границы остаются ясными, поскольку каждый интерфейс отвечает на свой тип вопроса.

Спроектируйте граф небольшого мобильного робота

Рассмотрим робота с дифференциальным приводом:

1. /encoder_driver публикует отсчёты колёс.
2. /odometry подписывается на отсчёты, публикует /odom и передаёт odom → base_link.
3. /range_driver публикует измерения расстояния.
4. /safety_controller подписывается на значения дальности и ограничивает /cmd_vel.
5. /navigator принимает действие перемещения и публикует требуемую скорость.

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

Используйте стандартные типы сообщений ROS, когда их семантика подходит. Пользовательские типы интерфейсов оправданы, когда контракт данных действительно специфичен для проекта, а не просто переименовывает существующие поля.

Отлаживайте граф слой за слоем

При отсутствии данных:

1. Убедитесь, что оба узла присутствуют в ros2 node list.
2. Проверьте имена и типы интерфейсов.
3. Изучите количество публикаторов и подписчиков.
4. Сравните политики QoS.
5. Выведите одно сообщение и проверьте метки времени и идентификаторы систем координат (IDs).
6. Проверьте журналы и загрузку средства выполнения.

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

Избегайте распространённых архитектурных ошибок

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

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