roboforum.ru

2=DeaD=: Вы меня м.б. не поняли. Мы в качестве бога или эволюции закладываем некий небольшой набор базовых алгоритмов поведения, особенно алгоритмов по выработке новых алгоритмов. Остальное должен сделать робот во время своей "жизни".

Пользователь сдохнет от скуки, пока робот будет таким образом наугад "эволюционировать".

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

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

Cильно много и очень сложных навыков делать вручную - совершенно напрасная трата огромного времени и сил. Ленат потратил более 30 лет и десятки миллионов зеленых, чтобы вручную создать онтологию Cyc. Аналогично ABBY истратило 30 млн долларов на создание своей онтологии знаний. И пока все они не достигли результата - чтобы программная система понимала смысл. http://top.rbc.ru/business/02/02/2015/54ceaf759a79472263c89c57
Если вы считаете, что навыки - это что-то отдельное и изолированное типа простой программы на G-кодах, то сильно ошибаетесь. Такой подход к навыкам как к станку ЧПУ или 3D принтеру неприемлем для робота хотя бы в силу того, что реальный внешний мир изменчив и ситуации не повторяются с точностью до миллиметра. Поэтому для передачи навыков от одного робота к другому и даже чтобы одному роботу воспользоваться своим опытом нужна некоторая степень абстрактности в описании навыков. Для этого и нужен единый формат онтологии, где среди других знаний могли бы храниться в общей форме и навыки.
Можно почитать старую книжку М. Минского о фреймах, чтобы понять, что сценарное направление весьма ограниченное и его нужно применять с осторожностью наряду с другими технологиями.
Выше lori в данной теме писал про тупиковость сценарного подхода к роботам и я с ним согласен.

Пошли дела кое-как. Тема двигается в нужном направлении, и это радует.

Добавлено спустя 2 часа 20 минут 11 секунд:
Если на форуме, есть человек, разобравшийся в ROS, было бы не плохо, чтобы он проанализировал целесообразность ее использования в данном проекте.
Также, хотелось бы знать, стоит ли тут задавать конкретные вопросы про java- код под андроид. Например, мне надо, чтобы распознавалка голоса запускалась по уровню сигнала с микрофона. При этом не издавая никаких звуков и без гугловской картинки с микрофоном. Частично я уже решил, но как-то громоздко и не красиво. Может у кого-то такие вещи уже отработаны. А, если таких людей нет, то и не буду тему засорять кусками кода и пойду искать на соответствующие форумы. Хорошо также бы было получить общие советы по построению софта, зная примерно его будущую структуру. Где стоит использовать интенты, интерфейсы, как лучше все синхронизировать и т.п.
Также нужен совет по практической реализации такого важного параметра, как текущее НАСТРОЕНИЕ. Настроение будет определять некоторое разнообразие в реакциях робота, придавая ему тем самым минимальную одухотворенность. Предлагаю для начала 3 возможных настроения: ХОРОШЕЕ, НЕЙТРАЛЬНОЕ, ПЛОХОЕ. Отображаться оно будет в выражении лица, активности и т.д. Настроение будет зависеть от физических факторов: холод (термометр), голод (уровень заряда), комфортная среда (освещенность с учетом времени суток), что еще?; и моральных: статистические данные по частоте и длительности включения, частоте и продолжительности диалогов, количестве знакомых лиц, отношения похвала/порицание, что еще?
Совокупность этих параметров даст какую-то переменную величину, которая будет умножена на коэффициент, отражающий индивидуальный для каждого робота ХАРАКТЕР. И в результате даст нам НАСТРОЕНИЕ. Характер в свою очередь, будет зависеть от ТЕМПЕРАМЕНТА и жизненного опыта. Например, длительное пребывание в плохом настроении ухудшает характер, в хорошем – улучшает.
Предполагается, что робот рождается с одним из типичных темпераментов, зашитых в память контроллера базы. Т.е. несчастный пользователь даже не будет знать, какой робот ему достанется. «Мой робот что-то все время грустит», «А мой веселый и подвижный». Кроме формирования характера, темперамент будет влиять на манеру поведения. Например, холерик будет двигаться резко и быстро, а меланхолик плаааавненько так разгоняться.
Т.о. мы уже получим какую-то индивидуальность, еще без применения ИИ. Хотя задача тоже не очень простая.

Следующий вопрос про язык для сценариев. Сценарии все равно в каком-то объеме понадобятся.
Например, сценарий, который я использовал в клипе, выглядит так:

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

Добавлено спустя 23 минуты 29 секунд:
Конкуренты не дремлют.

ИМХО надо определиться, куда всё-таки основной вектор - эмоциональность или функциональность/обучаемость. Два совершенно разных направления и идти по обоим вряд ли получится. Лично мне функциональность и обучаемость больше интересны.

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

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

Ну почему же. Характер и ум могут существовать параллельно. Например, на простой вопрос "Как дела?" Робот может ответить в зависимости от своего настроения "Хорошо, нормально, плохо". От степени его обученности это никак не зависит. А неизвестный заранее темперамент дает как раз элемент непредсказуемости, которого мы хотим добиться.
А от пользователя, конечно тоже будет зависеть
Корми во время и характер будет лучше со временем.
P.S. Как сказала моя супруга, посмотрев клип: "Кормление через задницу? Это оригинально!"

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

Выше в данной теме я указывал книгу Шампандар А. Дж. - Искусственный интеллект в компьютерных играх (Вильямс, 2007)
где вы найдете и по эмоции много чего полезного. Если у вас нет этой книги, могу скинуть на мыло.
Вы сначала ее гляньте, а потом будем дальше совместно думать в какую сторону грести в вашем проекте.
Т.к. в роботе главным будет вербальное общение, то самым сложным я считаю проблему понимания того, что сказал человек. Отсюда все и проистекать будет. Как с этим то быть?

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

Так это тот самый революционный семантический анализатор, который мы непременно разработаем и запатентуем.

Ну разве что за очень дополнительные деньги...

Добавлено спустя 26 минут:
Пример работы анализатора и самообучения:
Пользователь «Когда родился Хемингуэй?»
Анализатор:
- это не команда,
- это не типовая фраза,
- это вопросительное предложение.
- «когда родился» относится к дате рождения кого-то.
- все, что после слова «родился», запоминаем как идентификатор личности.
- Ищем в базе данных личностей (она пуста).
- запоминаем текущее состояние
- формируем ответ «Не знаю»
Пользователь «Посмотри в википедии»
Анализатор:
- это команда,
- нет параметра, значит используется предыдущая фраза, как контекст
- запрашиваем, парсим фильтруем, получаем объект личность: дата рождения
- проговариваем результат.
Пользователь «Запомни это!»
Анализатор:
- это команда запомнить текущую информацию.
- заполняем базу данных по личностям новая личность: дата рождения
- проводим самообучение по данной личности: добавляем место рождения, на ком женат, кто такой, когда умер и т.д.

С категорией «Исторические личности» разобрались. Сложно? Да в общем-то нет. С остальными 1500 категориями примерно также.
Это + эмоции и полезные умения – уже интересная игрушка.

Пора приступать к практике, господа, а то желание приобрести яхту уже начинает постепенно угасать...

Я с анализаторами текста долго как-то маялся. Самая первая книга, которая мне попалась на данную тему была "Общение с ЭВМ на естественном языке. Попов Э.В. 1982г." Я ее прочитал в 1982 году и теперь ее храню. Нужно бы прочитать ее второе более свежее издание.
И AOT я пробовал и много еще чего. Что-то вроде в голове в туманной дали вырисовывается в разрезе данного проекта. Но пока еще это облако не оформилось.

Ну, допустим, я в ROS разбирался. Применимость к проекту - высочайшая. А что?

Почему-то в ROS Jade нет поддержки Java клиента.

К чему приступать пока не очень ясно.

Apple/Google/MS выделяют многомиллионные бюджеты, чтобы разрабатывать только лишь таких помощников, без интеграции с исполнительными устройствами, без эмоциональной составляющей. Предлагается силами энтузиастов быстренько накидать нечто существенно лучшее и существенно более общее? Или я что-то упускаю?

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

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

Скорее всего причина в медлительности интерпретатора. В среднем, код написанный на Java выполняется медленнее кода написанного на C/C++ в два-три раза, а объема памяти требуемый при этом для Java в 10-30 раз больше.
ROS создается как универсальная ОС для роботов и не всякий робот несет на своем борту мощный и быстрый компьютер способный пережевать Java код. ROS заточен на использование таких языков как Phyton, C++, C, а самое важное в нем решена задача передачи сообщений между модулями и драйверами, стандартизированы подходы к обмену сообщениями, вы с легкостью можете добавлять как аппаратные так и программные модули в свой проект, используя при этом уже готовые решения ROS-а или решения созданные сообществом, или написав собственные узлы. К примеру, в ROS решена одна из главных задач робототехники SLAM, ROS работает с библиотеками компьютерного зрения с 3D датчиками, может работать с облачными технологиями (распознавание и синтез речи), умеет строить трехмерную карту окружающего мира и планировать свои действия в нем, например движения манипулятора, ну и много чего еще. Конечно, в ROS нет искусственного интеллекта, по той простой причине, что ИИ не существует пока вообще, но это отличная программная платформа для создания робота, гибкая и универсальная. Для "умника" абсолютно подходящая.
Scorpio, поверьте, стоит потратить время на изучение ROS. Мы тоже сначала пошли своим путем, начали писать программный код для нашего робота с нуля. Все было замечательно пока мы не дошли до того момента, когда код стал на столько сложным, что для того чтобы править его, приходилось прокручивать десятки экранных страниц, а еще помнить где что находится (при этом я имею хорошую привычку комментировать практически каждую строку программы). В один прекрасный момент мы дошли до того, что начали создавать свою систему сообщений внутри программы, писать свои протоколы передачи и обмена данными между узлами..., и вот тут я себе сказал: "СТОП! Где то я это уже видел." И вспомнил про ROS. Сейчас все усилия переключены на его изучение. Сразу скажу - доходит туго. А если учесть при этом мое полное не знание Linux, то вообще получается тяжко. Но я уверено, что это время и усилия не будут потрачены зря. Именно по этой причине мы приостановили все работы над проектом LUM, и готовимся к началу создания второй версии робота LUM-2, которая, конечно, будет функционировать под управлением ROS.
Собственно, написал я это для того, чтобы постараться сказать вам не торопиться, изучить то, что уже разработано и наиболее эффективно использовать это, а не наступать на грабли и изобретать велосипед как это делали, к великому сожалению, мы. Я думал так: куда проще сесть и сразу начать писать программный код для своего робота самостоятельно, сразу получать и видеть результат, чем сесть за изучение совершенно не знакомой среды, потратив на это несколько недель, а то и месяцев. Но я не учитывал одного, если знать ROS, то уже не придется писать портянки кода на получение данных, синхронизировать обработку этих данных с исполнительными механизмами, задумываться над тем как передать эти данные без искажений и потерь внутри создаваемой системы. Эти все задачи кажутся не очень сложными пока можно охватить одним взглядом написанную программу, но когда она разрастется до размеров монстра (а можно быть уверенным что разрастется ), все оказывается совсем даже не просто.
Я не навязываю никому свое мнение, и никого ни в чем не хочу переубеждать, я просто поделился опытом.
Извиняюсь за столь длинную написанную портянку.


Добавлено спустя 3 минуты:

PS Если идет речь только о базе, то ROS не нужен, это платформа для управления аппаратными средствами. В этом случае может посмотреть в сторону старых и добрых экспертных систем?

2 lori: Вы почитайте, что пишут про ROS 2 и каково его отличие от ROS 1. Сразу захочется взяться за второй. Но он только родился. Первая альфа версия вышла несколько дней назад. У меня тоже изучение ROS идет мучительно. Я нашел некоторые книги включая самые свежие. Если кому нужно, могу скинуть. Список литературы - по запросу. Проблема с ROS еще и в том, что везде речь идет о старых версиях. А в Jade, которую я изучаю, кое-что изменено. И получается в примерах и обучалках полный винегрет.
ROS 1, насколько я сейчас это представляю, лучше всего заточена под Ubuntu 14 и под процессор x64. Все остальное - от нечистой силы. Кстати, из последней версии ROS выведены все сербезные пакеты. Пакеты SLAM, Gazebo и OpenCV. Они устанавливаются лишь по зависимостям вместе с ROS. Но ничто не мешает, например, в совершенно отдельном проекте скомпилировать RTAB-MAP или использовать OpenCV. Т.е. все навороты над ROS могут использоваться вовсе без ROS.
Я все равно очень слабо представляю себе, чтобы ROS легко ворочилась на телефоне. То, что это в принципе возможно, не означает, что это нужно использовать. Ведь, собственно, кроме нодов и их взаимодействия, что тоже требует ресурсов, основная нагрузка будет внутри нодов. И я боюсь, что ресурсов телефона может не хватить.
Но по большому счету здесь проблема вовсе не в ROS.