Comments 42
Интересные эксперименты. Продолжай в том же духе.
Отличная серия статей намечается, буду следить! :-) Ваша оценка, например, чтобы обучить робособаку не глядя под ноги ходить по лестнице таким способом - насколько это трудо- и ресурсоёмко и насколько это лучше или хуже чисто алгоритмического кодирования поведения? В сравнении с вашими вошиками - во сколько раз будет сложнее обучение робособаки и во сколько раз больше потребует вычислительных ресурсов?
Я где-то даже видел модель такой собаки для MuJoCo, так что это точно возможно. Это будет безусловно дольше и тяжелее - при переносе из симулированной среды в реальность нужно принимать дополнительные меры, потому что симуляторы не повторяют реальностью в точности.
Например, используется рандомизация среды - в каждой инстанции меняются физические параметры симулируемой системы, например - коэффициенты трения, варьируются массы и моменты инерций компонентов и т.п. Таким образом сеть обучается адаптироваться к незнакомой ей среде, и при переносе "в железо" воспринимает ее как еще одну вариацию симуляции.
Многое будет зависеть от того, что идет вашей сетке на вход. В моей среде можно обойтись относительно небольшим вектором флоатов. Если вам нужно, чтобы робот ориентировался по картинке, то это дополнительно добавит вычислительной сложности и на генерацию этих картинок при обучении и на обучение сети.
нет нет, ориентироваться по картинке - это отдельная вселенная. хотя бы просто вслепую ходить. четвероноги в принципе могут наступать не глядя.
Ну и интересно - что эффективнее - учить или алгоритмически запрограммировать. Это любой локомоции касается. Роборыбу, например, - проще запрограммировать, или пустить плавать и ждать когда сама научится?
Честно говоря, мне кажется вариант с реализацией "вручную" сейчас не имеет смысла рассматривать. А как вы себе это представляете?
ИМХО для роботов с малым числом степеней свободы проще алгоритмический вариант. Чем больше степеней свободы - тем больше смысла использовать обучение с подкреплением. Пример - пушка (или пинг-понг робот), которая сама рассчитывает поправки и стреляет в цель - нет смысла её учить, 1-2 степени свободы, проще рассчитать поправки и навести куда надо. Парусник, идущий против ветра в точку назначения - 2 степени свободы (парус и руль) - проще рассчитать нужные углы, чем учить. Роборыба - одна степень свободы - движение хвоста - проще рассчитать как махать, чем учить. Робособака с руками и колёсами на ногах - 12+N+4 степеней свободы - умаешься писать алгоритмы. Но Boston Dynamics их писала.
Сети - адаптивны. Можно один раз обучить сеть с рандомизацией среды, и она будет работать при разных значения силы трения, при разных массах той же пушки. Не придется крутить какие-нибудь коэффициенты ПИД-регулятора каждый раз, как на нее присядет птичка. Те же пинг-понг роботы давно уже работают под управлением нейросетей.
Писали ли в Бостон Динамикс алгоритмы руками - не знаю, может быть, но у меня нет такой информации. То есть, до какого-то момента, наверно писали. Но как только сети предоставили возможность этого не делать, в основном стали переходить на них. Например те же робо-собаки теперь вполне реализуемы с куда более скромными ресурсами, чем у BD. Кстати, есть MIT Dog, он точно на нейросетевом управлении.
Впрочем, вы всегда можете продемонстрировать мощь алгоритмов на арене, мои нейросетевые агенты ждут противников)
Кстати, должен заметить, что дело не только в степенях свободы, а еще и в размерности входных данных (наблюдений). Может быть две степени свободы, но если на входе картинка, вам придется писать распознавание образов. У моих моделек на арене 8 управляющих сигналов, но на вход им идет вектор размерности 72.
Уважаемый автор, для битв на арене пришла в голову мысль о повторении игры "Terrarium" от Майкрософт. Суть была в том, что на компьютере пользователя запускался клиент, который загружал код для животных с центрального сервера, и эти животные начинали свою жизнь на "арене". Были травоядные и хищники. Код животных нужно было писать самостоятельно, используя .Net.
А какой именно аспект вы хотите повторить? Загрузку агентов с центрального сервера? Многоагентность? Разделение на травоядных и хищников?
Загрузку агентов по сети, чтобы не вы устраивали соревнования, а автоматически, и чтобы была возможность учета "кто кого победил".. многоагентность будет очень сложно симулировать на арене, думаю...
Чтобы я не устраивал соревнование, а вместо этого разрабатывал фронт-энд, автоматическое проведение матчей с учетом статистики, оплачивал и поддерживал сервер с видюхой...
Это бы имело хоть какой-то смысл, если бы не было отбою от желающих поучаствовать. Сейчас же - это просто трата времени, я лучше это время потрачу на исследование разных архитектур.
Класс, надо будет как нибудь повторить в свободное время.
У меня иногда в голове обдумывается идея игры типа UFC без графики но с расчётом физики и человеками которые работают в качестве "тренеров" одинаковых по показателям агентов. Всё время сомневался насчёт реализуемости такого на более менее недорогом железе. Видимо, не зря сомневался. Но, как вижу, до этого осталось всего ничего ))
А чем в MuJoCo создаются файлы MGCF с описанием робота и насколько удобно? Например, как задаются (и вычисляются) массы и моменты инерции частей? Как сделать URDF я более-менее представляю, вроде бы есть конверторы URDF->MJCF, но насколько они полезны не знаю.
Я руками писал, совместно с ИИ. Совсем неудобно, этот XML - не то, с чем хочется возиться)
Задаются плотности, массы и моменты инерции вычисляются на основании формы объектов.
могу порекомендовать - к FreeCad есть плагин RobotCAD. Во FreeCAD рисуете своего робота, задаёте материалы звеньев, суставы, пр. Плагин сам рассчитывает моменты инерции и генерирует URDF. Это лучший вариант, что я нашёл. За конвертацию URDF в MGCF ничего не могу сказать - не пробовал. Теоретически должно работать.
P.S. Если захотите - могу вам сделать URDF таким способом - мне будет интересно, а вам полезно :-)
Ну, модели у меня пока есть, спасибо. Вы лучше агента обучите, себе и мне на радость, посмотрим, как они будут драться.
Физические модели мне сейчас не нужны. Вот от красивой 3д-модели, натянутой поверх физической, я бы не отказался. MuJoCo это позволяет через skin, но я пока глубоко не разбирался с этим. Там менее удобно, чем даже в бледере риг делать (а блендер - далеко не вершина UX/UI)
Спасибо за JAX. Давайте еще про Taichi !!
https://github.com/taichi-dev/taichi
Если все сделано правильно, скрипт начнет медленно пробуждаться, JIT‑компилируя все необходимое (довольно медленный процесс).
тут он довольно быстро выжрал все 16Гб памяти и вывалился. А сколько ему надо-то?
в общем, на 16Гб он не компилируется, повыгружал всё что мог. Воркер довёл ревард максимум до 3.9 и пока всё. Завтра воткну ещё 16, посмотрим
У меня он на 32 ГБ расчитан. Можно уменьшить размер буфера в RAM, если не лезет.
buffer_size=4*4.096e6,
buffer_size=2*4.096e6, - так пошло веселее
Основной график, за которым надо следить — validator‑last‑reward
А почему у меня нет этого графика?

Не только этого, а вообще ни одного, кроме системных. Потому что данные еще не отправлены в Wandb. Сначала выполняется 2к (ну или сколько там в настройках) шагов случайными агентами, наполняется буфер. Потом начинается обучение, тогда пойдут первые данные. Валидация начинается еще позже, где-то с 5к итераций.
Движусь по-тихоньку. Буфер пришлось ещё подрезать.

Шикарно! С учетом того, что вы - единственный, кто запустил пайплайн, у вас уже техническая победа надо всеми читателями с Хабра)
А что у вас за видюха? Жаль, буфер пришлось уменьшить, боюсь, скажется на производительности агента.
такая же, как у вас, GTX 1080 8Гб. Озабочусь докупкой памяти.
Ох, тогда это будет долго и муторно... Я в итоге сменил на 4070, и время обучения сократилось с 5 суток до 30 часов. Даже сейчас это долго, трудно итеративно улучшать систему, когда каждый эксперимент занимает больше суток, но когда он занимал почти неделю, это было совсем печально.
через полсуток обучения выглядит так. Как будто уже научился:

Сейчас сравнил с вашим графиком - там на 250к как раз горизонтальная полочка, от которой потом рост. Видимо, я сейчас на ней и пройдено и вправду 1/8 пути
Что-то выглядит так, что обучение закончилось, врядли стоит ожидать новый рост. При этом лучший ревард достигнут 2.3, а у вас 10+. Что же пошло не так?


Вполне возможно, что надо еще подождать. Еще у вас размер буфера меньше.
ждём. пусть трудится.
пока вот так:

ревард 3.6
Его уже можно тестировать! Кидаете agent.flax в корень проекта, запускаете arena.py. Ваш будет оранжевым, противником по дефолту - агрессивный чемпион.
сохранил агента с 4.23 и пока поучу ещё, чтобы у меня их было два - чтобы можно было сравнить :-)
Это примерно на миллионе итераций?
Ну это нормальная динамика. Вот, например, график last reward моего прошлого чемпиона.

P.S. Так пайплайн же автоматом сохраняет прогресс, как только прошлый рекорд побит.

Сейчас так. Сохранил агентов 4.23, 4.9, 5.59, чтобы можно было им поспарринговать друг с другом и сравнить. Продолжаю обучение (сейчас 1.2М итераций). Да, по динамике похоже на вашу.
Устроить спарринг сейчас, я так понимаю, не получится, так как видюха занята обучением. Или можно прервать обучение и потом продолжить с той же точки? Поучу до 2М, наверное, как и вы.
Лучше не прерывать. Честно говоря, хоть я и закодил загрузку стейта, мне каждый раз кажется, что после загрузки учится хуже.
Но тестировать-то можно на CPU.
Обучение закончилось ещё позвачера, дошёл до 7. Запустил arena.py, но пока магия не случилась :-)
Получил ошибку:
(base) xxx:~/arena$ python
arena.py pygame 2.6.1 (SDL 2.28.4, Python 3.12.7)
Hello from the pygame community. https://www.pygame.org/contribute.html
Starting Battle Arena with parameters:
Agent 0: agent.flax
Agent 1: legacy-agents/eternal-firefly-57/agent.flax
Normalization 0: obs-norm/obs_norm_legacy.npz
Normalization 1: obs-norm/obs_norm_legacy.npz
Save mode: none
E0125 11:09:53.950128 7902 hlo_lexer.cc:443] Failed to parse int literal: 187511374564522277148574
и сейчас экран выглядит так (чёрный пустой экран pygame, но в питоне идёт какая-то битва):

ошибка возникает вот тут:
batched_state = vmap(ba.reset)(key)
Пока сделал 2 промежуточных вывода:
Уменьшение буфера в 3 раза по сравнению с вашим практически не повлияло на скорость обучения (те же 5 дней на GTX1080 8Gb), не знаю как на качество
Во время боя CUDA (видюха) таки используется, хотя и в 10% от того, как она загружена во время обучения.
Впервые такое вижу. У меня и на линуксе и на винде работает. Разумеется, видюха будет использоваться, если стартовать это все на линуксе - там же по дефолту JAX на CUDA считает. Если ему сказать, чтоб считал на CPU, будет на CPU. На винде у него выбора нет, поэтому он сразу на CPU считает.
Черный экран - значит MuJoCoвский опенгл рендер, видимо, не проходит - смотрите, что у вас с опенГЛем.
По поводу первой ошибки - понятия не имею, но если обучение шло, значит батчнутый резет выполнялся нормально.
Киньте мне вашего агента куда-нибудь, например, в телеграм, я посмотрю, как он справляется.
по-тихоньку обучение добралось уже до 7, так что не зря оставил учиться:

а вот с агентом вопрос возник. Заметил, что файл final/agent.flax не обновлялся с 19го числа, т.е. с начала обучения. То есть я сохраняю всё время один и тот же файл, а не агентов разной степени обученности, как я думал. А другого agent.flax я не вижу. И как, вообще, правильно останавливать обучение?
Он каждые секунд 30 пересохраняется, по идее (агент в checkpoints/имя агента/last). Этот код я не менял уже очень давно, там не должно быть никаких ошибок.
Лучше подождать до 2 млн итераций тогда, он сам завершится. Ну или ctrl+c)
Практическое обучение с подкреплением: от забав с MuJoCo'м до битв на арене