Я повернувся до комп’ютера!
Як я вже говорив у цьому коментарі , ROS, як правило, не є обов'язковим. ROS - одна з багатьох платформ, відома здебільшого завдяки тому, що Willow Garage в якийсь момент роздав безкоштовних роботів тому, хто написав більшість модулів ROS. Однак, це не найкраща можлива платформа, і це, звичайно, нічого надмірно особливого. Зокрема, зазначений конкурс призвів до безлічі модулів низької якості лише для того, щоб збільшити кількість.
З часом якість модулів ROS покращилася, їх також багато. Таким чином, використовуючи ROS, ви маєте перевагу повторно використовувати багато що вже зроблено. Ви можете прочитати тут кілька причин, чому ви можете використовувати ROS.
Зважаючи на це, ви повинні також стежити за побічними ефектами.
Розподілений контроль
З ROS у вас є багато вузлів, які спілкуються між собою через мережу. Іноді це добре і легко, але, як правило, призводить до різко різної затримки прийому повідомлень. Як результат, вам доведеться мати велику затримку управління, щоб переконатися, що всі повідомлення надходять, а це означає, що ви не можете швидко реагувати на події, а це, в свою чергу, означає, що вам потрібно переміщати робота з меншою швидкістю, щоб не пропустити ці події.
Вірите чи ні, люди насправді керують роботами через ROS ( MoveIt! - це назва відповідного набору компонентів). Повільно. Небезпечно. Але легко!
Не в режимі реального часу
Навіть коли він не розповсюджується, ROS не є платформою в режимі реального часу. Це означає, що ви перебуваєте на повному розсуді ядра Linux, щоб планувати свої завдання в будь-який час, коли вважаєте за потрібне. Для деяких програм це нормально, а для інших не нормально. Тому потрібно дивитися на власні вимоги. Чи потрібно мати гарантію, що ваше завдання закінчиться у відомі часові рамки? Якщо так, вам потрібна система в режимі реального часу.
Прийняте середовище виконання
Ще один момент, який слід врахувати, полягає в тому, що, хоча ROS є загальним протоколом зв'язку, він по суті підтримується лише для розміщених середовищ. Розташований означає, що код працює над ядром, на відміну від автономного, що означає, що код безпосередньо керує обладнанням (наприклад, на мікроконтролері).
Якщо ваш додаток з робототехніки працює впритул до апаратного забезпечення, і тому вам знадобиться програма, яка працює на мікроконтролері, ROS вам не допоможе.
Блокування платформи
Не в останню чергу, розробка для ROS призводить до блокування платформи. Це означає, що якщо в майбутньому з тих чи інших причин ви вирішите базувати свою роботу на іншій робототехнічній платформі, такі як OROCOS, YARP тощо, це буде неприємно.
Ви також були б дещо заблоковані до Linux. Linux - це найкраще, без сумніву, але одного разу вам, можливо, доведеться підтримувати іншу систему, таку як QNX, VxWorks тощо, і у вас також будуть проблеми.
Якщо ви пишете для мікроконтролерів, то забудьте про ROS. Якщо ви пишете модулі високого рівня, настійно рекомендую писати портативний код. Наприклад, скажіть, що ви розробили новий датчик, і ви хочете написати модуль, який отримує дані з цього датчика, який підключений до комп'ютера через шину CAN.
Що ви можете зробити в цій ситуації - це написати незалежну бібліотеку з функціями, здатними працювати з вашим датчиком і отримувати дані. Можна навіть подумати про нерестовину нитки в бібліотеці, яка періодично збирає та запитує дані.
У вас є бібліотека помічників, ви можете написати CLI, GUI, модуль ROS, модуль OROCOS, модуль YARP, підключитися до Matlab або будь-що інше, що ви хочете використовувати для взаємодії зі своїм датчиком.
Заключне зауваження: те, що я тут говорив, в основному стосується всіх платформ робототехніки, а не лише ROS.