Перейти к содержанию

Doob

Гуру
  • Публикаций

    776
  • Зарегистрирован

  • Посещение

  • Победитель дней

    78

Комментарии блога, опубликованные Doob


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

    А вот научить робота самому добывать пропитание и ресурсы для людей - это задача как раз по силам полносвязной сетки.


  2. Меня прельщает то, что входов и выходов мало, их легко нормализовать, есть кое-какие возможности (функция получения времени или уровня энергии), позволяющие спроектировать очень простую нейросеть. Обучать, да, сложно. Это собрать данные, собрать статистику, без прямого обучения через тушку робота это очень сложно. Но можно будет дообучать сеть в процессе работы.

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

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


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

     

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

     

    Меня давно интересует вариант засунуть в робота простую нейросетку, самый сложный этап обучения будет как раз у сканирования и добычи. Но практической пользы все-таки маловато, т. к. в текущем варианте робот добывает все и сразу. А с нейросеткой, будет блуждать по миру, выдавая ресурсы только по приказу игрока (можно сделать тягу к заряднику, но тогда робот много не добудет) Но потребление памяти и процессора во время работы, будет практически нулевым, т. к. обученная нейронка будет просто выплевывать готовые последовательности действий на внешние данные.


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


  5. Монте-Карло не самый лучший, зато самый компактный.

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

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


  6. Мне не нужно, чтобы он копал слой через два в свободном режиме, для этого есть алгоритм добычи "слой через два", который оказался самым неэффективным из эффективных.

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

    Мне осталось протестировать 3 эвристики из 7. По готовности, опубликую результат с замерами.

     

    Я предлагал рассчитывать путь до кластеров, а не одиночных блоков, еще когда сам играл с послойной добычей. Но зная как работает робот, считаю вычисление полного пути не эффективным - это сильно раздует код, а если рассчитывать еще с минимальным количеством действий, это ОЧЕНЬ сильно раздует код. Сложно представить, какая нагрузка на процессор будет даже при использовании метода Монте-Карло, может он будет падать с елдингами без остановки. Были бы в роботах квантовые процессоры, я бы конечно, запилил решение задачи коммивояжера.

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

     

    P.S. Вычисления может производить не только робот, есть ведь доступ к внешним ресурсам - таблицу меток можно загрузить через интернет на более эффективное устройство, которое выдаст готовый путь, но это уже другая история.


  7. Да, хорошо, штраф сделать не просто разницей между верхним Y и текущим. А умножением, относительно всей доступной высоты. Так и сделаю.

     

    Повороты можно даже не штрафовать, а делать анализ, на этапе поиска цели.


  8. Предпочтения игрока тут не учесть, руды все одной плотности (ic2 свинец это недоразумение, а не руда).

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

     

    На стандартных генерациях ванилы, IC2, AE2 (тестировались отдельно) свободный обход существенно превосходит послойный (4 чанка, высота 64). Поэтому, статистика говорит в сторону этого подхода, а что админ накрутит генерацию - проблема индейцев.

     

    Изначально, я планировать сделать гибрид из этих двух алгоритмов - робот свободно выбирает цель, но получает огромный штраф на ход по вертикали +Y. Добыча велась бы максимально оптимально и робот заканчивал чанк наверху, откуда короче путь к старту следующего чанка.

     

    На стенде подобрал расположение руд, чтобы оно было похоже на реальную генерацию и оба алгоритма были бы в одних условиях (руда в каждом слое, свободный пробег 1600 блоков)

     

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

    • Нравится 1

  9. Экономия скорости не большая, по сравнению с потреблением памяти.

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


  10. Как это неизвестно? Первые три строчки как раз про это самое.

    Получаем заряд батарей 

    computer.energy()

    Делаем шаг, который будет основной функцией во время работы. В коде шага есть взмах инструмента, за время работы функции, у робота отнимется энергия на работу всех компонентов - робот 0.25, чтение диска 0.1, слип 0.1, чанклоадер (если предварительно включили) и что там еще энергию потребляет.

     

    Измеряем заряд батарей заново, отнимаем от старого новый.

    energy-computer.energy()

    Округляем вверх, записываем в переменную E_C

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


  11. Со стандартным конфигом 1.7.4 робот расходует любые инструменты на 4 действия эффективней игрока.

    А с зачарованными/модифицированными инструментами куча багов, вроде-бы появились после апгрейда функции robot.swing(), а может были и раньше. Но работать можно.

     

    В функции step() есть взмах инструментом и перемещение, до любой точки робот может дойти, сделав всего 3 поворота. Дополнительный запас хода будем учитывать в основном цикле, когда будет ясно, какие действия нужно выполнить, кроме движения (будет еще чистка инвентаря, упаковка и сброс лута).


  12. Никак, стандартный уровень шума не изменился. Первая версия сканировала 8x8 блоков, я жестко задал плотности, которые получил при сканировании дальних блоков (самая мягкая руда и бедрок)

    В этой версии изменять ничего не придется, т. к. так же сканируются 4 квадрата x8, только теперь робот не будет смещаться по горизонтали, пока не дойдет до бедрока.

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

    • Нравится 1

  13. Все это довольно неплохо, но модуляция довольно простая тема, да и нагуглить не долго.

    Можно, конечно, собрать генератор семплов и играть чиптюн, но это довольно скучно.

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

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


  14. -- Взять программу для робота, которая умеет считывать и интерпритировать команду с таблички, писать данные на таблички и в СОЗУ и работать с адресацией в "глобальном" пространсве (находить таблички).

    -- Найти людей, которым будет интересно пописать программы на этом roboassembler'е.

    Получим физический brainf*ck, а не ассемблер.


  15. Примерно за пол-часа сообразил файловый навигатор:

    u9nlp0H.png

     

    Пока можно только ходить по папкам и открывать/запускать файлы.

    Что-то мне это понравилось, думаю сделать полноценный файловый менеджер.

    • Нравится 3

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

×
×
  • Создать...