roboforum.ru

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

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

может ещё что забыл
ну и базы данных : карты, идентефикаторы предметов, координаты NPC и гейтов карт (переходы)

Добавлено спустя 2 минуты 55 секунд:

Виктор Казаринов писал(а):]У вас - хорошая основа. Отличие MOORPG от реального мира - в бОльшей степени непредсказуемости, незамкнутости мира. Особую трудность представляет именно распознавание всего подряд.

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

К сожалению, роботы требуют особого подхода. Мой CLIPS не подойдет по нескольким параметрам - быстродействие, объем памяти, соответствие моим внутренним представлениям о процессе обработке информации.
1. Для роботов желателен жесткий реалтайм.
2. В бюджетных решениях желательно использовать 8 битные МК.
3. Мое представление - Rule Engine, основанная на работе с онтологиями - равитием фреймов.

Добавлено спустя 12 минут 10 секунд:
Рассмотрим нейросеть. Обычно у нее множество входов. Основные - перцептивное поле. И есть несколько выходов. Для робота это не годится. Если сделать распознавание нескольких объектов (маячок, лазерная линия и т.д.), то это не полностью решает задачу навигации, а тем более качественной работы робота, например, сбор разнообразного по форме и содержанию мусора, а также отсеиванию чего-то ценного. Распознаватель робота сразу должен быть нацелен на распознавание "неизвестно чего". Такое невозможно? Все гораздо проще.
Нужно создавать иерархический распознаватель. Модели мира могут начинаться с примитивов. Распознал примитивы - хорошо. Распознал на их основе что - то более общее - еще лучше. И т.д. И если в памяти робота хранится аналогичная связка в виде онтологии простых примитивов и более общих, то количество распознаваемых классов будет достигать количество узлов в этой онтологии. Достраивая онтологию, можем расширять (обучать) распознаватель. "Дергая" как за веревочку за простые примитивы, можем активировать более абстрактные понятия. Например, получили контур-окружность, а в нашей базе знаний - онтологии хранятся только два известных понятия - мяч и арбуз. Теперь мы можем существенно сузить круг поиска и классификации, отбрасывая др. понятия. Более того, мы можем целенаправленно, поведением робота поискать доп. признаки объектов, например, черные полосы на зеленой поверхности. Это уже похоже на выдвижение гипотез и их проверку. Хотя механизм тоже вроде бы несложный.
Чтобы проверить эту идею, давайте попробуем:
1. Сначала написать простейший алгоритм на каком- нибудь метаязыке.
2. Закодить на PC на любом языке.
3. Протестить и проанализировать результаты тестов - стоит ли такая "овчинка" выделки или нет.

>Чтобы проверить эту идею, давайте попробуем:
>1. Сначала написать простейший алгоритм на каком- нибудь метаязыке.
На бумажке
>2. Закодить на PC на любом языке.
На C
>3. Протестить и проанализировать результаты тестов - стоит ли такая "овчинка" выделки или нет.
На соревнованиях.

Из объектов там будут:
Следование по линии: белое поле, черная линия
Кегельринг: белое поле, черная окружность, белые банки
Слалом: белое поле, черная линия, белые банки
Теннис: белое поле, цветной мячик, другой робот
Минисумо: черное поле, белая окружность, другой робот

Почему не попробовать?
Очень мало объектов.. и МК (8битный) справится

AndreiSk писал(а):>Чтобы проверить эту идею, давайте попробуем:
>1. Сначала написать простейший алгоритм на каком- нибудь метаязыке.
На бумажке

Язык и бумажка - немного ортогональные вещи.

AndreiSk писал(а):>2. Закодить на PC на любом языке.
На C

Зависит от характера алгоритма. Еще не знаю

AndreiSk писал(а):>3. Протестить и проанализировать результаты тестов - стоит ли такая "овчинка" выделки или нет.
На соревнованиях.

Кто с кем соревнуется?

серевнование я так понимаю алгоритма RoboBrain против жесткой логики (существующие модели в стандартных соревнованиях)

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

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

Такое соревнование придется отложить "на потом". Рановато.

А как тогда тестировать модель?
Куда же проще, белое поле и черная линия...

Виктор Казаринов писал(а):2. В бюджетных решениях желательно использовать 8 битные МК.

Не факт, но эту тему лучше обсуждать отдельно.

Добавлено спустя 2 минуты 43 секунды:
2Виктор: А давайте сделаем так - вы начнете списком из 3-5 вариантов достаточно простых вариантов использования своих подходов, которые в то же время будут очевидно показывать отличие этого подхода от жесткого программирования или традиционных прямых реализаций алгоритмов? Хотя-бы на примере более легкого расширения и адаптации под модифицирующуюся задачу? Пусть они будут менее эффективны чем жестко прописанные решения конкретных задач.

После этого народ на форуме попробует так же накидать варианты использования, вы скажете подходят они или нет и почему, потом на примере этих вариантов использования мы рассмотрим базовую концепцию и попробуем её формализовать?

DeaD писал(а):А давайте сделаем так - вы начнете списком из 3-5 вариантов достаточно простых вариантов использования своих подходов, которые в то же время будут очевидно показывать отличие этого подхода от жесткого программирования или традиционных прямых реализаций алгоритмов? Хотя-бы на примере более легкого расширения и адаптации под модифицирующуюся задачу?

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

DeaD писал(а):После этого народ на форуме попробует так же накидать варианты использования, вы скажете подходят они или нет и почему, потом на примере этих вариантов использования мы рассмотрим базовую концепцию и попробуем её формализовать?

Тут я немного не въезжаю. Варианты использования? Тут нужно двигаться либо исходя из цели, например, распознать то-то и то-то и еще это. Либо из представления о структуре механизма восприятия, а потом проверять на разных тестах. Либо двигаться с обоих направлений - заранее придумать цели- тесты, реализовать структуру распознавателя, а затем расширить тестирование, чтобы убедиться, каков круг возможностей данного механизма восприятия на необученном, неожиданном материале.
Я вообще-то люблю (когда соблюдаю свои же правила) написать небольшой кусочек кода, а затем дописать очередной тест и включить его в общий прогонный список тестов, чтобы все время все ранее написанные тесты проходили. Поэтому разнообразные тестовые изображения должны присутствовать обязательно.

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

Формат данных - ветки онтологии в бинарном выражении. Нечто похожее на XML по структуре, но в XML важна форма, а здесь еще и содержание, похожее на OWL.http://roboforum.ru/wiki/%D0%A4%D0%B0%D0%B9%D0%BB:Main.gifТам видно, что все обработки с изображением включая препроцессинг будет делать RoboBrain. Поэтому и начинаю с препроцессинга.

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

Тут не совсем подходит метод проектирования "сверху вниз", хотя я предпочитаю такой. Дело в том, что эта сфера экспериментальная, полного прототипа нет, подглядеть особо неоткуда. Придется сначала набросать общую схему, что я и пытаюсь сделать, затем взять отдельные части и провести макетирование с тестированием. Макетирование частей можно делать "сверху вниз". Короче, придется сочетать экстремальный и иерархический подходы.
Первое - что такое модели в зоне образного мышления RoboBrain. Буду писать эту эскизную документацию.
Меня сильно беспокоит блок синтеза моделей миров на моей общей схеме. Один из вариантов его части - 3D синтезатор похожий на игровую видеокарту. Хотелось бы избежать его наличия.