Проверка коллизий в режиме реального времени

Мейнтейнер nav2 Алексей Мерзляков презентовал на ROS Developers Day'2023 новый пакет Collision Monitor, который быстро выявляет риск возникновения коллизий и, тем самым, добавляет дополнительный слой безопасности. Автор отмечает, что, так или иначе, проверка коллизий входит в большинство приложений робототехники, однако нода Collision Monitor предназначена для таких препятствий, которые появляются из практически ниоткуда (с точки зрения робота) или приближаются к роботу на такой высокой скорости, что ему необходимо немедленно остановиться, чтобы предотвратить столкновение, поэтому может быть уместной как для мобильной, так и для промышленной робототехники.

Видео-презентация
Github: github:ros-planning/nav2_collision_monitor

#ros2 #nav2 #collision

CI шаблон для пакетов ROS

Практики непрерывной интеграции (CI) позволяют поставить на поток наиболее рутинные этапы при подготовке пакетов к практическому применению.

Данный шаблон позволяет автоматизировать следующие процедуры для Вашего C++ пакета ROS:
1. Оценка вычислительной сложности по Холстеду (Halstead Complexity)
2. Соответствие выбранному стилю кода (KWStyle)
3. Оценка безопасности кода (Flawfinder)
4. Оценка цикломатической сложности алгоритмов (lizard, cppclean)
5. Выявление дубликатов в коде
6. Получение разнообразных метрик по качеству кода (metrixplusplus)
7. Статический анализ кода (CPPCheck, CodeChecker, PVS Studio)

После завершения конвейера проверок gitlab-runner компилирует пакет и формирует документацию на doxygen.

За шаблон спасибо Рейнско-Вестфальскому техническому университету Ахена

#ros #ci #gitlab

Foxglove vs RViz

Проект Foxglove динамично развивается, помогает развивать ROS-экосистему, заставляет обращать на себя внимание со стороны разработчиков и позиционируется как альтернатива RViz. Оба проекта имеют много общего - открытый исходный код, визуализируют трёхмерные данные о сцене, достаточно легко конфигурируются и расширяются с помощью системы плагинов - rviz с помощью компилируемых плагинов, Foxglove с помощью HTML/JS модулей. Но есть и отличия. Давайте попробуем разобраться в том стоит ли пересаживаться с Rviz на Foxglove и обеспечит ли он существенные преимущества вашему проекту. Для этого разберём преимущества Foxglove относительно RViz из одноимённой статьи на сайте разработчика.

Тезис №1. Rviz изначально спроектирован для визуализации трёхмерных изображений и маркеров, поэтому не рассматривает визуализацию того, для чего в экосистеме ROS есть соответствующие пакеты - rqt-multiplot, rqt-runtime_monitor и rqt-graph. Foxglove же даёт возможность комбинировать данные представления (3D, графики, изображения и т.д.) в рамках единого UI layout.

> Преимущество одного окна против много-оконности. Многие линуксоиды (подавляющее большинство разработчиков ROS) могли бы записать это в недостаток - с помощью тайлинга можно распределить окна по дисплею так, как им этого хочется, не прибегая к настройке Layout. Однако, Foxglove предоставляет возможность сохранять Layout и управлять ими, что, однозначно, обеспечивает дополнительное удобство.

Тезис №2. Rviz не поддерживает по умолчанию проигрывание rosbag-файлов. Для просмотра требуются отдельные утилиты (rosbag, ros2bag).

> Проигрывание файлов bag возможно в RViz, но при этом нужно пользоваться утилитой командной строки в двух терминалах - в одном запускать RViz, в другом - rosbag play.

Тезис №3. Кроссплатформенность. Сейчас RViz требует ROS для установки и на тех системах, где ROS не установлен, Вы не сможете запустить RViz. Foxglove построен на базе web-технологий, что позволяет запускать его как в браузере, так и в виде desktop-приложения, построенного на базе Electron.

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

Тезис №4. Коллаборация. Foxglove предоставляет инструменты для настройки многопользовательского доступа к данным визуализации.

> Де-факто в ROS2 этот функционал реализуется с помощью разграничения доступа к машине. Если Вы можете настроить виртуальную сеть (VPN) с удалённой машиной или роботом, то DDS-трафик становится доступен всем, кто к этой сети подключён. Само представление информации остаётся на клиентской стороне.

Если подытожить, то все представленные преимущества над RViz не имеют принципиального характера. Так или иначе, все они могут быть обеспечены имеющимися в экосистеме инструментами. Foxglove даёт дополнительные удобства с точки зрения современного внешнего вида, возможностей кастомизации UI, но нужно быть готовыми к тому, что могу отсутствовать функции, к которым все привыкли. Например, для наших специфических нужд текущего функционала Foxglove не хватило - их 3D Viewer не отрисовывает по умолчанию URDF (визуализирует состояние манипулятора с помощью дополнительных маркеров), а текущие пресеты не позволяют из коробки настроить представление и требуют доработки расширений.

Оба проекта активно поддерживаются, а итоговое решение по выбору средства визуализации может быть обусловлено и нефункциональными факторами - такими как наличие веб-разработчиков в робо-проекте, распределённость команды и предпочтения между Qt и веб-технологиями.

#foxglove #rviz #ros

​​ROSCon 2023

Уже через два дня с 18 до 20 октября в New Orleans, Louisiana состоится 12-я ежегодная конференция ROSCon! Докладов много и темы очень интересные.

Кто не смотрел, то вот видео с прошлогоднего события
https://vimeo.com/showcase/9954564

https://roscon.ros.org/2023/

#ros #conference

RosCon'2023 Видео

Краткое резюме по итогам конфы
https://www.youtube.com/watch?v=Yl3fIHlcCfQ

Записи стримов (пока не разделены на отдельные доклады, всё одним многочасовым видео):
https://vimeo.com/osrfoundation

#roscon

ROS 2 - варианты поставки

Для каждого дистрибутива ROS/ROS 2 существует несколько вариантов поставки, в зависимости от требований пользователя. Если будете использовать контейнеры, то эта информация пригодится. Все варианты представляют собой обычные ROS-пакеты, но с относительно большим количеством зависимостей.

ROS Core: базовый дистрибутив, без которого ничего не будет работать. Содержит утилиты для сборки, упаковки пакетов, для launch, rcpcpp/rclpy, генераторы интерфейсов IDL для DDS, ros2 security (позволяет настроить доступ к узлам через криптографические ключи).
ROS Base: собирается на базе ROS Core, к которому добавляет чуть более прикладные, но часто встречающиеся, вещи: geometry2, kdl_parser, robot_state_publisher, rosbag2, urdf.
Desktop: собирается на базе ROS Base. Тут куча примеров, утилиты для визуализации, мониторинга нод. Подойдёт для обучения.
Perception: основан на ROS Base; добавляет к нему пакеты для обработки изображений.
Simulation: основан на ROS Base; содержит мосты к Gazebo и их интерфейсы.
Desktop Full: содержит всё - Desktop + Perception + Simulation. Если много места на диске, то ставьте его.

Варианты поставки меняются от дистрибутива к дистрибутиву. Для получения детальной информации о составе пакетов заходите в REP 2001.

#ros #ros2 #distro

ROS 2 Meta System Exporter

Утилита командной строки rosmetasys позволяет получить слепок(snapshot) текущего состояния узлов ROS в системе:
имена нод и их пространства имён, издателей и подписчиков каждого узла, сервисы и клиенты, типы сообщений каждого топика. Данные можно выгрузить в json и визуализировать в веб-приложении RosComGraph. Утилита разработана в Потсдамском Университете как альтернатива rqt-graph. Она не преследует цели заменить RViz и абстрагируется от самих передаваемых данных, сосредотачиваясь на отслеживании состояния узлов.

#visualisation #ros #rqt

ros2nix

Утилита для конвертации package.xml (стандартного мета-описания зависимостей для пакетов в рамках ROS экосистемы) в выражения на языке Nix с использованием nix-ros-overlay.

https://github.com/wentasah/ros2nix

#ros #nix #convert

ROS Robotics Companies

Регулярно обновляемый список компаний (717 штук), использующих ROS или связанные с ним инструменты для разработки. Для каждой компании приведены ссылки на публичные репозитории и другие ресурсы, где использование ROS подтверждено.

#ros #awesome #github
https://github.com/vmayoral/ros-robotics-companies

Nix как нативный пакетный менеджер для ROS

В очередной раз на ROS Discource разгорелась жаркая дискуссия по поводу интеграции Nix в ROS. Автор обсуждения изложил основные проблемы сборки и управления зависимостями в ROS, а также предложил рассмотреть вопрос использования nix как нативной системы сборки пакетов.

CTO Open Robotics не слишком погружался в тему (мало знает о nix), но признаёт что лучшие использовать уже существующие инструменты, чем разрабатывать свои собственные (на момент разработки colcon альтернатив не было). Также он отметил, что ament-cmake, помимо сборки и управления зависимостями, выполняет также работу по генерации обработчиков для IDL-интерфейсов. Этого никс не делает по умолчанию (прим. ред. - и не должен, это задачи всяких хуков).
Разработчик Zenoh признаёт, что нужно слишком много поменять в текущем workflow публикации пакетов. Это слишком фундаментальная задача.
Один из Great Contributors высказал позицию, что воспроизводимость сборки не имеет значения, потому что репозитории git и пакеты pypi появляются и исчезают (прим. ред - видимо, он не в курсе кэш nix'а - даже если исходник будет потерян или перемещён, то сборка всё равно не нарушится). Также он отметил, что ROS как раз был очень хорош, потому что в нём было легко начать разработку, а с nix это может быть сложнее.
Один из контрибьюторов nix-ros-overlay дал подробные ответы на все возникшие вопросы и дал понять, что можно в ROS ничего и не менять - пользователи nix-ros-overlay уже привыкли жить как есть.
В общем, рекомендую топик к прочтению, если хотите разбираться с основными аспектами применения nix в контексте ROS и связанными с этим стереотипами.

Что также тут можно отметить?

Проблемы с управлением зависимостями существуют и признаются участниками сообщества. Однако, устоявшийся порядок сборки и дистрибьюции пакетов, построенный на vcstool/ament/bloom/colcon/rosdistro/apt, менять будет слишком накладно. Даже если представить, что кто-то пойдёт на столь решительный шаг, то будет сделано буквально следующее:
1. Отказ от поддержки создания ROS для любых других источников зависимостей, кроме nixpkgs (без apt, без dmf, без conda, без поддержки Windows без WSL, без yocto, без gentoo).
2. Поскольку использование нескольких менеджеров пакетов больше не является обязательным требованием, удаляются package.xml, зависимости задаются в файлах nix flake вместо содержащихся в них ключей rosdep.
3. Удаляются bloom и superflore; больше не нужно генерировать файлы конфигурации nix, поскольку они уже будут в репозиториях, вместо package.xml
Я вижу эти шаги маловероятными на текущем этапе. Более вероятны перспективы в виде изключения из процесса дистрибьюции централизованного rosdistro, репозиториев релизных пакетов и их замены на сборку из исходников напрямую. Теоретически это можно сделать через какой-то генератор, который находит upstream-репозитории, строит на базе разных веток .nix пакеты для соответствующих дистрибутивов ROS. Теоретически это можно сделать через какой-то генератор, который находит upstream репозитории, строит на базе разных веток .nix пакеты для соответствующих дистрибутивов ROS.

Итак, ROS и его инфраструктура представляют собой экосистему для разработки, сборки, дистрибьюции приложений робототехники, основывающуюся во многом на централизованных репозиториях (github) исходных и собранных пакетов. Как и любая другая экосистема, ROS существует благодаря стандартам/протоколам взаимодействия. Эти стандарты двояки: с одной стороны они сглаживают транзакционные издержки на кооперацию (делают проще взаимодействие участников), а с другой стороны - препятствуют внедрению нового - изменять стандарты в системах с большим количеством акторов довольно сложно. Хотя, откровенно говоря, инфраструктура ROS довольно централизованна и представить её работу без github затруднительно.

Сейчас консенсус состоит в том, что nixоводы сделали надстройку в виде nix-ros-overlay, которая ничего не меняет в этом устоявшемся порядке работы экосистемы и появления таких технологий как nix/guix стоит ожидать не ранее анонса ROS 3.

#ros #nix #discourse

​​Pixi

https://pixi.sh/latest/

Пакетный менеждер общего назначения на базе инфраструктуры Conda, позиционирующийся как замена стандартным инструментам управления зависимостями в ROS. Написан на Rust и по сути является логическим продолжением проекта RoboStack по интеграции приложений на ROS с библиотеками для ИИ и научных расчётов в экосистеме Conda - такими как NumPy, SciPy, Pandas, OpenCV, Natural Language Toolkit, PyTorch и TensorFlow.

Мотивация похожа на Nix - кроссплатформенность и независимость от хост-ОС, воспроизводимость, бинарный кеш, отсутствие необходимости в контейнерах и в установке ROS в систему, изоляция окружения разработчика для проекта. Инструментарий также соответствует - по сути всё сводится к оверлейным репозиториям для rosdistro: в случае с Nix он один, а в экосистеме RoboStack отдельные репозитории для каждого дистрибутива ROS. Преимуществами этого инструмента может быть исторически обусловленная хорошая поддержка Cuda-зависимых библиотек и macOS. Из недостатков можно выделить привязку к yaml. В остальном особых различий не вижу.

Подробнее о Pixi можно ознакомиться в статье
https://prefix.dev/blog/pixi_ros

Github
https://github.com/prefix-dev/pixi

#ros #robostack #conda

​​История 221 бага в Robot Operating System

Коллективная работа учёных из США, Дании, Нидерландов, Германии и Португалии в рамках проекта ROSIN посвящена качеству и безопасности кода для приложений робототехники. Она содержит подробный анализ обнаруженных и впоследствии исправленных ошибках в репозиториях пакетов ROS. В выборку попала 221 уязвимость, собранная по полной истории изменений; с помощью системы BugZoo для каждого бага был подготовлен отдельный Docker-контейнер, чтобы у других исследователей была возможность его воспроизвести. Датасет размещён в публичном репозитории на Github.

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

Специфичными для робототехники являются скорее методы обнаружения этих багов, связанные с необходимостью участия человека и его интерпретации событий в процессе тестирования в условиях эксплуатации робота в физической среде. Такие ошибки сложно вылавливать автоматически (например, с помощью традиционных CI/CD практик разработки ПО) и к ним относятся 115 из 221 рассматриваемых случаев.

Также есть трудности с покрытием тестами - менее 10% фиксов (15 из 156) сопровождаются соответствующими тестами. По одному из профильных социологических исследований отмечается, что сообщество ROS ценит создание новых функций, тогда как задачи контроля качества воспринимаются как сложные и отнимающие много времени, они часто недооцениваются и игнорируются.

Цитата со ссылками на исследования

"Учитывая важность и сложность написания тестов для ПО робототехники, существует острая и растущая потребность в новых инструментах, методах и инфраструктуре, которые позволят разработчикам легко и эффективно тестировать свое программное обеспечение для робототехники. С этой целью исследователи предложили методы генерации тестовых входных данных для отдельных компонентов (Santos et al., 2022) и целых систем (Kim et al., 2019), методы определения и мониторинга предполагаемого поведения робота (например, Aliabadi et al., 2017; He et al., 2019; Inoue и др., 2017; Афзал и др. 2021b), а также языки, специфичные для предметной области, для описания имитируемых сред тестирования (например, Fremont et al., 2019; Majumdar et al., 2019; Klück et al., 2018; Afzal et al., 2021a)."

В качестве средств для повышения качества кода предлагается рассмотреть такие инструменты раннего обнаружения ошибок как HAROS (увы, поддерживается только ROS1).

Мысли... Робототехника двояка - с одной стороны она тесно связана с железом и реальными миром, а потому объективно и обоснованно консервативна (это вам не байты туда-сюда гонять, а килограмы); в тоже время, роботы - это software intensive кибер-физические системы, а потому всё то, что происходит так стремительно в мире программного обеспечения, находит своё отражение и в подходах к разработке робототехники. Именно поэтому она является достаточно удобным мостиком для проникновения практик разработки ПО в материальное творчество и в скором будущем мы увидим робототехнические CI/CD пайплайны из испытательных полигонов для сокращения времени выхода в свет и повышения надёжности "железных" мозгов.

#ros #bugs #research

Быстрые плагины RViz из yaml

https://github.com/Juancams/rviz_publisher

При отладке ROS-проектов часто приходится публиковать тестовые сообщения для проверки логики. Обычно для этой задачи используется rqt_publisher, но в случаях когда проект большой можно запутаться при переключениях между инструментом визуализации и многочисленными терминалами. RViz Publisher реализует идею объединения всех GUI в рамках "одного окна" - отправляем сообщение и смотрим сразу результат. Он позволяет быстро сформировать интерфейсы для отладочных сообщений с помощью rosidl_defaults_generator (тот же пакет, что используется для создания кастомных сообщений в ROS). Для запуска нужно описать желаемые кнопки и сообщения в YAML-файле и добавить путь к нему в CMakeLists.txt.

Пример конфига:

panel:
  - name: "Hello"
    topic: "/example"
    topic_type: "std_msgs/msg/String"
    message:
      data: "Hello, world!"
  - name: "Forward"
    topic: "/cmd_vel"
    topic_type: "geometry_msgs/msg/Twist"
    message:
      linear:
        x: 0.5
  - name: "Move"
    topic: "/cmd_vel"
    topic_type: "geometry_msgs/msg/Twist"
    message:
      linear:
        x: 0.5
        y: 0.0
      angular:
        z: 0.5

В планах разработчика добавить слайдеры для динамического изменения значений, поддержку ROS-сервисов и экшенов, реализовать генерацию комбинированных интерфейсов (например, кнопка + отображение топика).

#rviz #ros #gui

Всем привет!

На связи Robossembler и мы на ROS Meetup'2025! Если кто-то из уважаемых подписчиков хочет пообщаться лично по нашему проекту и не только, пишите на @brylev - состыкуемся!

#ros #meetup #2025

​​ROS 1 - всё (теперь официально)

Поддержка ROS 1, включая последний релиз Noetic Ninjemys , завершилась 31 мая 2025 года. Больше не будут выпускаться обновления, исправления, баг-фиксы, будет отсутствовать поддержка от официального ROS сообщества. Бинарные пакеты останутся доступны на официальном репозитории, однако пользователи рискуют остаться с уязвимостями безопасности и багами без возможности их исправить через официальные каналы.

Гайд по миграции на ROS 2
https://docs.ros.org/en/humble/How-To-Guides/Migrating-from-ROS1.html

#ros #eol

​​Новый промежуточный релиз ROS 2 Kilted Kaiju

Что нового/интересного:

Actions:
- Работу Action можно теперь просмотреть через cli-интерфейс командой ros2 action echo. Подробнее в документации: https://docs.ros.org/en/kilted/Tutorials/Demos/Action-Introspection.html
- Статическая проверка типов для ActionClient и ActionServerв rclpy

RosBag:
- Добавлена поддержка записи и проигрывания Action
- Теперь можно проиграть несколько rosbag файлов одновременно ros2 bag play -i bag1 -i bag2 -i bag3 [storage_id]
- Сообщения можно проиграть в хронологическом порядке, использую Timestamp
- Флаг --sort в команде ros2 bag info позволяет отсортировать все топики

Общесистемное/IDL:
- Добавлен Rust генератор для idl
- В Windows зависимости подтягиваются через Pixi (о котором я как-то уже писал тут)
- В DDS добавлена поддержка Topic Instances (поясню в отдельном посте)

Подробнее тут
https://docs.ros.org/en/kilted/Releases/Release-Kilted-Kaiju.html

#ros #release
—
@robossembler_ru - Open Source Робототехника

​​Yet Another State MachINe

Помимо новомодных Деревьев поведения, о которых я уже много раз тут писал, есть и более классические методы программирования отказоустойчивых автоматизированных систем - например, FSM или конечные автоматы. В отличие от деревьев поведения, над теоретической базой которых работает штучное количество учёных в мире, конечные автоматы имеют гораздо более серьёзную теоретическую базу и изучаются с середины 20 века. В том числе и в России - см. научную школу автоматного программирования Анатолия Абрамовича Шалыто в ИТМО, где ведутся исследования по части формальной верификации автоматных программ или по их генерации с помощью генетических алгоритмов.

В мире ROS долгое время была популярна библиотека SMACC, но появляются и относительно новые проекты. Среди них YASMIN - проект, ориентированный на реализацию поведения роботов с использованием конечных автоматов.

Особенности

- Интеграция с ROS 2 для упрощения развертывания и взаимодействия
- Поддержка Python и C++
- Предназначена для разработки прототипов, позволяющих быстро изменять поведение конечного автомата.
- Включает предопределенные состояния для взаимодействия с ROS 2 - action-клиентами, сервис-клиентами и топиками
- Использует blackboards для обмена данными между состояниями и конечными автоматами
- Управление состоянием: поддерживает отмену и остановку автоматов состояний, включая остановку текущего состояния выполнения
- Встроенный веб-просмотрщик (YASMIN Viewer) для мониторинга выполнения автоматов состояний в режиме реального времени.

В научной работе авторов приводится пример применения иерархических конечных автоматов (т.е. с вложенными друг в друга состояниями) в рамках архитектуры программного фреймворка MERLIN2 совместно с планировщиками PDDL и ROS 2 нодами.

Проект разрабатывается Исследовательской группой мобильной робототехники Леонского универститета, Испания.

#fsm #ros #library

​​Интеграция нейросетей в ПО робота на примере ROS 2

Обобщённый конвейер инференса включает в себя:

1. Сбор данных (Observations)

Первый этап заключается в получении данных от различных датчиков и устройств, которые будут использоваться для обучения или применения ML-модели. В него входят обычно Драйверы ROS 2 , которые обычно реализуют доступ к robot state publishers, камерам, датчикам силы/крутящего момента (F/T sensors) и другим устройствам сбора данных. Также важно проработвать вопрос Синхронизации времени, особенно при работе с несколькими источниками данных. Для этого используются такие механизмы, как фильтры сообщений и трансформации TF (Transforms) для получения гарантий согласованности временных меток.

2. Вывод модели (Inference)

На этом этапе происходит обработка полученных данных с помощью обученной ML-модели.

в случае с Python: Обёртка над PyTorch в виде узла ROS 2. При этом важно быть осторожным с проблемами синхронизации между CPU и GPU, особенно при работе с многопоточными executors.
в случае с C++ : Использование ONNX Runtime для выполнения инференса. Дополнительным преимуществом является возможность обернуть модель в контроллер ROS 2, что позволяет более гибко интегрировать её в существующую систему.

3. Управление аппаратным обеспечением (Commanding Hardware)

Для управления различными типами устройств используются специальные драйверы, такие как контроллеры ROS 2. Важно определиться с тем, какие системы координат использовать — пространство суставов (Joint space) или декартово пространство (Cartesian). Также стоит учитывать вопросы импеданса (Impedance/admittance). Также на этом этапе возможно добавление опциональных слоёв поверх контроллеров, таких как проверка столкновений (collision checking) или решение обратной задачи кинематики (IK) для обеспечения надёжности/предсказуемости исполнения. Например, можно использовать MoveIt Servo (ограниченный функционал) или создать пользовательский узел ROS 2 с полностью настраиваемыми параметрами.

Автор - Sebastian Castro

#ros #model #inference

TAMSViz - RViz на максималках

Пока многие пытаются внедрить в ROS веб-технологии и Rust, эти ребята выжимают максимум из имеющихся в экосистеме инструментов визуализации.

Проект TAMSViz дополняет всем знакомый RViz новыми фичами:

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

Для работы с rosbag: загрузка rosbag-файлов, их визуализация, аннотирование; возможность перемотки с несколькими TF-издателями без разрыва TF

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

Кликайте по ссылке на документацию, там много скриншотов.
https://tams-group.github.io/tamsviz/index.html

Проект не то чтобы активно разрабатываемый, но и не совсем мёртвый - последний коммит 8 месяцев назад. Поддерживается TAMS - департаментом информатики Университета Гамбурга.

#rviz #extention #ros

​​Модульное (юнит) тестирование в ROS 2

Юнит-тестирование в ROS является нетривиальной задачей. Асинхронность во взаимодействии нод в сочетании со сложностью самого middleware приводят к различному поведению программы/модуля в зависимости от контекста исполнения, что может сделать тесты не детерминированными. Помимо этого, сама архитектура ROS содержит довольно много слоёв (ros nodes -> rclcpp -> rcl -> rmw interface -> rmw implementation), каждый из которых может служить источником ошибок, будучи оптимизированным для производительности, а не для тестируемости (как в случае с rclcpp).

Rtest - специализированный фреймворк для юнит-тестирования в ROS 2. Он решает проблему т.н. "ненадежных" (flaky) тестов, возникающих из-за особенностей межпроцессного взаимодействия в ROS 2, и позволяет проводить детальный контроль над выполнением тестов в однопоточном режиме. Основная цель Rtest — обеспечить повторяемость и надежность unit- и интеграционных тестов для кода на C++ в ROS 2 без необходимости перепроверки работы ROS middleware. В документации приведено подробное обоснование концепции этого фреймворка.

Фреймворк поддерживает мокирование ключевых компонентов ROS 2, включая издателей (publishers), подписчиков (subscribers), таймеры (timers), сервисы (services), клиенты сервисов (service clients), в свежем релизе 0.2 добавили также и экспериментальную поддержку action-серверов и клиентов. Это позволяет проверять, создает ли тестируемый узел ожидаемые сущности, корректно ли обрабатывает сообщения и запросы, а также имитировать временные события (например, срабатывание таймеров).

Rtest требует доступа к исходному коду тестируемых компонентов, так как подключает их напрямую в процесс сборки тестов. Для интеграции фреймворка в проект необходимо добавить его как зависимость в package.xml, создать тестовый каталог с CMakeLists.txt и явно указать исходные файлы тестируемой ноды (статическая или динамическая линковка не поддерживается). Тесты пишутся с использованием Google Test и Google Mock, а их запуск требует инициализации rclcpp.

#ros #unit #test #framework