roboforum.ru

-= Александр =- писал(а):А у меня такая вот идея появилась - просто добавить к любому роботу модуль связи - и он сможет работать в системе!

Я это и предлагаю в заголовке темы. Основным стыковочным элементом мог бы быть язык AIGL для обмена информацией. Но лишь для того, чтобы реально хотя бы несколько человек смогло воспользоваться этой системой, нужно сделать хотя бы один прототип, сделать эти несколько одинаковых вариантов, и начать с ними экспериментировать. Купить готовые модули можно, но вопрос, сколько все это добро вместе будет стоить. И вообще, для чего весь этот форум? Давайте дождемся готовых роботов, не только игрушек, но и настоящих бытовых. А глупые японцы делают не только на фирмах своих роботов, но и дома, в школах на уроках труда и т.д. Мы ведь не такие глупые. Давайте ждать.

-= Александр =- писал(а):У меня например есть 4 вполне работоспособные платформы...В принципе была б какая-нибудь связь - мог бы подключить одного из них к системе, сервер у меня всегда в сети... Правда в сетевых технологиях я мало что смыслю...

Это уже интересно. Давайте попробуем состыковать ваше железо и мой софт. Мой сын пишет на C#. Он может написать универсальный клиентский терминал, который будет соединяться с моей системой и вашим железом. Если можете, опишите тот программный интерфейс по управлению вашими платформами, что у вас есть.

avr123.nm.ru писал(а):1) а почему нельзя делать это в симуляторах? PROTEUS  Matlab +специальные программы симуляторы роботов.  Кто захочет железо купит.

Можно и симулятор применять. Но такое уж человек животное, что ему хочется, чтобы именно в реальном мире настоящая железяка делала что-то полезное, например, пербирала стопку книг и листки с разрозненными записями, приносила неведомо откуда нужный болтик, о котором лишь она знает, где он в доме лежит и т.д. Разве эмоции, полученные от этого сможет заменить симулятор? Второе и главное - реальный и симулируемый миры - две совершенно разные сущности. В простом симуляторе и мир примитивен. Зачем так много усилий тратить на то, что все равно придется переделывать? Если я ошибаюсь, объясните, в чем.

avr123.nm.ru писал(а):2) Нужен какой то стандарт по которому радио-сетевой модуль сможет расказать сети о том что может робот на котором он установлен.

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

avr123.nm.ru писал(а):Т.е. главное определить "язык общения" на котором разные модули будут общаться и понимать друг друга.

В качестве смысловой обертки предлагаю свой язык AIGL (http://www.aigl.org). Подробности о нем могу сообщить всем желающим. Спрашивайте. А более абстрактные языки для обслуживания нужд робототехники можно создать на основе этого языка в виде спец подъязыков.

Johnny Bravo писал(а):Может чего и не понимаю, но сложилось такое мнение, что управление с сервера будет однообразныим и писать этот ИИ будет кучка людей. А если я, скажем, не хочу видеть такой алгоритм поведения...

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

Johnny Bravo писал(а):Плюс ко всему следует наверно подумать о датчиках,- им следует присвоить адреса, для начала от тетрады и возможно до байта, чтоб знать чот анализировать и что возвращать.

Это дело механизма Plug&Play, который предстоит разработать. Билл Гейтс хотел внедрить в PC технологию микродрайверов, где бы связь с аппаратурой была бы достаточно примитивной, но эта идея так и осталась нереализованной до конца и в настоящее время каждый производитель компонентов для компа мается с дровами для своих изделий.

Johnny Bravo писал(а):И что вообще мешает организовать связь с компутером и отсылать на него данные, а там обрабатывать, к примеру по алгоритмам нечекой логики, и засылать инструкции с дествиями дальнейшими?!

Связь предполагается такая: датчики робота получают сигналы, которые после тривиальных преобразований, компрессии, шифрования и т.д. посылаются с пом. клиентской программы системы AIgod в серверную ее часть по интернету. Управляющие воздействия от владельца робота аналогично поступают в сервер. Там полученные данные правильно преобразуются и обрабатываются. Сервер в зависимости от его собственных динамических алгоритмов и полученных от робота и его владельца данных вырабатывает управляющеие воздействия, котрые через интернет поступают из сервера в клиентскую программу. Она, в свою очередь, передает эту информацию либо пользователю, либо самому роботу. Т.о. для пользователя наличие удаленного сервера должно быть незаметно или почти незаметно.
О взаимной пользе такой системы поговорим позже, если у  кого-то проявится интерес к такой системе.

Johnny Bravo писал(а):Не могу понять преимущества вашей модели.

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

2Виктор Казаринов:

Беглый осмотр привел к следующим вопросам:

1. Как ваш подход соотносится с аналоговыми входными сигналами?
2. Как ваш подход соотносится с аналоговыми выходными сигналами?
3. Как ваш подход соотносится с аналоговыми задачами? (то есть задачами оптимизации с мощностью множества решений больше счетного)

Верно ли я понял, что ваш подход это по сути языковой ИИ? То есть это некий черный ящик, которому можно в виде текста задать вопрос и в виде текста получить ответ?

Виктор Казаринов писал(а):

=DeaD= писал(а):1. Как ваш подход соотносится с аналоговыми входными сигналами?
2. Как ваш подход соотносится с аналоговыми выходными сигналами?

Хорошо соотносится. SQL запросы могут содержать числа. AIGod также может обмениваться с внешним миром сообщениями на языке AIGL, средствами которого числа, в т.ч. и с плавающей точкой, можно определять. Поставьте ЦАП и получите аналоговую величину.

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

Виктор Казаринов писал(а):

=DeaD= писал(а):3. Как ваш подход соотносится с аналоговыми задачами? (то есть задачами оптимизации с мощностью множества решений больше счетного)

Уже на уровне языка AIGL вводятся предельно абстрактные понятия: "сущность", "время", "число", "материя" и т.д. работа с нечеткостями и субъективностями вроде "слева", "больше", "не уверен", "приблизительно"  - родные задачи моей системы.

Нечеткая логика это понятно. В принципе концепция ясна.

Виктор Казаринов писал(а):

=DeaD= писал(а):Верно ли я понял, что ваш подход это по сути языковой ИИ? То есть это некий черный ящик, которому можно в виде текста задать вопрос и в виде текста получить ответ?

Если человека можно назвать языковым ЕИ, то мой ИИ - языковой.

Не понял, тогда немец для англичанина ввиду невозможности языкового общения не является существом с интеллектом? Является ведь?

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

Как следствие не вижу понятия "языковой ЕИ".



Теперь приступим к расспросам поинтересней

Пополняема ли ваша система информацией "на лету"?

Если да, то как ваша система защищена от переполнения информацией? Если я к ней подцеплю генератор очевидной информации типа "1 + N = (N+1)" - она сдохнет?