Я вернулся к компьютеру!
Как я уже сказал в этом комментарии , 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.