ROS (операционная система робота) является обязательной?
10
Нужно ли нам строить ROS для роботизированных исследований / приложений? В чем главное преимущество? Когда или в каких ситуациях ROS является обязательным?
Я бы написал ответ, но я печатаю по телефону. Как правило, ROS не является обязательным. По моему личному мнению, в зависимости от ROS это даже плохо. Какой бы компонент у вас ни был, сделайте из него портативную библиотеку, а затем напишите на ней модуль ROS. Когда ROS умирает или ваши требования меняются, вы были бы благодарны за это.
Шахбаз
Ответы:
18
Я вернулся к компьютеру!
Как я уже сказал в этом комментарии , ROS, как правило, не является обязательным. ROS - одна из многих платформ, известная в основном благодаря тому, что Willow Garage в какой-то момент времени раздает бесплатных роботов тем, кто написал большинство модулей ROS. Тем не менее, это не лучшая возможная платформа, и, конечно, ничего особенного. В частности, в результате указанного конкурса появилось много некачественных модулей, чтобы получить более высокие цифры.
Со временем качество модулей ROS улучшилось, и их стало много. Таким образом, используя ROS, вы можете повторно использовать многое из того, что уже сделано. Вы можете прочитать здесь некоторые причины, почему вы можете использовать ROS.
Имея это в виду, вы должны следить за побочными эффектами.
Распределенный контроль
С ROS у вас есть много узлов, которые общаются друг с другом через сеть. Это иногда хорошо и легко, но обычно приводит к сильно изменяющейся задержке приема сообщений. В результате вам потребуется большая задержка управления, чтобы обеспечить поступление всех сообщений, что означает, что вы не можете быстро реагировать на события, а это, в свою очередь, означает, что вы должны перемещать своего робота на более медленных скоростях, чтобы не пропустить эти события.
Верьте или нет, люди фактически управляют роботом через ROS ( MoveIt! - название соответствующего набора компонентов). Медленный. Опасное. Но легко!
Номера в режиме реального времени
Даже когда не распространяется, ROS не является платформой в реальном времени. Это означает, что вы по своему усмотрению можете назначить ядро Linux в любое время по своему усмотрению. Это нормально для некоторых приложений, но не хорошо для других. Так что вам нужно посмотреть на свои требования. Вам нужно иметь гарантию, что ваша задача будет выполнена в течение известного периода времени? Если это так, вам нужна система реального времени.
Хостинг Runtime Environment
Еще один момент, на который следует обратить внимание: хотя ROS является общим протоколом связи, он по существу поддерживается только для размещенных сред. Хостинг означает, что код выполняется поверх ядра, в отличие от автономного, что означает, что код напрямую управляет оборудованием (например, на микроконтроллере).
Если ваше робототехническое приложение работает близко к аппаратному обеспечению, и поэтому вам потребуется программа, работающая на микроконтроллере, ROS вам не поможет.
Блокировка платформы
Наконец, что не менее важно, разработка для ROS приводит к блокировке платформы. Это означает, что если в будущем по той или иной причине вы решите основывать свою работу на другой роботизированной платформе, такой как OROCOS, YARP и т. Д., Это будет мучительно.
Вы также были бы несколько привязаны к Linux. Без сомнения, Linux - лучший, но однажды вам может понадобиться поддержка другой системы, такой как QNX, VxWorks и т. Д., И у вас тоже возникнут проблемы.
Если вы пишете для микроконтроллеров, то забудьте о ROS. Если вы пишете высокоуровневые модули, я настоятельно рекомендую писать переносимый код. Например, предположим, что вы разработали новый датчик и хотите написать модуль, который получает данные от этого датчика, который подключен к вашему компьютеру через шину CAN.
В этой ситуации вы можете написать независимую библиотеку с функциями, способными работать с вашим датчиком и получать данные. Можно даже подумать о порождении потока в библиотеке, который периодически получает и ставит в очередь данные.
Если у вас есть эта вспомогательная библиотека, вы можете написать CLI, GUI, ROS-модуль, OROCOS-модуль, YARP-модуль, подключиться к Matlab или что-либо еще, что вы хотите использовать для взаимодействия с вашим датчиком.
Последнее замечание: то, что я здесь сказал, в целом применимо ко всем робототехническим платформам, а не только к ROS.
Комментарии не для расширенного обсуждения; этот разговор был перенесен в чат .
Марк Бут
2
«ROS» - это относительный термин, APM запускает полный пользовательский код, специально разработанный для управления квадрокоптером, где может быть желательно избежать нестандартного ROS, чтобы избежать сбоев, с другой стороны, Navio + работает на ядре Linux и выполняет код, отличный от автопилота, и до сих пор удается не разбиться. Большинство ROS на самом деле представляют собой набор функций поверх существующей ОС, в отличие от написания операционной системы с нуля. Как и во всем, это зависит.
Он говорит о системе управления роботом, а не системе реального времени ...
FooTheBar
2
Отказ от ответственности: Этот ответ каким-то образом является реакцией на пост Шахбаз, так что он имеет склонность к ROS.
Я не думаю, что ROS является обязательным, но это отличная отправная точка и стоит времени для инвестиций. Это началось в Willow Garage, но эта компания исчезла, а ROS все еще жива, используется и развивается. Большая часть ROS является полностью открытым исходным кодом, а также может использоваться в коммерческих целях, поэтому ROS просто не исчезнет, если компания больше не будет в этом заинтересована. Качество кода, конечно, различается между основными модулями и реализациями передовых алгоритмов, которые некоторые аспиранты опубликовали в своей статье.
ROS набирает все большую скорость в промышленных условиях (я был бы удивлен, если бы значительная часть стартапов робототехники во всем мире не использовала ROS). Некоторые алгоритмы будут в дальнейшем поддерживаться и развиваться консорциумом ros-industrial, и если вы посмотрите на участников, стоит поспорить, что ROS станет стандартом в отрасли:
Распределенный способ использования ROS очень помогает в создании и поддержке новых пакетов, особенно внутри команд. Определения сообщений и действий очень помогают в определении интерфейсов, что позволяет быстро обмениваться аппаратными средствами и алгоритмами. Это также помогает интегрировать новых членов команды, так как новый узел будет сбивать другие узлы, если он выйдет из строя (если он не съест всю оперативную память ...), так что довольно безопасно интегрировать частично работающие узлы в работающую систему в качестве их эффект ограничен. Для связи используется TCP, который является надежным и быстрым (на локальной машине), поэтому передача сообщений происходит очень быстро (возможно несколько сотен Гц для цикла управления).
Non-Real-Time
ROS в настоящее время не в реальном времени, так как подавляющее большинство алгоритмов не нуждаются в реальном времени. Чувство или планирование в большинстве случаев не имеют ограничений в режиме реального времени (сколько людей строят самостоятельно управляемые высокоскоростные автомобили?). Достаточно, если конечный контур управления работает в режиме реального времени, и во многих случаях это можно сделать непосредственно на двигателе (на который отправляется конечная позиция, например, через CAN). Реальное время, однако, является одной из основных целей ROS2 ( https://github.com/ros2/ros2/wiki/Real-Time-Programming ), поэтому даже если вам это понадобится в будущем для всей системы, ROS обеспечит вас ,
Если вы действительно хотите запускать встроенные компоненты, конечно, есть соединение с arduino, так что вы можете писать сообщения ROS непосредственно на arduino, которые затем отправляются через последовательное соединение.
Запуск ROS в Windows в настоящее время является довольно болезненной задачей, но поскольку Windows приближается к Linux (даже начиная с чего-то похожего на bash), это только вопрос времени, пока это станет возможным. (Но кто в любом случае хочет запустить робота с Windows?)
Аппаратные интерфейсы и алгоритмы:
Я думаю, что это действительно сильная сторона для ROS. Многие коммерчески доступные роботы уже поставляются с интерфейсом ROS, или кто-то уже потратил некоторое время на его реализацию. Большинство коммерческих вооружений можно использовать в MoveIt, поэтому большую часть работы по запуску приложения с определенным вооружением можно повторно использовать с другим оборудованием.
сообщество:
Еще одна сильная сторона для ROS. Новые алгоритмы очень быстро получают ROS-интерфейс, и у многих людей были такие же проблемы, как и у вас, поэтому вы найдете кого-то, кто вам поможет.
Последнее, что я хотел бы увидеть, это оглянуться на 20 лет назад, где все построено вокруг ROS, и понять, что, к сожалению, нам нужны роботы, чтобы работать с человеческой скоростью, сопоставимой, но мы не можем, потому что 20 лет назад мы думали сколько людей в любом случае строят себя за рулем высокоскоростных автомобилей ?
Шахбаз
2
Я думаю, что должен принять сторону @Shahbaz в этом. Дело не в том, что у ROS нет своего места, а в том, что вы не должны использовать ROS вместо хороших методов кодирования. Протокол ROS, который вы создаете, должен быть получен из библиотеки интерфейсов, а не наоборот.
Ответы:
Я вернулся к компьютеру!
Как я уже сказал в этом комментарии , ROS, как правило, не является обязательным. ROS - одна из многих платформ, известная в основном благодаря тому, что Willow Garage в какой-то момент времени раздает бесплатных роботов тем, кто написал большинство модулей ROS. Тем не менее, это не лучшая возможная платформа, и, конечно, ничего особенного. В частности, в результате указанного конкурса появилось много некачественных модулей, чтобы получить более высокие цифры.
Со временем качество модулей ROS улучшилось, и их стало много. Таким образом, используя ROS, вы можете повторно использовать многое из того, что уже сделано. Вы можете прочитать здесь некоторые причины, почему вы можете использовать ROS.
Имея это в виду, вы должны следить за побочными эффектами.
Распределенный контроль
С ROS у вас есть много узлов, которые общаются друг с другом через сеть. Это иногда хорошо и легко, но обычно приводит к сильно изменяющейся задержке приема сообщений. В результате вам потребуется большая задержка управления, чтобы обеспечить поступление всех сообщений, что означает, что вы не можете быстро реагировать на события, а это, в свою очередь, означает, что вы должны перемещать своего робота на более медленных скоростях, чтобы не пропустить эти события.
Верьте или нет, люди фактически управляют роботом через ROS ( MoveIt! - название соответствующего набора компонентов). Медленный. Опасное. Но легко!
Номера в режиме реального времени
Даже когда не распространяется, ROS не является платформой в реальном времени. Это означает, что вы по своему усмотрению можете назначить ядро Linux в любое время по своему усмотрению. Это нормально для некоторых приложений, но не хорошо для других. Так что вам нужно посмотреть на свои требования. Вам нужно иметь гарантию, что ваша задача будет выполнена в течение известного периода времени? Если это так, вам нужна система реального времени.
Хостинг Runtime Environment
Еще один момент, на который следует обратить внимание: хотя ROS является общим протоколом связи, он по существу поддерживается только для размещенных сред. Хостинг означает, что код выполняется поверх ядра, в отличие от автономного, что означает, что код напрямую управляет оборудованием (например, на микроконтроллере).
Если ваше робототехническое приложение работает близко к аппаратному обеспечению, и поэтому вам потребуется программа, работающая на микроконтроллере, ROS вам не поможет.
Блокировка платформы
Наконец, что не менее важно, разработка для ROS приводит к блокировке платформы. Это означает, что если в будущем по той или иной причине вы решите основывать свою работу на другой роботизированной платформе, такой как OROCOS, YARP и т. Д., Это будет мучительно.
Вы также были бы несколько привязаны к Linux. Без сомнения, Linux - лучший, но однажды вам может понадобиться поддержка другой системы, такой как QNX, VxWorks и т. Д., И у вас тоже возникнут проблемы.
Если вы пишете для микроконтроллеров, то забудьте о ROS. Если вы пишете высокоуровневые модули, я настоятельно рекомендую писать переносимый код. Например, предположим, что вы разработали новый датчик и хотите написать модуль, который получает данные от этого датчика, который подключен к вашему компьютеру через шину CAN.
В этой ситуации вы можете написать независимую библиотеку с функциями, способными работать с вашим датчиком и получать данные. Можно даже подумать о порождении потока в библиотеке, который периодически получает и ставит в очередь данные.
Если у вас есть эта вспомогательная библиотека, вы можете написать CLI, GUI, ROS-модуль, OROCOS-модуль, YARP-модуль, подключиться к Matlab или что-либо еще, что вы хотите использовать для взаимодействия с вашим датчиком.
Последнее замечание: то, что я здесь сказал, в целом применимо ко всем робототехническим платформам, а не только к ROS.
источник
«ROS» - это относительный термин, APM запускает полный пользовательский код, специально разработанный для управления квадрокоптером, где может быть желательно избежать нестандартного ROS, чтобы избежать сбоев, с другой стороны, Navio + работает на ядре Linux и выполняет код, отличный от автопилота, и до сих пор удается не разбиться. Большинство ROS на самом деле представляют собой набор функций поверх существующей ОС, в отличие от написания операционной системы с нуля. Как и во всем, это зависит.
источник
Отказ от ответственности: Этот ответ каким-то образом является реакцией на пост Шахбаз, так что он имеет склонность к ROS.
Я не думаю, что ROS является обязательным, но это отличная отправная точка и стоит времени для инвестиций. Это началось в Willow Garage, но эта компания исчезла, а ROS все еще жива, используется и развивается. Большая часть ROS является полностью открытым исходным кодом, а также может использоваться в коммерческих целях, поэтому ROS просто не исчезнет, если компания больше не будет в этом заинтересована. Качество кода, конечно, различается между основными модулями и реализациями передовых алгоритмов, которые некоторые аспиранты опубликовали в своей статье.
ROS набирает все большую скорость в промышленных условиях (я был бы удивлен, если бы значительная часть стартапов робототехники во всем мире не использовала ROS). Некоторые алгоритмы будут в дальнейшем поддерживаться и развиваться консорциумом ros-industrial, и если вы посмотрите на участников, стоит поспорить, что ROS станет стандартом в отрасли:
http://rosindustrial.org/ric/current-members/
Распределенный способ использования ROS очень помогает в создании и поддержке новых пакетов, особенно внутри команд. Определения сообщений и действий очень помогают в определении интерфейсов, что позволяет быстро обмениваться аппаратными средствами и алгоритмами. Это также помогает интегрировать новых членов команды, так как новый узел будет сбивать другие узлы, если он выйдет из строя (если он не съест всю оперативную память ...), так что довольно безопасно интегрировать частично работающие узлы в работающую систему в качестве их эффект ограничен. Для связи используется TCP, который является надежным и быстрым (на локальной машине), поэтому передача сообщений происходит очень быстро (возможно несколько сотен Гц для цикла управления).
Non-Real-Time
ROS в настоящее время не в реальном времени, так как подавляющее большинство алгоритмов не нуждаются в реальном времени. Чувство или планирование в большинстве случаев не имеют ограничений в режиме реального времени (сколько людей строят самостоятельно управляемые высокоскоростные автомобили?). Достаточно, если конечный контур управления работает в режиме реального времени, и во многих случаях это можно сделать непосредственно на двигателе (на который отправляется конечная позиция, например, через CAN). Реальное время, однако, является одной из основных целей ROS2 ( https://github.com/ros2/ros2/wiki/Real-Time-Programming ), поэтому даже если вам это понадобится в будущем для всей системы, ROS обеспечит вас ,
Если вы действительно хотите запускать встроенные компоненты, конечно, есть соединение с arduino, так что вы можете писать сообщения ROS непосредственно на arduino, которые затем отправляются через последовательное соединение.
Запуск ROS в Windows в настоящее время является довольно болезненной задачей, но поскольку Windows приближается к Linux (даже начиная с чего-то похожего на bash), это только вопрос времени, пока это станет возможным. (Но кто в любом случае хочет запустить робота с Windows?)
Аппаратные интерфейсы и алгоритмы:
Я думаю, что это действительно сильная сторона для ROS. Многие коммерчески доступные роботы уже поставляются с интерфейсом ROS, или кто-то уже потратил некоторое время на его реализацию. Большинство коммерческих вооружений можно использовать в MoveIt, поэтому большую часть работы по запуску приложения с определенным вооружением можно повторно использовать с другим оборудованием.
сообщество:
Еще одна сильная сторона для ROS. Новые алгоритмы очень быстро получают ROS-интерфейс, и у многих людей были такие же проблемы, как и у вас, поэтому вы найдете кого-то, кто вам поможет.
http://download.ros.org/downloads/metrics/metrics-report-2016-07.pdf
источник