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
Для меня это была новость

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

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

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

Дракон разрабатывался в рамках программы Буран но не применялся в его разработке
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 вместо иерархии реализована идеология сети обмена данными, грубо говоря, через публикацию и подписку, что обеспечивает гораздо больший простор и удобство.