roboforum.ru

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

Клиенты должны выполнять следующие функции:
1. Обеспечивать связь - свою и сервера с оборудованием с помощью программных подключаемых драйверов.
2. Обеспечивать ресурсоемкие первичные вычисления. К таким вычислениям я отношу в первую очередь обработку изображений до требуемой степени абстракции, с которыми работает сервер.
3. Обеспечивать быструю примитивную автономную реакцию системы (рефлексы), т.к. роботы работают в реальном времени и критическим является время реакции. Возможно, что такая автономность не потребуется.
4. Обеспечивать свою связь с удаленным сервером.
5...

Сервер должен выполнять следующие функции:
1. Служить единым хранилищем опыта роботов.
2. Выполнять все главные информационные функции жизнедеятельности робота.
3...

Вот такая приблизительно мысль. М.б. кому-то она интересна? Хотелось бы с кем-нибудь тнад такой платформой поработать совместно. Условия можно обсудить. Но сейчас в первую очередь нужно саму идею распределенного роботостроения обсудить.

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

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

Michael_K писал(а):А когда вас просят объяснить, чем же конкретно занимается например ядро, чем ваша схема отличается от тысяч других, то получают ответ типа "ядро ядрит" и "компоненты обменивается языком запросов"...

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

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

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

Виктор Казаринов писал(а):Исходя из экстремального подхода я и хотел бы создать тестовую сквозную систему для оценки правильности выбранного подхода. На данном этапе речь идет об обычном удаленном управлении с несколькими промежуточными звеньями.

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

=DeaD= писал(а):Я не понимаю зачем ровно эту же задачу надо начинать делать с нуля?

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

Словосочетание "коммерческая выгода" имеет слабое отношение к тому, что я сказал.

Я процессоры разрабатывал и паял, когда их можно было создавать из микросхем малой степени интеграции. 8, 12 и 16 разрядные. И системы команд придумывал. Но это - в прошлом.
Экстремальный подход позволяет изобретать велосипед, но немного с другой точки зрения, если можно так сказать.
2DeaD: коммерческая выгода обычно скрывается в самых неожиданных местах.

Кстати, ИМХО, Виктор, вы неправильно итерационный подход называете экстремальным программированием

Экстремальное программирование это всякие суровые приколы типа 2 человека на 1 компутер и т.п.

http://ru.wikipedia.org/wiki/%D0%AD%D0% ... 0%B8%D0%B5
Но я подразумеваю следующее: небольшой командой в чрезвычайно сжатые сроки делается только то, что жизненно необходимо только для реализации самой ближайшей цели. Ни качественного документирования, ни закладывания в продукт возможностей дальнейшего расширения - ничего этого нет. Почти всегда мне после таких этапов приходилось выбрасывать наработанное и сданное заказчику и делать заново с нуля, документируя для себя же родимого, чтобы я на следующий день хоть как-то понимал, что где написано и сделано. Как только заказчик просил что-то добавить в продукт - тут то и вылезают сразу грабли этого экстремализма.
Т.к. при таком подходе нет времени на понимание и увязывание конкретного кусочка кода в общую концепцию проекта, то итерационный подход, помноженный на крайнюю нужду в ресурсах (времени, людских и т.д.) порождает такой вид экстремализма.
Я же выступаю за сочетание итерационного подхода - проектирование снизу вверх с проектированием сверху вниз.

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

Чего-то вы не так поняли в экстремальном программировании.

Не буду судить об экстремальном программировании более, т.к. тема тут другая.
Возвращаюсь к "моим баранам".
Чтобы радикально упростить разработку и тестирование системы в самой первой альфа версии, я собираюсь разработать виртуального роботика. С окружающим его миром сильно заморачиваться не буду. Главное, как я уже говорил ранее - это создание хотя бы примитивной цепочки дистанционного управления автономного робота. Уже в таком виде всем желающим можно будет поиграться с роботом по интернету. И только после получения результатов перейду к реальному роботу

Странно... все как-то странно...
То вы про ИИ, то про удаленной управление роботом, то про душу в роботе, то про автономное функционирование...

В природе существуют неодушевленные предметы и одушевленные (с первых классов школы). Так вот робот это весЧь или шелеЗяка и какой псевдо-ИИ туда не закладывай души там не будет никогда. И тут речь не только о живых и неживых вещах.
А нужен ли робот-повар с "душой"? Вот захотелось мне поесть разбудил я его ночью часа в два, а он спросоня меня еще и пошлЁт. Или всю ночь будет по телевизору футбол смотреть - может он болеть за команду какую будет...

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

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

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

Добавлено спустя 53 минуты 21 секунду:
Вот ссылка forum10/topic8312-30.html

Само удаленное управление роботом через интернет - вещь весьма тривиальная. Но нельзя сделать что-то более сложное, не пройдя через этот этап.

Не знаю как другие, а я поддерживаю идею с распределённой клиент-серверной системой управления. Роботы могут быть разные - умные, тупые, с автономными мозгами, дистанционно управляеммые, с мозгами на "стороне", можете еще добавить если что-то забыл... И для каждого можно придумать свой круг задач. Идея клиент-серверного управления логична, на мой взгляд, и достаточно прогрессивна.
Маленько фантастики:) Представим себе кафе будущего, где шастают несколько роботов (ну, допустим, ориентируются по полосам на полу) и подают заказанные блюда на столики. Допустим, до 10 столиков, к каждому подходит дорожка, по которой робот и прикатывается. Возникает задача - централизованно управлять действиями несколькои роботов. Клиент заказывает за столиком через терминал интересующее блюдо, информация поступает в БД, формируется запрос на свободного робота официанта и команда прикатить в раздатку. Робот прикатывает, сообщает на сервер что он готов отвезти заказ за столик №3, человек на раздатке уже ставит блюдо и жмёт кнопку - Go!!! Сервер сообщает куда ехать, по какому пути и.т.д...
Можно долго критиковать описанный выше процесс, но речь не об этом! Клиент-серверная архитекрутра просто необходима в сложной информационной системе. Последние тенденции идут к тому, что даже внутри автономных сложный устройств всё организуется на принципах взаимодействия сервисов (Сервисно-ориентированное программирование , SOAP).
У меня есть подобная идея реализации клиент-серверной системы управления посредством WCF (. Net Framework), но пока занят над реализацией шасси телеги, т.е. механической части.