Что такое Microduck и зачем ему Isaac Lab
Microduck - недорогой открытый двуногий робот от Pollen Robotics и Hugging Face. Политику ходьбы для него обучают в Isaac Lab, открытом фреймворке NVIDIA, который запускает тысячи параллельных симуляций на GPU. Дальше политика экспортируется в ONNX и переносится на физического робота; в опубликованном разборе NVIDIA описан именно этот маршрут: симуляция, обучение, экспорт и деплой.
Смысл связки простой. Учить робота ходить на реальном железе долго, дорого и рискованно: неудачный эпизод заканчивается падением, ремонтом и простоем. В симуляции можно прогнать миллионы эпизодов, менять условия и не бояться сломать приводы. Isaac Lab берёт на себя параллельный запуск сред, а Newton отвечает за физику. Для проекта такого масштаба это критично: скорость обучения зависит от числа шагов среды в секунду, а не от размера нейросети.
Интерфейс политики в готовой среде компактный: 61 значение наблюдений на входе и 14 целевых позиций суставов на выходе. Это не гуманоид с десятками степеней свободы и не визуальная модель на миллиард параметров. Компактная MLP-политика быстрее обучается и легче переносится на борт, где нет мощной GPU.
Кто стоит за Microduck: Pollen Robotics и Hugging Face
Microduck - совместный проект Pollen Robotics и Hugging Face. Обе компании указываются как соразработчики открытого двуногого робота. Открытость и невысокая стоимость заявлены как свойства проекта; конкретную цену и спецификацию железа в доступном фрагменте блога NVIDIA не приводят, поэтому не стоит подставлять цифры по памяти.
Для обучения это даёт готовую модель в Isaac Lab: среда уже содержит модель робота, сцену, наблюдения, действия, награды и доменную рандомизацию. Стартовать можно не с чистого листа, а с конфигурации, которую остаётся запустить и адаптировать. Это не гарантирует, что железо поведёт себя так же, как модель, но убирает этап сборки сцены с нуля.
Почему Isaac Lab, а не «свой велосипед»
Собрать свой стенд можно, но придётся вручную связать физику, сенсоры, награды, рандомизацию, векторизацию сред и логирование. Isaac Lab уже даёт эти блоки и запускает среды параллельно на GPU. Главный аргумент - масштаб: тысячи симуляций одновременно дают политике больше опыта за то же время.
Для локомоции это важнее, чем архитектура сети. Политика на 61 вход и 14 выходов маленькая, а опыт нужен большой: шаги, падения, восстановления баланса, разные поверхности. Чем больше параллельных сред, тем быстрее набирается статистика, и тем меньше времени уходит на одну итерацию обучения.
Зачем обучать ходьбу в симуляции и как работает перенос sim-to-real
Политика, обученная в идеальной симуляции, быстро разваливается на реальном роботе. Причины прозаичные: трение в редукторах, задержки в контуре управления, механический люфт сервоприводов. В материале NVIDIA отмечено, что политика ходьбы должна справляться с трением, задержками и механическим люфтом реальных сервоприводов. Симуляция с идеальными приводами такой опыт не даёт.
Sim-to-real держится на наборе допусков. Вместо одной фиксированной среды политику учат на распределении сред: масса звеньев, трение, инерция, напряжение батареи и задержки управления меняются от эпизода к эпизоду. Политика видит не идеальный мир, а семейство правдоподобных миров и учится восстанавливать баланс при сдвиге параметров. Это снижает вероятность провала на железе, но не отменяет финальную доводку на реальном роботе.
Доменная рандомизация: какие параметры варьируются и почему
Для шагающего робота имеет смысл варьировать несколько групп параметров. Конкретные диапазоны в доступном фрагменте блога NVIDIA не раскрыты, их нужно смотреть в конфигурации среды и полной публикации.
- Масса звеньев. Меняет инерцию и нагрузку на суставы; политика не должна рассчитывать на один вес корпуса.
- Трение. Влияет на скольжение стопы и усилие, нужное для шага.
- Инерция. Определяет, как быстро робот разгоняется и тормозит.
- Напряжение батареи. По мере разряда падает доступный момент, и та же команда даёт другой результат.
- Задержки управления. Команда приходит на привод с запозданием; политика должна быть устойчива к рассинхрону.
Подставлять значения из головы бессмысленно: они зависят от конкретного робота, сервоприводов и стенда. Рандомизация помогает только тогда, когда распределение похоже на реальность. Слишком узкий разброс не готовит к железу, слишком широкий делает обучение хаотичным.
Моделирование сервоприводов: BAM и люфт (backlash)
Backlash - механический люфт в редукторе. Команда на сустав не совпадает с фактическим положением, особенно при смене направления движения. На реальном роботе этот люфт есть всегда, а в простой симуляции его может не быть. Политика, которая выучила идеальную связь команды и угла, на железе начинает раскачиваться или терять устойчивость.
В описании воркфлоу фигурирует модель сервопривода BAM. Она нужна, чтобы приблизить поведение привода к реальному: с ограничениями, задержками и люфтом. В доступном фрагменте блога NVIDIA детали реализации BAM не раскрыты, поэтому воспринимайте это как ориентир для чтения полной документации, а не как готовый рецепт с точными коэффициентами.
Пайплайн по шагам: от установки Isaac Lab до деплоя через robotctl
Маршрут выглядит так: подготовить окружение, выбрать среду, обучить политику, оценить её в симуляторе, экспортировать в ONNX и развернуть через robotctl. Для симуляции и обучения нужна Linux-станция с поддерживаемой GPU NVIDIA и драйвером, Git и uv. Для деплоя нужен настроенный физический Microduck с работающим бортовым ПО и поддерживаемый интерфейс управления, например спаренный геймпад. Оригинальный воркфлоу NVIDIA перечисляет эти требования явно.
Установка Isaac Lab на Linux с GPU NVIDIA
Установка Isaac Lab на Linux - скучный этап, на котором чаще всего ломается воспроизводимость. Порядок из материала:
- Установить uv.
- Клонировать репозиторий Isaac Lab, ветку develop.
- Выполнить
uv sync, чтобы подтянуть зависимости. - Проверить, что задачи Microduck видны:
uv run isaaclab list_envs --keyword MicroDuck --show_presets.
Если команда не находит среды, дальше идти нет смысла: проблема в драйвере, ветке репозитория или зависимостях. Точные версии пакетов в доступном фрагменте не указаны, поэтому ориентируйтесь на актуальную документацию Isaac Lab, а не на случайные комбинации из чатов.
Выбор среды: ровная поверхность и rough-вариант
Начинать стоит с задачи ходьбы по ровной поверхности. Rough-вариант добавляет лестницы, склоны и неровную местность; он нужен, когда базовая политика уже сходится и вы понимаете, как оценивать падения и восстановление баланса. Первый запуск на rough-среде может маскировать обычные ошибки в наградах и наблюдениях: политика падает, а причина не в сложной местности.
Практическая последовательность простая: сначала стабильная ходьба по плоскости, затем оценка на усложнённой геометрии. Переход к rough-среде без базовой метрики превращает обучение в угадывание.
Обучение: параллельные GPU-симуляции и распределённый запуск
Обучение локомоции в Isaac Lab ускоряется параллельными средами на GPU. В описании воркфлоу фигурируют до 4096 сред одновременно и до 1,25 млн шагов в секунду при распределённом обучении; Isaac Lab поддерживает запуск на нескольких GPU, включая пример с 16 GPU для ускорения тренировки. В доступном фрагменте блога NVIDIA эти цифры не приведены, так что проверяйте их в полной публикации и конфигурациях. Ориентир полезный, но не гарантия для вашей станции.
Главный рычаг здесь - масштаб сред, а не размер модели. Политика на 61 вход и 14 выходов компактная; время уходит на физику и сбор опыта. Похожий эффект от GPU-физики виден в эксперименте с LIBERO на MuJoCo Warp: там физика выдала 17 137 шагов среды в секунду против 38 на CPU, хотя это другой стек и другая задача. Вывод общий: параллельные среды меняют скорость итераций, а не сводятся к удобству.
Экспорт в ONNX и деплой через robotctl
После обучения политику оценивают в симуляторе. Если метрики устраивают, её экспортируют в ONNX. На этом шаге легко сломать перенос: при экспорте и развёртывании нужно сохранять порядок наблюдений, нормализацию и масштабирование действий. Политика формально загрузится, но робот будет вести себя неадекватно, если входные векторы перепутаны или действия отмасштабированы не так, как при обучении.
Деплой идёт через robotctl. На реальном Microduck должно быть установлено и работать бортовое ПО, а управление удобно проверять через поддерживаемый интерфейс, например спаренный геймпад. Первый запуск на железе стоит делать с ограниченной амплитудой и готовностью быстро снять питание: симуляция не отменяет физические риски.
Проверка и публикация политики: Hugging Face Hub и Microduck Arena
После экспорта политику можно опубликовать на Hugging Face Hub, проверить на совместимость и посоревноваться в Microduck Arena, а затем запустить на собственном Microduck. Это описано в материале NVIDIA. Практическая ценность внешней проверки в том, что она даёт обратную связь без своего железа: политика проходит фиксированный интерфейс, и ошибки формата всплывают до деплоя.
Ограничения Microduck Arena: интерфейс и лимит 64 МиБ
По описанию воркфлоу, Arena фиксирует интерфейс политики: 61 наблюдение на входе и 14 целевых позиций суставов на выходе. Там же указан лимит размера модели 64 МиБ. В доступном фрагменте блога NVIDIA эти параметры не подтверждены, поэтому перед загрузкой сверяйтесь с правилами площадки. Если лимит действительно такой, компактная MLP-политика проходит легко, а тяжёлый визуальный энкодер может не влезть.
Отсюда практическое следствие: восприятие через камеру глубины для Arena придётся ужимать. Квантизация, дистилляция или отдельный компактный энкодер становятся условием участия. Для базовой ходьбы это не проблема: 61 вход и 14 выходов оставляют большой запас по размеру.
Ограничения подхода: где sim-to-real ломается
Симуляция снижает риск, но не даёт гарантию. Список ограничений стоит держать перед глазами до того, как вы потратите недели на обучение.
- Доменная рандомизация не устраняет разрыв. Она делает политику устойчивее к вариациям, но не покрывает все эффекты реального железа.
- Backlash и задержки моделируются приближённо. Реальный износ редуктора, температура, люфт после нагрузки и проскальзывание стопы могут отличаться от симуляции.
- Модель робота не равна конкретному экземпляру. Партии сервоприводов, сборка и калибровка дают разброс; политика, обученная на одном распределении, может требовать подстройки на другом роботе.
- Arena ограничивает интерфейс и размер модели. По описанию воркфлоу, это 61 вход, 14 выходов и 64 МиБ; параметры нужно проверять в правилах, но архитектуру они задают заранее.
- Нужна Linux-станция с GPU NVIDIA. Ноутбук без подходящей GPU и драйвера не подходит для нормального обучения; распределённый запуск требует нескольких GPU.
- Часть деталей в доступном фрагменте не раскрыта. Конкретные диапазоны рандомизации, реализация BAM, точные цифры 4096 сред и 1,25 млн шагов в секунду, лимит 64 МиБ стоит сверять с полной публикацией и конфигами. Это не повод игнорировать подход, но повод не принимать маркетинговые цифры на веру.
Отдельно про ожидания: «работает из коробки» здесь не работает. Пайплайн воспроизводим, но требует настройки окружения, понимания наград и готовности к итерациям на железе.
Куда масштабировать: пересечённая местность, зрение и манипуляция
Базовая ходьба по ровной поверхности - только первый уровень. Дальше есть три направления, и каждое меняет пайплайн.
Пересечённая местность. Rough-вариант среды уже добавляет лестницы, склоны и неровную местность. Для обучения это означает более сложные эпизоды и более строгие критерии восстановления баланса. Политике нужно чаще менять походку и компенсировать сдвиг опоры; награды за скорость придётся уравновешивать штрафами за падения и проскальзывание.
Восприятие через камеру глубины. К сигналам с суставов добавляется карта глубины. Это расширяет наблюдения и требует энкодера, а значит, растёт размер модели и задержка. Для Arena с лимитом 64 МиБ такой энкодер придётся ужимать. На реальном роботе добавляется визуальный разрыв: освещение, текстуры, блики и шум сенсора. Симуляция должна покрывать и эти вариации, иначе политика будет уверенно шагать в идеальном рендере и теряться в коридоре.
Манипуляция в Isaac Lab 3.0. Это отдельный класс задач: объекты, контакты, захваты и награды за положение. Для Microduck как двуногого без манипулятора направление потребует другой модели робота или дополнительных степеней свободы. Переносить политику ходьбы на манипуляцию без пересборки наблюдений и действий не получится.
Новые примеры и конфигурации удобно отслеживать через Daily Papers на Hugging Face: там видно, какие статьи и репозитории появляются по теме, но проверять код и цифры всё равно придётся самостоятельно.
Кому это подходит и с чего начать
Подход имеет смысл для технических специалистов с Linux и GPU NVIDIA, которые уже знакомы с обучением с подкреплением или готовы разобраться. Он подойдёт командам, которые делают открытую робототехнику, исследователям локомоции и энтузиастам с доступом к Microduck или его симуляционной модели. Если нужен результат без настройки окружения, без чтения конфигов и без итераций на железе, это не тот путь.
Первый шаг конкретный: поставить Isaac Lab на Linux, проверить наличие задач Microduck командой uv run isaaclab list_envs --keyword MicroDuck --show_presets и запустить обучение на ровной поверхности. Дальше - оценка в симуляторе, экспорт в ONNX, проверка в Arena или на своём роботе. Если робота нет, начните с симуляции и публикации политики: это дешевле, чем покупать железо до того, как вы разобрались с пайплайном.
Главный вывод без магии: Microduck и Isaac Lab дают воспроизводимый маршрут от симуляции до железа, но успех зависит от качества доменной рандомизации, аккуратности экспорта и готовности доводить политику на реальном роботе. Начните с одной среды, одного сида и понятной метрики, а расширяйте сценарий после того, как базовая ходьба станет стабильной.