python — служба ROS и сообщение
Я использую систему ROS, и я новичок.
Я наткнулся на Службу и Сообщение (srv и msgs) в ROS. Из ros wiki я могу понять, что сообщения msgs используются для определения типа передаваемого сообщения, а служба — это запрос и ответ. Пожалуйста, поправьте меня, если я ошибся.
Тем не менее, я не могу понять, когда их использовать. Я подумал, что, возможно, было бы полезно, если бы у меня были модули, написанные на C ++ и другие модули обработки на Python, чем, возможно, я мог бы использовать srv и msgs для связи между двумя модулями. Однако, чем ROS также имеет систему издателей и подписчиков, которую можно использовать вместо этого?
Во-вторых, когда мы используем srv, чем нам нужно только определить msgs или можно использовать независимо друг от друга?
Решение
Прежде всего, позвольте мне указать вам здесь:
http://wiki.ros.org/ROS/Tutorials/WritingPublisherSubscriber%28c%2B%2B%29
Это первый пример Ros учебные пособия.
Издатели и подписчики — это объекты, используемые для взаимодействия узлов. Издатели публикуют сообщения на канале, в то время как подписчики слушают такие каналы, чтобы получать сообщения, возможно отправленные издателями. Издатели публикуют на канале сообщения, которые содержат различный вид данных в зависимости от того, чего пытаются достичь. Подписчики принимают эти сообщения и автоматически выполняют callback function добиться чего-то полезного с данными.
Теперь позвольте мне указать вам здесь:
http://wiki.ros.org/ROS/Tutorials/WritingServiceClient%28c%2B%2B%29
Это аналогичный пример, но на этот раз услуги используются для достижения связи. С сообщениями связано то, что, как только узел публикует сообщение, вся коммуникация заканчивается, и узел продолжает работу до конца. С другой стороны, клиент (они пользуются услугами) связывается с серверами; они публикуют сообщение на сервере, а затем ждут ответа от этого сервера.
Примеры:
- Представьте, что у вас есть два узла: первый создает и публикует случайные целые числа, а второй берет эти числа и публикует их квадраты на экране. Вы можете себе представить, что нам нужны только сообщения: первый узел не должен ждать ответа от второго узла. Первый узел будет использовать издателя для предоставления целых чисел, а второй узел будет использовать подписчика для получения этих целых чисел и выполнения функции, которая будет публиковать их квадраты.
- Представьте, что вы хотите реализовать игру в крестики-нолики с ROS: теперь вам нужно иметь 3 узла: два из них идентичны и представляют двух игроков, а третий — ИИ, управляющий доской. Теперь ИИ публикует доску игроку, но ему также нужно дождаться ответа; таким ответом будет ход, который выберет текущий игрок. Вот почему услуги должны быть использованы здесь.
Если вы убедитесь, что понимаете простую программу с сообщениями и простую программу со службами, то вы можете расширить свои знания, создавая примеры, подобные представленному выше. Только тогда вы сможете полностью понять его с полной детализацией.
Другие решения
Публикация / подписка ROS — это многие ко многим (с точки зрения соединений) и односторонние
транспорт данных. Это асинхронный, то есть ваш код не будет блокироваться, и вам нужно будет реализовать функцию обратного вызова, которая будет работать асинхронно.
Службы ROS, с другой стороны, являются синхронной и двусторонней передачей данных, что означает, что клиент блокирует и ожидает ответа от сервера.
Подумайте о следующих случаях:
- Представьте себе робота и симулятор с моделью робота. Симулятор должен обновлять модель робота в режиме реального времени (поскольку робот в реальном мире изменяет конфигурацию, симулятор должен обновлять модель, чтобы отразить это изменение так, чтобы модель робота в симуляторе всегда была в курсе текущая конфигурация реального робота).
- Представьте себе узел, управляющий кассиром робота. Этот узел требует, чтобы обнаружить клиента с помощью камеры робота, чтобы начать взаимодействие.
В первом случае вам понадобится модель публикации / подписки, потому что симулятору понадобятся данные для передачи в режиме реального времени при выполнении чего-то еще. Таким образом, робот опубликует свои общие значения в теме, а симулятор подпишется на эту тему с помощью функции обратного вызова, которая будет обновлять модель робота в симуляторе в режиме реального времени в асинхронном режиме.
Во втором случае, однако, вы не хотите, чтобы узел постоянно проверял клиента, и это не то, что вы хотите делать постоянно. В логике вашей программы вы знаете, когда вам нужно обнаружить клиента. Когда вы впервые запускаете свой узел, вы знаете, что вам нужно заблокировать и ждать прихода клиента. Здесь более уместно использовать сервис. Когда вы хотите обнаружить клиента, вы отправляете запрос на сервер (и в результате ваша программа блокирует ожидание ответа). Сервер будет использовать камеру для обнаружения клиента (используя некоторый алгоритм обнаружения) и соответственно ответит вам.
Вообще говоря, вы будете использовать публикацию / подписку, когда вам нужно, чтобы данные непрерывно передавались, и вы хотите работать с этими данными асинхронно, и сервисы, когда вам нужно, чтобы определенные вычисления выполнялись синхронно.