Статья: Анализ производительности ROS2
В ролях: Дипак Чаран Логавасикаран, Ракшит Маха Биллава
Редактор: Облако точек PCL
Статья предназначена только для академического обмена. Если есть какие-либо нарушения, свяжитесь с нами и удалите статью. Пожалуйста, не перепечатывайте без согласия блоггера.
Публичный аккаунт предназначен для обработки облаков точек.,SLAM,3D видение,Обмен полезным контентом, связанным с высокоточными картами и другими областями.。Пожалуйста, не перепечатывайте без разрешения автора. Все студенты могут активно делиться информацией и общаться.
Предыстория
ROS (операционная система робота) — это платформа с открытым исходным кодом, используемая для облегчения разработки приложений робототехники. ROS помогает управлять сложностью и облегчает быстрое создание прототипов приложений. Одним из основных преимуществ использования инфраструктуры ROS является совместимость и модульность, обеспечиваемые ROS. Он поддерживает несколько языков программирования, включая Python и C++, и обеспечивает структуру узлов plug-and-play, которую можно использовать даже в сетевой среде на нескольких устройствах. ROS1 был первоначально создан в 2007 году компанией Willow Garage и пользуется большой популярностью среди энтузиастов. Однако у него есть и свои недостатки, и для удовлетворения потребностей была разработана ROS2. ROS2 использует совершенно другую архитектуру, чтобы обеспечить лучшую модульность и независимую от платформы поддержку. ROS2 обещает предоставить аналогичные API для разных языков программирования и ускорить развертывание новых функций за счет многоуровневой реализации, в которой важна базовая библиотека. для всех Языки программирования все остаются прежними. ROS2 также предоставляет централизованную систему, в которой каждый узел может обнаруживать другие узлы, поддерживать асинхронные службы и действия и устраняет зависимость от главного узла ROS. ROS2 использует промежуточное программное обеспечение DDS и, следовательно, обеспечивает все соответствующие политики качества обслуживания. Он также предоставляет различные инструменты отладки и визуализации, а также расширенную поддержку Windows и macOS. Хотя ROS2 широко используется исследователями и энтузиастами, все еще существуют некоторые проблемы с ее производительностью в средах реального времени. В этом исследовании мы оцениваем производительность ROS2 и понимаем ее актуальность в экосистеме реального времени.
Задача этой статьи — проанализировать производительность связи между узлами ROS2, а также записать процесс выполнения анализа и полученные результаты.
Описание решения
Описание оборудования
Все тестирование для этого обзора проводилось на комплекте разработчика NVIDIA Jetson Orin, оснащенном 12-ядерным процессором ARM Cortex A78 и твердотельным накопителем eMMC емкостью 64 ГБ. Используется Jetson JetPack SDK 5.1.1, оснащенный устройством Jetson Orin, под управлением операционной системы Ubuntu 22.04 (Linux Kernel 5.10.X), в основном с использованием ROS2 Humble для тестирования.
rclpy vs rclcpp
rclpy и rclcpp — это клиентские API ROS2, используемые для установки/настройки узлов или взаимодействия с ядром ROS2. Они являются реализациями Python и C++ соответственно. Большинство API и их использование схожи. Однако, согласно проблеме, которую мы обнаружили в репозитории задержек ros2, rclpy при публикации больших данных работает в 30–100 раз медленнее, чем rclcpp. Эта проблема была решена и объединена до выпуска ROS2 Foxy. Нам удалось клонировать репозиторий, в котором обнаружена проблема, и запустить тесты с минимальными изменениями, подтвердив, что разница в производительности не превышает 30 раз.
Чтобы оценить разницу в производительности между rclcpp и rclpy, мы создали простой тест, который публикует блок данных и измеряет время, необходимое обеим реализациям для публикации сообщения. Сначала мы генерируем данные для публикации и создаем экземпляр таймера. Таймер запускается перед вызовом API публикации и останавливается сразу после вызова публикации. В реализациях rclpy и rclcpp методы остаются согласованными. Мы наблюдаем, что rclpy публикует сообщения. Время. require всегда примерно в 6 раз длиннее, чем rclcpp, как показано на рисунке 1.
Рисунок 1. Время выпуска rclpy и rclcpp.
Затем был проведен тест, сравнивающий задержку реализаций rclpy и rclcpp, для расчета задержки сначала создавалось сообщение с необходимым количеством байт, затем записывалось время эпохи и вызывался API публикации, сразу после времени публикации эпоха время было отправлено подписчику, в узле подписчика мы записываем время эпохи, как только сообщение получено, затем получаем время публикации и вычисляем разницу, чтобы получить задержку сообщения, этот тест повторяется примерно 15 раз, и среднее из 15 результатов, использованных в нашей оценке. Мы видим, что задержка реализации rclpy примерно в 3 раза больше, чем у реализации rclcpp, как показано на рисунке 2.
Рисунок 2. Задержка rclpy и rclcpp
Поскольку в лаборатории используются несколько версий ROS2 на нескольких устройствах, мы также оценили версии ROS2, чтобы увидеть, влияют ли разные версии на результаты. Мы провели один и тот же тест на задержку на версиях ROS2 Humble и Foxy. В этом тесте использовалась реализация rclcpp как на версиях Humble, так и на Foxy. Основываясь на наших наблюдениях, мы не нашли убедительных доказательств того, что одна версия лучше другой. на рисунке 3, хотя Foxy работает немного лучше для больших сообщений.
Рисунок 3. Задержка ROS2 Humble и Foxy
Поскольку ROS2 использует промежуточное программное обеспечение DDS, которое само по себе также обеспечивает различные политики QoS, для целей данного исследования мы хотели оценить влияние использования надежных и оптимальных политик QoS. Здесь также использовался тест на задержку, использованный в предыдущей оценке, только с измененной политикой QoS, и снова мы не смогли найти явного улучшения одного по сравнению с другим, как показано на рисунке 4. Поскольку тест проводился только с двумя узлами, сетевой трафик отсутствовал, что означало отсутствие или почти полное отсутствие потери пакетов, поэтому мы пришли к выводу, что либо при максимально возможной, либо при надежной реализации политики QoS будет отправляться что-то вроде данных без дублирования, что может быть причиной подобных результатов.
Рисунок 4. Надежность ROS2 и лучшее качество обслуживания (QoS)
Совет эксперта
Имея опыт работы с ROS2, Марк сделал следующие предложения:
* Используйте исполнители событий в реализации ROS2 на C++.
* Выключите режим IDLE процессора через операционную систему Linux.
* Закрепите задачи, интенсивно использующие ЦП, для отдельных ядер ЦП.
* Измените планировщик Linux на Round Robin.
* Объедините несколько узлов в один процесс, избегайте использования IPC и используйте общую память.
Приняв эти предложения, мы обнаружили, что это не привело к существенному улучшению задержки в нашем конкретном тестовом примере. Кроме того, мы связались с профессором Питером Габриэлем Адамчиком и его студентами Исеном Вангом и Кираном Николсом. Хотя они не тестировали ROS2, отправляющую большие сообщения в МБ, они отметили, что их опыт работы с ROS2 был в чем-то схожим, а также рекомендовали использовать живое ядро Linux и использовать UDP вместо TCP в соединениях ROS2, поскольку все наши узлы все работает на одном устройстве, и выбор сетевого протокола не подходит для наших экспериментов. Однако мы надеемся рассмотреть возможность использования патча RT PREEMPT для Linux в будущем.
Заключение
Основываясь на приведенных выше результатах исследования, очевидно, что реализация ROS2 на C++ лучше, чем версия на Python, с точки зрения скорости. Однако, несмотря на усилия разработчиков ROS2 по улучшению производительности в реальном времени, фреймворк по-прежнему не подходит по времени. -критические системы и системы реального времени. Результаты наших испытаний показывают, что по сравнению с преимуществами, предоставляемыми ROS2 в сценариях реального времени, накладные расходы на передачу сообщений слишком велики. Поэтому ROS2 не рекомендуется на данном этапе для приложений реального времени.
Если в приведенном выше содержании есть какие-либо ошибки, пожалуйста, оставьте комментарий. Исправления и обмен приветствуются. Если есть какие-либо нарушения, пожалуйста, свяжитесь с нами, чтобы удалить их.