roboforum.ru

Системы, основанные на продукционных правилах - нечто среднее между истинной параллельностью и событийной системой. С ее помощью можно легко запрограммировать и чисто последовательные алгоритмы и параллельные и их сочетание. При этом набор загруженных в машину правил вообще не описывает никакую последовательность их выполнения.
Суть проста. Если в рабочем списке фактов появляется новый факт, система ищет применимые к этому факту правила с учетом уже имеющихся в этом списке фактов. Т.о. могут выполняться правила, относящиеся к разным процессам. Конечно, последовательно. Например, одно правило одного процесса, затем правило другого, потом опять первого. Такая последовательность определяется лишь фактами.
Кроме того, если воспользоваться языком CLIPS, то можно соспоставлять не только факты, но и слоты объектов. Это дает еще бОльшие возможности. Для того, чтобы все облечь в удобную для пользователей компьютеров форму, я соединил движок, основанный на правилах с формами Windows, сделав GUI надстройку в программе моей программе AIAssistant. Теперь нажав любую кнопочку на форме, получим изменение слота объекта и срабатывание правила, если есть такое, что следит за этим слотом.
Не хотел бы, чтобы вы считали это саморекламой. Но мне Rule Engine очень нравится, т.к. позволяет производить прямой и обратный логический вывод. И самое главное - это система, кот. управляется данными, а не алгоритмами, заранее заложенными в нее. А это как раз то, что нужно для роботов.
Ядро CLIPS написано на чистом С. Наверное под ARM можно скомпилировать. А отлаживать можно на PC с красивым интерфейсом.

Виктор, какие еще продукционные системы? Мы же про пятиклассников!

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

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

Добавлено спустя 3 минуты 23 секунды:
какие эклипс, какие виндовые гуи? нааааа... кой ляд этот гимор? если арм с ММУ обычный линух и пошло всё в сад. или как другой вариант микрофрэмворк дот нэта (давно хочу, возможно скоро таки буду пробовать, нужные мне армы только после НГ закажу. в сети давно видел, кто-то даже графику и WPF прикрутил)

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

Фактически это напоминает работу схемы, выполненной в железе (с некоторыми допущениями, конечно)

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

Для исключения таких ситуаций применяются специальные управляющие конструкции
(Например в лабвью - "синхронизаторы", "шифт-регистры"...)

И... что-то мне кажется, что это совсем-совсем непросто для понимания
(Впрочем, я не скажу, что я крутой лабвьюшник - так "баловался" в основном для себя...)

=DeaD= писал(а):Виктор, какие еще продукционные системы? Мы же про пятиклассников!

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

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

Michael_K, а вы часом не описали работу обычного контроллера AVR?

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

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

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

=DeaD= писал(а):Так вопрос не во внутренностях вроде пока? Надо для начала понять в чем всё это рисоваться будет, а уж там во что компилировать - вопрос десятый, скомпилируем как нибудь в си, а его уже на МК

Гораздо лучше, когда внутренности и внешности хорошо интегрированы и совместимы друг с другом.
Да и суть вот в чем. и это- самое главное. От жестких алгоритмов и простых событийных программных средств в робототехнике нужно уходить. а точнее перемещать их на нижние уровни. Непредсказуемый внешний мир, окружающий робота не позволяет запрограммировать заранее все возможные виды его поведения. Поэтому обычный алгоритмический подход - лишь частный случай и не очень адекватен задачам робототехники.

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

Michael_K, а вы часом не описали работу обычного контроллера AVR?

Если говорить о железных внутренностях микроконтроллера - то да, описал (причем не только АВР).
А если говорить о выполнении программ, то нет конечно

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

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

Добавлено спустя 17 секунд:

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

Вот!

2DeaD: Давайте и обсудим, что будет видеть пользователь и язык. Во - первых, для чего нужен какой-то язык включая графический?
Мне нравится язык Locos http://e-novosti.info/forumo/viewtopic.php?t=1534
Я даже одно время хотел создать свою пиктографическую надстройку над OWL.
По сути дела, нужен язык, однозначного (точного) описания некоторого мира и процессов, протекающих в нем. Частный случай - внутренности программ и железа. При этом сам язык и то, чем манипулирует человек на экране, должны довольно хорошо совпадать. т.е. экранные сущности должны хорошо ложиться на смысловые.
Удобно было бы, чтобы можно нажав на одну экранную сущность, она бы раскрывалась, показывая структуру вложенных. Тогда не перегружая экранный интерфейс, можно либо манипулировать самыми общими вершками, либо в нужном месте докопаться до самых глубин, не нарушая целостности картины

В общем случае предсказуемость результата необязательна.

Имхо, в ОБЩЕМ случае, как раз она нужна,
и только в частных случаях иногда необязательна.

Если же нужны жесткие последовательности, то легко ввести синхронизирующие факты или их наборы.

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

В общем, я бы не ориентировался на всякие "прологи", как на языки управления.

2Michael_K: а вы знакомы с системой G2? Она спутниками и атомными реакторами управляет. Но основана на правилах. http://www.gensym.com/
G2 - занимает более половины рынка подобных систем в мире. Она - система реального времени и при этом имеет собственную очень навороченную графическую оболочку.
Как видите, правила используются в критических по времени и надежности системах.

Но я вот о чем хочу сказать. Бессмысленно пытаться описать все и вся хоть с пом. жестких алгоритмов, хоть с пом. правил. Нужно сделать так, чтобы эти алгоритмы и правила вырабатывал сам робот на основе небольшого набора базовых способностей (правил или др.) Тогда когда человек будет задавать новое задание роботу, то не будет описывать ему все подробности (в какое время какую серву включить), а даст ему глобальную команду, например, копать яму. А робот сам выстроит в своем воображении несколько вариантов решения задачи, выберет наиболее оптимальный и приступит к его выполнению. Вот такое программирование нам с вами светит.
Т.е. "мозг" робота должен заниматься динамическим самопрограммированием, а человек - метапрограммированием.
Основы такого метапрограммирования и нужно преподавать школьникам.

А давайте отучим пятиклассников есть еду ртом...
Все равно в будущем они будут лежать в креслах и питаться внутривенно.

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

Да, нужно. Но обучение (детей, а не роботов имею в виду) должно основываться
на опыте - такое обучение может хоть чему-то научить и заинтересовать детей.
(я услышал и забыл, я увидел и запомнил, я сделал и понял).

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

А фантазировать можно много, да...

Добавлено спустя 50 минут 53 секунды:
В общем, я подумал, что в лего достаточно неплохая структура, можно ее взять за основу...
Примерно так:

На компе:
- Графический язык
- Си-образный код
- Байт-код

На роботе:
- Интерпретатор байт-кода
- Кооперативная многозадачная ось
- Реалтаймовая поддержка железа

Все это, несмотря на красивые слова, в очень упрощенной реализации.

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

Экспертные системы уже лет 30 существуют. А роботы всё еще не научились сами вырабатывать алгоритмы и правила на достаточном уровне, до сих пор индустрия программирования живет в старых принципах. Почему через 10-20 лет что-то поменяется? По-моему в продукционных системах пока никаких принципиально новых идей всё еще нету, которые могут продвинуть их вперед за ближайшие десятилетия.

Предлагаю не обсуждать в этой теме то, что еще совсем не факт. И не учить этому пятиклассников.