roboforum.ru

Scorpio писал(а):Удобно ли писать программы под ROS? Что там со средой разработки?

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

Scorpio писал(а):как то напрягает постоянная необходимость пользоваться командной строкой. На набивание команд уходит куча времени по крайней мере у меня.

Командной строкой придется пользоваться, по крайней мере на этапах отладки вашего робота.

Scorpio писал(а):Хотелось просто общего описания простым человеческим языком еще, до того, как вдаваться в детали. Типа "программы пишутся на питоне в текстовом редакторе, без всякой автоматической проверки синтаксиса с кучей дополнительных ограничений, зато легко и надежно можно обмениваться данными между параллельными потоками".

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

Scorpio писал(а):Жду, что кто-нибудь скажет во вступительном слове, что в ROS работать легко, быстро и приятно. Стоит только в него въехать.

Именно так. Вообще, работа с пакетами ROS напоминает мне некий процесс юстировки, "подкручивания" всяких там параметров, настройки всевозможных переменных. На самом деле интересно и совсем не сложно.

Добавлено спустя 3 часа 24 минуты 12 секунд:
Продолжим. Рассмотрим архитектуру ROS. Здесь будет немного теории, без понимания которой вы не сможете работать с ROS. В общем, это достаточно сложная тема для первоначального осознания, и я рекомендовал бы вам периодически возвращаться сюда, когда будет не понятно что то в структуре пакетов ROS. Должен сказать, что если до этого момента было мало что понятно, то после прочтения этого раздела не станет понятно вообще ничего. Как правило все начинающие изучать ROS спотыкаются как раз на теме архитектуры ROS. Но прошу вас, не торопитесь бросать, ознакомьтесь со следующим разделом, пусть сейчас мало что ясно, со временем прояснится
Итак.

Архитектура ROS
В архитектуре ROS можно выделить три концептуальных уровня:
∙ Уровень файловой системы (Filesystem level), или, если проще сказать, где и какие файлы и папки расположены для успешного запуска и работы пакетов и стеков.
∙ Уровень вычислительного графа (Computation Graph level), или тот самый граф работы создаваемого робота, на подобии того, что я публиковал в начале темы
∙ Уровень сообщества (Community level), или просто люди создающие в ROS свои проекты и как то общающиеся друг с другом
Первый уровень — это уровень файловой системы. На этом уровне расположена внутренняя структура ROS — структура папок, файлы, необходимые для работы.
Второй уровень — это уровень вычислительного графа, на котором происходит взаимодействие между процессами и системами. На этом уровне находятся концепции и модули, которые имеются в ROS для создания систем, обработки всех процессов, коммуникации с более чем одним компьютером и так далее.
Третий уровень — это уровень сообщества. Этот уровень содержит инструменты и концепции для обмена знаниями, алгоритмы и код от любого разработчика. Этот уровень очень важен, поскольку ROS быстро растет при мощной поддержке со стороны сообщества.

Файловая система ROS
Первым уровнем в архитектуре ROS является уровень файловой системы. Как только мы начинаем использовать или же разрабатывать проекты на ROS, мы сразу же видим эту концепцию, которая вначале может показаться достаточно странной, но в дальнейшем все становится понятно. Как и в случае обычной операционной системы, программы в ROS разделены на папки, в которых содержатся некоторые файлы, описывающие ее функциональность:
∙ Пакеты (Packages): формируют атомарный уровень ROS. Пакет имеет минимальную структуру и содержимое, чтобы создать программу в ROS. Он может иметь выполняемые процессы (узлы или node), файлы конфигурации и так далее.
∙ Декларации (Manifests): содержится информация о пакетах, лицензионная информация, зависимости, флаги компиляции и прочее. Управление декларациями осуществляется через файл manifests.xml.
∙ Стеки (Stacks): когда вы собираете вместе несколько пакетов для получения некоторой функциональности, то получите стек. В ROS, существует много таких стеков для различных целей, например, стек навигации.
∙ Декларации стеков (Stack manifests): предоставляют данные о стеке, включая его лицензионную информацию и его зависимости от других стеков. Файл stack.xml.
∙ Типы сообщений (Message types, msg): сообщение является информацией, которую процесс отправляет другим процессам. В ROS имеется множество стандартных типов сообщений. Описание сообщения сохраняется в my_package/msg/MyMessageType.msg
∙ Типы сервисов (Service types, src): описания сервисов хранятся в my_package/srv/MyServiceType.srv Определяют в ROS структуры данных запросов и ответов для сервисов.


Пакеты
Обычно, когда мы говорим о пакетах, то имеем ввиду типичную структуру папок и файлов. Эта структура выглядит следующим образом:
∙ bin/ Это папка, где сохраняются наши скомпилированные программы
∙ include/package_name Эта директория включает заголовки библиотек, которые понадобятся. Не забудьте экспортировать декларацию, так как она используется другими пакетами
∙ msg/ Если вы разработали нестандартное сообщение, то помещайте его сюда
∙ scripts/ Здесь находятся исполняемые скрипты. Это могут быть скрипты оболочки Bash, Python’а или какие-либо еще
∙ src/ Здесь располагаются исходные файлы вашей программы. Вы можете создать папку для узлов и разрешений для узлов, либо организовать, так как вы хотите
∙ srv/ Здесь представлены типы сервисов
∙ CMakeLists.txt Это файл построения CMake
∙ manifest.xml Это файл декларации пакета
Для создания, редактирования или другой работы с пакетами, в ROS имеется несколько вспомогательных инструментов:
∙ rospack Эта команда используется для получения информации или поиска пакетов в системе
∙ roscreate-pkg Если вы хотите создать новый пакет, то воспользуйтесь этой командой
∙ rosmake Эта команда используется для компиляции пакета
∙ rosdep Эта команда устанавливает системные зависимости для пакета
∙ rxdeps Эта команда используется, если вы хотите посмотреть зависимости пакета в виде графа
Для перемещения между пакетами и их папками, в ROS имеется очень полезный инструмент, называемый rosbash, в котором имеется несколько команд, очень сильно похожих на команды Linux. Вот несколько примеров:
∙ roscd Эта команда помогает сменить директорию — аналог команды cd в Linux
∙ rosed Команда используется для редактирования файла
∙ roscp Команда используется для копирования файла из некоторого пакета
∙ rosd Эта команда выдает список директорий пакета
∙ rosls Список файлов пакета — аналог команды ls в Linux
Файл manifest.xml обязательно должен присутствовать в пакете. Он содержит специфическую информацию о конкретном пакете. Если вы найдете этот файл в папке, то возможно, эта папка является пакетом.
Если открыть файл manifest.xml, то вы увидите информацию о названии пакета, зависимостях и так далее. Все это упрощает установку и распространение этого пакета.
Два типичных тега, которые используются в файле декларации — это <depend> и <export>. Тег <depend> показывает, какие пакеты должны быть установлены до того, как будет установлен выбранный пакет. Это сделано из-за того, что новый пакет пользуется некоторой функциональностью других пакетов. Тег <export> говорит системе, какие флаги должны быть использованы для компиляции пакета, какие заголовки должны быть включены и так далее. Ниже приведен пример этого файла.

Код: Выделить всё • Развернуть

<package>
<description brief="short description">
long description,
</description>
<author>Ivanov Ivan Ivanovich</author>
<license>BSD</license>
<url>http://example.com/</url>
<depend package="roscpp"/>
<depend package="common"/>
<depend package="otherPackage"/>
<versioncontrol type="svn" url="https://urlofpackage/trunk"/>
<export>
<cpp cflags="-I${prefix}/include" lflags="-L${prefix}/lib -lros"/>
</package>

Пакеты в ROS организуются в стеки. В то время, как целью пакетов является создание минимального набора кода, для облегчения его повторного использования, целью стеков является упрощение процесса совместного использования кода. Стеку необходима базовая структура файлов и папок. Ее можно создать вручную, однако, в ROS для этого имеется инструмент в виде команды roscreate-stack. Для стека необходимы следующие три файла: CMakeList.txt, Makefile и stack.xml. Если в папке вам попадется файл stack.xml, вы можете быть уверены, что это стек. Ниже приведен пример этого файла.

Код: Выделить всё • Развернуть

<stack>
<description brief="Sample_Stack">Sample_Stack1</description>
<author>Ivanov Ivan Ivanovich</author>
<license>BSD,LGPL,proprietary</license>
<review status="unreviewed" notes=""/>
<url>http://someurl.blablabla</url>
<depend stack="common_msgs" /> <!-- nav_msgs, sensor_msgs, geometry_msgs -->
<depend stack="ros_tutorials" /> <!-- turtlesim -->
</stack>

Сообщения
ROS использует упрощенный язык описания сообщений для характеристики значений данных, которые выдают узлы ROS. Используя это описание, ROS может создать правильный источник кода для этих типов сообщений для нескольких языков программирования. ROS имеет множество предопределенных сообщений, но если вы разрабатываете новое сообщение, оно будет в папке msg/ вашего пакета. Внутри этой папки, некоторые файлы с расширением .msg определяют сообщения. Сообщение должно иметь две основные части: поля и константы. Поля определяют тип данных, передаваемых в сообщении. например, int32, float32 и string, или же новые типы, которые вы могли создать до этого, например, типы type1 и type2. Константы определяют имена полей.
Пример файла msg:

Код: Выделить всё • Развернуть

int32 id
float32 vel
string name

В ROS имеется множество стандартных типов для использования в сообщениях.

Код: Выделить всё • Развернуть

Простой тип данных     Описание                C++            Python
bool                   Unsigned 8-bit int      uint8_t        bool
int8                   Signed 8-bit int        int8_t         int
uint8                  Unsigned 8-bit int      uint8_t        int
int16                  Signed 16-bit int       int16_t        int
uint16                 Unsigned 16-bit int     uint16_t       int
int32                  Signed 32-bit int       int32_t        int
uint32                 Unsigned 32-bit int     uint32_t       int
int64                  Signed 64-bit int       int64_t        long
uint64                 Unsigned 64-bit int     uint64_t       long
float32                32-bit IEEE float       float          float
float64                64-bit IEEE float       double         float
string                 ASCII string (4 bit)    std::string    string
time                   Secs/nsecs signed       ros::Time      rospy.Time
                       32 bit int
duration               Secs/nsecs signed       ros::Duration  ros::Duration
                       32 bit int                             rospy.Duration

Специальным типом в ROS является Header. Он используется для добавления временных меток, кадров и так далее. Этот тип позволяет сообщениям быть пронумерованными, таким образом, мы можем знать, кто отправил сообщение. Могут быть добавлены другие функции, прозрачные для пользователя, но управляемые ROS.
Тип Header содержит следующие поля:

Код: Выделить всё • Развернуть

uint32 seq
time stamp
string frame_id

Сервисы
ROS использует упрощенный язык описания сервисов для характеристики типов сервисов. Он создается непосредственно из формата msg для обеспечения связи запрос/ответ между узлами. Описания сервиса хранятся в .srv файлах в поддиректории srv/ пакета.
Для вызова сервиса необходимо использовать имя пакета вместе с именем сервиса. Например, файлу sample_package1/srv/sample1.srv соответствует sample_package1/sample1.
Есть несколько инструментов для работы с сервисами. Инструмент rossrv выводит описание сервиса, пакет содержащий .srv файлы и может найти файлы источников, которые используют этот тип сервиса.
Если вы хотите создать сервис, ROS может помочь вам генератором сервисов. Эти инструменты генерируют код для начального определения сервиса. Вам только нужно добавить строку gensrv() в ваш файл CMakeLists.txt.

Продолжение следует.

Выскажу свое личное мнение, которое скорее всего ошибочно.
После войны с ROS я победил одну из ее проблем. В нем нет OpenCV свежих версий. При попытке собрать Jade с третьей версией зрения получил облом. Удалось подключить только старую версию 2.9. Мне нужна была эта библиотека для работы с GPU, т.е. взять готовые бинарники было нельзя.
Но не это главное. У меня создалось впечатление, что при всем многообразии пакетов различных производителей очень трудно воспользоваться ими для соединения во что-то единое целое. У всех что-то да отличается не на уровне ROS, а на прикладном уровне. То сообщения не того калибра, то набор абстракций не тот, то нет исходников, то они для старой версии ROS. То понос, то золотуха.
Многие пакеты существуют и отдельно от ROS. И речевые и навигационные и моделирующие. Для научной работы ROS достаточно. Но, к примеру, сами сообщения для жесткого реалтайма никуда не годятся из-за своей громоздкости и тормознутости. Наличие в системе только одного главного сервера, вокруг которого все вертится, приводит к низкой надежности всего робота. Основной канал передачи сообщений - сеть, которая является самым медленным звеном. Поэтому разработчики ROS придумали костыли - встраиваемые модули, чтобы общение между ними происходили внутри одного приложения.
Все эти и еще огромная масса недостатков существующих версий ROS (за исключением самой новой версии, про которую я ничего не знаю) заставило часть разработчиков начать разработку ROS2. Но и там я вижу часть нерешенных проблем. Основная - это то, что ROS по существу клей для робота на уровне железа и низкоуровневого взаимодействия драйверов. А как только появляются пакеты высокоуровневые, такие, как навигации, планирования и т.д., то обнаруживается вакуум. Нет в ROS клея для этих более абстрактных функций.
Общее первое впечатление у меня создалось от ROS такое: Насобирали в состав разношерстных вагонов от нефтеналивных и угольных до трамвайных и вагонеток и отправились в дальний путь.

При попытке собрать Jade с третьей версией зрения получил облом. Удалось подключить только старую версию 2.9.

может раньше что то было не так? тут заявлена поддержка начиная с indigo http://wiki.ros.org/opencv3

Но, к примеру, сами сообщения для жесткого реалтайма никуда не годятся из-за своей громоздкости и тормознутости.

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

Но в чём то разработчики с вами согласны ,вот тут можно почитать их размышления по этому поводу
http://design.ros2.org/articles/why_ros2.html
http://design.ros2.org/articles/realtim ... round.html
https://github.com/ros2/ros2/wiki/Intra ... munication

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

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

не уловил проблему, можно конкретный пример?

Общее первое впечатление у меня создалось от ROS такое: Насобирали в состав разношерстных вагонов от нефтеналивных и угольных до трамвайных и вагонеток и отправились в дальний путь.

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

И эта проблема широко известна в мире opensource, в разных дистрибутивах решается по разному, в рос пока используют подход создания стабильных релизов в пределах которого все собранные пакеты должны быть совместимы.
Есть другой вариант решения этой проблемы - роллинг релизы (как например реализовано в дистрибутиве arch ), т.е. постоянное асинхронное обновление всего программного обеспечения. В этой системе есть свои минусы - перманентное состояние beta релиза, в любой момент что нибудь где нибудь отвалится из того что работало раньше.

Я так понял, что ROS1 ,будет еще какое-то время работать параллельно ROS2, но никакого импортирования проектов от ROS1 похоже не обещают. В любом случае, разобравшись в ROS1, будет проще въехать в ROS2, обещающую быть просто конфеткой.

Нужно понимать - лучшее враг хорошего.
В линуксе в последнее десятилетие много чего поломали в стремлении сделать лучше, так что я немного скептически отношусь к ROS2.

Если действительно нужны те плюшки что заявлены в ROS2 то можно подключиться к тестированию, но вообще говоря, многое из заявленного в ROS2 можно сделать и в ROS1 просто по другому.

Основной коллектив, делающий ROS, потерял почти всю группу сетевых программистов (аж целых полтора человека). После чего они пару лет провели в метаниях "какую библиотеку взять за основу, чтобы самим не возиться с сетью, ибо некем", вместо того, чтобы допилить UDP транспорт и прикрутить нормальный interprocess communication. И после чего они наворотили кучу обёрток, размер которых превышает кодобазу например того же ZMQ.

Вообщем ROS 2.0 штука технически подозрительная. А для программирования из visual studio или arduino ide есть ros serial. Мы в своих решениях ещё долго будем применять ROS 1.x

Виктор Казаринов писал(а):В нем нет OpenCV свежих версий

А кто заставляет ставить opencv из ros дистрибутивов? Между ROS и OpenCV общего только модуль cv_bridge, в котором аж целых две функции: конвертировать из sensor_msgs::Image в cv::Mat и наоборот. Если вы собрались применять OpenCV с размахом, то написать конвертер самостоятельно проблем не составит под любые входные данные (nav_msgs::OccupancyGrid). И при том вы вольны собирать любую версию OpenCV.

Хм, подумал ещё пару раз. Если у вас под рукой вкусный ROS пакет, которому хочется подложить OpenCV 3x, а он и не собрался, то да, печаль-проблема. Но это уже вопросы к комьюнити. С тем же G2O устроили ту ещё упячку с версиями

Выдаю следующую порцию ROS.
Продолжим изучение.

Уровень вычислительного графа
ROS создает сеть, в которой соединены все процессы. Любой узел в системе может получить доступ к этой сети, взаимодействовать с другими узлами, смотреть информацию, которую они посылают и передавать данные в сеть.

Структура уровня вычислительного графа

Базовыми понятиями на этом уровне являются: узлы, мастер, сервер параметров, сообщения, сервисы, темы и бэги. Все они различными способами обеспечивают граф данными.
∙ Узлы (nodes): являются процессами, производящими вычисления. Если вам нужен процесс, который может взаимодействовать с другими узлами, вам нужно создать узел с этим процессом, подключив его к сети ROS. Обычно, система имеет множество узлов для управления различными функциями. Лучше иметь множество узкоспециализированных узлов, выполняющих единственную функцию, чем большой универсальный узел, который бы делал в системе все на свете. Узлы записываются в клиентскую библиотеку ROS. Примером могут служить roscpp или rospy.
∙ Мастер (master): обеспечивает регистрацию имени и ищет оставшиеся узлы. Если его нет в системе, вы не сможете обмениваться информацией с узлами, сервисами, сообщениями и прочим. Мастер может быть на компьютере, где узлы работают с другими компьютерами.
∙ Сервер параметров (parameter server): дает возможность сохранять данные, используя ключи, размещенные централизованно. С этим параметром возможно конфигурировать узлы во время их работы или для изменения
рабочего узла.
∙ Сообщения(messages): узлы взаимодействуют друг с другом посредством сообщений. Сообщение содержит данные, передающие информацию другим узлам. ROS имеет много типов сообщений. Возможно разработать свой собственный тип сообщения, используя стандартные сообщения.
∙ Темы (topics): Каждое сообщение должно иметь имя, чтобы направляться в сети ROS. Когда узел является отправителем данных, мы говорим, что узел опубликовал тему. Узлы могут получить темы от других узлов, просто подписавшись на тему. Узел может подписаться на тему, и не обязательно, чтобы узел, который бы публиковал тему, должен в настоящий момент существовать. Это позволяет отделить выпуск от потребления. Важно, чтобы название темы было уникальным, чтобы избежать проблем и недоразумений между темами с одинаковыми названиями.
∙ Сервисы (services): при публикации темы, вы отправляете данные, имеющие отношения многие-ко-многим, но когда вам нужно сделать запрос или получить ответ от узла, вы не можете сделать это, используя темы. Сервисы дают нам возможность взаимодействовать с узлами. Сервисы также должны иметь уникальное имя. Когда у узла есть сервис, все узлы могут общаться с ним, благодаря клиентским библиотекам ROS
∙ Бэги (bags): формат для сохранения и воспроизведения данных сообщений ROS. Бэги являются важным механизмом для хранения данных, таких как данные сенсоров, которые сложно собирать, но они требуются для разработки и тестирования алгоритмов. Бэги часто используются при работе со сложными роботами.
На Рисунке 7 показано графическое представление уровня вычислительного графа. Это представление реального робота в реальных условиях. На графе есть узлы, темы, информация о том, на какие темы подписан узел и т.д. На этом графе не представлены сообщения, бэги, сервер параметров и сервисы. Для их графического представления требуются другие инструменты. Инструментом для создания графа является rqt_graph.

Структура уровня вычислительного графа

Узлы
Узлы являются исполнительными элементами, которые могут соединяться с другими процессами, используя темы, сервисы и сервер параметров. Использование узлов в ROS дает нам отказоустойчивость и отделяет код от функционала, тем самым, упрощая систему. Узел должен иметь в системе уникальное имя. Это имя используется для получения доступа узлом к обмену информацией с другим узлом, используя недвусмысленное имя. Код узла может быть написан с использованием различных библиотек, таких как roscpp (C++) и rospy (Python).
ROS имеет инструменты для обработки узлов и получения информации о них, например, rosnode. rosnode — это инструмент командной строки для отображения информации об узлах, например списка выполняющихся в настоящее время узлов.
Поддерживаемые команды:
∙ rosnode info node — информация об узле
∙ rosnode kill node — завершает работу узла или отправляет такой сигнал
∙ rosnode list — список активных узлов
∙ rosnode machine hostname — список узлов, выполняющихся на конкретной машине или список компьютеров
∙ rosnode ping node — тест подключения к узлу
∙ rosnode cleanup — очищает регистрационную информацию о недоступных узлах
Важной особенностью узлов ROS является возможность изменять параметры в момент его запуска. Эта функция позволяет изменить имя узла, имена тем, и названия параметров. Это используется для перенастройки узла без повторной компиляции кода, так что мы можем использовать узел в разных ситуациях.
Пример изменения имени темы:

Код: Выделить всё • Развернуть

$ rosrun roboscool_tutorials tutorialX topic1:=/level1/topic1

Эта команда изменит имя темы topic1 на /level1/topic1.
Для изменения параметров узла необходимо добавить нижнее подчеркивание к названию параметра. Например:

Код: Выделить всё • Развернуть

$ rosrun roboscool_tutorials tutorialX _param:=9.0

В результате param будет присвоено вещественное число 9.0.
Нельзя использовать зарезервированные системой имена:
∙ _name — специально зарезервированное ключевое слово для имени узла
∙ _log — зарезервированное ключевое слово, обозначающее место, куда должен записываться лог-файл узла
∙ _ip и _hostname — синонимы для ROS_IP и ROS_HOSTNAME
∙ _master — синоним для ROS_MASTER_URI
∙ _ns — синоним для ROS_NAMESPACE.

Темы
Темы являются шинами, используемыми узлами для передачи данных. Темы могут передаваться без прямого соединения между узлами. Это означает, что выдача и потребление данных разделены. Тема может иметь различных подписчиков.
Каждая тема строго типизирована по используемому для ее публикации типу сообщения ROS , и узлы могут получать только сообщения от узлов соответствующего типа. Узел может подписаться на тему, только если он имеет тот же тип сообщения.
Темы в ROS могут передаваться, используя TCP/IP и UDP. Основанная на TCP/IP передача называется TCPROS и использует постоянное TCP/IP соединение. Это используемый по умолчанию тип передачи в ROS. Передача, основанная на UDP, называется UDPROS. Это передача с низкой задержкой. Лучше всего подходит для задач дистанционного управления.
В ROS есть инструмент для работы с темами, называемый rostopic. Это инструмент командной строки, который дает информацию о теме или публикует данные непосредственно в сети.
Этот инструмент имеет следующие параметры:
∙ rostopic bw /topic — отображает ширину канала данных, используемую темой
∙ rostopic echo /topic — отображает сообщения на экране
∙ rostopic find meggage_type — ищет темы по их типу
∙ hz /topic — отображает скорость публикации темы
∙ rostopic info /topic — информация об активной теме, опубликованных темах, подписчиках и сервисах
∙ rostopic list — информация об активных темах
∙ rostopic pub /topic type args — публикует данные к теме. Позволяет создавать и публиковать данные в желаемую тему, прямо из командной строки
∙ rostopic type /topic — отображает тип темы, то есть тип сообщения, который она выдает.

Сообщения
Узел посылает информацию на другой узел, используя сообщения, которые публикуются темами. Сообщение имеет простую структуру, которая использует стандартные типы или типы, разработанные пользователем.
Типы сообщений используют следующие стандартные соглашения об именах ROS: имя пакета, затем прямой слеш и имя .msg файла. Например, std_msgs/msg/String.msg имеет тип сообщения std_msg/String. В ROS есть иструмент командной строки rosmsg для получения информации о сообщениях.
Используемые параметры:
∙ rosmsg show — отображает поля сообщения
∙ rosmag list — список всех сообщений
∙ rosmsg package — список всех сообщений в пакете
∙ rosmsg packages — список всех пакетов, в которых есть сообщение
∙ rosmsg users — ищет файлы с кодом, которые используют тип сообщиения
∙ rosmsg md5 — отображает MD5 сумму сообщения

Сервисы
Когда необходимо обмениваться сообщениями с узлами и получать от них ответ, то это нельзя сделать, используя темы. Для этого нужны сервисы. Сервисы разрабатываются пользователем и для узлов не существует стандартных сервисов. Файлы с исходным кодом сообщений хранятся в папке srv. Как и темы, сервисы имеют соответствующий тип, который является файлом с расширением .srv для названия пакета источника. Как и с другими основными типами файловой системы ROS, тип сервиса предсталяет собой имя пакета и имя .srv файла. Например, файл roboschool_tutorials/srv/roboschool_srv1.srv имеет тип сервиса roboschool_tutorials/roboschool_srv1.
В ROS есть два инструмента командной строки для работы с сервисами, rossrv и rosservice. С rossrv мы можем понять информацию о структуре данных сервисов и он используется также как и rosmsg. С rosservice мы можем перечислять и запрашивать сервисы. Поддерживаемые команды:
∙ rosservice call /service args — вызывает сервис, используя указанные параметры
∙ rosservice find msg-type — ищет сервисы по типу сервиса
∙ rosservice info /service — информация о сервисе
∙ rosservice list — список активных сервисов
∙ rosservice type /service — тип сервиса
∙ rosservice uri /service — отображает сервис ROSRPC URI

Бэги
Бэг - файл, созданный ROS с расширением .bag для сохранения всей информации сообщений, тем, сервисов и так далее. Эти данные можно использовать для визуализации, можно воспроизводить, останавливать, перематывать и производить другие операции.
Бэг-файл может быть воспроизведен в ROS как реальный сеанс, посылая темы одновременно с теми же данными. Обычно, мы используем эту функциональность для отладки алгоритмов.
Для использования бэг-фалов в ROS есть следующие инструменты:
∙ rosbag — используется для записи, воспроизведения и других операций
∙ rxbag — используется для визуализации данных в графическом окружении
∙ rostopic — помогает выяснить темы, отправленные в узлы

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

Сервер параметров
Сервер параметров является используемым совместно многомерным словарем, доступным через сеть. Узлы используют этот сервер для хранения и извлечения параметров во время выполнения.
Сервер параметров реализуется, используя XML-RPC и запускается внутри мастера ROS. Это означает. что его API доступны из обычных XMLRPC библиотек.
Сервер параметров использует типы данных XMLRPC для значений параметров, включая следующие:
∙ 32-bit integer
∙ Boolean
∙ String
∙ Double
∙ ISO 8601 date
∙ List
∙ Base 64-encoded binary data
В ROS для работы с сервером параметров имеется инструмент rosparam. Поддерживаемые параметры:
∙ rosparam list — списки всех параметров на сервере
∙ rosparam get parameter — получает значение параметра
∙ rosparam set param value — устанавливает значение параметра
∙ rosparam delete parameter — удаляет параметр
∙ rosparam dump file — сохраняет сервер параметров в файл
∙ rosparam load file — загружает файл (с параметрами) на сервер параметров

Уровень сообщества ROS
Уровень сообщества ROS представляет собой ресурсы ROS, которые позволяют отдельным сообществам обмениваться ПО и знаниями. Эти ресурсы включают:
∙ Дистрибутивы — дистрибутивы ROS являются наборами версий стеков, которые мы можем устанавливать. Дистрибутивы ROS играют ту же самую роль, что и дистрибутивы Linux. Они упрощают установку совокупности ПО, а также поддерживают последовательные версии через набор ПО.
∙ Репозитории — ROS опирается на объединенную сеть репозиториев кода, где различные разработчики могут разрабатывать и выпускать компоненты ПО их собственных роботов.
∙ ROS Wiki — ROS Wiki является основным форумом для документирования информации по ROS. Любой может зарегистрироваться и распространять свою собственную документацию, производить корректировки или выпускать обновления, создавать учебные пособия и прочее.
∙ Списки почтовых ящиков — Списки почтовых ящиков пользователей ROS являются главным каналом получения информации о новых обновлениях ROS аналогично форуму с вопросами по ROS.

Вопрос по темам. Я так понимаю, что это скорее ящик для временного хранения сообщений? Т.е. узел- издатель помещает в него сообщение, пока все узлы-подписчики его не получат? Потом оно удаляется? Если, например, узел, получающий картинку с камеры,10 раз в секунду публикует картинку, предназначенную узлу поиска на нем лица и узлу детектора движения. Что происходит с сообщением, если один из подписчиков не успевает считать очередную картинку, до появления следующей? Что происходит в случае, если сообщение опобликовано для всех желающих?
Вопрос по узлам. Как создаются узлы? Это обычная С++ библиотека, которая работала бы на данном компьютере и без ROS? Или ROS имеет свой С++ компилятор, но не имеет собственной среды разработки? Как отлаживается программный код самого узла?
Прошу прощения, за, возможно, наивные вопросы. Но, надеюсь, что эта тема как раз для ROS-чайников, а не для тех, кто в ней уже разобрался.

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

Сообщение в топике (теме) заменяется на новое только после того как издатель поместит в него новое сообщение. Если издатель не поместил в топик новое сообщение, то и подписчики, при каждом обращении к топику будут читать одни и те же данные.

Scorpio писал(а):Если, например, узел, получающий картинку с камеры,10 раз в секунду публикует картинку, предназначенную узлу поиска на нем лица и узлу детектора движения. Что происходит с сообщением, если один из подписчиков не успевает считать очередную картинку, до появления следующей?

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

Scorpio писал(а):Что происходит в случае, если сообщение опобликовано для всех желающих?

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

Scorpio писал(а):Вопрос по узлам. Как создаются узлы? Это обычная С++ библиотека, которая работала бы на данном компьютере и без ROS? Или ROS имеет свой С++ компилятор, но не имеет собственной среды разработки? Как отлаживается программный код самого узла?

Узел это программа написанная на C++, Phyton или др., мы рассмотрим создание узлов в дальнейшем. Если мы пишем код под ROS, то в него включаются ссылки на библиотеки ROS по этому узел сам по себе, без запуска roscore (ядро ROS), работать не будет. ROS имеет компилятор и систему сборки, своей среды разработки нет. Отладку узла можно производить в любой среде разработки которая вам нравится.

Сильно зависит от "клиентской реализации". В roscpp/rospy каждый паблишер хранит очередь исходящих сообщений. Длина очереди фиксирована и задаётся при создании паблишера. Сабскрайбер периодически просит "дай ещё сообщений" от каждого подключеного к нему паблишера. Паблишер сам по себе удаляет сообщения из очереди только если она переполняется. Благодаря этой особенности могут работать latched темы: мы опубликовали 'latched' сообщение. Потом запустили узел с подписчиком. Подписчик получит это сообщение, несмотря на то, что при фактической публикации этого подписчика не существовало.

Аналогичная очередь спрятана в каждом сабскрайбере. Туда складываются все полученые пакеты до того, как будет вызван соответствующий callback. Эта очередь заполняется отдельным потоком (так же зависит от реализации). Если callback выполняется редко, то сабскрайбер начинает выкидывать старые пакеты при переполнении очереди. Такое, кстати, регулярно случается в gmapping при обработке сканов: он успевает их жевать не чаще раза в пару секунд (зависит от компа), а дальномер их выдаёт на частоте 40Гц.

Scorpio писал(а):Вопрос по узлам. Как создаются узлы?

Просто сетевое приложение, которое "каким-то образом" реализует ROS протокол. Для разных языков существуют разные "клиентские" библиотеки:

• roscpp для С++
• rospy для python
• rosjava для java
• ROS.NET для C# (лично переписывал XMLRPC часть с С++ на C#)
• и т.д

Соответственно, для каждой "платформы" так же делается кодогенератор из описания типа сообщения (файл msg/srv/action) в класс конкретного языка (утилиты gencpp/genpy/...). В этих классах прописывается преобразование содержимого в набор байт (сериализация) некоторым стандартным путём. Благодаря этому можно публиковать сообщение из питона си спокойно получать это сообщение в С++ приложении.
Для cmake/linux платформ ROS так же предоставляет сборочную систему catkin (есть ещё rosbuild), которая помогает пользовательским пакетам найти нужные зависимости и сгенерировать классы сообщений для нужных языков

Scorpio писал(а): Хотелось просто общего описания простым человеческим языком еще, до того, как вдаваться в детали. Типа "программы пишутся на питоне в текстовом редакторе, без всякой автоматической проверки синтаксиса с кучей дополнительных ограничений, зато легко и надежно можно обмениваться данными между параллельными потоками".

Вот вводная книга. Все примеры на питоне. https://play.google.com/store/books/details/Morgan_Quigley_Programming_Robots_with_ROS?id=G3v5CgAAQBAJ&hl=ru

Спасибо. Стало понятнее. Дальнейшие "спасибо" по умолчанию, чтобы не загромождать тему.

Добавлено спустя 1 час 48 секунд:
Попутный вопрос. События (кнопка нажата/кнопка отпущена) организованы тоже в виде сообщений?

Чугунный Дятел, благодарю за расширенный ответ с пояснениями, признаюсь, некоторых моментов, из того, что вы написали я тоже не знал. Вот так, коллеги, мы совместными усилиями и коллективным разумом "победим" ROS!!!

Scorpio писал(а):События (кнопка нажата/кнопка отпущена) организованы тоже в виде сообщений?

Как уже писалось выше, и в дальнейших примерах вы это увидите, что сообщение это ни что иное, как обычная переменная какого либо типа (bool, int, char, until, float и т.п.), вам нужно объявить ее в коде вашего узла как издаваемую на какую то конкретную тему (это делается посредством подключенных библиотек ROS), в процессе вычислений ваш узел должен записывать в эту переменную вновь полученные значения и публиковать его в топик, а ROS позаботится о доставке топика содержащего это сообщение. Говоря о вашем вопросе, можно привести такой пример: у вас есть Arduino и кнопка, вам нужно публиковать состояние кнопки в ROS (заведомо не стану здесь писать никаких примеров в исполняемом коде, для того чтобы не загромождать вас раньше времени, примеры с кодом будут дальше). Постараюсь описать процесс на естественном языке:
1. Используя библиотеку rosserial сделать вашу Arduino узлом ROS;
2. В скетче для Arduino создать именованный топик с публикуемым сообщением, этим сообщением должна быть Булева переменная в которой будет храниться значение состояния кнопки 0/1 (как это сделать рассмотрим в дальнейшем);
3. Далее в скетче Arduino вы организуете (обычными методами Arduino void setup() {...}; void loop() {...};) чтение кнопки и записываете ее состояние в нашу переменную;
4. Затем публикуете сообщение.
В loop() этот цикл (пункты 3 и 4) постоянно повторяется, т.е. производится считывание кнопки и публикация ее состояния в сети ROS. А далее, топик, имеющий определенное вами имя и содержащий булеву переменную (на языке ROS-а "сообщение") в которой хранится состояние кнопки распространяется внутри сети ROS, и любой другой узел подписанный на ваш топик получит данные о состоянии кнопки.
Для лучшего понимания что такое топик (тема) и сообщение, можно провести следующую аналогию: у вас имеется контейнер в который вы можете положить "все что угодно" - это топик, "все что угодно" - это сообщение, естественно сообщение должно быть определенного типа, т.е если вы создали топик "capacity" (ёмкость), и поместили туда сообщение "aqua" (жидкость), то кроме как вещества в жидком состоянии вы в это сообщение влить не сможете. Но вы можете разделить ваш контейнер на отсеки, и добавить в него сообщение "solid" (твердый), и тогда в этот отсек можно положить твердые предметы, а можете добавить сообщение "gas", и вуаля! закачиваем вещества в газообразном состоянии, и вот, вы вашем контейнере может перевозить как нефть, так и золото, так и природный газ , вы этот контейнер можете отправить по железной дороге, и на любой станции в него могут как добавить так и взять из него содержимое. Таким образом топик это именованное хранилище каких либо данных которое передается внутри сети ROS, и содержимое этого хранилища доступно для любого потребителя, причем любой потребитель может быть как подписчиком так и издателем, и любой топик может иметь любое количество как издателей так и подписчиков.

Понятно. Но всетаки события в, обычном понимании, гарантированно запускают свой обработчик. Здесь же больше похоже на периодическую проверку состояния некой переменной программой-обработчиком. Без гарантии, что переменная не успеет сменить состояние еще до следующего ее опроса. Может с кнопкой я и утрирую, но в примере выше, пока другой узел обработки изображений ищет лицо, то камера успеет выдать еще 10 кадров. Если эти кадры становятся в очередь на обработку, то очередь до них может и не дойти. Видимо в этом случае надо использовать другой механизм.

Scorpio писал(а):Понятно. Но всетаки события в, обычном понимании, гарантированно запускают свой обработчик. Здесь же больше похоже на периодическую проверку состояния некой переменной программой-обработчиком. Без гарантии, что переменная не успеет сменить состояние еще до следующего ее опроса. Может с кнопкой я и утрирую, но в примере выше, пока другой узел обработки изображений ищет лицо, то камера успеет выдать еще 10 кадров. Если эти кадры становятся в очередь на обработку, то очередь до них может и не дойти. Видимо в этом случае надо использовать другой механизм.

Да, здесь вы правы, отношения издатель/подписчик не являются событийно-зависимыми. Строго говоря, для обменом сообщениями в ROS пропуск каким то из узлов (в случае его малого быстродействия) пакетов не всегда является критичным моментом, а событийно-зависимые отношения в ROS можно реализовать на уровне сервисов. Здесь как раз все делается по запросам и исключаются потери данных. Тем не менее в ROS имеются механизмы для синхронизации работы издателей/подписчиков, и в дальнейшем мы их рассмотрим.
Если говорить о детектировании лиц, то и до этой темы мы еще, надеюсь, доберемся, там в связке openCV-ROS тоже ничего особо сложного нет, но это совсем другая история.