Как я могу управлять быстрой (200 Гц) системой реального времени с медленной (30 Гц) системой?

В настоящее время мы разрабатываем мобильный робот + установленный кронштейн с несколькими контролируемыми степенями свободы и датчиками.

Я рассматриваю архитектуру в двух частях:

1. Набор контроллеров реального времени (Raspeberry Pis с ОСРВ, такими как Xenomai или голые металлические микроконтроллеры) для управления двигателями и энкодерами. Назовем эти машины RTx, с x = 1,2,3… в зависимости от количества микроконтроллеров. Этот цикл управления будет работать на частоте 200 Гц.

2. Мощная ванильная машина Linux, работающая под управлением ROS, для вычисления SLAM, mocap и выполнения логики высокого уровня (решить задачу робота и вычислить желаемое положение и скорость двигателей). Этот цикл управления будет работать с частотой 30 Гц.

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

Моя главная проблема состоит в том, чтобы решить, как установить связь между различными RTx и ПК1. Я смотрел на документы, связанные с архитектурой роботов (например, HRP2 ), чаще всего они описывают архитектуру управления высокого уровня, но мне еще предстоит найти информацию о том, как обеспечить связь низкого уровня с высоким уровнем и масштабируемым способом. Я что-то пропустил?

Чтобы соединить машины быстрого RT, обеспечивающие управление двигателем, с ПК1, я рассмотрел TCP / IP, CAN и UART:

• TCP / IP: не детерминированный, но легко устанавливаемый. Является ли недетерминизм реальной проблемой (так или иначе она будет использоваться только на медленной скорости 30 Гц)?
• CAN: медленный, очень надежный, ориентированный на автомобили (есть примеры использования CAN с роботами, но это выглядело экзотично)
• UART: если бы у меня была только одна машина RT для управления двигателем, я бы рассмотрел UART, но я думаю, что этот порт плохо масштабируется со многими RTx. Действительно ли TCP / IP бесполезен из-за его недетерминированных характеристик? Это так просто в использовании ...

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

У кого-нибудь есть четкое мнение по этому вопросу или литература, на которую можно указать? Существуют ли типичные или общепринятые коммуникационные решения для роботов?

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

Я просмотрел статьи, связанные с архитектурой роботов [...], но мне еще предстоит найти информацию о том, как обеспечить низкоуровневую связь с высоким уровнем и масштабируемым способом. Я что-то пропустил?

Из вашего описания звучит так, будто вы пытаетесь подключить каждый контроллер RTx напрямую к ПК1, на котором работает ROS. Что вы упустили, так это то, что ROS предназначен для обработки группы приложений, которые могут производить и потреблять данные с разной скоростью.

Вашему приложению нужен коммуникационный мост - единый интерфейс между вашей петлей 200 Гц и вашей средой ROS. Другими словами, вместо того , чтобы связывать каждый контроллер RTX к PC1, связать все контроллеры RTX вместе и подключить , что к ПК1.

Например, используйте шину I2C, чтобы связать системы RTx вместе, и добавьте еще один контроллер RTx в качестве «Master Master» (AM). Работа АМ состояла бы в том, чтобы принимать входящие команды в некотором формате и протоколе, дружественном к ПК1, и преобразовывать эти команды в сообщения I2C. Затем вы бы написали приложение ROS для отправки команд в AM.

Другой способ сделать это с помощью I2C - установить контроллер I2C непосредственно на ПК1 и записать всю логику управления плечом в приложении ROS. Это может показаться более упрощенным способом достижения вашей цели, но это может усложнить отладку, поскольку вы удаляете модульность системы - вам придется устранять неполадки в виде одной большой сложной системы вместо двух легко тестируемых компонентов.

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

Любая система управления требует высокой степени детерминизма, из-за чего каналы с высокой пропускной способностью (такие как Ethernet) обычно неэффективны (особенно при использовании с ОС общего назначения, которая вводит большое количество дрожания планирования), см. Следующую ссылку для обсуждения детерминизма планирования ). Прикладные процессоры (такие как ARM11 Raspberry Pi) также, вероятно, плохо подходят для систем реального времени (из-за таких эффектов, как задержка прерываний и разметка команд). Смотрите следующее обсуждение digikey, сравнивающее поведение ядра приложения ARM в реальном времени и микроконтроллера .

Жаль, что наличие встроенной CAN не так широко распространено, как UART (RS-485) или I2C (пока), потому что я думаю, что это действительно упрощает проблему распределенного зондирования и приведения в действие. И хотя обычная скорость 1 Мбит / с может показаться низкой, этого обычно более чем достаточно после вычисления частоты обновления всех элементов шины (и скорость передачи всегда можно увеличить в зависимости от длины шины, полного сопротивления и того, позволят ли ваши трансиверы это). Также доступно отличное программное обеспечение для моделирования, которое в основном гарантирует наихудшее время отклика (например, RealTime-at-work имеет бесплатный анализатор шины CAN под названием RTaW-Sim). И, наконец, кажется, что доступность MEMS-датчиков со встроенным CAN довольно скудна.

Другим примером, в котором приводы настроены как шина (или кольцо), являются серии Dynamixels AX и MX, где каждый двигатель соединен последовательно с последовательным соединением UART. Это значительно упрощает конструкцию системы, если у вас большое количество приводов.

Но, чтобы вернуться к актуальному вопросу, я думаю, что если вы описываете свою систему как заданные значения в реальном времени, а не команды (например, непрерывно передаете угол двигателя, а не команду, такую ​​как угол goto), это упрощает связь между петля 200 Гц и 30 Гц.

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

1. Как передать команды от медленной системы (30 Гц) к быстрому контроллеру (200 Гц), и как я могу передать данные, принимаемые на частоте 200 Гц, обратно в мой мозговой центр 30 Гц?
2. Как я могу контролировать то, что происходит на частоте 200 Гц, когда я могу только сказать роботу, что делать на частоте 30 Гц?

Пункт 1 может быть решен аппаратно, поскольку ваш первоначальный вопрос, по-видимому, указывает - вы можете поставить в очередь данные на частоте 200 Гц и отправить пакет на частоте 30 Гц в систему более высокого уровня. Вы можете сделать это с TCP / IP или, возможно, с CAN, в зависимости от того, сколько данных вы хотите отправить. Разное оборудование имеет разные максимальные скорости передачи данных. Также может помочь добавление уровня архитектуры, такого как ROS, в качестве коммуникационного моста / арбитра, как это предлагается в других статьях.

Пункт 2 - это проблема теории управления, которая не может быть решена с помощью одного только оборудования. Требуемые SLAM, определения местоположения и скорости, а также определение задач должны быть разумнее, поскольку они отправляют и получают информацию реже. Вы, вероятно, захотите 2 контура управления : 1 при 200 Гц и 1 при 30 Гц.

Есть много других вопросов, которые касаются контуров обратной связи, обратной связи и ПИД-регулирования, но вы специально задали вопрос о масштабируемости - способ, которым большинство гигантских систем масштабируется, за счет наслоения контуров управления и логики так, чтобы минимально необходимая информация передавалась на любом оборудовании. вы в конечном итоге. Например, ваш контроллер верхнего уровня может только давать очки за позицию цели и среднюю скорость цели на уровень ниже уровня, а не изменять скорость 30 раз в секунду.