От «ROS рядом с проприетарными роботами» к «ROS внутри робота»: зачем промышленной робототехнике полная интеграция. Это особенно важно в связи с санкциями и импортозамещением, так как позволяет построить свою открытую-совместимую экосистему и стандарты на базе ROS2, от чего выиграют и российские производители роботов и интеграторы и заказчики и государство. Как бонус мы получаем бесплатное с открытым исходным кодом программное обеспечение написанное всем миром в виде ROS2 пакетов.
Промышленная робототехника долго строилась по понятной, но уже устаревающей схеме: робот работает на своём закрытом контроллере, а всё, что связано с современным программным стеком — визуализация, планирование движения, собственные алгоритмы, компьютерное зрение, ии, интеграция с внешними системами, — выносится на отдельный компьютер с ROS. Такая архитектура позволяла добавить гибкость, но делала систему сложной, громоздкой и зависимой от проприетарных интерфейсов.
Новая модель меняет саму логику построения робота. ROS больше не живёт «сбоку» от промышленной системы. Он становится её частью. В результате возникает не связка из нескольких разрозненных компонентов, а единый ROS-ориентированный промышленный робот, в котором вычисления, управление, интеграция и доступ к данным собраны в одной архитектуре.
Именно этот переход — от старого подхода к полностью интегрированной модели — и является сегодня одним из самых важных сдвигов в промышленной робототехнике.
Что такое ROS - короткий документ-презентация.
Основные термины:
ROS2 пакет - открытый исходный код который скачивается с открытого репозитория и компилируется на роботе. В интернете выложены тысячи ROS2 пакетов с разными алгоритмами под разных роботов, в основном все совместимо между собой так как используется стандартизированный формат сообщений ROS2 пересылаемый между ROS2 узлами.
ROS2 узел - отдельная одна программа в ROS2 пакете. Может быть написан на разных языках, например: С++, Python, Rust, Java итд.
Тип ROS2 сообщения - описывается текстовым файлов в виде структуры из переменных разных типов. Много стандартных сообщений. Можно создавать свои кастомные сообщения и выкладывать как ROS2 пакеты в публичные репозитории с открытым исходным кодом.
RMW (ROS Middleware) в ROS 2 - это транспортный уровень(протокол передачи данных), который обеспечивает взаимодейс��вие между ROS2 узлами и даже может коммуницировать не с ROS2 узлами. Пересылает данные между узлами как на одном компьютере так и между несколькими компьютерами. RMW можно менять, в основном используют DDS протокол - промышленный сертифицированный стандарт.
Moveit2 - ROS2 метапакет для манипуляторов, есть все от алгоритмов планирования и следования траектории, до зрения и визуализации состояния робота, пользовательского интерфейса управления роботом.
Navigation2 - ROS2 метапакет навигации для мобильных роботов.
ros2_control - это слой в ROS 2, который позволяет отделить “мозг” робота от его железа: сверху у тебя работают контроллеры и алгоритмы, а снизу — моторы, энкодеры, датчики и драйверы, и ros2_control делает так, чтобы всё это говорило на одном понятном интерфейсе. На практике это используют так: например, у мобильного робота ты подключаешь колёса и энкодеры, ставишь diff_drive_controller, и он по команде /cmd_vel сам считает, как крутить левое и правое колесо; у манипулятора подключаешь суставы, ставишь joint_trajectory_controller, и робот плавно едет по точкам траектории; у квадропода или промышленной руки поверх этого могут работать алгоритмы ПИД-регулирования, интерполяции траектории, ограничения скорости/ускорения, импеданс-контроль, forward/inverse kinematics и planners вроде MoveIt. То есть если совсем просто: ros2_control нужен, чтобы ты не писал вручную логику “считать датчики → вычислить управление → отправить команды в моторы” для каждого нового робота, а собирал систему из готовых контроллеров и менял железо без переписывания всей управляющей части.
RVIZ2 - визуализация состояния робота и данных с сенсоров, камер, лидаров в 3D.
На эти мысли и написание этой статьи окончательно повлияли просмотренные доклады с последних конференций по робототехнике ROSCON и ROS Industrial:
Промышленная робототехника в процессе перемен: ROS — важный элемент открытых систем - статья написана в основном из этого доклада
Что требуется промышленной автоматизации от ROS — Siemens AG
KUKA RSI Driver: техника для надежного управления промышленными роботами в режиме реального времени — новый KUKA ROS драйвер
Поддержка ROS в манипуляторе UR: взгляд со стороны поставщика — Universal Robots
Запуск ROS нативно на блоке управления промышленного робота Universal Robots
ROS2 на роботах Yaskawa и его приложениях
ROS2 переходит в промышленное производство - ros2_control
Старый подход: ROS как внешняя надстройка
В классической схеме архитектура выглядит так: слева находится отдельный IPC с ROS, на котором запускаются RViz, MoveIt2, пользовательские ноды и другие программные компоненты. Справа — собственно промышленный робот с отдельным контроллером и приводами. Между ними — связующий слой в виде UDP/IP, EtherCAT или другого канала, но ключевая проблема в том, что доступ к роботу обычно идёт через проприетарный streaming interface.
На практике это означает следующее.
ROS-приложение не управляет роботом напрямую как естественной частью системы. Оно вынуждено «договариваться» с отдельным контроллером производителя через специальный интерфейс. Более того, сама система уже изначально раздвоена: есть мир ROS и есть мир промышленного контроллера. А значит, есть и граница между ними, которую приходится постоянно обслуживать.
Это создаёт сразу несколько ограничений.
Во-первых, появляется дополнительный уровень интеграции. Любая функция — от движения до обмена данными — должна проходить через прослойку между ROS и штатным контроллером.
Во-вторых, система становится сложнее физически и логически. Вместо одной платформы нужно поддерживать как минимум два вычислительных контура: ROS IPC и робот-контроллер.
В-третьих, возникает зависимость от проприетарного интерфейса производителя. Насколько глубоко можно управлять роботом, насколько быстро получать данные, какие команды доступны, как обрабатываются ошибки — всё это определяется не архитектурой ROS, а ограничениями закрытого канала интеграции.
В-четвёртых, усложняется развитие системы. Каждый новый модуль, каждая новая функция, каждое нестандартное применение требует учитывать не только логику приложения, но и ограничения между двумя мирами.
Иными словами, в старой модели ROS может быть очень мощным инструментом, но он остаётся внешним инструментом. Он помогает роботу, но не является его естественной основой.
В чём главная проблема legacy-архитектуры
На первый взгляд старая схема кажется рабочей: ROS-компоненты запущены, визуализация есть, планировщик есть, робот двигается. Но с инженерной точки зрения у неё есть системный недостаток: архитектура собрана из частей, а не задумана как единое целое.
Когда ROS вынесен на внешний компьютер, а промышленная логика живёт в отдельном контроллере, проект получает не просто распределённую систему, а набор постоянных компромиссов:
где заканчивается ответственность ROS и начинается ответственность контроллера;
какие данные доступны в реальном времени, а какие только через обходные механизмы;
как синхронизировать состояние системы;
как обновлять программный стек;
как отлаживать сбои;
как масштабировать решение на другие роботы и ячейки.
В лаборатории или пилотном проекте такая архитектура ещё терпима. Но в промышленной эксплуатации именно она начинает становиться источником лишних затрат, задержек и ограничений.
Новая модель: ROS как ядро робот-контроллера
Во второй архитектуре логика меняется принципиально. Отдельный классический робот-контроллер исчезает как внешний обязательный элемент. Вместо него появляется ROS Robot Controller, который напрямую связан с приводами и является центральной точкой системы.
Это не просто косметическое изменение схемы. Это переход от идеи «подключить ROS к роботу» к идее «построить робота вокруг ROS».
В новой модели:
ROS-инструменты и пользовательские ноды больше не существуют отдельно от контроллера;
не нужен отдельный проприетарный streaming-интерфейс к робот-контроллеру;
не нужен дополнительный внешний робот-контроллер как обязательная промежуточная сущность;
архитектура становится цельной: управление, интеграция, приложения и доступ к данным собираются в одном контуре.
Safety модуль единый и гибко настраиваемый.
На слайде эта идея выражена очень наглядно: старый контроллер перечёркнут, а вместо него остаётся единый ROS-ориентированный контроллер, напрямую работающий с приводами. Подчёркнуты три ключевых преимущества: полная интеграция в одном robot controller, отсутствие проприетарного streaming interface, отсутствие необходимости в дополнительном robot controller.
Именно здесь рождается главный выигрыш новой модели.
Почему полная интеграция ROS меняет экономику и инженерную логику проекта
Преимущество полностью ROS-ориентированного промышленного робота не сводится к тому, что «так современнее». Его смысл в том, что архитектура становится проще и при этом функциональнее.
1. Меньше слоёв — меньше сложности
Когда ROS живёт внутри робот-контроллера, исчезает отдельная прослойка между программной логикой и машиной. Это означает меньше точек отказа, меньше интеграционных швов, меньше мест, где данные могут теряться, задерживаться или искажаться.
Проще говоря, система перестаёт быть конструктором из двух миров. Она становится одним миром.
2. Нет зависимости от закрытого streaming-интерфейса
В старой архитектуре возможности ROS всегда ограничены тем, как именно производитель открыл доступ к роботу. Если интерфейс бедный, медленный или неудобный, страдает вся система.
В полностью интегрированной модели ROS не «просит доступ» к роботу через внешний канал. Он уже является частью управляющей платформы. А значит, разработчик получает более прямой и естественный доступ к функциям системы.
Это резко повышает свободу разработки и снижает зависимость от вендорских ограничений.
3. Быстрее внедрять собственные алгоритмы
Если робот построен вокруг ROS, тогда MoveIt2, зрение, собственные программы-ноды, логика координации, цифровые двойники, аналитика, веб-интерфейсы и другие компоненты перестают быть внешними дополнениями. Они становятся естественным расширением системы.
Это особенно важно для тех предприятий, которым недостаточно типового набора функций. Как только робот должен выполнять нестандартную задачу, интегрироваться с компьютерным зрением, адаптироваться к изменяющейся среде или координироваться с другими машинами, полностью ROS-ориентированная архитектура начинает давать реальное преимущество.
4. Проще сопровождение и развитие
Отдельный IPC, отдельный контроллер, отдельные интерфейсы, отдельная логика интеграции — всё это делает эксплуатацию дороже. Нужно обновлять больше компонентов, поддерживать больше связей, разбираться в большем количестве источников сбоев.
Единая архитектура проще для поддержки. В ней легче отслеживать состояние системы, обновлять программный стек, тестировать новые версии и переносить решение на другие установки.
5. Естественная масштабируемость
Полная интеграция ROS особенно выгодна там, где робот — это не одиночная машина, а часть более крупной системы. В современных производственных ячейках робот должен взаимодействовать с сенсорами, визуализацией, системами качества, логистикой, другими роботами и внешними сервисами.
Когда робот изначально построен как ROS-ориентированная платформа, он проще включается в такие сценарии. Не через набор адаптеров и костылей, а на уровне базовой архитектуры.
Что в итоге получает заказчик
сли смотреть на вопрос не глазами разработчика, а глазами предприятия, выгода полностью ROS-ориентированного промышленного робота становится ещё понятнее.
Заказчик получает не просто манипулятор с набором базовых функций, а расширяемую программную платформу, которая:
легче интегрируется в существующее производство;
быстрее адаптируется под новую задачу;
лучше подходит для внедрения интеллектуальных функций;
меньше зависит от закрытых интерфейсов поставщика;
потенциально проще и дешевле в сопровождении на жизненном цикле.
То есть ценность смещается с «мы купили робот и теперь подстраиваемся под его ограничения» к «мы получили робототехническую платформу, которую можно развивать вместе с производством».
Почему это особенно важно именно сейчас
Современный промышленный робот всё реже выполняет одну фиксированную операцию в неизменной среде. От него ждут гибкости, быстрого переналадочного цикла, работы с данными, интеграции с ИТ-системами, поддержки новых приложений и постоянного программного развития.
В такой реальности старая схема, где ROS вынесен на внешний компьютер и общается с роботом через закрытый интерфейс, начинает тормозить развитие.
Новая модель, напротив, соответствует логике современной автоматизации: робот — это не закрытый аппаратный остров, а открытая, программно определяемая система.
И именно поэтому полная интеграция ROS — это не просто удобство для инженеров. Это шаг к другой промышленной модели, где робота можно быстрее внедрять, глубже интегрировать и дольше развивать без архитектурных тупиков.
Вывод
ROS как основа нового промышленного робота
Промышленная робототехника долго строилась по простой, но жесткой схеме: у робота есть собственный проприетарный контроллер, у интегратора — отдельный компьютер с ROS, а между ними работает специальный интерфейс, чаще всего закрытый и зависящий от производителя. Такая архитектура позволяла подключать современные программные инструменты к промышленному оборудованию, но делала это ценой дополнительной сложности, лишних компонентов и постоянной зависимости от проприетарных решений.
Предлагают перестать воспринимать ROS как внешнюю надстройку рядом с роботом и начать строить промышленного робота так, чтобы ROS был встроен в его архитектуру изначально.
В старом подходе рядом со штатным robot controller появляется отдельный ROS IPC. Он должен обмениваться данными с контроллером по специальному streaming-интерфейсу, а инженер вынужден поддерживать еще один компьютер, его операционную систему, безопасность, обновления и совместимость со всей остальной системой. Более того, при работе с разными роботами приходится каждый раз заново разбираться с новыми интерфейсами и ограничениями конкретного производителя.
Новый подход выглядит иначе. Вместо двух миров — промышленного контроллера и внешнего ROS-компьютера — появляется единая платформа, в которой robot control и ROS-интеграция объединены в одном устройстве. Это значит, что больше не нужен отдельный промежуточный controller, а связь с приводами может строиться через стандартные полевые шины, например EtherCAT, без опоры на закрытые проприетарные streaming-механизмы.
На первый взгляд это просто архитектурное упрощение, но на деле речь идет о качественно другой модели роботизации. Когда ROS встроен в саму систему управления, разработчик получает доступ к визуализации, планированию движения, драйверной экосистеме и собственным приложениям без постоянной борьбы с чужим закрытым стеком. А предприятие получает робота, которого легче внедрять, ��бслуживать и развивать после запуска.
Преимущество такого подхода особенно заметно в реальной промышленной среде. Современный робот должен не только выполнять движения, но и обеспечивать обмен данными, поддержку пользовательских интерфейсов, обновления ПО, device management, безопасность эксплуатации и защиту от киберугроз. В старой архитектуре все это распределено по разным слоям и системам, а в новой собирается в единую промышленную платформу.
Важно и то, что это не противопоставление ROS промышленным требованиям. Наоборот, это подчеркивает, что ценность полной интеграции в том и состоит, чтобы совместить открытость ROS с реальным временем, сертифицируемым оборудованием, PLC-логикой, safety и security. Иными словами, речь идет не о «роботе для лаборатории», а о промышленном продукте, который использует открытые программные принципы без отказа от требований производства.
Для разработчика полностью ROS-ориентированный робот означает свободу: меньше закрытых прослоек, меньше ручной интеграции, быстрее внедрение собственных алгоритмов и сервисов. Для интегратора — это сокращение числа компонентов и снижение зависимости от вендорских интерфейсов. Для заказчика — это робот, ценность которого не заканчивается в момент поставки, потому что его можно обновлять, расширять и встраивать в более широкую цифровую инфраструктуру предприятия.
Главная выгода полностью ROS-ориентированного промышленного робота в том, что он сочетает промышленное управление с открытой программной экосистемой не через компромисс, а в рамках одной платформы.
Именно это делает его не ��росто «роботом с поддержкой ROS», а роботом нового поколения, который изначально создан для интеграции, расширения и развития.
Российское сообщество робототехников ROS общается в телеграм: ROS чат, ROS канал, ROS Industrial канал. В MAX: чат, канал, промышленный канал.
Совсем скоро 20-22 марта состоиться конференция по робототехнике ROS Meetup(бесплатная), на которой будет выделенный день по промышленной и сервисной робототехнике, на нем будут доклады от бизнеса и дискуссия на тему стандартов промышленной робототехники, поэтому если тебе эта тема интересна то регистрируйся и приходи.
В заключение хотелось бы сказать, что наша страна сейчас находится в сложном положении с точки зрения санкций западных производителей роботов и задач по уровню роботизации который поставил президент. И именно ROS2 это то что позволит в кратчайшие сроки выполнить необходимый уровень роботизации, так как это открытые технологии которые позволяют быстро разрабатывать и управлять сложными роботами.
