ROS - это игрушка? Или мы уже делаем промышленный код?
Это не такой сложный вопрос, как может показаться. Все зависит от того на каком этапе времени жизни проекта находится наш робот.
На MVP - лучше использовать ROS из-за большого объема простых модулей (драйверов, симуляторов, path-планеров).
На MMP - лучше от ROS отказаться и использовать что-то проверенное временем.
Здесь я рассказываю, как используем ROS в наших системах мы (В том числе uROS в embedded). Вопросы можно задать в комментариях.
Что я понял за время своей практики про ROS?
🕰Детерминированность/реальное время**
• ROS (версия 1) использует нерелевантный, асинхронный publish/subscribe поверх UDP/TCP.
• ROS 2 переходит на DDS, но стандарт DDS‑RTPS только "может быть" реальным временем - это зависит от конфигурации ядра и выбранного RT‑провайдера.
❗️Проблема.** На производственной линии требуется гарантированная задержка (обычно < 1 мс) и отсутствие потерь сообщений. Любое отклонение может привести к сбою процесса, потере качества и даже аварии.
🚧Безопасность и сертификация**
• ROS не поставляется с встроенными механизмами IEC 61508/ISO 13849‑1.
• «Проверки» - происходят вручную.
❗️Проблема. **Для производства требуется формальная верификация, доказательства безопасности (HMI‑стандарты, «fail‑safe» режимы) и сертификация от независимого органа.
⌛️Производительность**
• ROS использует C++ или Python.
• Его архитектура - «загружаемая» (node‑spawn, dynamic linking), что может создавать лишнюю нагрузку.
❗️Проблема. **Для массового производства нужны «bare‑metal» решения, которые работают с минимальной задержкой и максимальной пропускной способностью.
🔬Тестируемость и диагностика**
• ROS даёт «лог‑сервисы», но они не стандартизированы, нет единого формата для отладки, а тесты пишутся «на лету».
❗️Проблема.** Разработчикам нужна единая модель диагностики (например, OPC UA Diagnostics), возможность автоматического восстановления, журналирование в стандартизованном формате.
🗜Интеграция с промышленным оборудованием**
• ROS может подключаться к PLC, контроллерам и датчикам, но для этого нужны собственные драйверы/интерфейсы.
❗️Проблема.** В реальном производстве часто требуются «out‑of‑the‑box» решения с поддержкой EtherCAT, EtherNet/IP, CANopen, Modbus/TCP и т.д.
⚙️Вывод**
Если вам нужно не только быстро прототипировать, но и гарантировать стабильную работу в промышленном процессе, стоит рассмотреть одно из альтернативных решений, либо комбинированный подход, где ROS/ROS 2 остаётся «интерфейсом», но реальное время и безопасность обеспечиваются более надёжными платформами.