roboforum.ru

Графы нас всех спасут !
Посмотрел
https://habrahabr.ru/post/241941/
и не мог удержаться от повторного размещения ссылки:
http://is.ifmo.ru/books/_book.pdf
Там всё это прописано с разбором задач и с академическим подходом, те всё разложено по полочкам и с картинками.
Чтобы не путаться в построении сценариев рисуются графы. Есть даже программы преобразующие графы в код. Это описано там же, в конце книги.
По графам легко искать проблемы в логике. При этом копаться в коде не надо. Рисуем граф (на Visio или из другого варианта) и переводим в код сценария, вручную или программой.

Графы это просто способ визуализации, и это кому как нравится.
Можно графами а можно как тут уже писали таблицу состояний + таблицу переходов.

Но все в результате сводится к конечному автомату.

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

Графы могут быть не только простой визуализацией, а и средством разработки в том числе и с автоматической генерацией кода, в этом то вся прелесть метода.
На компактной картинке с графами легче понять логику, чем листая страницы кода.

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

выше - это где?

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

Ну тебя там напрягает бесконечный цикл ожидания - это же не проблема сценария, а архитектурная проблема. Если у тебя есть сигналы, то не обязательно ждать в цикле события.
А если нет - ну это просто одна из ветвей графа - проверка состояния кнопки. Она начинается и заканчивается на узле "idle"

Допустим. Хотя уже по твоему ответу видно, что написать тебе проще, чем нарисовать. Значит не очень-то удобны эти графы. Но, все равно я не представляю, если я захочу заменить в сценарии фразу, произносимую роботом, с "Добро пожаловать" на "Привет Вася", в каком месте графа я должен это сделать? А ведь именно для этого нужны сценарии. Для оперативного вмешательства в логику поведения, даже если ты не помнишь, как там твоя программа устроена. Но, Бог с ней с Ванессой.
Я бы предложил желающим потренироваться на простом примере:
Допустим у нас задание сделать игрушку луноход (по аналогии со старым советским луноходом, который программировался кнопками), но с условием, что пользователь может загружать в него сценарии поведения, написанные на изобретенном нами языке сценариев (текстовом или графическом).
В распоряжении есть не хитрые действия: движение на заданное в см расстояние {Вперед(), Назад(),Влево(), Вправо()}, Останов и воспроизведение звукового сигнала из набора - {Звук()}.
Также имеются 3 события: кнопки ПУСК, СТОП и срабатывание датчика ПРЕПЯТСТВИЕ.

Вот пример событийного сценария на изобретенном только что языке:

Код: Выделить всё • Развернуть

СТОП->{Стоп()}
ПРЕПЯТСТВИЕ->{Стоп(),Звук("Ошибка"}
ПУСК->{Вперед(50),Вправо(30),Влево(80),Звук("ОК")}

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

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

Блин, ты же прописываешь не автомат, а сценарий. Вот попробуем взять пример из статьи хабровской.

Код: Выделить всё • Развернуть

struct transition FSM_table[3][3] = {
    [state_idle][signal_start] = {state_execute, fxn_execute},
    [state_idle][signal_stop]  = {state_idle, NULL},
    [state_idle][signal_block] = {state_idle, NULL},
    [state_execute][signal_start] = {state_execute, NULL},
    [state_execute][signal_stop]  = {state_idle, fxn_halt},
    [state_execute][signal_block] = {state_blocked, fxn_block},
    [state_blocked][signal_start] = {state_blocked, NULL},
    [state_blocked][signal_stop]  = {state_idle, fxn_halt},
    [state_blocked][signal_block] = {state_blocked, NULL},
};

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

Думаешь, твой код покажется легко читаемым пользователю лунохода (не программисту со стажем) от 6-ти до 99 лет? Хрен кто купит такой луноход И сам ты его читать замучаешься через пару лет.
ПРЕПЯТСТВИЕ, допустим, генерирует событие при любом изменении состояния, т.е. 2 события ЕСТЬ ПРЕПЯТСТВИЕ, НЕТ ПРЕПЯТСТВИЯ.

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

Добавлено спустя 35 секунд:
Но это я все теоритизирую, конечно. Надо книжки читать и делать что-то.

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

кстати, g-code - это тоже оно и есть

Вопрос смахивает на неразрешимую задачу. Мне непонятен пример с "Скучный про Ванессу". Все-таки это программа, а не сценарий. И с точки зрения VB6 - эта программа совершенна. Программисту поставить 5 и отпустить

Второй пример:

Scorpio писал(а):Вот пример событийного сценария на изобретенном только что языке:

Scorpio писал(а):Что если пользователь захочет, чтобы робот хотябы продолжил выполнять задание после того, как препятствие убрали с его пути?

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

А вообще, сложно вам программистам, кто учился по книгам. Загоняют вас в определенные рамки.

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

dccharacter писал(а):кстати, g-code - это тоже оно и есть

По идее, весь вопрос и сводится к написанию такого языка.

Dmitry__ писал(а): Программисту поставить 5 и отпустить

Раньше ты помнится говорил, что надо плясать от события и никаких циклов ожидания.
Сценарий - это основной стержень программы, вокруг которого все и крутится. типа g-code, только более гибкий.
Совершенно не обязательно, чтобы он был отдельно от программы и не на языке программы. Дело не в грамматике, а мыслях и последовательности их изложения. Нарисуйте лучше граф про луноход, раз они такие удобные.