roboforum.ru

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

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

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

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

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

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

Так у меня и так описан протокол:
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
см. раздел "Формат обмена данными".

frig писал(а):а мне не нравится. вы уж простите за честное мнение.

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

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

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


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

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

вариант

даже просто васик понятнее.

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

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

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

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

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

компилить наверное проще через С. т.е. из софтины в С а потом компилятором из С...

? получать сразу прошивку, лить её и все. а для "телеруления" надо dead-a подергать. у него в прошивке реализовано.

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

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

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

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

однако вот пример из школьного задачника:

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

здесь можно посмотреть как выглядит разработка Microsoft-а

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

а так выглядит визуальная среда Lego

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

здесь можно посмотреть как выглядит разработка Microsoft-а

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

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

а так выглядит визуальная среда Lego

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

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

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

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

как шаманство

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

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

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

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

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

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

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

EdGull писал(а):я считаю что нужно зафиксировать стандарт на передоваемые комманды боту.

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

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

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

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

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

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

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

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