?

Log in

No account? Create an account

Компьютерная лингвистика

Новостная лента www.solarix.ru

Entries by tag: роботы

NIPS 2017: Learning to Run: улучшенная модель
kelijah
Подготовил новую модель для соревнования "NIPS 2017: Learning to Run (Reinforcement learning environments with musculoskeletal models)", организатором которого является Stanford Neuromuscular Biomechanics Laboratory:
Умчался вдаль, гремя костями (видео)...Collapse )
Визуально модель слишком динамична, склонна к энергичным и высокоамплитудным движениям. Возможно, следует штрафовать ее за слишком активную работу мышц, причем постепенно усиливать штраф.

NIPS 2017: Learning to Run - сделал первый сабмит
kelijah
Засабмитил своего киборга сюда https://www.crowdai.org/challenges/nips-2017-learning-to-run/leaderboards
Теперь надо попробовать улучшить устойчивость, а именно научить не падать после первого шага. Добиться, что модель делала шаги поменьше, не задирала ноги выше того, что раньше было ушами.

Пробное использование keras для обучения детекторов движения
kelijah
1. Задача детектирования движения (направления и скорости) решается, вообще говоря, и по-другому - через БПФ. Но решение через ANN легко обобщается и на детектирование других первичных признаков, насколько получается построить генератор обучающих датасетов. Поэтому ANN.

Смещение определяется в окне 16*16 пикселей по осям X и Y независимо для -3...+3 пикселей. Берется абсолютная яркость пикселей без какой-либо предобработки.

2. Я взял keras, чтобы посмотреть в принципе на эффективность привлечения стороннего deep learning фреймворка вместо самописной реализации на C#. Первые же прогоны модели показали, что с оптимизированным C++ кодом даже без перехода на GPU решение на C# близко не лежит. Разница ошеломляющая.

3. Код для обучения модели. Он загружает текстовые паттерны из 4-х файлов. По 2 файла для тренировочного и тестового набора. Датасет - 100,000 тренировочных паттернов. Это проблем влезает в память, так что головную боль с десятками гигабайтов данных я пока отложил.
pythonовский код...Collapse )

4. Я попробовал для начала четыре варианта: с дропаутом и без, с сигмоидой и с ReLU. Результаты не удивляют - заранее никогда нельзя сказать, в плюс ли сыграет включение какой-то фичи в модели или в минус. В данном случае 50-процентный dropout делает модель хуже. Побеждает, в том числе по скорости - модель с RReLU, без dropout'а и без batch'ей.

Показано значение validation loss для mean squared error по мере выполнения 100 эпох обучения.
результаты...Collapse )

Какой хитрый ландшафт....
kelijah
Подбираю метапараметры нейросети для классификатора (детектор движения для робозрения).
Вот такие кривые обучения для трех значения скорости обучения:
Read more...Collapse )То есть при большой скорости обучения 0.2 модель категорически отказывается спускаться по склону. Можно было бы предположить, что скорость обучения выбрана слишком большой и модель перескакивает через оптимальный овраг.

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

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

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

Диффузия диспаритетов для карты глубины сцены
kelijah
Далее - результаты вычислительного эксперимента по мотивам раздела "Surface Representation Using Confidence-based Filling-in" в A Neural Model of Early Vision:Contrast, Contours, Corners and Surfaces. Как мне показалось, математика в этом разделе книги ошибочна, поэтому я немного скорректировал уравнение диффузии на сетке конечных разностей.

На входе - два изображения мячика на фоне стены со стереокамеры модели робота:
Left image...Collapse )Right image...Collapse )

Ищем ключевые точки, в которых горизонтальный градиент достигает максимума, а также особо выделяем углы:
Points of interest...Collapse )
Этих точек может быть слишком много, поэтому отбираем некоторое количество. Отбор ведем так, чтобы в каждом концентрическом слое от центра изображения (условная область fovea) было одинаковое заданное кол-во максимально интересных точек.

Вычисляем горизонтальные смещения в ключевых точках:
исходные смещения...Collapse )
Получаем разреженную карту. В ней есть зоны отсутствия данных. А для оценки сцены и выбора направления движения нам нужна dense карта. Поэтому надо как-то заполнить лакуны. Самый простой способ - выполнить сглаживание с учетом того, что отсутствующие данные не должны влиять на надежно измеренные значения. Добавляем в алгоритм учет уровня достоверности данных, а также информацию о проницаемости. Проницаемость зависит от градиента: измерения не диффундируют через яркостные границы, это позволяет сохранять пространственные границы объектов.

Промежуточный результат диффузии (синим выделены заполненные, белым - измеренные данные):
Intermediate diffusion map...Collapse )
И финальная карта глубины:
final depth map...Collapse )

Реккурентные горизонтальные связи для снятия шумов и гештальт "continuity"
kelijah
На входе - изображение прямоугольника с добавлением 50% высокочастотного шума:
Исходное зашумленное изображение...Collapse )
Шум с высокой пространственной частотой склонен забивать детекторы границ, использующих производные. Например, Sobel filter по одной оси:
Sobel filterCollapse )
Или Canny:
Canny detector...Collapse )
Но мы-то отчетливо видим прямоугольник на фоне "шумовой текстуры"! Что нужно добавить в алгоритм, чтобы он увидел объект?
Нужно, чтобы алгоритм реализовал гештальт "продолжения". Упрощенно говоря, алгоритм должен стремиться выстраивать прямые линии (или гладкие контуры), а случайные вбросы - подавлять. Как это выглядит?

Вот результат обработки исходного изображения набором из 2000 ориентационных фильтров (feedforward фаза):
Feedforward processing....Collapse )

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

Не зная общего контекста, каждый из них просто голосует за лучшее направление в своем рецептивном поле. Если выбрать победителя в каждой локальной группе (группа фильтров представляет полный набор ориентаций - 360 градусов, как и биологический оригинал):
Local strong inhibition...Collapse )
По-прежнему отдельные фильтры обрабатывают только свое рецептивное поле, не зная об общем контексте.

Добавим теперь торможение по широкому полю. Каждый фильтр при этом соревнуется с близкими соседями в области, составляющей несколько радиусов своего рецептивного поля. При этом сила торможения пропорциональна разнице в направлениях ориентации, то есть сильно отличающиеся направления тормозят друг друга сильнее, а коллинеарные - не тормозят. В алгоритме появляются реккурентные горизонтальные связи. Получаем вот что:
Wide inhibition...Collapse )

Это уже лучше. Учет контекста снимает большую часть шума.

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

Так реализуется вышеупомянутый гештальт продолжения. Отдельные детекторы теперь чувствуют общий контекст и работают совместно над его улучшением:
Горизонтальное реккуретное возбуждение...Collapse )

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

Irrlicht и рендеринг сцены: стул, мячики и будильник
kelijah
На сцену добавил мячики отсюда, стул и будтльник отсюда. Получилось так:Один кадр...Collapse )

Или общий вид с обзорной камеры:Облет сцены...Collapse )

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

Поэтому я сменил транспортный протокол для клиент-серверного взаимодействия на нативные pipes в WinAPI:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365588%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365592%28v=vs.85%29.aspx

Решение не портабельное, так как под Linux API совсем другой. Но обработчик запросов вынесен и максимально изолирован от самого рендерера, поэтому при необходимости можно будет "прикрутить" другой вариант.

Тем не менее, сейчас можно цепляться к серверу рендеринга по сети с другого хоста и управлять роботом простыми командами, а также запрашивать изображение со стереокамер. Поэтому ставлю галочку на этой задаче и перехожу к следующим:
Read more...Collapse )

Обзорная камера над сценой
kelijah
Немного причесал сцену.
Добавил примитивный детектор коллизий через проверку пересечения bounding box'ов - работает, не позволяя роботу проходить сквозь препятствия и стены.
И поставил третью камеру общего обзора, чтобы видеть сцену с роботом с высоты (желтый кирпичик - это собственно сам робот):
3d rendering via Irrlicht...Collapse )

Протокол обмена с визуализатором среды/робота
kelijah
Думаю, оптимальный вариант транспортного протокала по удобству отладки и использования - HTTP. Это позволит отлаживаться даже через браузер (если отдавать на стороне http-сервера специальную админскую веб-страничку).

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

На стороне рендерера думаю использовать Mongoose (был опыт использования в поисковке и сервере перевода под Win и Lin, работал хорошо) или Libmicrohttpd (никогда не использовал).