roboforum.ru

Хорошо. Я не буду эту тему засорять. Однако мнение у меня такое. Чему только не учи, а знания люди получают сами на стороне. Наверное 97% знаний в ВУЗе я получил именно так. А то, что преподавали, пригодилось в жизни процентов на 20-30. Например, нам преподавал профессор узлы ЭВМ на отдельных транзисторах и лампах, когда уже была интегральная "Электроника 60". Учили сумматоры с различными видами сквозного переноса и т.д. и т.п. Изучал языки Фортран, ассемблер, устройство мультизадачной ОС System-360. И где они пригодились, эти мои конкретные знания?

Я на своей шкуре испытал то, о чем говорю. И наверняка многие могут сказать аналогично. Не учите прошлому. Не учите будущему. Учите детей способностям самообучаться. А это и есть метапрограммирование, только не роботов а детей.

Michael_K писал(а):Все это, несмотря на красивые слова, в очень упрощенной реализации.

А что именно и в какую сторону предлагается сильно упрощать? И главное - что будем использовать готовое?

Добавлено спустя 2 минуты 5 секунд:

Виктор Казаринов писал(а):Например, нам преподавал профессор узлы ЭВМ на отдельных транзисторах и лампах, когда уже была интегральная "Электроника 60". Учили сумматоры с различными видами сквозного переноса и т.д. и т.п.

Так тогда сумматоры только-только появились и уже ого-го сколько всего дали, а продукционным системам сейчас уже ого-го сколько лет и они пока ничего грандиозного не дали

Добавлено спустя 40 секунд:

Виктор Казаринов писал(а):Не учите прошлому. Не учите будущему. Учите детей способностям самообучаться. А это и есть метапрограммирование, только не роботов а детей.

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

2Dead: именно поэтому я предлагаю рассмотреть задачи самообучения роботов. Т.е. роботы и дети смогли бы вместе самообучаться, влияя друг на друга. А вы пытаетесь рассматривать станок с ЧПУ в качестве робота. Это- совершенно разные вещи. Называйте вещи своими именами.

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

Предлагаю отложить сложные и совершенные системы до версии 3.0
Сейчас вопрос стоит в минимальной дастаточности, очерченной Сергеем. По моему мнению даже он добавил кое-что из версии 2.0, хоть и согласен, что оно было-бы необходимое прямо сейчас.
Может пора разделять тему на направления - железо, софт, v2.0?

Sergey Filippov писал(а):1. Графическое представление команд с явным заданием последовательности выполнения.
2. Масштабирование графического окна (почему не сделали этого в NXT-G? - в Ma-Vin есть).
3. Явное указание параметров (модификаторов) выполнения команд. Глядя на программу, ребенок должен точно сказать, что в ней происходит. (В NXT-G какие-то едва различимые пиктограммы на блоке, а вся информация в отдельной панели, как в Object Inspector - ненаглядно). Можно ввести опцию скрывать параметры.
4. Очень желательна визуализация. Т.е. инициализирует пятиклассник моторы и ему предлагается указать их на роботе в маленьком окошке. Ряд стандартных задач тоже можно визуализировать: движение по линии и прочее. Это просто, а эффект даст потрясающий!
5. Ветвления не только по показаниям датчиков или значениям переменных, но и по логическим выражениям.
6. Циклы тоже. И с предусловием, и с постусловием. Выделенный параметр (счетчик) цикла.
7. Набор стандартных функций, включая тригонометрию и логарифмы. Скобки в выражениях!!!
8. Вставка кусков текстового кода вместо отдельных блоков. Если язык будет расширяем таким образом, он может стать невероятно популярен.
9. Именуемые переменные разных типов, включая строковый.
10. Массивы хотя бы до 256 элементов. Лучше - больше.
11. Целый тип четырехбайтовый.
12. Управление выводом на экран.
13. Управление задержками.
14. Таймеры с точностью до 1 мс, штуки четыре.
15. Команды типа "Сделай" и команды типа "Жди события", а также их композиции: "Крути моторы 720 градусов".
16. Веселый дебаггер, который, например, может вербализовать содержимое блоков.
17. Измерение показаний датчиков в процентах, мощность моторов тоже: от -100 до 100. Или от -512 до 511.
18. Функционал для сетевого соединения и обмена данными: проводной и беспроводной.
19. Подпрограммы, вызываемые по имени.
20. Возможность преобразования графического кода в C или Паскаль и продолжения программирования на нем.
21. Многозадачность. Глобальные переменные.

Давайте прикинем, что из существующих языков под это подойдёт?
Я думаю вариантов немного - C / Basic / Pascal / Java

Добавлено спустя 2 минуты 11 секунд:
Еще есть сам Lego NBC

По моему мнению даже он добавил кое-что из версии 2.0

Мне тоже так показалось...

И главное - что будем использовать готовое?

Это хороший вопрос... Я потратил ночку, чтобы поискать, что в этом направлении сделано.
Вообще, подобные системы есть (исключая разве что графический ввод), только вот...
они в таком интегрированном и поддерживаемом виде денег стОят.
Кто готов вложиться?
По такой схеме работают всякие С-stamp, Basic-stamp, http://www.zbasic.net/
В основном, правда, это бэйсики. И, если честно, я склоняюсь к такому же решению.

Но меня, честно говоря, не очень пугает перспектива наваять такую канитель с нуля.
Понятно, что в упрощенном виде.

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

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

Первое, что подлежит упрощению - это, по-моему, язык:
Выкинуть к чертовой матери "лишние" чары, флоаты, структуры,
юньоны, тайпдефы, указатели, ссылки итп.

Второе - операционная среда.
Только равноценные потоки, которые обмениваются через глобальные переменные и все.

Добавлено спустя 4 минуты 18 секунд:

C / Basic / Pascal / Java

Склоняюсь к подмножеству Си или бэйсика...

Написание программы начинается с конфигурации, где дите показывает компу,
в какую дырку (порт контроллера) у него что воткнуто.
Тут задаются режимы работы порта и портам даются имена
(например, вот эта дырка работает на выход шимом и называется "ПравыйМотор",
эта дырка работает цифровым входом и называется "ЗаднийБампер").
Конфигурация не может меняться по ходу выполнения программы.

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

Соответственно можно сохранить конфигурацию в файл,
загрузить из файла, или загрузить из контроллера
(в контроллер конфигурация загружается вместе с программой и запоминается)

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

Все переменные - публичные члены классов.
Классы могут описывать функцию (в том числе функцию самого
верхнего уровня) или устройство.

Так, например, есть переменная ПравыйМотор.Скорость или МояПерваяПрограмма.СчетчикУгловВКомнате.
Переменные без прямого указания класса - это члены той функции,
в которой они написаны (локальные). То есть можно просто написать "СчетчикУгловВКомнате"

Переменная может принимать строковое или числовое значение.
Типы и переменные заранее не объявляется.

Набор "ключевых слов" языка такой:
- Условие (if)
- Цикл (for, while...)
- Выбор варианта (switch)
- Новый процесс (new_task)
- простая математика и логика (+-*/= <>) (битовые операции можно, имхо, выкинуть)

Вот чего нашел: http://www.harbaum.org/till/nanovm/index.shtml - Java-машинка для ATMega8/32

Добавлено спустя 2 минуты 27 секунд:
ИМХО веревки-пути данных имеют смысл только если делаем управляемую событиями систему.

Пробовал я пару этих JVM для AVR - игрушка, не более.

Так и делается игрушка мы же конкурента Lego NXT обсуждаем...

Если на игрушечной машинке можно перевозить пару кубиков, это еще не значит, что на ней может ребенок кататься. Образно говоря, тут надо ребенка катать, а эти JVM годятся только на то, чтобы кубики возить. Причем ребенка просто катать, за веревочку. А у лего моторчик какой-никакой. Зато руль не для всех удобный. Как-то так

А в чем игрушечность особая? Тормозит совсем жестко? Или функционал порезанный сильно?

Ребят, вы конечно, извините, но я не понимаю, в чем тут проблема.

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

Blindman, Dead, вы же серьезные проекты тянете...

Меня гораздо сильнее беспокоит компилятор, например, и визуальная среда программирования.
Но может быть на форуме найдутся люди, которые весело пишут портируемые приложения на PC.