Очень короткий ответ: 2
датчиков
Что касается чтения всех датчиков в одном узле или в отдельности, вы должны задать себе этот вопрос:
Датчики бессмысленны без других?
Этот вопрос спрашивает, тесно ли связаны датчики или нет. Например, скажем, у вас есть датчик, чувствительный к температуре (и вам нужно это компенсировать). Вы добавляете датчик температуры прежде всего, чтобы зафиксировать значение другого датчика. В этом сценарии имеет смысл читать оба значения одновременно, так как они тесно связаны. Фактически, без показаний датчика температуры показания исходного датчика бесполезны.
С другой стороны, если датчики полезны по отдельности, обязательно храните их в отдельных узлах. Это имеет много преимуществ:
- Узлы могут работать на отдельных процессорах
- Узлы могут быть повторно использованы в будущих роботах
- Сбой в связи с одним узлом не вредит всей системе
- Перезапуск сбора данных с неисправной сенсорной панели может быть выполнен отдельно от других.
На самом деле, если вам нужны какие-либо из перечисленных выше преимуществ, вам придется использовать отдельные узлы, даже если датчики тесно связаны, но этого обычно не происходит.
исполнительные
Это аналогично.
Являются ли приводы бессмысленными без другого?
Например, если вы проектируете запястье с роботизированными сухожилиями, в котором для каждого сухожилия (по какой-либо причине) два двигателя отвечают за одновременную работу по перемещению сустава в одном или другом направлении, то их обслуживание в одном и том же узле делает намного больше смысл, чем отдельный.
С другой стороны, когда исполнительные механизмы независимы (общий случай), имеет смысл иметь один узел для каждого исполнительного механизма. В этом случае каждый может быть помещен в другой узел. Помимо тех же преимуществ, что и с датчиками, есть еще одно преимущество:
- Если привод заблокирован (по какой-либо причине), остальные приводы все еще работают. Если есть избыточные степени свободы, они могут даже полностью ее компенсировать.
Это имеет один смысл. Если вам нужно, чтобы приводы работали в гармонии, поместите их в один узел. Это не только из-за сбоя в коммуникации, но и потому, что разные узлы означают разные задержки; в распределенной системе каждый узел находится в другой части сети и, следовательно, разница в задержках, в централизованной системе разные задержки происходят при высоких нагрузках на ЦП из-за удачи каждого процесса в планировании.
Должен ли быть обработчик?
Даже если ответ «это зависит», существует общий подход со многими преимуществами. Давайте изменим имя и назовем его «контроллер». Подход "да, должен быть контроллер".
Преимущества наличия контроллера (среди многих):
- Разделенная обработка: каждый узел отвечает за одну вещь, которая означает:
- Простота: что подразумевает
- Более легкое развитие
- Более простая отладка
- Меньше ошибок
- Меньше шансов на провал
- Возможность повторного использования: потому что один и тот же контроллер может использоваться с разными узлами датчиков, если они имеют одинаковую функциональность (т. Е. Форматы сообщений и услуг).
- Исполнение на отдельном оборудовании: каждый узел может быть перемещен в сети. Например, узлы датчика и исполнительного механизма могут быть перемещены на выделенный микроконтроллер ( например, Arduino (не рекомендуется)) и контроллер на ПК.
- Избегайте крайнего уродства: если датчики хотели напрямую влиять на исполнительные механизмы, результат просто беспорядок. Предполагая отсутствие контроллера, давайте посмотрим на каждый случай:
- Один сенсорный узел: в основном это означает, что сенсорный узел и контроллер объединены в одном узле. Не так уж плохо, но очень ненужно.
- Много сенсорных узлов: это беспорядок. Это означает, что контроллер распределен между узлами датчика. Поэтому все узлы датчиков должны общаться друг с другом, чтобы знать, как управлять соответствующими исполнительными механизмами. Представьте себе сбой в общении или различные виды задержек, и вы увидите, насколько это сложно. Учитывая, что это совершенно не нужно, нет никаких оснований для этого!
Тем не менее, есть и недостатки. Наличие большего количества узлов (любых узлов, а не только контроллера) означает:
- Более бесполезное общение: данные должны перемещаться в стандартных форматах (с сериализацией и десериализацией) через сеть или общую память, ядро ROS должно смотреть на них и решать, кому их доставлять и т. Д. Короче говоря, некоторые системные ресурсы теряются в общении. Если бы все узлы были в одном, эта стоимость могла бы быть нулевой.
- Более высокая вероятность сбоя: если по какой-либо причине сетевое соединение выходит из строя или узел умирает, в системе происходит сбой. Если вы не готовы к этому, это может разрушить всю систему. Сейчас это вообще хорошая вещь - иметь возможность потерять часть системы, но не всю ее ( постепенное ухудшение ), но существуют также приложения, в которых этого следует избегать, насколько это возможно. Разрыв связи и помещение всего кода в один узел на самом деле помогает стабильности системы. Недостатком является то, что система либо работает нормально, либо внезапно полностью умирает.
- Хаотические тайминги: каждый узел работает самостоятельно. Время, необходимое для доставки сообщений другим пользователям, не является детерминированным и варьируется в зависимости от выполнения. Если только ваши узлы не отметят время каждого сообщения (как примечание: вам нужно в достаточной степени синхронизировать часы, чего нет у ROS), и если каждый принимающий узел не сможет учесть задержку и соответственно контролировать (что является очень сложной задачей) само по себе) тогда наличие нескольких узлов означает высокую неопределенность относительно возраста данных. Это на самом деле одна из причин (среди многих), что большинство роботов движутся так медленно; их цикл управления должен быть достаточно медленным, чтобы все данные соответствовали текущему периоду. Чем больше задержки, тем медленнее цикл управления.
При всех вышеперечисленных недостатках решение состоит в том, чтобы уменьшить количество узлов, предпочтительно до одного узла. Погоди, это больше не использует ROS! Точно.
Подвести итоги:
- Используйте ROS для систем не в реальном времени, где задержки могут время от времени увеличиваться. В этом случае не стесняйтесь иметь столько узлов ROS, сколько пожелаете. На самом деле, очень полезно, чтобы каждый узел ROS выполнял одну-единственную вещь. Таким образом, они становятся очень простыми и пригодны для многократного использования.
- С другой стороны, для систем реального времени обязательно избегайте ROS. Для этого есть orocos и технологии, такие как EtherCAT и, чаще всего, специальные решения.
Как последнее слово, на практике ROS работает хорошо. Не отлично, но хорошо. Очень часто система не критична, и вероятность отказа настолько мала, что время от времени перезапуск не имеет большого значения. Это страусиный алгоритм !
