Как собрать Physical AI-конвейер на манипуляторе за 30 тысяч рублей: ROS2, LeRobot и end-to-end imitation learning

Вокруг Physical AI сейчас много шума, но если отб��осить красивые слова, у большинства разработчиков до сих пор нет главного — воспроизводимого конвейера на реальном роботе, который можно поднять своими руками, покрутить, записать данные, обучить policy и вернуть её обратно в железо. Обычно всё рассыпается на отдельные куски: где-то есть teleop, где-то есть датасеты, где-то крутится ML-модель, но цельного ROS 2-native пути от демонстрации до execution почти не видно.

Именно поэтому проект SO-101 ROS Physical AI зацепил меня не как очередная «роборука с ИИ», а как честный инженерный стек. Это open-source ROS 2 stack для манипулятора SO-101(используется в проекте LeRobot), заточенный под end-to-end imitation learning на реальном железе: с bringup робота, ros2_control, leader/follower teleoperation, multi-camera support, записью эпизодов, ROS-to-Rerun визуализацией, конвертацией rosbag/MCAP в LeRobot dataset и запуском policy обратно через ROS 2.​

Важно и то, что здесь речь не про абстрактный research demo, а про довольно практичную архитектуру вокруг доступной руки. Сам SO-101 в публичных материалах вокруг экосистемы LeRobot фигурировал как low-cost arm, сейчас вы его можете найти на aliexpress.

В живую на эти манипуляторы вы можете посмотреть на хакатоне соревновании open-source/ROS2 роботов проводимом на ROS Meetup 20-22 марта.

Если вы занимаетесь или интрересуетесь темой робототехники или ИИ то приходите на ROS Meetup 20-22 марта послушать доклады или принять участие в практических воркшопах.

Что вообще делает этот проект

Если объяснять совсем просто, то проект решает не задачу «как управлять сервами», а задачу «как собрать полный конвейер для imitation learning на реальном манипуляторе». Логика такая: оператор показывает роботу примеры движений через leader/follower teleoperation, система пишет эпизоды в rosbag или MCAP, затем эти записи конвертируются в LeRobot dataset, после чего policy обучается и запускается обратно на том же роботе уже через ROS 2

На бытовом примере это можно представить так: вы хотите научить руку простому pick-and-place. Сначала человек несколько раз руками показывает нужное действие, затем проект превращает эти демонстрации в обучающие данные, а потом policy пытается воспроизвести задачу уже без участия оператора. По сути, оператор здесь выступает как «живой датасет-генератор», а ROS 2 — как скелет всей системы, который держит управление, наблюдения, запись, inference и обратную связь.

Вот почему ценность проекта — не в отдельной модели ACT, SmolVLA или какой-то ещё policy. Ценность именно в цельности pipeline: от data collection до execution, без разрыва между «робототехникой» и «машинным обучением».

Почему это интересно именно сейчас

Тема Physical AI и VLA сейчас сильно разогнана инфополем, но в большинстве обсуждений не хватает одного приземлённого вопроса: а как это повторить не в презентации, а у себя на столе или в лаборатории. SO-101 ROS Physical AI интересен тем, что показывает не слайды про будущее, а очень конкретную связку: low-cost arm, ROS 2-native архитектура, съём данных на реальном железе и возможность вынести тяжёлый inference на удалённый GPU через policy_server.

И вот эта часть про удалённые вычисления особенно важна. В проекте отдельно подчёркивается сценарий, где робот запускает ROS 2 client локально, а policy крутится на удалённом GPU-сервере; это нужно не только ради удобства, но и потому, что action-chunking policies и более тяжёлые модели логичнее исполнять вне маленького robot-side компьютера. Иными словами, здесь удалённый inference — не костыль, а взрослая архитектурная идея: робот остаётся рядом с пользователем, а «мозг» можно масштабировать независимо.​

Как это устроено внутри

Внутри проект можно мысленно разложить на семь слоёв. Снизу находится железо SO-101, выше — низкоуровневое управление через ros2_control, затем teleop и сбор демонстраций, после этого запись и визуализация, далее конвертация в LeRobot dataset, обучение policy и, наконец, execution через локальный или удалённый inference.​

1. Железо.
Базой выступает реальный манипулятор SO-101, а не симулятор. Это принципиально, потому что проект изначально задумывался как practical learning resource для работы с imitation learning на настоящем роботе.​

2. Низкоуровневое управление.
Управление завязано на ros2_control, причём в описании проекта отдельно упомянут hardware interface для Feetech STS3215. Это означает, что рука входит в стандартный для ROS 2 control graph и перестаёт быть набором «магических» Python-скриптов, жёстко пришитых к конкретной плате.

3. Teleop и сбор демонстраций.
Следующий слой — leader/follower teleoperation. Оператор ведёт одну руку или управляющий контур, а follower arm повторяет движения, формируя как раз те демонстрации, из которых потом рождается датасет для imitation learning.​

4. Запись и визуализация.
Во время показа эпизоды пишутся в rosbag или MCAP, параллельно проект умеет работать с несколькими камерами, а для просмотра observations, actions и camera streams используется ROS-to-Rerun визуализация. Это сильно повышает воспроизводимость: данные можно не только собрать, но и нормально проверить до обучения.

5. Конвертация в датасет.
После записи эпизоды конвертируются в формат LeRobot dataset. Это важный инженерный мост между ROS-миром и ML-миром, потому что вместо самодельного формата вы переходите в уже существующую экосистему LeRobot.

6. Обучение policy.
Дальше в игру входит LeRobot как ML-слой. В описании проекта прямо фигурируют ACT и SmolVLA, а удалённый inference заявлен для action-chunking policies, включая ACT, SmolVLA и 𝜋0/𝜋0.5

7. Execution / inference.
На последнем слое policy либо работает локально, либо обращается к внешнему policy_server, после чего вычисленные действия уходят обратно в ROS 2-контур робота. В результате получается не отдельный ML-эксперимент, а замкнутая цепочка «демонстрации -> датасет -> обучение -> действие на реальном манипуляторе».

Вот как общий поток данных можно объяснить совсем наглядно:

Эта схема отражает именно тот workflow, который автор проекта описывает как основной: teleop, запись эпизодов, конвертация в LeRobot, обучение policy и запуск её обратно на реальном роботе через ROS 2.

А runtime-контур inference выглядит ещё проще:

Здесь особенно круто то, что робот остаётся ROS 2-системой, а inference можно масштабировать отдельно. Для реальных проектов это куда ближе к нормальной инженерии, чем попытка впихнуть всё — и control loop, и тяжёлую policy — в один маленький компьютер возле руки.

Почему это важно
Этот проект показывает, что Physical AI начинается не с громкого названия модели, а с правильно собранного pipeline, где данные, управление и inference живут в одной воспроизводимой архитектуре.

Из каких модулей и ROS 2 сущностей это состоит

Инженерная карта системы

Если смотреть по смыслу, то в проекте есть как минимум восемь больших зон ответственности. Bringup поднимает реальную руку, ros2_control связывает железо с ROS 2, teleop — за данные, Rerun — за просмотр, LeRobot-конвертер — за dataset, policy client — за исполнение, а policy_server — за внешний вычислительный мозг.

Отдельно мне нравится, что автор явно не пытался спрятать «грязную» часть работы. В проекте важны не только policy demos, но и все промежуточные инженерные стыки: bringup, запись эпизодов, review MCAP, перенос в формат датасета и интеграция inference обратно в ROS 2.

Где здесь реальный engineering, а не хайп
Реальный engineering начинается там, где вы не просто запускаете модель, а можете воспроизвести весь путь: собрать данные, проверить их, обучить policy и встроить её обратно в работающий ROS 2 контур.​

Пошагово: как это повторить у себя

Ниже — практический roadmap, с которого реально можно начать.

Теперь коротко по шагам.

Сначала нужно добиться самого скучного, но самого важного результата: рука должна стабильно подниматься как обычное ROS 2-устройство. Пока у вас не работают bringup, чтение состояний и базовый control graph, никакой Physical AI не начинается.

Дальше запускается teleop. На этом этапе цель не «собрать красивое видео», а получить повторяемые и чистые демонстрации, из которых не стыдно строить датасет.​

Потом идёт запись эпизодов и их просмотр. Именно здесь чаще всего вскрывается реальность: камеры стоят не так, действия записываются рвано, синхронизация плохая, а человек-оператор показывает задачу непоследовательно.

После этого начинается переход из robotics в ML. Rosbag или MCAP нужно конвертировать в LeRobot dataset, и только потом уже имеет смысл трогать обучение ACT, SmolVLA или другой policy.

И только на последнем этапе включается inference. Причём если локального компьютера рядом с рукой не хватает, remote policy_server позволяет вынести вычисления на внешний GPU и оставить на стороне робота только policy client и исполнительный ROS 2 контур.​

Что особенно круто в remote policy server
Он отделяет robot-side runtime от тяжёлой policy, а значит позволяет экспериментировать с более серьёзными моделями без полного переписывания системы вокруг манипулятора.​

Почему это больше, чем игрушка

Самое интересное в этом проекте — не сама рука SO-101, а архитектурный паттерн. Автор прямо пишет, что стек задуман как practical reference для реализации похожих ROS 2 идей на других robot arms. И это очень важная оговорка: переносится прежде всего ROS2 software/data pipeline, а не обещание, что «любая большая рука сейчас мгновенно заработает на той же policy».​

Именно поэтому проект ценен как учебная и исследовательская площадка. На дешёвом манипуляторе можно отладить весь цикл — ros2_control, teleop, запись, визуализацию, датасет, обучение, remote inference — и только потом переносить эти идеи на более серьёзные системы, где уже отдельно решаются вопросы hardware integration, planning и safety.​

Кому это особенно зайдёт, тоже довольно очевидно. Во-первых, студентам и инженерам, которым нужен внятный вход в embodied AI без лабораторного бюджета; во-вторых, ROS 2 разработчикам, которым интересно, как состыковать классический control stack с learning-based policy; в-третьих, тем, кто слышал про VLA и imitation learning, но до сих пор видел только презентации и твиты, а не реальный pipeline на столе.

Если вам интересны манипуляторы, ROS 2, LLM/VLA и Physical AI не как buzzword, а как инженерная практика, такие темы лучше всего раскрываются не в вакууме, а в сообществе на конференции ROS Meetup 20-22 марта  — там, где можно разобрать launch-файлы, посмотреть чужие сетапы, поспорить про teleop, датасеты и inference latency, а потом руками что-то собрать и запустить. На ROS Meetup 20-22 марта будут доклады и воркшопы про манипуляторы, LLM, VLA и ROS 2, после прочтения этого проекта это уже не выглядит как «послушать модные слова», а как шанс разобраться в стеке, который сегодня реально формируется на стыке робототехники и ML.

На ROS Meetup будет хакатон-соревнование на ROS2 роботах, где разрешено использовать LeRobot и вычисления на внешнем компьютере. Описанный выше подход для вас превращается из статьи в практическую тактику: поднимать ROS 2-native контур, собирать демонстрации, быстро делать dataset, ��робовать remote inference и тестировать policy не в изоляции, а в живой соревновательной среде. И, возможно, это лучший аргумент в пользу таких проектов: они не только вдохновляют, но и дают понятный вход в практику, с которой уже можно прийти на митап как слушателем, так и участником.