Создание сервера действий и клиента в ROS

Я пытаюсь настроить сервер и клиент действий ROS для обработки отправки изображений (закодированных как 64-битные строки) между Python и ROS (с целью сделать изображение чем-то, что другие сценарии могут извлечь из ROS). Поскольку я новичок во всем этом (Python, Ubuntu, Bash, ROS и т. Д.), Мне очень трудно определить, КАК именно это сделать. Я думаю, что отчасти причина в том, что вики-руководства / документация ROS линейны по отношению к ошибке, и процесс выглядит запутанным и чрезвычайно сложным. Кто-нибудь знает какие-либо руководства, не относящиеся к ROS-wiki или зависимые от них, которые помогут мне разобраться в этом? Или вы можете составить краткое пошаговое руководство по созданию этой системы? Мне не удалось найти ничего, что касалось конкретно этой темы, что заставляет меня думать, что это либо очень необычное использование, либо это супер просто, и я еще не на том уровне.

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

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

Еще раз спасибо за любую помощь, которую вы можете оказать!

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


python ubuntu python-2.7 ros rospy
person godfreap    schedule 30.09.2015    source источник
comment
Не могли бы вы подробнее рассказать, чего именно вы хотите достичь? Насколько я понимаю, узел Python должен просто дождаться запроса изображения, а когда поступит такой запрос, загрузить изображение и отправить его запрашивающей стороне (т.е. узел Python не выполняет тяжелую работу, которой требуется некоторое время, чтобы получить законченный). Если это правильно, я думаю, что простой службы вполне достаточно, и ее гораздо проще реализовать.   -  person luator    schedule 30.09.2015
comment
Проблема со службами в том, что запрашивающая сторона заблокирована до тех пор, пока запрос не будет завершен. С помощью действий инициатор запроса не блокируется, а подписывается на обратный вызов, который получит результат после завершения запроса (и тем временем запрос также может быть прерван, и можно отправить отзыв о ходе выполнения). Таким образом, действия полезны для запросов, выполнение которых требует больше времени, но, с другой стороны, их гораздо сложнее реализовать (см. Также здесь).   -  person luator    schedule 30.09.2015
comment
... Так что, если вам не нужны эти функции, я лучше пойду за услугой.   -  person luator    schedule 30.09.2015
comment
Относительно вашего редактирования: нужны ли вам все (или почти все) изображения этого видеопотока? Если да, то лучше всего подойдет тема (просто транслирует сообщения без запроса, и другие узлы могут подписаться на поток с обратными вызовами). Если вам нужно всего несколько изображений и только в определенных ситуациях, я все равно считаю услуги лучшими. Возможно, я что-то упускаю в вашей задаче, но я не вижу веских причин для того, чтобы создавать сервер действий для такой простой задачи. Конечно, если ваш босс так хочет, вам, вероятно, также следует изучить это. К сожалению, я также не знаю лучшего учебника   -  person luator    schedule 30.09.2015
comment
Перечитывая ваш вопрос, я не совсем уверен, что вы имеете в виду под , который затем опубликует их на сервере действий ROS. Вы имеете в виду, что какой-то узел A читает поток и публикует все изображения через тему на узле B (который является сервером действий), а затем другой узел C запрашивает отдельные изображения у B?   -  person luator    schedule 30.09.2015
comment
Я бы сказал, что все они мне нужны. И это была моя первая идея: подписаться на соответствующую тему и просто бесконечно перемещать изображения с разделителем для разделения изображений. У меня уже написано 90% этого. В конечном итоге мы будем запрашивать кадры видео, но я не думаю, что это что-то меняет, поскольку все они должны быть последовательными. Я думаю, что основная причина, по которой нам нужны хотя бы услуги, - сделать их доступными для других программ. Хотя включение подписчика в сценарий анализа кажется тривиальным, изображения должны быть доступны в системе для любого запущенного сценария, имеющего доступ к ROS.   -  person godfreap    schedule 30.09.2015
comment
Что касается вашего последнего комментария, да, я считаю, что это правильно. У меня очень шаткое представление обо всей иерархии, поэтому я не совсем уверен, как серверы действий / услуг связаны с узлами, клиентами и темами ...   -  person godfreap    schedule 30.09.2015
comment
Обратите внимание, что темы не являются бесконечными потоками в традиционном смысле, но вы можете публиковать только автономные сообщения, то есть без разделителей (кстати, уже существует тип сообщения для изображений). Как правило, любой узел ROS (= сценарий / программа, подключенный к ROS), который может получить доступ к службе, также может подписаться на темы. Это скорее вопрос, какой тип доступа лучше подходит для конкретной задачи, которую выполняет узел. Серверы сами по себе являются узлами, которые просто объявляют услугу другим (клиентским) узлам.   -  person luator    schedule 30.09.2015
comment
Я действительно использовал from sensor_msgs.msg import Image в своем издателе ROS. Возился с переносом по темам, вижу разделитель, но тогда есть разница, что быстрее - сервисы или темы? еще один подходит для стриминга? И, кстати, спасибо @luator, вы очень помогли с тех пор, как я присоединился к сайту: D   -  person godfreap    schedule 30.09.2015
comment
Пожалуйста, я рад, если смогу помочь :) Я бы сказал, что темы быстрее, особенно если подписчиков несколько. Издатель просто публикует изображения, и все подписчики автоматически получают их через обратные вызовы (и без копирования из-за общей памяти). В отличие от служб, каждый клиент должен активно запрашивать каждое отдельное изображение, что увеличивает накладные расходы на связь, и клиенты могут пропустить отдельные изображения. С другой стороны, это позволяет избежать ненужного взаимодействия, когда клиенту нужны не все изображения, а только отдельные изображения в определенных ситуациях (то есть они запрашивают только в случае необходимости).   -  person luator    schedule 30.09.2015
comment
Так что это действительно зависит от того, что нужно клиенту / подписчику. Если ему нужно каждое новое публикуемое изображение, используйте тему. Если нужны только отдельные изображения и только в определенных ситуациях, воспользуйтесь услугой.   -  person luator    schedule 30.09.2015
comment
Я рад, что, по крайней мере, был прав, считая, что темы самые простые, и теперь они кажутся самыми быстрыми. Я провел небольшой тест и, исходя из среднего времени передачи 12 изображений в байтовых строках, могу сделать 1787 кадров в секунду. Я подозреваю, что этого будет достаточно быстро! ха-ха. Еще раз спасибо @luator, я собираюсь поговорить об этом со своим боссом и посмотреть, считает ли он, что услуги лучше всего. Вы мне многое прояснили! Большое спасибо! : D   -  person godfreap    schedule 30.09.2015

Ответы (1)


arrow_upward
0
arrow_downward

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

  1. Напишите свой узел, который транслирует видео, публикуя изображения по теме. Вы можете реализовать это как сервер actionlib, но это не обязательно. В моем случае я использовал уже существующий raspicam_node для чтения камеры Raspberry Pi. Если вы хотите реализовать это на Python, прочтите руководство по созданию издатель.
  2. Создайте узел, который подписывается на вашу тему изображения, а затем читает изображение из сообщения темы. И снова в руководстве показано, как создать подписчика. Основное отличие состоит в том, что в качестве типа сообщения вы должны использовать CompressedImage или Image из sensor_msgs.msg.

Для подписчика: вот пример узла Python ROS, который я написал, который реализует стример MJPEG. Он подписывается на тему, считывает данные изображения и повторно публикует их с помощью потокового HTTP-ответа. Несмотря на то, что это «медленный Python», у меня задержка составляет менее 1 секунды.

person Cerin    schedule 21.04.2016