roboforum.ru

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

В принципе, а что тут думать? На сенсорах нужно получить определённые сигналы, грубо говоря, это и есто то, что "нужно сделать". Допустим, в роботе уже есть алогритмы, как добиться заданного результата. Осталась "мелочь" - определить, а зачем это нужно делать?

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



В том то и дело, что такая формулировка не прокатывает сразу же.

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

Не получиться... Разве что, если есть огрОмная матрица ПСС, то отказаться от количественной оценки, оставить качественную, ввести критерии необходимости и достаточности... Ух тут и наколупаться прийдёться.

Огромная матрица - IMHO уже не подходит, хотя никто не запрещает одному из модулей быть огромной матрицей

А то, что поколупаться придется - дак кто же сомневается...

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

Ну дык вот она, эта огромная матрица ПСС. Если её небудет, то в роботе должен быть хотя-бы каталог со ссылками, где можно получить эти ПСС. А как-же иначе?
По-моему, уже есть такая...  Называеться "Теория решения изобретательских задачь"(ТРИЗ). Но она исключительно "для людей". В принципе, если скрестить ТРИЗ и системный анализ, то получиться именно такая решалка.

Видимо у нас разные понятия "огромная" - у меня это под миллиард, а у тут вроде даже тысячей не пахнет...

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

Так и в жизни бывают проблемы такого сорта - будем пробовать, ошибаться, оценивать отклонения, делать выводы и пробовать дальше - стандартный подход

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

Откуда вы будете миллиард моделей брать? Их же вроде я не предлагал рандомом генерить на лету... фрактальным методом

К моделям причисляется только то, что либо HAND-MADE, либо уже зарекомендовало себя в качестве способа решения задачи.

Кстати, о птичках. Как там альфа-версия ядра?

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

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

Фишка в том, что я сейчас тоже "ядро" собираю (от железа временно вообще пришлось отказаться - out of time). Так вот и предлагаю - устаканить интерфейсы модулей и протокол взаимодействия с ядром, авось чё толковое и получиться.

Так у вас вроде жутко практическая цель, а у меня полутеоретическая, у вас ядро какие вещи поддерживать будет?