У цій статті порівнюються рішення системи керування двома промисловими роботами, маніпулятором і мобільним роботом, і представлені їхні характеристики.
Наведена вище класифікація базується на об’єкті застосування. Крім того, на ринку є більш загальні контролери руху, тобто ті, які керують нестандартним обладнанням.
1 Рішення нижнього рівня контролера 1.1 Тип маніпулятора Контролер типу маніпулятора розроблений раніше та є відносно зрілим. Давайте подивимося на існуюче рішення нижнього рівня системи управління. 1.2 Тип мобільного робота Контролер мобільного робота відноситься до відносно нового напрямку. Промислові мобільні роботи представлені у вигляді АГВ, безпілотної інженерної техніки тощо. Рішення нижнього рівня системи керування виглядає наступним чином:
1.3 Порівняння
Маніпулятор має високі вимоги до точності та стабільності руху, тому обсяг розрахунку великий, а цикл короткий, що зазвичай на 1-2 порядки вище, ніж у мобільних роботів. Мобільні роботи, як правило, не мають високих вимог до точності синхронізації, а їхня конфігурація відносно низька.
Маніпулятор, як правило, працює у фіксованій зоні, а його контролер зазвичай розміщений у шасі, тому рівень захисту невисокий, зазвичай IP20. Мобільні роботи мають бути водонепроникними та пилонепроникними, оскільки їм доводиться часто переміщатися, особливо інженерне обладнання для зовнішньої експлуатації, тому їм потрібно передбачити захист від води та пилу. Ступінь захисту у них вище, зазвичай IP67.
2 Вступ до CoDeSys 2.1 Склад CoDeSys
Ви побачите, що багато програмного забезпечення для керування роботами реалізовано за допомогою CoDeSys, тож що таке CoDeSys?
CoDeSys — це платне програмне забезпечення для розробки ПЛК. Простіше кажучи, він складається з двох частин: системи розробки та системи виконання. Система розробки — це програмний інтерфейс, який використовується для програмування (подібно до Visual Studio, Eclipse та іншого програмного забезпечення, яке також можна назвати IDE). Проектування, налагодження та компіляція програм ПЛК виконуються в IDE, з якою часто мають справу користувачі;
Після написання програми ПЛК її необхідно передати на апаратний пристрій для роботи. Однак згенерована програма ПЛК наразі не може працювати сама по собі. Він повинен працювати в певному програмному середовищі. Це середовище є системою виконання, яка невидима для користувачів.
Місця встановлення обох зазвичай відрізняються. IDE зазвичай інсталюється на комп’ютері розробника, а Runtime System розташовано на апаратному пристрої, який відіграє роль керування. Обидва зазвичай з’єднуються мережевими кабелями, і програма завантажується в Runtime через мережевий кабель для роботи.
CoDeSys не дуже відомий у Китаї, але має давню репутацію в Європі, особливо у сфері промислового контролю. Багато компаній-роботів, про які ми згадували вище, використовують його продукти, такі як KEBA, Beckhoff, Googol і майже всі виробники контролерів мобільних роботів.
3S, компанія, яка розробила CoDeSys, продає лише програмне забезпечення, а не обладнання. Апаратна схема повинна бути розроблена користувачем, і 3S відповідає за перенесення Runtime System на апаратне забезпечення клієнта. Runtime System може працювати без використання апаратного забезпечення, але зазвичай вона працює в операційній системі, і налаштування операційної системи також є роботою клієнта.
Якщо замовник вимагає, IDE CoDeSys можна налаштувати, щоб змінити логотип і зовнішній вигляд замовника, тому ви побачите, що платформи розробки різних виробників виглядають по-різному, але стилі відносно схожі.
Звичайно, користувачі також можуть використовувати інші IDE. Наприклад, Beckhoff використовує Microsoft Visual Studio, тоді як ядро та бібліотека функцій за компілятором все ще використовують рішення CoDeSys.
Runtime CoDeSys має сильну адаптивність і підтримує більшість операційних систем і архітектур апаратних мікросхем.
2.2 Принцип виконання CoDeSys
Частина IDE CoDeSys безкоштовна, і ви можете завантажити її з офіційного веб-сайту, щоб випробувати її. Справжнім зарядом є система виконання Runtime System.
На початку свого проектування CoDeSys розділив функції на кілька компонентних модулів, таких як стек протоколів шини, візуальний інтерфейс, керування рухом, контроль безпеки тощо. Користувачі можуть вибрати необхідні модулі для створення власної системи як будівельні блоки, і, нарешті, сформувати налаштовану програмну платформу керування.
Деяким користувачам, які вперше знайомляться з програмним ПЛК, ця частина може бути незнайомою, але насправді цей метод проектування дуже поширений. Наприклад, панель інструментів реального часу (Real-Time) MATLAB Simulink працює таким чином. Користувачі розробляють керуючі програми, перетягуючи їх у графічний інтерфейс Simulink, а потім завантажують їх на справжнє обладнання для запуску. Ви можете дізнатися про це тут.
Є й такий спосіб використання, як Beckhoff. Користувачі програмують у TwinCAT IDE, а потім завантажують їх на контролер Beckhoff. Насправді середовище виконання попередньо встановлено в контролері. Siemens STEP7 також є IDE, і його ПЛК також має відповідне середовище виконання.
Програма PLC, написана користувачем, схожа на програму в нашому комп’ютері. Він працює в системі виконання, а система виконання працює в операційній системі.
Система середовища виконання розташована між програмою та операційною системою. Тому це можна назвати проміжним програмним забезпеченням. У програмному забезпеченні роботів ROS, OROCOS (Real-Time Toolkit) тощо займають таке ж положення.
Керування роботом, як і верстати з ЧПК, потребує продуктивності в реальному часі, тому операційна система, яку ми обираємо, є переважно операційною системою реального часу (RTOS). На жаль, операційні системи, які ми часто використовуємо, не працюють у режимі реального часу, як-от Windows і Linux. Але, на щастя, хтось модифікував їх, тобто додав патчі в реальному часі.
Операційні системи реального часу, які зазвичай використовуються, включають: VxWorks, QNX, Windows RTX, Xenomai, RT Linux, Linux RTAI, WinCE, μC/OS, SylixOs тощо. Враховуючи, що є багато користувачів операційних систем Windows і Linux, CoDeSys запустив відповідний патч у реальному часі (RTE), щоб позбавити користувачів модифікації.
Для отримання додаткової інформації про CoDeSys Runtime ви можете прочитати офіційний документ [Math Processing Error] [1][2][1][2].
2.3 Недоліки CoDeSys
CoDeSys привносить зручність у розробку наших контролерів і позбавляє нас від проблем починати з нуля. Однак розробка наших власних контролерів на основі комерційного програмного забезпечення, такого як CoDeSys, також має багато недоліків:
(1) Базовий алгоритм не відкритий
Компоненти керування рухом і стеки протоколів шини, інтегровані CoDeSys, інкапсульовані. Користувачі не можуть зрозуміти їхні внутрішні деталі, а також не можуть налаштувати й оптимізувати їх відповідно до своїх конкретних потреб. Вони можуть називати їх лише просто. Користувачі можуть покладатися лише на платформу CoDeSys і їм важко створити власну основну технологію.
(2) Обмежені функції, які важко розширити
Нові технології, представлені машинним зором, штучним інтелектом і автономним водінням, зараз просуваються семимильними кроками, а багатьом технологіям промислового управління все ще 20 років. Візьмемо як приклад сцену навігації в мобільному роботі. Метод навігації, заснований на зору або лазері, потребує збору великої кількості даних і їх обробки, що включає багато матричних обчислень.
Тепер ПЛК може виконувати лише зворотні одновимірні цифрові обчислення, що ускладнює реалізацію складних алгоритмів. На відміну від стилю спільноти штучного інтелекту з відкритим кодом, спільнота промислового управління закрита одна для одної. Ніхто не хоче відкривати власні бібліотеки функцій. Існує дуже мало бібліотек функцій з відкритим кодом (OSCAT). Навіть найпростіші алгоритми фільтрації та обчислення матриці доводиться писати з нуля. Крім того, базові функції, передбачені міжнародними стандартами, надто обмежені і взагалі не можуть адаптуватися до нових сценаріїв. Вони потребують термінового розширення.
(3) Важко оновити
Через повну залежність від CoDeSys оновлення апаратного забезпечення власного продукту клієнтів потрібно налаштовувати та трансплантувати, що призводить до збільшення витрат.
3 Рішення з відкритим кодом
На даний момент існують деякі рішення систем керування з відкритим кодом, такі як Beremiz, Orocos, OpenPLC, OpenRTM і ORCA.
Розробка контролерів роботів — важке завдання. Слід уточнити низку вимог до продуктивності, першою з яких є продуктивність у реальному часі.
Продуктивність у реальному часі, як правило, необхідна для промислових роботів, але не обов’язково для сервісних чи розважальних роботів. Звичайним людям легко прийняти «продуктивність у реальному часі» як швидку обробку або швидкість відповіді, але насправді «продуктивність у реальному часі» означає «детермінізм» у часі. Наприклад, час затримки відповіді на переривання або перемикання процесу в операційній системі реального часу (RTOS) має бути в межах діапазону часу.
Операційні системи, які ми зазвичай використовуємо (Windows, Linux), не є операційними системами реального часу, оскільки вони розроблені для пропускної здатності та не можуть гарантувати, що кожна подія обробляється в певному діапазоні. Наприклад, швидкість передачі стандартного Ethernet набагато вища, ніж у промислового Ethernet реального часу, але це також не реальний час, оскільки він також не може гарантувати, що дані передаються протягом певного часу.
Розібратися в реальному часі неважко, але які завдання робота потрібно виконувати в реальному часі? Як визначити часовий інтервал для виконання програми відповідно до вимог до продуктивності робота (1 мс або 10 мс)? Чи залежить реальний час від апаратного чи програмного забезпечення?
Як вибрати конкретне обладнання та програмне забезпечення на основі реального часу (ARM або X86, Linux RTAI або VxWorks)? В Інтернеті бракує поглибленого обговорення цього аспекту, і великі виробники роботів не розголошують результати своїх випробувань і експериментів. Здається, що цей аспект в основному залежить від досвіду та методу проб і помилок.
Тут я можу навести лише кілька показників. На даний момент цикл управління промисловими роботами становить близько 1 мс, а цикл керування контуром позиціонування високопродуктивного сервоприводу може досягати 125 [Помилка математичної обробки] мксм. PLCopen визначає деякі стандарти для сервоприводу та керування рухом, включаючи мову програмування, основні функціональні блоки керування рухом, параметри інтерфейсів введення та виведення тощо. [Помилка математичної обробки] ^{[3]}
[3] Конкретні деталі коду реалізації надаються різними виробниками.
