Развертывание системы

Конфигурация развернутой системы описывается тремя элементами:

  1. Загруженные компоненты.
  2. Параметрами всех компонент.
  3. Отношениями между компонентами (соединения портов и операций).

OROCOS компоненты могут иметь скрытые параметры, не представленные в их внешних интерфейсах как Properties. Изменять их можно, например, вызовом операций. Таких ситуаций следует избегать, т.к. такие настройки не будут видимы стандартным средствам ROS/OROCOS.

В ROS отношения компонент представлены набором сервисов и топиков.

Пространства имен

Для именования компонент OROCOS в рамках ROS предлагается схема:

<sybsystem>/<component_name>

<sybsystem> --- внешнее имя Deployer, <component_name> --- имя компонента. Все объекты связанные с компонентом размещаются в его пространстве имен (параметры, сервисы динамической конфигурации и т.п.).

Такая схема наиболее близка к принципам именования в OROCOS. Вопрос выделения значимых топиков и сервисов ROS в отдельные объекты открыт.

Параметры

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

Статические параметры --- параметры состав которых и типы заранее фиксированы (скорость передачи днанны, имя файла).

Динамические параметры --- состав параметров (древовидная структура) при написании компонента (список и параметры приводов).

Процедура работы с параметрами:

  1. Динамических параметры хранятся в .cpf файлах OROCOS. (Иного способа нет, rosparam не поддерживает динамическую загрузку, но можно написать к нему патч).

    Именами, ответствуют компоненту или его типу. Т.к. .cpf --- это XML формат, то можно использовать включение файла по URI (в частности по относительному пути от включающего .cpf файла). Общую конфигурацию для нескольких компонент следует выделять в отдельный файл. 2. Статические параметры можно хранить как угодно: .cpf. Загрузка: marshalling.updateProperties() .yaml при соблюдении правил именования. Загрузка: .yaml -> Parameter Server -> rosparam.getAll() (Cм. rtt_rosparam). Скрипты развертывания (менее предпочтительно). 3. Модификация параметров Скрипты при загрузке dynamic_reconfigure через rtt_dynamic_reconfigure 4. Мониторинг: rqt_reconfigure 5. Сохранение конфигурации .cpf, marshalling.storeProperties() Для статических можно также использовать .yaml, rosparam dump

Таким образом предпочитаемый способ хранения --- .cpf.

Пример использования параметров: param_tester.

Обработка параметров

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

  1. Создание структур происходит в configureHook() их очистка в cleanupHook(). Таким образом, изменение соответствующих параметров работающего компонента не влияет на его функционирование.

  2. Если необходима возможность перенастройки работающего компонента --- реализовать операцию notifyPrpertiesUpdate() (OwnThread) в соответствии с rtt_dynamic_reconfigure (Обратите внимания, в документации этот метод назван неправильно).

Развертывание системы

OROCOS предоставляет различные средства развертывания:

  • .xml описание.
  • .ops скрипты.
  • .lua скрипты

.xml --- эквивалент roslaunch. В обоих случаях, похоже, нет возможности исполнять операции. Поэтому конфигурация плагинов ROS будет затруднена. Нет доступа к окружению и rospack. Однако этот способ более удобен для больших проектов за счет автоматизации ряда действий. В принципе, недостатки можно исправить за счет вызова скриптов.

.ops предоставляет наиболее полный и наглядный способ развертки. Плагин rtt_rospack предоставляет средство определения путей пакетов, os к переменным окружения. Не хватает некоторой функциональности: выразительности языка, средств работы с файлами (рабочий каталог, проверка существования), автоматизации ряда процедур (например, запустить все), получения списка загруженных компонент.

Недостатки можно устранить, написав несколько вспомогательных скриптов. Для работы с ФС потребуется сервис.

.lua наиболее выразительна (полноценный язык) но хуже документирована.

Методы могут смешиваться в любой пропорции. Из любого описания можно вызвать любое.

В качестве основного способа предлагается использовать скрипты .ops.

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

Конфигурация системы

Полная конфигурация подсистемы движения размещается отдельном пакете. Такой пакет может содержать несколько связанных конфигураций.

Каталог с конфигурацией имеет структуру:

|- properties/
|   |- component1.cpf --- параметры 
|   \- component2.cpf --- параметры
|- core.ops --- базовый файл конфигурации, запускается для развертывания
|- core_include1.ops --- часть базовой конфигурации, 
|- component1.ops --- специфичная конфигурация компонента, вызывается из core.ops
|- supplemental_action1.ops --- скрипт выполнения некого вспомогательного действия
\- supplemental_action2.ops --- скрипт выполнения некого вспомогательного действия

В пакетах, реализующих компоненты можно хранить примеры конфигурации, но излишнее дублирование нежелательно.

Проблема: неясно, как управлять рабочим каталогом deployer.

Вспомогательны скрипты

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

Для обращения к компоненту по имени можно использовать следующий код:

aliasPeer("Deployer", name, "peer");
peer.action();
... 
removePeer("peer");

Повторное использование конфигурации

Желательна возможность создания новой конфигурации по базовой путем замены core.ops и модификации небольшого числа параметров через .cpf или скрипты. При этом модифицированная версия должна содержать только измененные файлы.

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