Насколько зрелым является программирование в реальном времени в робототехнике? [закрыто]

Редактировать: я не знаю почему, но этот вопрос, кажется, сбивает с толку многих людей. Я знаю, когда / где / почему / как использовать в режиме реального времени. Мне интересно знать, действительно ли люди, у которых есть задача в реальном времени, действительно заботятся о том, чтобы реализовать их в реальном времени, или нет.

Нет необходимости упоминать, почему операции в реальном времени важны для робота. Мой вопрос, однако, насколько это на самом деле используется в робототехнике?

Возьмите этот вопрос для примера. Только в одном ответе упоминается какая-либо платформа с возможностями реального времени, и она также далеко не вершина. ROS, видимо, является очень популярной платформой, которая работает не в режиме реального времени.

Однако в мире реального времени RTAI ¹ представляется единственной работоспособной бесплатной платформой в реальном времени. Однако он ограничен Linux (без проблем), плохо документирован и медленно развивается.

Итак, насколько поведение в реальном времени востребовано среди разработчиков робототехники?Вопрос в том, насколько разработчики склонны писать приложения в реальном времени, когда поведение в реальном времени действительно необходимо? Если не так много, почему?

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

¹ или аналогично Xenomai

Помните, что есть реальное время и есть реальное время .

Трудно Реальное время трудно достичь без аппаратной поддержки или поддержки программного обеспечения низкого уровня, но вам часто не нужно все, чтобы поддерживать Hard Real Time . Реакция Soft & Firm Real Time гораздо проще достичь и часто более чем достаточна для многих приложений.

Кроме того, разные части системы могут иметь очень разные требования в реальном времени . Если вы используете программные петли PID, у них действительно должен быть жесткий отклик в реальном времени (вам действительно не нужно выбирать между мягкой настройкой ваших PID или жесткой настройкой и, например, периодической нестабильной работой). Система видения может иметь твердые требования реагирования в реальном времени , производительность снизится, если вы не сможете вовремя обработать образ для следующего решения, но это не должно препятствовать работе системы, в этом случае, если вы не можете обработать его вовремя, вы лучше отбрасывать частичные результаты и не терять время, начиная анализ на следующем кадре. Наконец, ваше общее планирование и координация (возможно, самая сложнаячасть вашей роботизированной системы) часто может твердо оставаться в области мягкого реального времени .

Даже в сфере ПК с Windows вы можете добиться высокой производительности в режиме реального времени , вам просто нужно правильное программное обеспечение с правильными хуками в ядре. Мягкий ПЛК TwinCat от Beckhoff успешно выполнил ПЛК с высокой скоростью сканирования, разделив половину машинных циклов Pentium, уступив другую половину Windows NT, и это было более десяти лет назад. Даже современные системы управления, такие как некоторые опции в линейке Aerotech A3200, выполняют основную работу на хост-ПК, поскольку низкоуровневое ядро ​​отнимает столько процессорного времени, сколько требуется для жестких требований реального времени, и оставляя оставшиеся циклы ЦП для Windows 7. использовать!

Система реального времени на самом деле не требуется для многих (большинства?) Роботизированных систем управления. Если у вас есть цикл управления, который работает достаточно быстро, с достаточно низким джиттером и не пропускает слишком много циклов, то этого вполне достаточно для роботизированного управления и сервопривода.

В доказательство этого позвольте мне представить PR2 и Shadow Robot Hand:

Этот робот имеет около 20 степеней свободы, и все они обслуживаются через основной цикл ROS. Или как насчет Shadow Robot Hand, который также имеет 20 степеней свободы, плюс набор тактильных и других датчиков, а также подается через основной цикл ROS.

Основной цикл ROS страдает от небольшого джиттера, иногда до 100 мкс, а иногда и вовсе пропускает циклы. Но это не имеет значения, если 99,9% циклов выполнены успешно.

Использование множества ядер на хост-ПК означает, что одно основное ядро ​​предназначено для запуска основного цикла, и поэтому оно очень редко задерживается другими задачами.

Основная причина использования ОС реального времени для роботизированной системы заключается в безопасности. Если робот работает в критической ситуации безопасности, то вы несете ответственность за 100-процентную поддержку контроля времени, а отчасти это гарантирует его характер в реальном времени.

Независимо от того, используете ли вы операционную систему в реальном времени или нет, ваши сервоприводы должны делать что-то безопасное в случае полного прекращения цикла управления. Эта система безопасности также будет полезна в тех редких случаях, когда ваша ОС не в режиме реального времени пропускает больше, чем цикл. Например, в Shadow Hand двигатели останавливаются, если контур управления пропускает более 20 циклов (20 мс). Я никогда не видел, чтобы это случилось, хотя.

добавленной

Еще один способ подумать об этом заключается в следующем: какая частота обновления нужна вашей сервосистеме? Если это большая рука, и она не требует сверхвысокой производительности и высокоскоростного позиционирования, тогда может быть достаточно 500 Гц. Для езды вокруг, вероятно, достаточно 200 Гц. В обоих этих случаях, если ваш цикл фактически работает на частоте 1000 Гц, то поздний или пропущенный цикл действительно не представляет никакой проблемы, если ваш алгоритм управления учитывает фактическое время, прошедшее между циклами.

Назначение программного обеспечения определяет, должно ли оно быть строго в режиме реального времени.

Там, где целью является планирование пути или локализация, часто достаточно низкой частоты, например, 10 Гц. В этих случаях хорошо работает установка плеера / плеера в Linux. Мы видим, что есть несколько проблем, если один временной шаг немного длиннее или короче.

Строгое поведение в реальном времени требуется, если динамика робота быстрая. Например, перемещение роботизированной руки для отслеживания положения или для обработки / захвата объектов и их перемещения. Если временной шаг пропущен, позиция может нежелательно отклоняться, и нам может потребоваться более предсказуемое поведение. В этом случае мы можем иметь частоту до 1 кГц или более. Если используется операционная система, нам нужна операционная система реального времени.

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

Роботы, использующие компьютеры / микропроцессоры (поскольку требуется большая вычислительная мощность), должны будут использовать операционную систему в реальном времени, чтобы гарантировать высокую частоту дискретизации.

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

Наша компания строит роботов с использованием FreeRTOS, работающих на микроконтроллерах PIC. Для нас основными причинами использования FreeRTOS является простота перераспределения приоритетов в задачах, одновременная обработка нескольких линий связи и простота обмена данными между обработчиками прерываний и основными задачами. Микроконтроллеры намного дешевле, чем установка полного Linux-машины в каждый робот, который мы производим.

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

Часть программирования в реальном времени обычно настолько мала, насколько это возможно, потому что ее труднее отлаживать и меньше кода легче проверить на правильность. Документация на ОС реального времени обычно довольно хорошая (включая RTAI / Xenomai).

Я использовал QNX и RTAI-> Xenomai в различных реальных проектах робототехники. Я предпочел QNX, но Xenomai был таким же эффективным.

Orocos - это зрелая система программного обеспечения для управления робототехникой в ​​реальном времени. Я видел, как он успешно управлял высокоскоростными роботизированными манипуляторами с жесткими требованиями в реальном времени. Он имеет много компонентов того же уровня инфраструктуры, что и ROS, связь, конфигурация, сериализация и пакетная компоновка компонентов.

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

Вы можете разгрузить цикл управления, подобный этому, на выделенный процессор реального времени, такой как дешевый 8-битный AVR или 32-битный ARM нижнего уровня, найденные в классе устройств Arduino. Ничто не мешает вам добавить множество десятков этих небольших микроконтроллеров с выделенными контурами управления, перечисление USB-устройств даже делает это простым.

Теперь, когда у вас есть чувствительные к синхронизации контуры управления, обрабатываемые выделенным процессором, вы можете ослабить потребности «мозга» робота в реальном времени, который может запускать логику более высокого уровня, используя такие компоненты, как ROS в Linux или Kinect для Windows.

В ответ на «когда / в каком случае» используются системы реального времени:

По моему опыту, управление движением является основным приложением для систем реального времени. Для управления двигателями важны высокая частота (100 Гц, 1000 Гц и более) и низкий джиттер (временные колебания). Безопасность здесь важна. Рассмотрим робота среди людей: например, вы хотите / должны убедиться, что робот (рука) останавливается в течение определенного промежутка времени / расстояния.

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

В настоящее время большие роботы, такие как PR2, объединяют оба мира. В контексте реального времени операционной системы с поддержкой RT (например, Linux + Xenomai) происходит управление движением, а в части не в реальном времени (пользовательская область) обработка зрения и планирование встроены в такие системы, как ROS. Оба могут работать на одном компьютере.

Я с удовольствием отредактирую этот ответ, как только вопрос прояснится. :-)

Да, если предположить, что аппаратные ресурсы могут соответствовать требованиям синхронизации (достаточная вычислительная мощность, достаточно низкая задержка), когда планировщик не может должным образом упорядочить процессы и потоки, тогда используется планировщик реального времени, обычно подключенный к ядру, специально оптимизированному для проблемы этого. Аппаратные драйверы также могут быть оптимизированы для условий в реальном времени.

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

Одно хорошее решение - сделать ОБА. Конструкция, которую я использую, помещает «жесткие» функции реального времени на небольшой микроконтроллер, узкие контуры сервоуправления и тому подобное. Тогда есть другой процессор, который больше, работает под управлением Linux и ROS. Я позволил ROS обрабатывать задачи более высокого уровня, а uP - такие вещи, как управление шаговым двигателем или запуск цикла PID.

Как уже говорилось выше, вы МОЖЕТЕ разрешить ОС не в реальном времени запускать управляющие контуры 1 кГц, но для того, чтобы это работало, вам нужен компьютер большого размера с избыточным количеством убийств, который большую часть своего времени проводит в режиме ожидания. Если вы используете компьютер с Linux / ROS при почти 100% загрузке ЦП, производительность в реальном времени будет низкой. Использование двухуровневой конструкции позволяет всегда получать очень хорошую производительность RT, а также использовать меньший, менее энергозатратный компьютер (возможно, задачи более высокого уровня Pi2). В настоящее время в моем uP не работает ни одна ОС, но я перехожу на FreeRTOS