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

(Новая версия. Старая доступна тут).

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

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

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

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

Общие идеи работы системы

На уровне ROS система представлена набором roslaunch скриптов. На уровне OROCOS --- lua скрипты развертывания. Каждый из скриптов представляет собой законченный модуль, добавляющий в систему законченную функциональность с четко детеминированным интерфейсом (порты, топики, сервисы), зависит от других модулей * инвариантен по отношению пространств имен, где запускается (необходимо для поддержки виртуального и реального робота).

Параметры развертывания хранатяся в yaml файлах (для последующей загрузки в Parameter Server ROS), cpf используется как исключение, где применени yaml невозможно. Жесткое назначение парамеров внутри модулей развертки не верхнего уровня неприемлемо.

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

В настоящий момент система одномастерная (один roscore), однако перспективной выглядит использование многомастерной схемы (требуется дополнительное исследование). В одномастеной системе целостность всех настроек и данных достигатся за счет использование сервера параметров ROS. В многомастеной для синхронизации серверов параметров перед запуском используется mongodb config_manager, в процессе работы содержимое параметров не должно меняться. Она же использеутся как централизированное хранилище данных (траектории).

Предполагается наличие в развернутой системе двух машин: Компьютер робота (Rashberry Pi или Beagle Board) исполняет подсистему управдления движением, код анимации глаз и звука. В опреленных конфигурациях может работать автномно. Управляющий компьютер (компьютер оператора, ПК) запускает виртуального робота (часть подсистемы движения), графические системы мониторинга и управления движением (rviz, интерфейс flexbe). На эту же машину могут быть вынесен высший уровен управления, сложные операции по обаботке изображений, SLAM и т.п.

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

Правила именования изложены в общих соглашениях. Ниже приводится сема пространств имен ROS с загруженной подсистемой OROCOS

+- sweetie_bot
|   +- motion (нода rttlua, OROCOS)
|   |   +- resource_control/arbiter
|   |   +- agregator_ref (компонент, публикует желаемую позу)
|   |   +- servo_inv
|   |   +- herkulex/array (компонент)
|   |   +- agregator_real (компонент, публикует реальную позу)
|   +- eyes (нода глаз или пространство с нодами глаз)
|   +- robot_state_publisher
|   +- flexbe_engine (на управляющей машине или на роботе)
+- sweetie_bot_virtual
|   +- motion (нода rttlua, OROCOS)
|   |   +- resource_control/arbiter
|   |   +- agregator_ref
|   |   +- controller/gait
|   +- robot_state_publisher
|   +- moveit_group
+- hmi
    +- rviz
    +- joint_trajectory_editor

Обе основные ветки sweetie_bot и sweetie_bot_virtual содержат идентичные развернутые системы управления, отличающиеся только уровнем взаимодествия с оборудованием. Все топики дублируются внутри этих пространств. Такая схема наиболее удоба для последующего перехода на вариант с несколькими мастерами.

Компоненты sweetie_bot запускаются на роботе, однако отдельные элементы этого пространства (moveit, flexbee_engine) могут быть выненсены на машину оператора. Компоненты sweetie_bot_virtual и hmi запускатся на машине оператора. Поддержки запуска hmi на строне робота не требуется.

Идентификаторы систем координат

ROS требует уникальности идентификаторов систем координат в рамках одного roscore. Топик \tf полагается глобальным, rviz не поддерживаетиспользование нескольких \tf.

Чтобы преодолеть эти сложности предлагается следующая стратегия (проект, надо проверить работоспособность move_group и соответвующего модуля rviz):

  1. Внутри sweetie_bot_virtual и sweetie_bot все глобальные топики дублируются при помощи remap. Соответвенно появлется свой tf, tf_static и т.п. Внутри заускается полная инфраструктура, в частности robot_state_publisher, публикующий позу в локальный топик tf без каких-либо префиксов. Здесь же развертываются подсистемы moveit одометрии и т.п.
  2. Вне этих пространств имен запускается еще пара robot_state_publisher (или транзитные ноды), добавляющая к сообщениям локальных tf нужные префиксы: real и virtual.

Сложность может вызвать запуск в rviz плагина moveit, т.к. не ясно, как он будет воспринимать префиксы. В этом случае придется убирать один из префиксов (real, virtual) в зависимости от того, где запущена move_group.

Система развертывания

Система развертывания представлена набором пакетов в каталоге deployment: sweetie_bot_deploy --- базовая подсистема развертывания. sweetie_bot_movit_config --- конфигурация moveit!. sweetie_bot_test --- средства тестирования подсистем, требующих развертки значительной части СУ робота. sweetie_bot_deploy_... --- дополнительны средсва развертки для новых подсистем.

sweetie_bot_deploy предоставляет средства для запуска системы.

Скрипт config.lua и sweetie-bot-core

Центральным его элементом является скрипт common/config.lua, предназанченный для запуска нужной конфигурации OROCOS.

     rttlua config.lua <module1>.lua <module2>.lua> ... <overlay1> <overlay2> ... __ns:=<namespace> __name:=<name>

Скрипт выполняет следующие дествия:

  1. Разрешает параметры <overlayX> в имена каталогов. Если путь относительный, то к нему добавляется префикс пакета sweetie_bot_deploy, иначе используется переданный путь. К полученному добавляются <sweetie_bot_deploy_pkg>/common и <sweetie_bot_deploy_pkg>

  2. Добавляет полученный список каталогов к LUA_PATH, <overlay1> идет будет первым, затем <overlay2> и т.д.

  3. Загружает необходимое окружение RTT: модули rosnode, rosparam, rttlib_extra, объявляет глобальные переменные depl (Deployer), ros (сервис ROS).

  4. Имя ноды <name> и <namespace> используется для назначения параметра default_root_category сервиса log4cpp.

  5. Предоставляет функцию config.file, которая ищет файл по имени последовательно в <overlay1>, <overlay2> и т.д.

  6. Последовательно загружает <moduleX> командой require.

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

Для удобства использование этого скрипта его вызов инкапсулирован в скрипт bash sweetie-bot-core:

sweetie-bot-core <module1>.lua <module2>.lua> ... <overlay1> <overlay2> ... __ns:=<namespace> __name:=<name>

Использование скрипта развертки OROCOS

Развертка осуществляется при помощи модулей lua и конфигурационных файлов:

sweetie_bot_deploy
 |- sweetie-bot-core --- скрипт bash для запуска config.lua
 |- common --- скрипты и конфигурация общего назначения
 |   |- config.lua --- главный скрипт развертки
 |   |- rttlib_extra.lua --- библиотека вспомогательных функций (обращение к rosparam, упрощение назначения сложных параметров и т.п.)
 |   |- reporting.lua --- функции загрузки и подключения `OCL::ReportingComponent`
 |   |- logger.lua
 |   \- logger.log4cpp
 |- motion_core
 |   |- resource_arbiter.lua, resource_control.yaml
 |   |- motion_core.lua --- арбитр и агрегатор (минимальный набор).
 |   |- motion.lua --- арбитр и агрегатор и подсистема управления приводами.
 |   |- virtual_motion.lua --- ядро для симуляции.
 |   \- herkulex_feedback.lua, herkulex_feedback.yaml, sweetie_bot_servos.cpf --- подсистема Herkulex.
 |- joint_space_control --- задатчики, работающие в угловой СК.
 |   |- controller_joint_state.lua --- контроллер `FollowJointState`.
 |   |- controller_joint_trajectory.lua --- контроллер `AnimationJointTrajectory`.
 |   |- controller_joint_space_all.lua --- все контроллеры.
 |   \- controller_joint_space.yaml --- парметры.
 ...

Модули подчиняются общим соглашениям:

  1. Устанавливают между собой зависимости посредством require. Это позволяет загружать один модуль не более одного раза, независимо от того, сколько раз вызывалось require.

  2. Загружают соответвующие компоненты, устанавливают параметры используя процедуру из rttlib_extra, соединяют порты. Благодаря вызову require можно считать, модули, от которых зависит данный уже загружены.

  3. Создают переменную lua, по которой легко обращаться к загруженному компонету (agregator_ref, servo_inv и т.п.). Имя переменной совпадает с именем компонента без префикса (см. общие соглашения).

    Отдельне модули (resource_control, задатчики) в соответвие со схемой имнования помещают переменные компонента в таблицу, играющую роль пространства имен:

    herkulex.array
herkulex.sched
resource_control.arbiter

    В этой же таблице могут присутсвовать вспомогательные переменные и функции модуля.

  4. Для обращения к конфигурационным файлам (.log4cpp и .cpf) используют config.file(). Это позволяет замещать фалы при помощи механизма overlay.

  5. Для обращения к не входящим в оверлеи модулям можно использовать нотацию require "<overlay>.<module>". См. документацию lua к команде require.

  6. По завершению выполнения модуля соответвующая подсистема должна быть в работоспособном состоянии.

Типовой вызов выгдядит так:

sweetie-bot-core controller_joint_state.lua motion.lua joint_space_control motion_core

Он загружает один контроллер и полситему управления реальным роботом. Для успешного запуска все необходимые параметры должны быть загружены из yaml в сервер параметров.

Параметры ROS, топики ROS

Для каждого компонента следует загружать конфигурацию из сервера параметров, используя вызов rttlib_extra.get_peer_rosparam(). Он обращается к Parameter Server, используя пространство имен вида (см. общие соглашения):

<namespace>/<nodename>/<component_name>
<namespace>/<nodename>/<subsystem>/<component_name>

Топики ROS, связанные с компонетаи OROCOS, располагаются в том же пространстве имен. Их имена совпадают с именами портов.

Скрипты launch

Скрипты launch разамещаются в тех же каталога-оверлеях, в завсимости отпринадлежности к той или иной подсистемы. Принципиально они могут быть двух типов: 1. Модули, подобно модулям развертки OROCOS, загружающие некую хорошо определнну часть системы. Обладают свойством универсальности, что позволяет их задействовать в любой части системы. Их можно разделить на две группы: * Модули робота, которые могут быть запущены в sweetie_bot или sweetie_bot_virtual, соответвенно на самом роботе и на машине оператора. Они не должны сильно зависить от того, что вне их пространства имен. * Модули машины оператора, которые запускаются вне sweetie_bot и sweetie_bot_virtual и соответвенно видеть эти два пространства имен.

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

    Особенностью этих скриптов является следующие параметры: * run_real (boolean) означает, что будут запущены компоненты исполнительной системы робота (управление приводами, экраны-глаза). * robot (boolean) указывает, что будут запущены компоненты, которые должны исполнятся на бортовом компьютере робота. * host (boolean) указывает, что будут запущены компоненты, кторые должны исполнятся на машине оператора.

    Таким образом, чтобы запустит робота в виртуальном режиме (режим по умолчанию):

      user@host $ roslaunch sweetie_bot_deploy joint_space_control.launh run_real:=false host:=true robot:=true

    Для запуска на реальном роботе:

      user@host $ roslaunch sweetie_bot_deploy joint_space_control.launch run_real:=true host:=true robot:=false

  sweetie@sweetie_bot $ export ROS_MASTER_URI=http://host:11311/
  sweetie@sweetie_bot $ roslaunch sweetie_bot_deploy joint_space_control.launch run_real:=true host:=false robot:=true

Модули реализующие функциональность робота должны быть инвариантны по отношению к базовому пространству имен: sweetie_bot или sweetie_bot_virtual. В целях эффективного повторного использования кода парамеры из yaml файлов должны загружаться в модулях как можно более высокого уровня. Любой *.launch файл начинается с поясняющего комментария, описывающиего его тип (MODULE --- модуль, DEPLOYMENT --- скрипт развертки) и назначение.

Хранение параметров

Праметры хранятся в YAML файлах в каталогах оверлеев по подсистемам:

sweetie_bot_deploy
 |- motion_core
 |   |- resource_control.yaml
 |   |- motion.yaml
 |   \- herkulex_feedback.yaml
 |- joint_space_control
     \- controller.yaml

Непосредственно кнфигурация робота хранится без префикса sweetie_bot/sweetie_bot_virtual.

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

Дополнительные пакеты развертывания

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

Использование нескольких roscore

Наиболее надежную систему можно получив, развернум несколько roscore: одно на роботе, другое на управляющем компьютере (http://wiki.ros.org/sig/Multimaster/Existing Techniques).

Единственный стабильный механизм (http://wiki.ros.org/multimaster_fkie) позволяет видеть топики и сервисы другого roscore, что достаточно, чтобы создавать единое рабочее пространство. Некоторую сложность представляет синхронизация параметров. Эту возможность предоставляет config_manager из mongodb_store.