roboforum.ru

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

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

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

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


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

Так у меня и так описан протокол:
wiki/%D0%A8%D0%BB%D1%8E%D0%B7-%D0%BA%D0%BE%D0%BD%D1%82%D1%80%D0%BE%D0%BB%D0%BB%D0%B5%D1%80_GATE-A8D8M2
см. раздел "Формат обмена данными".

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

любое мнение приветствуется. аргументы желательны


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


каждый блок производит действие, результат передается следующему блоку и т.д. В разрабатываемой студии аналогично. Связи будут в дальнейшем прорисованы и могут быть даже при "отладке" анимированы.
для примера:
здесь можно посмотреть как выглядит разработка Microsoft-а
а так выглядит визуальная среда Lego



вариант

не отвергается. визуальная среда - это еще один [другой] способ программировать. Есть люди плохо понимающие тексты - разные степени дислексии, или просто боязнь вникать с незнакомые термины, запоминать их.


разрабатывается способ программирования


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


заманчиво, думал об этом. разумно использовать для расширения списка команд внутри робота - как программы или резидентные модули в dos-е, например.


часто достаточно добавить нужное, если нет веского мотива все сначала написать, иначе дорого [по времени] получится. Если упомянутый dos обеспечит нужную функциональность - не вижу причин его отвергать.

В общем я пока с помощью телепатии не смог понять чего требуется от протокола и как его кто себе представляет

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

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



те же яйца что и дерево алгоритма . только обрисовано красиво. о таком я и говорю.



мало понятно что тут.



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


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

таким образом будет 2 способа - создание автономной прошивки через уровень абстракции, либо непосредственное руление в онлайн режиме.


если...
я не вижу преимуществ доса перед описанными выше 2-мя методами управления роботом.

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

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

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

Надо определиться что делаем мы.

Если классический подход, тогда надо делать блок-схемы алгоритмов в которые класть команды миниботу.

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

VPL мелкомягких очень похож на блоки в алгоритме. только я бы скорее придерживался стандартных обозначений блоков. так будет и проще объяснять алгоритмы и понятнее будет что блок делает.

ветвления есть - базовая активити ("base activity" - так это в MSRS называется) "условие" - у нее есть вход и 2 выхода да/нет. Циклы через нее и активити "объединение" (или "делать") реализуются.


у них больше народу над этим работает - в первых релизах не так красиво было


в youtube можно посмотреть


о прорисовке связей упоминал выше. переменные имеются (как и константы)


надеюсь детьми поначалу будет ассоциироваться с "маленьким волшебством"


для этого придумывался basic, например


dos-это лишь более высокий [самодостаточный] уровень абстракции

ИМХО, протокол подобного плана должен обеспечивать по выбору при инициализации обмена:
1 - потоковая передача команд, можно даже сказать запись регистров и их чтение, а также робот должен ругаться на событи по прерываниям а-ля сработал бампер.. тоесть мк на роботе является транстпортом и вс обработка идет на ПК, такое интересно и нужно с тем же техническим зрением..
2 - выполнение заранее созданных программ, в принципе можно даже писать их во флешку и бутлоадером грузить в МК, тут вот только предел перезаписи флеша мешается .. или как-то иначе реализовать работу кучи разных программ по выборы...

_________________
«Как сердцу выразить себя? … Мысль изреченная есть ложь!»
В этом мире меня подводит доброта и порядочность...
"двое смотрят в лужу, один видит лужу, другой отраженные в ней звезды"

хорошее резюме (обобщение) дискуссии.
по первому пункту подходит шлюз-контроллер, по второму dos? (если dos такое может)


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

по первому - да, а по второму, так дос вроде как только с файликами работает...



надо взять спецификацию протокола dead -a все. там должно быть достаточно.

У меня команды только на исполнение, в отличие от теле-режима в котором команды идут по радио в случае интерпретатора на борту надо туда включать будет переменные, формулы, циклы, ветвления и т.п.

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

не нужно. только контроль датчиков и исполнение. т.е. надо доделать контроль датчиков.