Создаем ROBO_API

DI HALT

Пища для размышлений:

Виртуальные машины

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

Orcinus Orca

Т.е. ты хочешь сделать некий интерпретатор на котором уже будет выполнятся определенный байт-код? Какие требования к байт коду? Одно-байтиный или дву-байтные команды? Или с переменной длинной?

Условные операции там точно нужны. Например, если ты должен развернуться на 90 градусов, а тут у тебя сработал датчик касания. Датчик касания может обработаться подсознательной частью робота (отъехать на пол-оборота в противоположную сторону), но из-за этого команда будет выполнена не верно.

Операции задержки, типа нопов. Даже с аргументом в миллисекндах.

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

SWG

Думаю, чтобы не начинать на пустом месте, в качестве информации для размышления можно ознакомиться с этим: http://ironfelix.ru/modules.php?name=Pa ... age&pid=54
Могу также предложить для ознакомления систему команд, реализованную уже в моем роботе (обмен между ним и виртуальным пультом в компьютере). Только мне надо их аккуратно оформить, снабдив подробными комментариями.

Svensson

Здравствуйте, я вот только зарегистрировался, поскольку тема мне интересна самому.
Давно уже думаю над реализацией ВМ.
Пока не сложилось в голове следующее: как организовать взаимодействие задач нижнего уровня в многозадачной среде в рамках ВМ.
То есть ВМ - это, в моем понимании, некий новый уровень абстракции над кодом, чтобы, грубо говоря, почти любой чайник мог написать код (в терминах данной ВМ), который будет выполняться безопасно. Это будут некие отдельные функции или даже задачи, например: "Задача нагреватель: Включить нагреватель, ожидать температуры Х и далее ее поддерживать", "Задача Индикация: Индицировать текущую температуру, при достижении заданной мигать" и так далее. Все это работает параллельно.
Так вот меня волнует, как в терминах ВМ описать эти задачи? Чтобы любой пользователь мог их использовать достаточно просто.
Опять же: взаимодействие м/у задачами (сообщения? семафоры?)
Вот такие у меня пока нестройные мысли на этот счет.

DI HALT

Код естественно переменной длинны, большой проблемы это не создаст.
Первый байт команда - второй операнды.

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

DI HALT

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

DI HALT

Цитата:

"Задача нагреватель: Включить нагреватель, ожидать температуры Х и далее ее поддерживать", "Задача Индикация: Индицировать текущую температуру, при достижении заданной мигать" и так далее. Все это работает параллельно.

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

Orcinus Orca

Код с переменными длинами команд проблем не составит. Но одно дело знать что у нас все операции двухбайтные и если требуется пропустить 50 операций, то мы просто прыгнем на 100 байт вперед (всяко будет курсор следящий за местом выполнения байт-кода); и совсем другое когда придется просмотреть весь код вычленяя код операции от его аргументов (в этом случае 50 команд могут быть и через 51 байт и через 200 байт).

Кстати, нужны команды отладчика. А там внутри уже сами решим кто на ЛЦД выведет текст, кто в КОМ-порт его отрыгнет.

DI HALT

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

SWG

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

Код:

Формат команды: $KХХx
 где: $ = "$" (Hex 36)  - признак команды
      "K" = (Hex 00-FF) - код команды (1й байт)
      "X" = (Hex 00-FF) - параметры команды. (2,3й байт). При отсутствии заменяется 0.
      "x" = (Hex 00-FF) - параметр команды. (4й байт). При отсутствии заменяется 0. Как вариант - использование как контрольная сумма.

  '0' (Hex 30) - Стоп. (Оба).   2,3,4 байт могут задавать дополнительные условия. Пока игнорируются.
  '1' (Hex 31) - Оба вперед.    2 и 3 байт - путь левого и правого колеса(пока - время работы двигателей).
  '2' (Hex 32) - Оба назад.     2 и 3 байт - путь левого и правого колеса(пока - время работы двигателей).
  '3' (Hex 33) - Левый вперед,  Правый назад. 2байт - путь левого, 3байт - правого.
  '4' (Hex 34) - Правый вперед, Левый назад. 2байт - путь левого, 3байт - правого.
  '5' (Hex 35) - Левый вперед,  Правый стоп. 2байт - путь.
  '6' (Hex 36) - Правый вперед, Левый стоп. 3байт - путь.
  '7' (Hex 37) - Левый назад,   Правый стоп. 2байт - путь.
  '8' (Hex 38) - Правый назад,  Левый стоп. 3байт - путь.
  '9' (Hex 39) - Скорость, 2байт - скорость (Длит. ШИМ_1), 3байт - скорость (Длит. ШИМ_2).
  'B' (Hex 42) - Запрос состояния датчиков бамперов. Измерить и выдать в RS232 (радиоканал)
  'V' (Hex 55) - Измерить и выдать в RS232 (радиоканал) напр. аккумулятора.
  'Z' (Hex 5A) - Пищим. 2байт - время в 1/100 сек. (макс. 2,55сек).

  Пока не подключил еще датчики одометров, поэтому вместо пути левого и правого колеса -задаю время работы двигателей в 1/10сек).

У контроллера поворотной платформы будут свои команды с действиями типа:

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

И еще в том же духе, пока еще в стадии разработки.

Orcinus Orca

Шаги в обратную сторону можно реализовать повторным прогоном с дополнительным курсором. Но тут встает другая проблема, количество повторных прогонов равно количеству отшагиваемых команд. Это дополнительное время. Либо создать массив векторов с адресами команд, но это огромное расточительство памяти. Я думаю, что лучше процессорным временем на шагание пожертвовать.

bevice

Написать компилятор для языка типа ассемблера труда не составит, заодно и проблем с адресами переходов не будет, а при дальнейшем раскуривании можно и что-то вроде C/Pascal соорудить с не сильно замороченным синтаксисом.

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

SWG

Orcinus Orca писал(а):

Код с переменными длинами команд проблем не составит. Но одно дело знать что у нас все операции двухбайтные и если требуется пропустить 50 операций, то мы просто прыгнем на 100 байт вперед (всяко будет курсор следящий за местом выполнения байт-кода); и совсем другое когда придется просмотреть весь код вычленяя код операции от его аргументов (в этом случае 50 команд могут быть и через 51 байт и через 200 байт).

Не понял. Зачем нам куда-то прыгать, тем более считать операции? Если подразумевается пропуск команды, так она должна рассматриваться как единый обьект, независимо от длины кода ее обработчика. Команда может иметь состояние (статус) типа : "Исполнение", "Ожидание события (флажка, обнуления таймера, срабатывания датчика, конца передачи и т.д.)", "Выполнена", "Отложена (поставлена в очередь?)", может выполняться частями или целиком, но для диспетчера она в любом случае - одно целое! Иначе это не команда, а список неизвестно чего...

Цитата:

Шаги в обратную сторону можно реализовать повторным прогоном с дополнительным курсором. Но тут встает другая проблема, количество повторных прогонов равно количеству отшагиваемых команд. Это дополнительное время. Либо создать массив векторов с адресами команд, но это огромное расточительство памяти. Я думаю, что лучше процессорным временем на шагание пожертвовать.

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

aeore

Интересная тема, приму участие :)

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

SWG

aeore писал(а):

Интересная тема, приму участие :)

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

Да уж лучше сразу тогда в контроллер VISTA запихнуть и юзать RoboAPI от MicroSoft... Чего зря напрягаться. ("Все украдено до нас!")

aeore

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

Мне данный проект представляется компилятором скриптов на ББ, байт-код которых будет выполнять робот в пределах определенной среды и набора устройств.

aeore

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

SWG

aeore писал(а):

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

Вот модуль из моей программы для обработки 13 команд, приведенных выше. Весь главный цикл, лишь частью которого он является, занял в памяти программ 697 байт (вместе с одометрами колес). Вся программа полностью заняла 1601 байт ПЗУ (20%) и 85 байт (24%) ОЗУ. Главный цикл вертится с периодом 250микросекунд при тактовой 16МГц. (PIC16F876).
Строки считайте сами:

Код:

//----- Дешифрация команды! -----

    if SSP_2.7 = 1 then  // Дешифрация команды.
      begin
        s1 := Buf_prm[1]; // Код команды.
        if cur_prm >1 then s2 := Buf_prm[2] else s2 := 0;
        if cur_prm >2 then s3 := Buf_prm[3] else s3 := 0;
        if cur_prm >3 then s4 := Buf_prm[4] else s4 := 0;

//  0 ($30) - Стоп. (Оба). 2 байт может задавать дополнительные условия.
        if s1 = '0' then
          begin
            SSP_1.0 := 0; // Работа ДВ_ЛЕВ  двигателя закончена.
            SSP_1.1 := 0; // Работа ДВ_ПРАВ двигателя закончена.
            DWL_2   := 0; // Время работы заданное.
            DWP_2   := 0; // Время работы заданное.
          end;

//  1 ($31) - Оба вперед.  2байт - путь.
        if s1 = '1' then
          begin
            SSP_1.0 := 1; // Работа ДВ_ЛЕВ  двигателя НЕ закончена.
            SSP_1.1 := 1; // Работа ДВ_ПРАВ двигателя НЕ закончена.
            SSP_1.2 := 0; // Реверс ДВ_ЛЕВ
            SSP_1.3 := 0; // Реверс ДВ_ПРАВ
            DWL_2   := s2;// Время работы заданное.
            DWP_2   := s3;// Время работы заданное.
          end;

//  2 ($32) - Оба назад.   2байт - путь.
        if s1 = '2' then
          begin
            SSP_1.0 := 1; // Работа ДВ_ЛЕВ  двигателя НЕ закончена.
            SSP_1.1 := 1; // Работа ДВ_ПРАВ двигателя НЕ закончена.
            SSP_1.2 := 1; // Реверс ДВ_ЛЕВ
            SSP_1.3 := 1; // Реверс ДВ_ПРАВ
            DWL_2   := s2;// Время работы заданное.
            DWP_2   := s3;// Время работы заданное.
          end;

//  3 ($33) - Левый вперед, Правый назад. 2байт - путь левого, 3байт - правого.
        if s1 = '3' then
          begin
            SSP_1.0 := 1; // Работа ДВ_ЛЕВ  двигателя НЕ закончена.
            SSP_1.1 := 1; // Работа ДВ_ПРАВ двигателя НЕ закончена.
            SSP_1.2 := 0; // Реверс ДВ_ЛЕВ
            SSP_1.3 := 1; // Реверс ДВ_ПРАВ
            DWL_2   := s2;// Время работы заданное.
            DWP_2   := s3;// Время работы заданное.
          end;

//  4 ($34) - Правый вперед, Левый назад. 2байт - путь левого, 3байт - правого.
        if s1 = '4' then
          begin
            SSP_1.0 := 1; // Работа ДВ_ЛЕВ  двигателя НЕ закончена.
            SSP_1.1 := 1; // Работа ДВ_ПРАВ двигателя НЕ закончена.
            SSP_1.2 := 1; // Реверс ДВ_ЛЕВ
            SSP_1.3 := 0; // Реверс ДВ_ПРАВ
            DWL_2   := s2;// Время работы заданное.
            DWP_2   := s3;// Время работы заданное.
          end;

//  5 ($35) - Левый вперед, Правый стоп. 2байт - путь.
        if s1 = '5' then
          begin
            SSP_1.0 := 1; // Работа ДВ_ЛЕВ  двигателя НЕ закончена.
            SSP_1.1 := 0; // Работа ДВ_ПРАВ двигателя закончена.
            SSP_1.2 := 0; // Реверс ДВ_ЛЕВ
            SSP_1.3 := 0; // Реверс ДВ_ПРАВ
            DWL_2   := s2;// Время работы заданное.
            DWP_2   := 0; // Время работы заданное.
          end;

//  6 ($36) - Правый вперед, Левый стоп. 2байт - путь.
        if s1 = '6' then
          begin
            SSP_1.0 := 0; // Работа ДВ_ЛЕВ  двигателя закончена.
            SSP_1.1 := 1; // Работа ДВ_ПРАВ двигателя НЕ закончена.
            SSP_1.2 := 0; // Реверс ДВ_ЛЕВ
            SSP_1.3 := 0; // Реверс ДВ_ПРАВ
            DWL_2   := 0; // Время работы заданное.
            DWP_2   := s3;// Время работы заданное.
          end;

//  7 ($37) - Левый назад, Правый стоп. 2байт - путь.
        if s1 = '7' then
          begin
            SSP_1.0 := 1; // Работа ДВ_ЛЕВ  двигателя НЕ закончена.
            SSP_1.1 := 0; // Работа ДВ_ПРАВ двигателя закончена.
            SSP_1.2 := 1; // Реверс ДВ_ЛЕВ
            SSP_1.3 := 0; // Реверс ДВ_ПРАВ
            DWL_2   := s2;// Время работы заданное.
            DWP_2   := 0; // Время работы заданное.
          end;

//  8 ($38) - Правый назад, Левый стоп. 2байт - путь.
        if s1 = '8' then
          begin
            SSP_1.0 := 0; // Работа ДВ_ЛЕВ  двигателя закончена.
            SSP_1.1 := 1; // Работа ДВ_ПРАВ двигателя НЕ закончена.
            SSP_1.2 := 0; // Реверс ДВ_ЛЕВ
            SSP_1.3 := 1; // Реверс ДВ_ПРАВ
            DWL_2   := 0; // Время работы заданное.
            DWP_2   := s3;// Время работы заданное.
          end;

//  9 ($39) - Скорость, 2байт - скорость (ШИМ).
        if s1 = '9' then
          begin
            current_duty_1 := s2; // Длит. ШИМ_1
            current_duty_2 := s3; // Длит. ШИМ_2
          end;

//  B ($42) - Бамперы, 2байт Х, - запрос состояния датчиков бамперов.
        if s1 = 'B' then SSP_2.4 := 1; //- Выдать в канал Состояние бамперов.

//  V ($55) - Измерить и выдать в RS232 напр. аккумулятора.
        if s1 = 'U' then SSP_1.4 := 1; // = Меряем V батареи!
        
//  Z ($5A) - Пищим. 2байт - время в 1/100 сек. (макс. 2,55сек).
        if s1 = 'Z' then
          begin
            SSP_1.7 := 1;
            T_sound := s2; //Время работы пищалки заданное.
          end;

        SSP_2.5  := 0; // нет принятой команды.
        SSP_2.7  := 0; // Дешифрация команды завершена.
        Sost_Prm := 0; // Очистить Слово состояния  приема.
        cur_prm  := 0; // Курсор приема.
      end; // if SSP_2.7 = 1 - Дешифрация команды

//------ Конец - Дешифрация команды  ----------

Остальная часть главного цикла в соответствии с расставленными флажками слов состояния программы SSP_1 и SSP_2 принимает и выдает сообщения в канал, устанавливает коэффициенты ШИМ, меряет напряжение аккумулятора, включает/выкл. двигатели, общается с контроллером бамперов, следит за датчиками одометров, считает пройденный путь, и т.д.
Только и делов. Будет надо - вставлю еще хоть сотню команд.

aeore

:)
Это не виртуальная машина - это дешифратор команд.

aeore

Как вы зададите такое условие своему роботу:

"Поехать вперед, не доезжая до стены 1 метр остановится, развернуться, и вернуться в первоначальную позицию"

?

SWG

aeore писал(а):

:)
Это не виртуальная машина - это дешифратор команд.

Естественно. Я же не собираюсь в 8кб памяти программ VISTA пихать. Все, что мне надо, я на своем любимом флаговом автомате сделаю. Безо всякой мороки с виртуальными машинами, операционками... Тем более в контроллерах нижнего уровня - ходовом, бамперов, башни... Вот для центрального - может, и озабочусь операционкой. И то пока особой необходимости не вижу. Лучше больше интеллекта напихать, чем занимать место ненужными оболочками. Думаю, Мега 128 или аналогичный по возможностям из PIC24-32 вполне справятся.
Не важен процесс, важен результат. С операционкой или без - лишь бы свои задачи выполняло. Лет 20-25 назад на работе на 2-4кб ПЗУ я такие многозадачные контроллеры реального времени делал...

aeore

Да, но мне кажется, что в этой теме идет обсуждение ВМ, а не флаговых автоматов для атомарных действий :) Вот я и предлагаю думать в соответствующем направлении. В 8 КБ памяти можно много чего напихать, может и ВМ с RISC набором команд поместится. А весь интеллект будет задаваться с помощью этого самого байт-кода, так что ничего более там не будет. А так как байт-код будет читаться как данные, то место его хранения значения не имеет - хоть на компакт-флеш

SWG

aeore писал(а):

Как вы зададите такое условие своему роботу:
"Поехать вперед, не доезжая до стены 1 метр остановится, развернуться, и вернуться в первоначальную позицию"?

Это уже будет функция не ходового, а центрального контроллера, а он будет работать с картами окружающего пространства, промерянного дальномерами и разбитого на квадраты.
Тут скорее я бы вам задал вопрос: Как вы с пульта или компьютера сформулируете роботу задание: "Поехать вперед, не доезжая до стены 1 метр остановится, развернуться, и вернуться в первоначальную позицию"? Каким формализованным языком или набором команд?
Я при своем вполне логичном и рациональном подходе скорее дал бы задание "Проехать в точку с координатами ХУ и вернуться в точку отправления". Трассу робот выберет сам, исходя из кратчайшего пути и наличия препятствий. А ходовой контроллер от центрального будет получать те же команды пути и скорости, что я уже отладил и описал выше.

SWG

aeore писал(а):

Да, но мне кажется, что в этой теме идет обсуждение ВМ, а не флаговых автоматов для атомарных действий :) Вот я и предлагаю думать в соответствующем направлении. В 8 КБ памяти можно много чего напихать, может и ВМ с RISC набором команд поместится. А весь интеллект будет задаваться с помощью этого самого байт-кода, так что ничего более там не будет. А так как байт-код будет читаться как данные, то место его хранения значения не имеет - хоть на компакт-флеш

ROBO_API - это не обязательно ВМ. Это всего лишь инструмент, с помощью которого можно создавать программы для роботов. А инструмент бывает разный, и вовсе не обязательно забивать гвозди микроскопом, хоть и им тоже можно. Я предлагаю для этого молоток. А микроскоп приберегу для чего-нибудь другого, если будет нужно. Кстати, микроскоп у меня был. Лет 30 назад. Я им побаловался, удовлетворил свое любопытство, и продал. Не гвозди же им забивать...

bevice

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

>"Поехать вперед, не доезжая до стены 1 метр остановится, развернуться, и вернуться в первоначальную позицию"
В итоге (как я думаю) должно получиться что-то вроде
пока(Датчик(дальномер)<100см) {
Двигаться(вперед,1см);
}
Компилятор переведет это в что-то вроде

:Метка1
Получить Дальномер, х
Сравнить х,100см
ЕслиМеньшеПереход на метка2
Сервопривод ПравоеКолесо, 1см
Сервопривод ЛевоеКолесо, 1см
ЖдатьВыполнения ЛевоеКолесо И ПравоеКолесо

Переход Метка1
:Метка2
Такого рода инструкции уже можно довольно просто написать (а у SWG они уже реализованы)
Самое интересное будет организовать универсальность. Например унифицировать все обращения к датчикам, сервоприводам, етс. Тогда модификция получившейся ОС для нового робота будем минимальна -- зарегистрировать при старте устройства и написать их обработчики. А для конечного пользователя будет абсолютно неважно, опрашивает он датчик напряжения аккумулятора или дальномер, едет вперед или машет рукой

Easyelectronics.ru

Создаем ROBO_API

Кто сейчас на конференции