Введение

Для управления роботом должна существовать некая программа. Чем больше и сложнее робот, тем "больше и сложней" должна получиться эта программа.

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

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

В формулировках ROS ( Robot Operating System) такая программа называется нода (node). Писать и поддерживать такие мини-программы значительно проще, чем одну большую.

Если мы разделяем одну большую программу на много маленьких, то у нас появляется вопрос, каким образом данные из одной программы (ноды) должны попадать в другие программы. Без обмена данными такие программы будут абсолютно бесполезны.

Для этого в ROS используется несколько разных подходов. Один из самых часто используемых подходов — это протокол, построенный по так называемой модели PubSub (Издатель и Подписчик)

Рассмотрим сущности этого подхода:

Издатель (Publisher) - это процесс, который имеет какие-либо данные и хочет сообщить о них всему роботу. Например, программа получает данные с датчика температуры, переводит их в понятные нам градусы Цельсия и отправляет эти данные в ROS.

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

Чтобы Издатель и Подписчик могли обмениваться данными, обе программы должны понимать, где "брать" и куда "складывать" данные. Для этого в модели PubSub вводится понятие Topic (Тема), которое идентифицируется простым текстовым названием (и служит некоторым адресом, где данные находятся).

Так Топик температуры может называется temperature, тогда Подписчик может, зная имя топика, подписаться на него и получать данные. А Издатель знает, куда "отдавать" свои данные.

Само значение температуры (данные) в модели PubSub называется Сообщение (message).

Важно понимать, что в рамках одного топика должны находиться сообщения только одного типа, например, температуры. Если нам необходимы данные о давлении, то необходимо работать с другим топиком, например, pressure и т.д.

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

Любая нода может быть одновременно как подписчиком, так и издателем. Такой подход позволяет строить очень сложные взаимодействия, используя очень простой подход для обмена данными.