roboforum.ru

ИМХО основная задача - это не решить ряд задачек типа "по линии кататься" и т.п., а - обучение школьников программированию. А уже исходя из этой задачи надо строить всё остальное.

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

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

А само по себе многозадачное ядро... сейчас откопаю самое тупое:



Я ТЗ обсуждаю... а куда - какая разница, еще не известно, что сложнее.

2Michael_K: разница в ресурсах

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

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

Предлагаю поправку: обучение не программированию, а УПРАВЛЕНИЮ (отсюда и "кибернетика" - наука об управлении). Программировать детей научат на уроках информатики, если повезет со школой и преподавателем. А здесь нам нужно сконцентрироваться на управлении с обратной связью.

Набор задач будет постоянно меняться. Взятое в качестве примера - правильно. Движение в круге, по линии, объезд предметов, управлением манипулятором. Это чистые классические задачи, их решение может быть коротким и изящным. Но перед детьми будут вставать кОмплексные задачи, в которых придется воспользоваться полученными навыками из джентльменского набора. Например, такая: движение по линии с разрывом вдоль стенки, захват предмета, возвращение и установка его в нужный ангар, расположение которого определяется крупно нарисованным штрих-кодом. И тут наша среда программирования должна показать свои лучшие стороны .

Вот первые 4 уровня, пока что относящиеся к 5-7 классам. Надеюсь, что через пару лет им этого уже будет недостаточно.

В качестве комплексной задачи можно взять футбол роботов, в который могут играть даже семиклассники. Есть специальные соревнования для детей на Robocup.
Фото1
Фото2

Сергей, футбол роботов - это хорошо, но не могли бы вы, вместо ни о чем не говорящих фоток,
выложить несколько примеров графического "кода" (не самых навороченных и не самых тупых - типичных)
Я имею в виду 5-7 классы... (Думаю, что дальше при желании вполне можно переходить на более
"низкоуровневые" языки).

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

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

Пример 1. Нечто аналогичное можно сделать прямо на NXT без компьютера.

Пример 2. Тоже самое с помощью ветвления.

Пример 3. Вложенные ветвления.

Пример 4. Другой подход к решению той же задачи.

Пример 5. Как обеспечить гарантированно прямолинейное движение?

Пример 6. Двигаться по азимуту, например, к воротам противника.

Пример 7. Двигаться вдоль неровной стенки с помощью ультразвукового датчика.

Пример 8. Использование сторожевого таймера в параллельной задаче для защиты от застреваний.

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

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

Так ли это на самом деле?

Чистых "веревок данных" (которые бы соединяли источник данных с получателем) я не увидел.
Это неудобно, или это ограничения языка, или это трудно в понимании?

- Используются ли пользовательские функции (подпрограммы, субвиайчики)? Насколько широко?

- Существует ли механизм передачи в них (в пользовательские функции) параметров и получения
из них результатов? Или все это делается через ручное назначение контейнеров ("баночек")?
Насколько такие параметрические подпрограммы и механизмы нужны или полезны на начальных этапах обучения?
Можно ли использовать одну и ту же пользовательскую функцию в разных (параллельно исполняющихся) задачах?

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

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

- И совсем дурацкий вопрос... что-то везде по-разному пишут - там арифметика с плавающей точкой вообще есть?

Извините, если нагрузил

Все празднуют... С Рождеством!

Да, Михаил. В стандартном Роболаб нет веревок данных между командами, весь обмен реализован через переменные-контейнеры или константы, которые называются модификаторами. Правда, там есть начинка Лабвью, которую можно достать через режим Исследователь (Projects->Oprions->Controls/Function Palettes->Palette View->Investigator 5new), в ней найдется всякое.

Здесь некоторая недоработка. Например, детям не предлагается возможность прицепить на вход ветвления результат работы логического выражения (только через глубоко зарытые возможности Labview с преобразованием логики в число).

Широко используются подпрограммы. Их может быть до 8 шт. Вызываются по номеру, причем, что удобно, номер можно параметризовать. Обмен данными исключительно через глобальные переменные (контейнеры).

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

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

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

Вообще в Роболабе есть хороший встроенный Help с примерами и контекстная подсказка. Для вызова надо установить блок на поле программы и через контекстное меню выбрать Help или нажать Ctrl-H и водить курсором по блокам.

Есть. Имеется тип float, а блок f(x) понимает основной набор математических функций. Для этого нужен патч 2.9.4.

Да что-то качать его не хочется совсем

Из патриотических чувств?

Ну леги-то нету у меня
Скачать и поставить корягу в 80 метров только ради того, чтобы заглянуть в хелп?
(а потом избавляться от огрызков лабвью-рантаймов...) Ну его нафиг!

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

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

Недостаток - не предназначены для частых подключений\отключений, вытащить розетку из разъема можно только очень крепко удерживая пальцами и раскачивая, а то и за провод. Оба способа ведут к разрушению контактов или отрыву проводов Те разъемы на фото как вытаскивают?

Разъемы типа SHARP'овских должны нормально подойти, они такого же типа как Sergey Filippov указал.

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