roboforum.ru

Для простых роботов, гораздо проще аналог FBD или VPL... готовые модули соединяются между собой и всё, для детей это проще, чем множество строк кода... Да и для взрослых
ЗЫ. заодно и цифровую схемотехнику поучат

2kos_ua, dtcDev: Я так понимаю ваша среда не должна особо зависеть от того, что за робот будет к ней подключен, иначе она окажется не расширяемой. Насколько я понимаю - оптимально получать на выходе из вашей среды просто код Си-программы и иметь возможность подключать к вашей программ любой набор специализированных кубиков, которые можно менять для разных роботов или даже для разных наборов функций одного и того же робота. В том числе подключаемыми должны быть наборы типов данных, которые между кубиками передаются. Тогда ваша среда будет унифицирована и сможет быть применена хоть на ПК, хоть на КПК, хоть на МК.

Имхо, проблема только в симуляторе... А нужен ли он?

Симулятор вторичен, его лучше портировать готовый - какой-нибудь из проекта ROS или вообще взять из MSRS...

Это зависит от желаемой "глубины" симуляции

Если серьезно, то конечно вы правы, но раз уж человек спрашивает о "системе команд"...

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

Проблема не в симуляторе.
Проблема в наборе команд.

Т.к. программа подразумевает под собой решение для нескольких платформ (такой функционал в нее заложен, есть возможность загружать данные о МК из специального файла конфигурации), то переписывать код для нескольких платформ не придётся.

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

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

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

2dtcDev: Я не понимаю ваших вопросов с набором команд. Сделайте унифицированный формат в котором в вашу программу поставляется:

1) Набор типов данных;

2) Унифицированный набор блоков который специфичен для разных платформ (инициализация, микроОС, ссылка на компилятор gcc и т.п.) и не виден пользователю вообще кроме как выбор платформы под которую собирать;

3) Набор пользовательских кубиков из которых собственно составляется программа (графическое представление, расположение входов-выходов, программный код, который будет реализовывать этот блок, необходимые вставки инициализации блока и очистки памяти в конце);

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

EdGull писал(а):и вот мы снова вернулись к вопросу стандартизации терминальных команд роботу...

Нифига

ээээээээ, нет. однако накой какие-то команды? непонима. это уже высокий уровень абстракции, до него еще доползти дожить нужно

Что-то, кажется, лыжи не едут... вот только у кого?

Добавлено спустя 2 минуты 7 секунд:
2 dtcDev:
Попробуйте все-таки посмотреть на существующие прототипы...
Неужели не интересно?

у всех едут, тут только две разных точки зрения на реализацию, которые "слегка" не совместимы

А топикстартер еще свою точку зрения сам себе пока не до конца определил

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

"я собираюсь сделать голосовой движок с разбором семантики и интонированием,
скажите пожалуйста, какие слова и каким голосом он должен говорить"...
Ну ахинея же!

Мне кажется, что и во всём мире нет единого мнения...просто, кто то должен сделать выбор

2 dtcDev
Предлагаю простой набор конкретных команд

Код: Выделить всё • Развернуть

СкоростьПравогоМотора(value)            // value от -100 до 100
СкоростьЛевогоМотора(value)             // value от -100 до 100
Var = ЗначениеДискретногоДатчикаN()     // N номер датчика или канала, куда он подключен (от 1 до 9)
                                        // Var примет значение 0 или 1
Var = ЗначениеАналоговогоДатчикаN()     // N номер датчика или канала, куда он подключен (от 1 до 9)
                                        // Var примет значение от -100 до 100
ВыдатьВАналоговыйКаналN(value)          // Выдать в аналоговый канал номер N значение value (ограничивается внутри от -100 до 100)
ЗапуститьТаймерN(timeout)               // Таймер номер N ( (от 1 до 9) начинает отсчитывать timeout времени 
               // timeout - от 0.1 сек до 10 минут
Var = ПроверитьТаймерN()                // Возвращает 0, если timeout времени еще не прошло с момента запуска, 1 - если прошло
Var = НажатаКнопкаПульта()              // Возвращает 1, если была нажата кнопка пульта, 0 - если нет
Var = КомандаСПульта()                  // Возвращает номер нажатой кнопки на пульте
ПроигратьЗвук(sound)         // sound - номер встроенного звука
ЛевыйГлаз(mode)                 // mode определяет режим моргания левым глазом
ПравыйГлаз(mode)         // mode определяет режим моргания правым глазом

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

Код: Выделить всё • Развернуть

#define LeftProximitySensor() (ЗначениеАналоговогоДатчика5()) // К пятому аналоговому каналу подключен левый датчик расстояния
#define HAPPY_SONG 12 // двенадцатый звук называется "Радостная песенка"

А может быть даже и такие:

Код: Выделить всё • Развернуть

#define __hidden__gain_for_left_proximity_ (1.17E-2)

Ну и управляющие конструкции, переменные, арифметика нужны в каком-то виде...
На самом деле, в них-то, по-моему, основная сложность и есть... ну это ж "по-моему"