---
title: Модуль исполнения планов
---

Модуль исполнения планов (Robossembler Runtime) представляет собой набор пакетов ROS 2 (на данный момент Humble), которые реализуют логику управления роботом манипулятором, взаимодействие с виртуальным и реальным окружениями. Исходный код всех пакетов размещён на [gitlab.com/robossembler/robossembler-ros2](https://gitlab.com/robossembler/robossembler-ros2).

## Архитектура

![](img/robossembler_runtime_architecture.jpg)

## Пакеты ROS 2 и их функции

- **`env_manager`** - менеджер виртуальных сред:
    - **`env_manager`** - управление объектами в сцене симуляции Gazebo.
    - **`env_manager_interfaces`** - ROS 2 интерфейсы для конфигурации, загрузки, активации и выгрузки сред.
    - **`rbs_gym`** - модуль обучения с подкреплением: управление обучением, создание симуляционных сред, управление пространствами действий и наблюдений, утилиты. Предназначен для реализации среды обучения с подкреплением для роботов-манипуляторов. Он активно использует возможности пакета **env_manager**, упрощая управление сценой и настройку среды. Подробнее о нём в разделе [Сценарии использования](usecases).
    - **`rbs_runtime`** - запуск основного рантайма с использованием `env_manager`.
- **`rbs_bringup`** - запуск сценариев: симуляция, реальный робот, многороботные конфигурации.
- **`rbs_bt_executor`** - выполнение деревьев поведения с Behavior Tree CPP v4.
- **`rbs_interface`** - интерфейс для связи деревьев поведения со скилл-серверами (рекомендуется объединить с `rbs_bt_executor`).
- **`rbs_perception`** - модуль машинного зрения с различными версиями.
- **`rbs_simulation`** - модели для симуляции (рекомендуется объединить с `env_manager` или `rbs_gym`).
- **`rbs_skill_interfaces`** - общие интерфейсы для взаимодействия с скилл-серверами и деревьями поведения.
- **`rbs_skill_servers`** - пакеты для скилл-серверов (рекомендуется заменить на индивидуальные пакеты для каждого сервера).
- **`rbs_task_planner`** - планировщик задач на основе PDDL.
- **`rbs_utils`** - утилиты для работы с конфигурациями, содержащими позиции захвата.
- **`rbss_objectdetection`** - скилл-сервер для обнаружения объектов с YOLOv8.

## rbs_runtime

Модуль **rbs_runtime** предназначен для управления симуляцией в режиме реального времени. Если **env_manager** отвечает за конфигурирование сцены, а **rbs_gym** связывает обучаемых агентов с ROS2, то **rbs_runtime** используется для стандартного запуска симуляции без ограничения по времени. Этот модуль представляет собой обёртку для запуска **env_manager** как ROS2-ноды и реализует базовые сервисы управления средой. На данный момент доступен сервис сброса симуляции в начальное состояние. При этом, если для объектов сцены установлены параметры рандомизации, они будут пересчитаны и применены при каждом сбросе. Модуль обеспечивает интеграцию конфигураций среды в инфраструктуру ROS2 и позволяет легко запускать симуляцию, оставляя её гибкой для последующего расширения или взаимодействия.

## rbs_assets_library

**rbs_assets_library** представляет собой инструмент для интеграции трёхмерных объектов в симуляцию. Она содержит все необходимые ресурсы, включая возможность автоматического расчета инерциальных параметров на основе геометрии объекта. Это достигается благодаря использованию библиотеки **trimesh**, которая анализирует предоставленные модели и генерирует данные, необходимые для корректного воспроизведения физики объекта в симуляторе. 

В библиотеку также входит скрипт для автоматической генерации изображений объектов с различных ракурсов. Эти изображения используются для создания датасета, применяемого в задачах сегментации (выделения объектов) на основе зрения. Для этого используется фреймворк [CNOS](https://arxiv.org/pdf/2307.11067), который интегрируется с библиотекой. 

![templates](./img/templates.png)  
*Пример сгенерированного датасета для CNOS, созданного с помощью скрипта из **rbs_assets_library***

### Возможности библиотеки

Библиотека предоставляет внешний API, который позволяет получать любую информацию о модели по её имени. Название модели формируется автоматически, исходя из имени папки, в которую она была помещена.  

Для работы с геометрией объекта пользователю необходимо:  
1. Создать папку с именем модели.  
2. Разместить в ней файлы геометрии: `.dae` для визуализации и `.obj` или `.stl` для описания коллизии (на выбор).  

После этого пользователь запускает скрипт, который предлагает:  
- выбрать модель для обработки
- задать плотность материала детали

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

### Пример использования

Тестирование возможностей **CNOS** проводилось через разработку навыка для инференса модели сегментации. Это стало возможным благодаря использованию предварительно обученных моделей, таких как **SAM** и **DINOv2**:  
- **SAM** обеспечивает высококачественную сегментацию изображения,  
- **DINOv2** используется для извлечения дополнительных признаков объектов.  

Результаты тестирования показали успешное применение **CNOS** в симуляторе Gazebo. Камера, расположенная на эффекторе робота-манипулятора, фиксировала детали, как, например, "звезда".  

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

![cnos_inference](./img/cnos_inference.png)  
*Результаты тестирования **CNOS** в симуляторе Gazebo на примере детали "звезда"*  

## robot_builder

Модуль **robot_builder** представляет собой универсальное решение для парсинга, конвертации и формирования конфигураций роботов. Его архитектура включает масштабируемый парсер и конвертер, а также дополнительные модули для обработки и использования распарсенной информации. **robot_builder** упрощает работу с конфигурациями роботов и обеспечивает гибкость в интеграции с другими инструментами.

На данный момент поддерживаются два формата:  
- **URDF** — стандартный формат для описания структуры роботов в ROS
- **YAML** — формат, который выделяется своей универсальностью, читабельностью и возможностью ссылаться на внешние данные, что упрощает повторное использование уже описанной информации.

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

### Пример использования

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

| AR4 | Robossembler Arm |
| -------------- | --------------- |
| ![](./img/ar4_robot_builder.png) | ![](./img/rbs_robot_robot_builder.png) |

На рисунках можно заменить, что требуемые параметры вычисляются должным образом. Два робота с разным числом степеней свободы и разными наименовниями конечных звеньев формируют
рабочую конфигурацию. Для проверки движений обоих роботов можно использовать метод телеуправления роботов с помощью интерактивного маркера входящий в состав Rviz2. Для передачи сигналов с интерактивного маркера используется отдельный контроллер `motion_control_handle`, который также генерируется в автоматизированном режиме для любого робота и который позволяет передавать управляющие сигналы на `cartesian_motion_controller`, конфигурация которого представлена на рисунке выше.

Пример запуска конфигурации робота AR4:
![](./img/ar4_robot_builder_control.png)

Пример запуска конфигурации робота Robossembler Arm
![](./img/rbs_robot_builder_control.png)


## rbs_skill_servers

Модуль **rbs_skill_servers** представляет собой систему управления движением робота. Он обеспечивает удобство работы с навыками, не привязан к MoveIt2 и снижает общую сложность конфигурации, которую MoveIt2 накладывает на экосистему ROS 2. Для выполнения задач, где не требуется избегать препятствий, использование MoveIt2 избыточно. Более того, прежняя система навыков движения была тесно связана с типом используемых контроллеров: пользователю приходилось либо ограничиваться навыками, использующими один и тот же контроллер, либо вручную переключать контроллеры. Новая библиотека решает эти проблемы, предоставляя гибкий инструмент в виде обёртки для ROS2 Action Server, который скрывает логику работы с контроллерами.  

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

Для реализации навыка пользователь должен написать функцию `executeAction()`, определяющую логику успешного или неуспешного выполнения задачи. Автоматическое переключение контроллеров реализовано через запросы к сервисам ROS 2 в ноде `controller_manager`. Конфигурация контроллеров формируется автоматически на основе URDF-модели робота с использованием библиотеки `robot_builder`.

Диаграмма последовательности работы с переключение навыков представлена ниже:  

![skills_sequence_diagram](./img/skills_sequence_diagram.png)  
*Диаграмма последовательности работы библиотеки навыков с автоматическим переключением контроллеров.*  

#### Преимущества и возможности  

1. **Автоматизированное переключение контроллеров**  
   Это упрощает вызов навыков из дерева поведения, даже если они используют разные контроллеры.  
2. **Расширенный набор навыков**  
   Помимо движений через декартовы контроллеры, добавлены:  
   - Навыки для движения в конфигурационном пространстве робота.  
   - Навыки в пространстве задач, которые используют обратную кинематику для избегания сингулярных положений.  
3. **Улучшение декартовых контроллеров.**  
   В новой версии движения по декартовым траекториям обрабатываются с использованием линейной интерполяции между точками. Это позволяет избегать неконтролируемых отклонений при попадании в сингулярные положения, делая движения робота более плавными и предсказуемыми.  

Переработка системы навыков значительно повысила надёжность управления движением и упростила разработку новых задач.

### Пример использования

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

![](./img/until_controllers_switched.png)
*Состояние контроллеров перед запуском навыка*

Отправляемые запрос на движение выглядит следеющим образом

![](./img/sended_request.png)
*Отправляемый запрос на выполнение движения навыком*

Видно, что навык запрос отправляется для навыка `mtp_jtc`. Данный навык представляет собой решение обратной задачи кинематики для целевой точки и планирование движения в конфигурационном пространстве
робота. Видно, что навык вернул результат SUCEEDED, что является успешным выполнением в данном случае

Общий вид логированных данных выглядит следующим образом

![](./img/log_when_swithing.png)
*Логи при выполнении навыка*

Приведём комментарий к выводу:
- Изначально запрос отправляется для робота и менем rbs_arm;
- Производится запрос для получения текущего состояния контроллеров;
- Производится попытка загрузка требуемого контроллера;
- Контроллер успешно загружен и сконфигурирован;
- Производится проверка всех загруженных контроллеров на возможные конфликты аппаратных интерфейсов;
- Найден конфликтующий контроллер с именем cartesian_motion_controller;
- Теперь контроллер активирован, а конфликтный контроллер деактивирован;
- Проверяем, есть ли в навыке параметр joints;
- Подключаемся к серверу параметров контроллера и запрашиваем необходимые параметры;
- Начинаем выполнения цели;
- Начинаем решение обратной задачи кинематики;
- Начинаем интерполяцию траектории в конфигурационном пространстве робота;
- Отправляем результат в целевой контроллер;
- Принимаем ответ, что движение выполнено успешно;

После завершения операции можно вывести список состояний контроллеров:

![](./img/controllers_switched.png)