В главе о диагностике ROS мы запрограммировали узел (monitor_dynamixels.py) который может отключить один или несколько сервоприводов Dynamixel, если они будут слишком горячими. Затем другие узлы могут попытаться управлять сервомоторами, но их запросы будут проигнорированы драйвером arbotix. Однако не все аппаратные контроллеры обеспечивают такой уровень управления. Кроме того, могут быть и другие причины, по которым мы хотим контролировать доступ к общему ресурсу, требующему более гибкого подхода.
Предположим, например, что мы хотим, чтобы базовый контроллер робота всегда отдавал наивысший приоритет ручному вводу, такому как джойстик. Другие узлы, такие как move_base, могут одновременно пытаться управлять базой, но пользователь всегда должен иметь возможность переопределить ввод с помощью ручного управления. Вместо того чтобы встроить этот вид переопределения управления в сам базовый драйвер, мы можем использовать утилиту ROS mux, которая является частью мета-пакета topic_tools.
Mux-узел позволяет нам объединять несколько входных команд в одну выходную команду. Только один входной поток за раз передается на выход. Предоставляются услуги по выбору активного входа, а также добавлению и удалению вводимых тем, о чем мы расскажем позже. Обратите внимание, что даже без мультиплексирования можно управлять базовым контроллером ROS, используя несколько входов одновременно. Проблема в том, что все такие входы, как правило, публикуют свои Twist сообщения на одной и той же теме /cmd_vel. В результате робот вяло двигается, так как поочередно реагирует на каждое из сообщений Twist или на другие сообщения, поступающие из разных источников. Утилита mux позволяет обойти эту проблему, разрешая только один вход в любой момент времени.
В случае нашего базового контроллера, вызовем тему ввода навигации move_base_cmd_vel и тему ввода джойстика joystick_cmd_vel. Пусть выходной темой будет cmd_vel. Следующая команда настроит наш мультиплексор:
$ rosrun topic_tools mux cmd_vel move_base_cmd_vel joystick_cmd_vel
mux:=mux_cmd_vel
Здесь мы запускаем mux-узел из пакета topic_tools с первым аргументом, указывающим выходную тему, и двумя аргументами, указывающими две входные темы. Последний аргумент, приведенный выше, дает mux-узлу уникальное имя и определяет пространство имён для сервиса и, как мы увидим позже, имен тем.
Обратите внимание, что при запуске выбирается первая входящая тема в командной строке.Таким образом, если бы мы выполнили команду выше, узел с именем mux_cmd_vel сначала прослушивал бы сообщения на тему move_base_cmd_vel, которые затем передавались бы на выходную тему cmd_vel.