Дуже коротка відповідь: 2
Датчики
Що стосується того, чи читаєте з датчиків все в одному вузлі або кожен окремо, вам слід задати собі це питання:
Чи датчики безглузді без іншого?
Це питання задає, чи датчики щільно з'єднані чи ні. Наприклад, скажіть, у вас сенсор, чутливий до температури (і вам потрібно це компенсувати). Ви додаєте датчик температури головним чином, щоб фіксувати значення іншого датчика. У цьому сценарії є сенс читати обидва значення одночасно, оскільки вони щільно з'єднані. Насправді, без показань датчика температури, показання з оригінального датчика марні.
З іншого боку, якщо датчики корисні індивідуально, усіма силами зберігайте їх в окремих вузлах. Це має багато переваг:
- Вузли можуть працювати на окремих процесорах
- Вузли можна повторно використовувати в майбутніх роботах
- Порушення зв'язку з одним вузлом не збиває всю систему
- Перезапуск придбання з несправної плати сенсорів можна здійснити окремо від інших
Насправді, якщо вам потрібна якась із перерахованих вище переваг, вам доведеться пройти окремими вузлами, навіть якщо датчики щільно з'єднані, але цього зазвичай не відбувається.
Приводи
Це аналогічно.
Чи приводи безрезультатні без інших?
Наприклад, якщо ви проектуєте зап'ястя з робототехнічними сухожиллями, де за кожне сухожилля (з будь-якої причини) два двигуни відповідають за одночасну роботу над переміщенням суглоба в ту чи іншу сторону, то подання їх в один вузол робить набагато більше сенс, ніж окремий.
З іншого боку, де виконавчі пристрої незалежні (звичайний випадок), має сенс мати по одному вузлу для кожного приводу. У цьому випадку кожен може бути поміщений в інший вузол. Окрім тих самих переваг, що й у сенсорів, є ця додаткова перевага:
- Якщо виконавчі пристрої зупиняються (з будь-якої причини), інші приводи все ще функціонують. Якщо є зайві ступені свободи, вони могли б навіть повністю компенсувати це.
Це має одне значення. Якщо вам потрібні приводи, щоб вони працювали злагоджено, тоді поставте їх у той же вузол. Це не тільки через збій у спілкуванні, а через те, що різні вузли означають різні затримки; у розподіленій системі кожен вузол знаходиться в іншій частині мережі, а отже, різниця у затримках, у централізованій системі трапляються різні затримки при великих навантаженнях процесора через удачу кожного процесу в плануванні.
Чи повинен бути обробник?
Незважаючи на те, що відповідь "це залежить", існує спільний підхід з багатьма перевагами. Давайте змінимо ім’я та назвемо його «контролером». Підхід "так, має бути контролер".
Переваги наявності контролера (серед багатьох):
- Об'єднана обробка: кожен вузол відповідає за одне, що означає:
- Простота: що означає
- Легший розвиток
- Легша налагодження
- Менше помилок
- Менший шанс невдачі
- Повторність використання: тому що один і той же контролер може використовуватися з різними датчиками датчиків, якщо вони мають однаковий функціонал (тобто формати повідомлень та обслуговування).
- Виконання на окремому апаратному забезпеченні: кожен вузол можна перемістити в мережі. Наприклад, датчики та вузли приводу можуть бути переміщені до спеціалізованого мікроконтролера (наприклад, Arduino (не те, що я рекомендую)) та контролера на ПК.
- Уникайте надзвичайної потворності: якщо датчики хотіли безпосередньо впливати на пускачі, результат - просто безлад. Припускаючи, що немає контролера, давайте розглянемо кожен випадок:
- Один сенсорний вузол: в основному це означає, що вузол датчика і контролер об'єднані в один і той же вузол. Не надто погано, але дуже непотрібно.
- Багато сенсорних вузлів: це безлад. Це означає, що контролер розподілений між вузлами датчиків. Тому всі вузли датчиків повинні розмовляти між собою, щоб знати, як керувати пов'язаними з ними приводами. Уявіть провал у спілкуванні чи різного роду затримки, і ви побачите, як це стає важко. Зважаючи на те, що це абсолютно непотрібно, немає ніяких причин для цього!
Сказані, є і недоліки. Мати більше вузлів (будь-яких вузлів, а не лише контролера) означає:
- Більше даремно спілкування: дані повинні переміщуватися у стандартних форматах (так серіалізовані та десеріалізовані) через мережу або спільну пам'ять, ядро ROS повинно подивитися на них і вирішити, кому їх доставити тощо. Коротше кажучи, деякі системні ресурси марно витрачаються у спілкуванні. Якщо всі вузли в одному, ця вартість могла б дорівнювати нулю.
- Більш високий шанс виходу з ладу: якщо з якихось причин мережеве посилання відхилиться або вузол відмирає, в системі відбувається збій. Якщо ви не готові до цього, це може зняти всю систему. Зараз це взагалі гарна річ у тому, що можна втратити частину системи, але не всю її ( витончена деградація ), але також існують додатки, де цього слід уникати якомога більше. Вирізання зв'язку та розміщення всього коду в одному вузлі насправді допомагає стабільності системи. Знизу, звичайно, система або працює нормально, або раптом повністю гине.
- Хаотичні таймінги: кожен вузол працює самостійно. Час, який потрібно, щоб повідомлення надходили до інших, не є детермінованим і змінюється залежно від запуску. Якщо ваші вузли не позначають тимчасовим позначенням кожного повідомлення (як побічна примітка: вам потрібно синхронізувати годинник, який не має ROS), і якщо кожен вузол, який приймає, може врахувати затримку і відповідно контролювати (що є дуже складним завданням самостійно), то наявність кількох вузлів означає високу невизначеність щодо віку даних. Це насправді одна з причин (серед багатьох), що більшість роботів рухаються так повільно; їх цикл управління повинен бути досить повільним, щоб переконатися, що всі дані відповідають поточному періоду. Чим більше затримок, тим повільніше цикл управління.
З урахуванням усіх вищезгаданих недоліків, рішення полягає у зменшенні кількості вузлів, переважно до одного вузла. Зачекайте хвилину, це вже не використання ROS! Саме так.
Узагальнити:
- Використовуйте ROS для систем не в реальному часі, де затримки можуть епізодично отримувати високі рівні. У цьому випадку сміливо майте стільки ROS-вузлів, скільки бажаєте. Насправді, дуже хороша практика, щоб кожен вузол ROS робив одне і лише одне . Таким чином, вони стають дуже простими, і вони стають багаторазовими.
- З іншого боку, для систем реального часу уникайте ROS. Для цього є orocos та такі технології, як EtherCAT, і найчастіше - спеціальні рішення.
Як підсумкове слово, на практиці ROS робить чудово. Не чудово, але добре. Дуже часто система не є критичною, і ймовірність виходу з ладу настільки мала, що раз у раз перезапуск не є великою справою. Це алгоритм Страуса !
