Як я можу керувати швидкою (200 Гц) системою в режимі реального часу із повільною (30 ГГц) системою?

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

Я розглядаю архітектуру в двох частинах:

1. Набір контролерів у режимі реального часу (або Raspeberry Pis, що працює під керуванням RTOS, таких як Xenomai, або мікроконтролери з голими металами) для управління руховими двигунами та кодерами. Назвемо ці машини RTx, з x = 1,2,3 ... залежно від кількості мікроконтролерів. Цей цикл управління буде працювати на 200 Гц.

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

Я знаю, що моя основа повинна бути масштабованою, щоб враховувати більше двигунів, більше датчиків, більше ПК (наприклад, для зовнішньої карти).

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

Для того, щоб з'єднати швидкі RT-машини, що забезпечують управління двигуном, до PC1, я розглянув TCP / IP, CAN і UART:

• TCP / IP: не детермінований, але простий у створенні. Невже детермінізм - це справжнє питання (оскільки воно буде використовуватися лише на повільній швидкості 30 Гц)?
• МОЖЛИВО: повільний, дуже надійний, націлений на автомобілі (бачили, що є деякі приклади використання CAN з роботами, але це виглядало екзотично)
• UART: якби у мене була лише одна RT-машина для управління двигуном, я вважав би UART, але, мабуть, цей порт не дуже добре розширюється з багатьма RTx. Чи справді TCP / IP не спрацьовує через його недетермінованих характеристик? Це так просто у використанні ...

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

Хтось має чіткий погляд на цю точку чи літературу, на яку слід вказати? Чи існують типові або основні комунікаційні рішення, які використовуються на роботах?

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

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

З вашого опису здається, що ви намагаєтеся прив’язати кожен контролер RTx безпосередньо до PC1, на якому працює ROS. Те, що ви пропустили, - це те, що ROS призначений для обробки групи програм, які можуть виробляти та споживати дані з різною швидкістю.

Ваша програма потребує комунікаційного мосту - єдиний інтерфейс між вашим циклом 200 Гц та середовищем ROS. Іншими словами, замість того, щоб прив’язувати кожен контролер RTx до PC1, зв’яжіть всі контролери RTx разом і підключіть його до PC1.

Наприклад, використовуйте шину I2C, щоб з'єднати системи RTx разом, і додайте інший контролер RTx, щоб бути "головним зброєю" (AM). Завданням AM було б приймати вхідні команди у певному форматі та протоколі для ПК1 та перетворювати ці команди на повідомлення I2C. Тоді ви напишете додаток ROS для надсилання команд до АМ.

Ще один спосіб зробити це з I2C - поставити контролер I2C безпосередньо на PC1 і записати всю логіку управління рукою в додаток ROS. Це може здатися більш спрощеним способом досягнення вашої мети, але це може ускладнити налагодження, оскільки ви видаляєте модульність системи - вам доведеться усунути проблеми як одну велику складну систему замість двох легко перевіряваних компонентів.

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

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

Прикро, що наявність інтегрованого CAN не настільки поширена, як UART (RS-485) або I2C (поки що), тому що я думаю, що це дійсно спрощує проблему розподіленого зондування та приведення в дію. І хоча звичайні 1 Мбіт / с можуть здаватися повільними, зазвичай це більш ніж достатньо після обчислення швидкості оновлення всіх членів шини (і швидкість передачі завжди можна збільшити, залежно від довжини шини, імпедансу та того, чи дозволять ваші приймачі). Існує також геніальне програмне забезпечення для моделювання, яке в основному гарантує найгірші часи реакції (наприклад, RealTime на роботі має безкоштовний аналізатор шини 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 Гц.

Існує безліч інших питань, які стосуються циклів управління подачею, зворотним зв'язком та PID, але ви спеціально запитали про масштабованість - спосіб масштабності більшості гігантських систем полягає в розшаруванні циклів управління та логіці, щоб мінімально необхідна інформація передавала будь-яке обладнання ви закінчите. Наприклад, ваш контролер вищого рівня може наводити лише очки позиції цілі та середню швидкість цілі на нижній, а не змінювати швидкість 30 разів на секунду.