Вокруг Physical AI сейчас много шума, но если отбросить красивые слова, у большинства разработчиков до сих пор нет главного — воспроизводимого конвейера на реальном роботе, который можно поднять своими руками, покрутить, записать данные, обучить policy и вернуть её обратно в железо. Обычно всё рассыпается на отдельные куски: где-то есть teleop, где-то есть датасеты, где-то крутится ML-модель, но цельного ROS 2-native пути от демонстрации до исполнения почти не видно.
Именно поэтому проект 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 сущностей это состоит
Инженерная карта системы
Компонент | Где лежит | Роль | Что публикует | Что подписывает | Когда запускается |
so101_bringup | launch, config | Bringup(скрипты запуска драйверов робота и программ) реального SO-101 и базовый runtime. | Joint states / robot state | HW interface / controller inputs | На старте системы |
so101_control | src, config | Интеграция с ros2_control и Feetech STS3215. | Состояния суставов | Команды контроллеров | После bringup |
so101_teleop | src, launch | Leader/follower teleoperation для сбора демонстраций. | Команды follower arm | Положение leader arm / input | Во время data collection |
so101_cameras | launch, config/ | Подъём multi-camera наблюдений. | image / camera_info | Драйверы камер | Во время записи и inference |
so101_recording | scripts, launch | Episode recording в rosbag/MCAP. | Bag/MCAP артефакты | Topic streams | Во время демонстраций |
so101_rerun | src,scripts | ROS-to-Rerun визуализация observations и actions. | Визуализационные потоки | Joint, action, image topics | Для проверки данных |
so101_lerobot_convert | scripts | Конвертация rosbag/MCAP в LeRobot dataset. | Dataset files | Rosbag/MCAP inputs | После записи эпизодов |
so101_policy_client | src, launch | Robot-side клиент policy inference. | Action commands | Observation topics | Во время автономного прогона |
policy_server | Отдельный сервис / модуль | Async remote inference для action-chunking policies. | Action chunks | Observation requests | При remote inference |
Если смотреть по смыслу, то в проекте есть как минимум восемь больших зон ответственности. 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, с которого реально можно начать.
Шаг | Что делаем | Результат | Типичная ошибка |
1 | Подготавливаем железо: SO-101, сервоприводы, питание, ПК с ROS 2. | Рука физически готова к запуску. | Недооценить питание и механическую калибровку |
2 | Клонируем репозиторий и ставим зависимости. | Workspace собирается без пропавших пакетов. | Пропустить системные зависимости или версии ROS 2 |
3 | Поднимаем bringup и ros2_control. | Видны состояния робота и живой control graph. | Путаница в портах, драйверах и конфиге серв |
4 | Запускаем teleop. | Follower arm повторяет движения оператора. | Плохая калибровка leader/follower контура |
5 | Пишем 5–10 демонстраций в rosbag/MCAP. | Появляются сырые эпизоды для обучения. | Записать мало данных или неудачные ракурсы камер |
6 | Проверяем визуализацию и корректность данных через Rerun. | Видно, что actions, observations и кадры синхронны. | Учить policy на кривых или неполных эпизодах |
7 | Конвертируем записи в LeRobot dataset. | Получаем dataset в формате LeRobot. | Несовпадение схемы данных и ожиданий конвертера |
8 | Обучаем policy в LeRobot. | Получаем чекпоинт policy. | Слишком мало демонстраций или слабый контроль качества |
9 | Подключаем local sync inference или remote policy_server. | Policy начинает выдавать действия в ROS 2 контур. | Задержки, несогласованный observation format |
10 | Прогоняем первую автономную задачу. | Робот выполняет learned behavior на реальном железе. | Сразу пытаться решать сложную задачу без постепенной отладки |
Теперь коротко по шагам.
Сн��чала нужно добиться самого скучного, но самого важного результата: рука должна стабильно подниматься как обычное 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 не в изоляции, а в живой соревновательной среде. И, возможно, это лучший аргумент в пользу таких проектов: они не только вдохновляют, но и дают понятный вход в практику, с которой уже можно прийти на митап как слушателем, так и участником.
