Продакт роботов

Кажется, сейчас происходит очередной интересный обмен технологиями между геймдевом и робототехникой. (3/3)

На этот раз роботы забирают у игр не отдельный алгоритм и не движок, а целую индустрию работы с человеческим движением.

Игры и кино десятилетиями решали одну задачу: как записать движение человека и перенести его на персонажа с другими пропорциями и анатомией. Так появился привычный стек: motion capture → модель тела → перенос движения → обратная кинематика → физическая анимация.
Помню как в детстве залипал на видосы, как с помощью motion capture костюмов делали трюки в Pro Skater.

А потом пришли гуманоиды — и оказалось, что им нужно почти то же самое. Только теперь движение надо перенести не на персонажа, а на настоящего робота: с другой длиной ног, другой кинематикой, ограничениями суставов и приводов.

Сам перенос движения между скелетами — старая задача. Ещё в 1998 году Michael Gleicher показывал на SIGGRAPH, как адаптировать motion capture под персонажей с другими пропорциями. Сегодня похожие методы используются при подготовке данных для гуманоидов.

Появились и огромные библиотеки движений. Например, AMASS собрал в едином формате больше 40 часов motion capture: ходьба, бег, приседания, повороты и тысячи других движений. Роботу больше не обязательно с нуля «изобретать» человеческую походку — можно сначала показать, как двигаются люди.

Но просто проиграть записанные углы суставов нельзя. Виртуальный персонаж может немного нарушить физику — зритель этого даже не заметит. Робот в этот момент упадёт.

Поэтому следующий шаг — обучение движения в физическом симуляторе. Одна из ключевых работ здесь — DeepMimic 2018 года. Берём motion capture и через обучение с подкреплением учим персонажа не копировать траекторию кадр в кадр, а самому находить управляющие воздействия, которые дают похожее движение. В результате он сохраняет баланс, компенсирует ошибки и может восстановиться после толчка.

Позже появился AMP: вместо того чтобы вручную прописывать в функции награды, что значит «двигаться естественно», система учится этому по примерам движений.

А теперь открываем современные работы по гуманоидам — и видим ту же конструкцию. В HumanPlus движения людей переносят на модель гуманоидного робота, затем в симуляции обучают систему управления и только потом переносят её на реальное железо. В OmniH2O похожая цепочка дополняется управлением роботом через VR-шлем.

Современная фабрика данных для гуманоидов выглядит примерно так:

человек двигается → движение записывается → переносится на робота → робот учится воспроизводить его в физике.

Классно, что двадцать лет назад весь этот инструментарий был нужен, чтобы персонаж в игре красивее бегал. Сегодня на нём учат ходить настоящих роботов.

Пока меня нет в Москве, команда нашла мне замену. На фото — новый руководитель 🪰 — та самая муха.

Если пропустили: после истории про оцифрованную нервную систему дрозофилы интернет начал поручать ей всё подряд. Играть в Doom, торговать криптой, водить машину. В мемах она уже освоила все профессии. Теперь добралась до должности CEO робо-компании.

В целом кандидат сильный: умеет жужжать на встречах, потирать лапки при обсуждении бюджета. По ключевым компетенциям — полное совпадение.

Нужен ли роботу мизинец? Примотайте свой и проверьте.

Boston Dynamics выпустили видео про новые кисти Atlas. И как же мне нравится, что в этой команде работают настоящие нерды: Альберто Родригез рассказывает про них в рубашке с C-3PO. Носить любимого робота из «Звёздных войн» и параллельно создавать своего — прекрасно. У ярких рубашек здесь, кстати, богатая история: основатель Boston Dynamics Марк Райберт годами представлял роботов в своих фирменных гавайских рубашках.

У новой кисти четыре пальца и 13 степеней свободы. Она рассчитана на то, чтобы поворачивать предмет внутри захвата, перехватывать его и пользоваться инструментами: например, удерживать дрель и одновременно нажимать на курок.

Но больше всего мне понравилась история про отсутствующий пятый палец. Когда команда обсуждала, нужен ли мизинец, CTO Зак Яковски предложил примотать его к безымянному, провести так день и посмотреть, что не получится сделать. После эксперимента решили обойтись четырьмя: выигрыш в ловкости не оправдывал дополнительные приводы, габариты и сложность.

Вот это очень крутой продуктовый подход к исследованию нерешённой проблемы. Найти дешёвый способ буквально руками почувствовать, что теряешь без спорной функции. Такой эксперимент, конечно, не заменяет испытания робота, но помогает понять, какие ограничения вообще стоит проверять.

В какой момент GTA V стала инструментом разработки беспилотных автомобилей? (2/3)

Гораздо раньше, чем может показаться.

В середине 2010-х беспилотное вождение упёрлось в одну из главных проблем машинного обучения: нужны огромные датасеты, а покадровая разметка реальных дорог стоит дорого и плохо покрывает редкие сценарии.

И тут выяснилось, что игровая индустрия уже построила почти идеальный генератор данных: большие трёхмерные миры с дорогами, машинами, пешеходами, погодой и — главное — доступной эталонной разметкой.

В работе Playing for Data исследователи получили из коммерческой игры 25 тысяч кадров с попиксельной семантической разметкой. Причём без доступа к исходному коду игры — нужные данные восстанавливали, анализируя обмен между игрой и видеокартой.

Добавление таких синтетических данных улучшало качество семантической сегментации уже на реальных изображениях.

А дальше взялись непосредственно за GTA V.

В работе Princeton Beyond Grand Theft Auto V из игры получили более 480 тысяч размеченных кадров. На них учили сеть предсказывать не только объекты на сцене, но и параметры, важные непосредственно для вождения: положение машины в полосе, направление движения и дистанцию до автомобилей впереди.

То есть сначала игра стала источником обучающих данных.

Но есть пример ещё интереснее.

В Safe At Any Speed GTA V использовали уже как симулятор с замкнутым контуром. Настоящая система восприятия и управления получала изображение из игры, в реальном времени выдавала управляющие команды обратно, а исследователи искали сочетания погоды и дорожных условий, при которых алгоритм начинал вести себя опасно. Это уже фактически виртуальный полигон для беспилотника.

Следующий шаг — CARLA. Это уже не игра, а открытый симулятор для беспилотного вождения, построенный на Unreal Engine. В нём можно задавать набор сенсоров, трафик и сценарии, получать точную разметку и многократно воспроизводить один и тот же эпизод.

Для беспилотника это критично. Реальный мир очень неудобен для проверки редких и опасных сценариев.

Ситуацию «пешеход внезапно выбегает перед машиной» хочется прогнать тысячи раз, меняя скорость автомобиля, освещение, траекторию пешехода и задержки системы восприятия, а не воспроизводить вручную на полигоне.

С роботами происходит то же самое.

В Isaac Sim есть физика, камеры, лидары и инструменты генерации синтетических данных. Можно случайно менять освещение, материалы, положение объектов, параметры камер и даже физические свойства среды.

Это называется рандомизацией параметров среды: виртуальный мир специально делают немного разным в каждом запуске, чтобы модель не запоминала один идеальный симулятор, а училась работать с вариативностью.

По сути, привычный игровой редактор уровней превращается в генератор обучающих сценариев.

Похожая логика видна даже в стандартах описания мира.

OpenDRIVE описывает статическую дорожную сеть: полосы, перекрёстки, светофоры.

А OpenSCENARIO — то, что на этой дороге происходит: кто, когда и какое действие выполняет.

По сути, сначала мы описываем уровень, а затем — сценарий событий внутри него.

Но главное наследство геймдева даже не Unreal и не красивая графика.

Это возможность перезапускать мир.

В реальности робот упал — его надо поднять.
В симуляции — reset.

А когда тысячи таких виртуальных сред можно запускать параллельно на GPU, совсем по-другому начинает масштабироваться обучение с подкреплением.

Получается такая цепочка:

Игровой мир → виртуальный полигон → фабрика данных → среда обучения робота.

Сначала виртуальная сцена просто заменяет реальный мир. Потом в ней начинают гонять опасные и редкие сценарии. Дальше она же автоматически генерирует размеченные данные для обучения. А когда таких миров можно запускать тысячами параллельно, симулятор превращается уже в полноценную среду, где робот набирает опыт.

Кстати, удачно совпало: сегодня на онлайн-конференции Яндекса про образование выступает Валера Ильин — главный двигатель наших образовательных инициатив, создатель и идейный вдохновитель совместной программы со Сколтехом.

Послушать можно здесь: https://yace.yandex.ru/

Что общего между Tesla Optimus и Марио? (1/3)

На первый взгляд — примерно ничего.

Но если отбросить то, что одним управляет нейросеть, а другим игрок, задача удивительно похожая: есть тело в трёхмерном мире, нужно куда-то добраться, не врезаться в препятствия, взаимодействовать с объектами и другими агентами.

Поэтому история геймдева и робототехники последние полвека выглядит как постоянный обмен технологиями.

Начать можно с A*.

В конце 1960-х его разработали в SRI для Shakey — одного из первых мобильных роботов, способных самостоятельно строить планы и перемещаться по помещениям.

Идея A* довольно простая: выбирая, куда двигаться дальше, алгоритм учитывает не только уже пройденный путь, но и оценку того, сколько ещё осталось до цели.

Через пару десятилетий A* стал стандартом уже в game AI. Например, его использовали для навигации юнитов в оригинальном StarCraft.

Но у классического поиска по сетке есть забавная проблема. Если цель находится по диагонали, маршрут часто получается «ступеньками», хотя человек просто пошёл бы напрямую.

Так появился Theta* — родственник A*, который умеет проверять прямую видимость между точками и срезать лишние углы.

Причём Theta* сложно записать либо в «игровые», либо в «робототехнические» алгоритмы. Авторы сразу формулировали задачу для computer games и robotics, а тестировали алгоритм в том числе на картах Baldur’s Gate II.

Хороший символ всей этой истории: две индустрии независимо упираются в одну и ту же математику.

А дальше становится ещё интереснее.

Представьте StarCraft: десятки юнитов одновременно идут к своим целям. Если каждому просто построить кратчайший маршрут, они довольно быстро начнут блокировать друг друга в узких проходах.

В 2005 году David Silver описал Cooperative Pathfinding именно для RTS (Real Time Strategies).

Один из алгоритмов, WHCA*, планирует движение уже не просто по карте, а в пространстве-времени: условно, «в этой клетке в этот момент уже будет другой юнит».

Сегодня ровно такие задачи называются Multi-Agent Path Finding и возникают, например, при управлении флотом складских роботов.

И тут аналогия становится почти буквальной.

Современный RMS, управляющий сотнями AMR, сверху очень похож на стратегию: есть юниты с разными возможностями, есть очередь заданий, нужно решить, кому что отдать, построить маршруты, разрулить пробки и не допустить deadlock.

Ещё один хороший пример — Behavior Trees.

Пока у NPC три состояния — условно «стоять», «идти», «атаковать» — можно обойтись простой state machine.

Но когда персонаж умеет прятаться, садиться в машину, помогать союзнику, менять оружие и реагировать на десятки событий, граф переходов очень быстро превращается в лапшу.

В Halo 2 Behavior Trees стали одним из способов собирать сложное поведение из понятных иерархических блоков.

А теперь открываем ROS 2 Nav2 — и навигация реального робота оркестрируется по очень похожему принципу:

построить путь → ехать → проверить прогресс → если застрял, выполнить recovery → попробовать снова.

И иногда круг замыкается совсем красиво.

AI в F.E.A.R. прославился подходом GOAP — Goal-Oriented Action Planning. Вместо заранее прописанного сценария агенту задают цель и набор возможных действий, а последовательность он строит сам.

Но GOAP вырос из идей STRIPS (Stanford Research Institute Problem Solver) — классического планировщика, созданного десятилетиями раньше для того самого Shakey.

То есть буквально:

роботы → игры → роботы.

И это пока только planning.

Раз уж вспомнили «Матрёшку», нужно рассказать про неё чуть подробнее.

Мы начали работать над ней больше десяти лет назад, а первый публичный концепт показали в 2016 году.

Главная фишка «Матрёшки» была не в том, что мы научили автобус ездить без водителя.

Мы пытались понять, каким должен быть транспорт, если водителя в нём не было изначально.

В то время большинство беспилотников делали довольно очевидным способом: брали обычный автомобиль и автоматизировали то, что раньше делал человек. Руль, педали и традиционная компоновка оставались, сверху появлялись компьютеры и сенсоры.

Мы пошли с другой стороны. Если водителя нет — зачем водительское место? Зачем машине вообще иметь привычные «перед» и «зад»? И зачем строить отдельный беспилотник под каждую задачу?

Так появилась MatrЁshka — модульная электрическая платформа, изначально спроектированная как беспилотный автомобиль.

«Матрешка» разрабатывалась двумя командами:
- Элеткротранспортные
технологии (ЭТТ) – разрабатывали платформу,
- а моя команда из Visillect – ссенсорику, бортовой вычислитель и автопилот.

Полный привод, полноуправляемое шасси — поворачивались обе оси, поэтому четырёхметровая машина имела радиус разворота меньше 3 метров. Запас хода доходил до 130 км, а грузоподъёмность — до 1,3 тонны.

Причём электропривод был не готовым автомобильным решением. Его специально для проекта разрабатывала команда ЭТТ. Использовались два двигателя по 60 кВт, интегрированные в передний и задний силовые модули.

Но самое интересное было в архитектуре. По задумке «Матрёшка» была конструктором. По краям — силовые модули с приводами, рулевыми механизмами, электроникой и батареями. Посередине — сменный функциональный модуль.

Отсюда, собственно, и название — «Матрёшка».

Идея была в том, чтобы отделить дорогую роботизированную платформу от её полезной функции. Вместо трёх разных беспилотников — одна технологическая база под разные задачи.

Сегодня такой подход кажется знакомым. Но Toyota e-Palette и Mercedes Vision Urbanetic с очень похожей логикой показали только в 2018-м. При этом сама идея purpose-built беспилотника уже появлялась: Zoox с 2014 года проектировал роботакси с нуля, NAVYA в 2015-м выпустила ARMA, а почти одновременно с нами появился Local Motors Olli.

Была ещё одна довольно смелая ставка — computer vision.

Мы в Visillect делали беспилотный стек и хотели использовать камеры как основной сенсор восприятия и локализации, не строя машину вокруг дорогих лидаров. Тогда (да и сейчас) большинство автономных авто были буквально ими обвешаны.

Для нас это был прежде всего вопрос экономики: если беспилотник должен стать массовым продуктом, сенсорный комплект не может стоить как половина машины.

И всё это было не только концептом и красивыми рендерами — «Матрёшка» реально ездила.

Мы собрали около 10 машин, на которых обкатывали шасси и беспилотный стек. А в 2017 году для наших испытаний в московском технопарке «Калибр» выделили часть существующих дорог и оборудовали на них полигон.

В августе он официально открылся как первый в России открытый полигон для тестирования беспилотного транспорта.

Там была 400-метровая трасса: разметка по ГОСТу, знаки, пешеходные переходы, остановка, светофор и круговое движение.

Потом были Сколково, Сочи, катание всех желающих на дне города Москвы и много-много часов испытаний.

До массового продукта «Матрёшка» в итоге не дошла. У закзачика проекта закончилось финансирование. Сегодня я вижу десяток вещей, которые мы сделали бы совершенно иначе.

Но многие идеи — purpose-built конструкция, drive-by-wire, центральный компьютер, модульная платформа, computer vision, удалённая диспетчеризация — десять лет спустя выглядят удивительно современно.

Наверное, поэтому мне особенно нравится, что теперь одна из «Матрёшек» стоит в Музее Транспорта Москвы.

Это не просто старый беспилотный автобус. Это очень хорошо сохранившийся артефакт того, как мы десять лет назад представляли себе транспорт будущего.