ros-orocos.pdf

Цель данной страницы --- описание основных возможностей ROS и пакетов группы OROCOS в контексте задачи управления движением.

Обе системы компонентно-ориентированы, т.е. работающее приложение --- совокупность компонент, взаимодействующих через известные интерфейсы.

Основная задача проектирования --- выделение компонент и их интерфейсов .

Компоненты должны быть универсальны (использование их в разных вариантах системы, с разными настройками).
Относительно слабо связаны между собой. Хороший критерий --- компонент можно испорльзовать без любого другого.
Следует избегать повторения функций, при необходимости использовать соответвующие приемы: библиотеки, плагины.
Интерфейс компонента должен быть задокументирован. Полностью!

Жизненый цикл компонента

Компонент (нода в ROS) загружается, настраивается, запускается, работает, останавливается, выгружается. В OROCOS эти стадии четко разделены, в ROS явного разделения нет, но можно сделаь искуственно через операции.

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

В ROS ограничения на нити нет, так и нет основных режимов работы. Все в руках программиста.

Средства взаимодействия компонент

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

ROS	OROCOS	Примечания
топик	порты	Передача типизированых сообщений издатель/подписчик, основной интерфейс РВ.
сервис	операция	Аналог методов классов. Взаимодействие запрос-ответ. Используются для осуществления сложных операций, настройки.
параметр	параметр	Аналог полей классов. Основной средство настройки компонент.
плагин	плагин	Аналог динамической библиотеки. Некий програмный объект загружаемый в компонент и придающий ему некую дополнительную функциональность.

Наиболее близкий аналог сигналов ТАУ --- сообщения передаваемые по портам/топикам. Примеры сигналов: поза, скорость и т.п. Следует отметить, что порты могут быть использованы для синхронизации, т.к. один компонент извщает другой о событии.

Именование

Статическое

ROS, OROCOS: пакет/типа компонента

В ROS возможны вложения пакетов.

Динамическое (времени выполнения)

OROCOS: имя компонента/ресурс
Ресурс --- имя порта, операции, парметра...

В ROS к этой схеме добавляется:

Пространства имен (внутри и снаружи).
Механизм относительныъх имен.
Name remapping: стандартное имя заменяется на псевдоним.
Средсва агрегирования roslauch (группа компонентов объединябтся в большой виртуальный компонент).

Компонент определнного типа может быть заружен под заданным

Развертывание приложения

Работующее приложение собирается из набора компонент. Их связывани и настройка позволяет получить различную функциональность и режимы работы.

В OROCSO эту задачу решает специальный компонент deployer, работающий в интерактивном режиме и исполняющий скрипты OPS и/или XML файлы. Возможно применения rtlua и языка lua. Язsк OPS алгоритмически полон. Позволяет писать компоненты и автоматы.

В ROS есть средства командной строки (rosrun), загрузки конфигурации из (roslauch: YAML *.lauch файлы), централизированный сервис настроек (Parameter server и dynamic_reconfigure).

Операция	ROS	OROCOS
интерактивная настройка	коммандная строка	`deployer`
загрузка компонент	`roslauch`, *.lauch файлы	`deployer`, .ops, .xml `rtlua`
связывание портов	ноды сами знают имена топиков name remapping `roslauch` + remappnig	Явно указываются связи портов. `deployer`, .ops, .xml `rtlua`
подключение плагинов	командная строка `roslauch`	`deployer`, `rtlua` `rtt_roscomm`: порты превращатся в топики.
назначение параметров	`parameter_server` yaml файлы компоненты сами запрашивают параметры remapping --- изменение имени запрашиваемого параметра `dynamic_reconfigure` .cfg файлы с декларациями парметров в каждом компоненте запрос их у `parameter_server` изменение во время выполнени при помощи операций gui, единое древо динамических парметров remapping не раболтает (?) видимо, не перваривает одинаковые декларации парметров в разных .cfg `nimbro_config_server` призван решить проблему `dynamic_reconfigure` с одинаковыми параметрами в разных компонентах. синтаксис без .cfg, имя параметра в коде.	`deployer`, `rtlua`, xml `rtt_ros_param`, `rtt_dynamic_reconfigure` --- интеграция с ROS, праметры OROCOS обретают все свойства ROS.