roboforum.ru

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

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

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

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

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

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

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

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


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

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

вариант

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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