> For the complete documentation index, see [llms.txt](https://voltbro.gitbook.io/arduino-ros/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://voltbro.gitbook.io/arduino-ros/4_ros-base/problem.md).

# Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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