Наскільки зрілим є програмування в режимі реального часу в робототехніці? [зачинено]

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

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

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

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

Отже, наскільки в реальному часі поведінку домагаються серед розробників робототехніки?Питання в тому, наскільки розробники схильні писати програми в реальному часі, коли поведінка в реальному часі насправді потрібна? Якщо не багато, чому?

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

¹ або аналогічно Xenomai

Пам'ятайте, що в реальному часі є і в реальному часі .

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

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

Навіть у царині комп'ютерів з Windows ви можете отримати важку продуктивність у режимі реального часу , вам просто потрібно правильне програмне забезпечення з правильними гачками в ядро. Beckhoff «s TwinCAT м'який PLC цілком щасливо побіг високу швидкість сканування PLC нарізаючи половину машинних циклів Пентіум, даючи іншу половину Windows NT, і це було більше десяти років тому. Навіть сучасні системи керування, як-от деякі параметри в діапазоні A3200 Aerotech, робкують роботу на хост-ПК, при цьому ядро ​​низького рівня займає стільки часу для процесора, скільки потрібно для жорстких вимог у режимі реального часу та залишає решту циклів процесора для Windows 7 використовувати!

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

Як доказ цього, дозвольте представити PR2 та руку Shadow Robot:

Цей робот має близько 20 градусів свободи, всі вони подаються через основний контур ROS. А як щодо Shadow Robot Hand, який також має 20 DOF, плюс масив тактильних та інших датчиків, а також подається через основний контур ROS.

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

Використання багатьох ядер всередині хост-ПК означає, що одне ціле ядро ​​присвячене виконанню основного циклу, і тому воно дуже рідко затримується іншими завданнями.

Основна причина використання дійсно ОС у режимі реального часу для роботизованої системи - це безпека. Якщо робот працює в критичних ситуаціях щодо безпеки, тоді ви зобов’язані гарантувати 100% контроль часу, і частина цього гарантує характер його в реальному часі.

Незалежно від того, використовуєте ви оперативну операційну систему чи ні, ваші сервоприводи повинні зробити щось безпечне у випадку, якщо цикл управління повністю відмирає. Ця система безпеки також була б корисною в рідкісних випадках, коли ОС в реальному часі пропускає більше циклу. Наприклад, на руці «Тінь» двигуни зупиняються, якщо контур управління пропускає більше 20 циклів (20 мс). Я ніколи не бачив, щоб це сталося.

Додано

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

Мета програмного забезпечення визначає, чи потрібно це суворо в режимі реального часу.

Якщо метою є планування або локалізація шляху, часто достатньо низької частоти, наприклад, 10 ГГц. У цих випадках налаштування програвача / сцени, що працює на Linux, чудово. Ми можемо побачити, що існує мало проблем, якщо один крок трохи довший або коротший.

Якщо динаміка робота швидка, потрібна сувора поведінка в режимі реального часу. Наприклад, переміщуючи робототехнічну руку, щоб відстежувати положення або обробляти / стискати предмети, і переміщувати їх. Якщо пропущений крок часу, позиція може небажано переступити, і ми можемо захотіти більш передбачуваної поведінки. У цьому випадку ми можемо мати частоту до 1 кГц або більше. Якщо використовується операційна система, ми хочемо операційну систему в режимі реального часу.

Поведінка в режимі реального часу може бути виконана у вбудованих додатках, використовуючи таймери та переривання (складений код С на мікроконтролері). У цьому випадку ми повинні переконатися, що навантаження на обробку не надто висока, щоб підтримувати регулярну частоту вибірки.

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

Тому, чи потрібна поведінка в режимі реального часу, залежить від того, для чого розробник має намір її використовувати.

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

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

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

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

Orocos - це зріла рамка програмного забезпечення для управління робототехнікою в реальному часі. Я бачив, що він використовувався для успішного управління високошвидкісними робототехнічними маніпуляторами з жорсткими вимогами в режимі реального часу. Він має багато тих же компонентів базового рівня, що і ROS, комунікації, конфігурація, серіалізація та упаковка на основі компонентів.

Почніть думати про свого робота з точки зору декількох процесорів та змін питань реального часу. Якщо у вас є алгоритм, який потребує високошвидкісних надійних зворотних зв’язків, таких як двоколісний балансир або квадрокоптер-стабілізатор або серво імпульс, реальний час надзвичайно важливий, але завдання також дуже обмежене.

Ви можете вивантажити подібний цикл управління на спеціалізований процесор у режимі реального часу, наприклад дешевий 8-бітний AVR або 32-бітний ARM низького рівня, знайдений у пристроях класу Arduino. Ніщо не заважає вам додати багато десятків цих невеликих MCU, які працюють з виділеними петлями управління, перерахування 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