roboforum.ru

Scorpio я в Вас не ошибся! Вы мой герой! )))
Почитаю подробнее по Умнику.

В копилку визуального программирования:
http://xgu.ru/wiki/%D0%A1%D0%B8%D0%BD%D1%82%D0%B5%D0%B7_%D0%B7%D0%B2%D1%83%D0%BA%D0%B0_%D0%B2_%D1%81%D1%80%D0%B5%D0%B4%D0%B5_Pure_Data
Для меня это была новость

https://ru.wikipedia.org/wiki/ДРАКОН
http://drakon.su

О языке CLIPS в планировании действий роботов.
Нашел https://www.fawkesrobotics.org/projects/rcll-planning/
Там внизу упоминается CLIPS:
"Software Stack Release
We have released the software stack for the RCLL 2014 in full, including our current task-level executive based on the CLIPS rule-based reasoning system as well as all other components required to play the game. We expect to provide an updated release for the 2015 gameplay after RoboCup 2015."

https://www.fawkesrobotics.org/publications/2013/clips-agent-llsf-aaai-springsymp2013/
И вот документ, в котором поподробнее:https://www.fawkesrobotics.org/media/publications/clips-agent-llsf-aaai-springsymp2013.pdf

Я с ДРАКОНОМ немного повозился. Неплохой вариант для разработки несложных систем, когда нужно отслеживать поток управления и последовательность действий. Позволяет видеть логику работы, как и обычная блок схема, но более продвинутая и формализованная. Неплохо бы школьников обучать на этих примерах, а не на LEGO WeDo или Scraatch где потоки управления не очевидны. Если за разработку логики отвечают одни люди, а за реализацию другие, тоже подходящий вариант. Но реализован на операторах goto на С, что не очень хорошо. Драконовский СИЛУЭТ и ветки силуэта ни что иное, как некий автомат и состояния автомата. Не удобен при проектировании систем со сложным поведением, когда отдельные части взаимодействуют между собой. То есть когда должно быть несколько взаимодействующих Силуэтов (автоматов, объектов) со многими связями. При этом ДРАКОН теряет визуальную простоту восприятия.

smur писал(а):Неплохой вариант для разработки несложных систем

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

вместо if-then-else, while и прочих конструкций это всё цветастыми блоками рисуется. отличия от простого текста минимально. получается, тогда и текстовым кодом "ничего стоящего" не сделаешь.

App Inventor мне нравится по сути, т.к. говорит людям, всступающим на стезю программирования: "Смотрите, не Боги горшки обжигают, и вы это можете". Я бы сделал в нем 2 веши: разделение программного кода на модули/вкладки, для облегчения навигации и возможность переключиться в текстовый режим представления кода.
Продолжаем пополнять копилку, связанных с темой ссылок: Быстрый, гибкий и забавный Qt Script

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

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

Дракон разрабатывался в рамках программы Буран но не применялся в его разработке
https://ru.wikipedia.org/wiki/ДРАКОН
Итоговая концепция это Графит-Флокс, использовалась в морском старте и др программах, но точно не сказано для каких задач. Можно покопаться в интернете.
http://drakon.su/_media/biblioteka/grafit_a4.pdf
http://drakon.su/_media/biblioteka/grafitfloks.pdf
Призвана разделить труд конструкторов и программистов. Конструкторы рисуют логику работы системы, далее по построенной графической схеме строиться код и вручную оптимизируется под конкретный вычислитель. Так что думаю не всё там было полностью автоматизированно.

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

Да уже тут несколько раз сформировали.

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

В том числе и в ссылке выше в разделе "Что предоставляют сценарии?" И в задаче про "луноход".
Повторю еще вопрос, раз тема пока не заглохла:

Scorpio писал(а):В той-же ROS наверняка тоже предполагается место, где роботу надо явно описать последовательность каких-то действий.
- Для чего нужна ROS? - чтобы не писать самому SLAM,
- Для чего нужен SLAM? - чтобы проехать в определенную точку на карте,
- Для чего нам туда ехать? - чтобы сказать "Привет, Вася!".
Это уже сценарий. Что в ROS все равно где и как его записать?

это формулировка "обо всём и ни о чём конкретном".

Scorpio писал(а):Повторю еще вопрос, раз тема пока не заглохла:

Scorpio писал(а):В той-же ROS наверняка тоже предполагается место, где роботу надо явно описать последовательность каких-то действий.
- Для чего нужна ROS? - чтобы не писать самому SLAM,
- Для чего нужен SLAM? - чтобы проехать в определенную точку на карте,
- Для чего нам туда ехать? - чтобы сказать "Привет, Вася!".
Это уже сценарий. Что в ROS все равно где и как его записать?

Нет там такого специально выдуманного места

И в указанной схеме - вдруг это не сценарий, а еще один уровень, над которым может быть ещё один вопрос - зачем говорить "привет вася!" кому-то? И так далее.
Где остановиться и сказать "вот это уже сценарий" - это вопрос разработчика, а не платформы (если вообще есть смысл ставить такой вопрос).

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