Разработка Open Robotics: Command Line Interface

setar

Command Line Interface (CLI) - дополнительный уровень виртуализации (или абстракции) находящийся на внешнем вычислителе (ноутбук,компьютер,сервер, кпк, микроконтроллер со встроенной ос) и являющийся прослойкой между прошивкой контроллера ORFA и внешним управляющим воздействием (web форма с кнопками управления, секвенсер, пакетный файл, программа ИИ, аппаратный джойстик итд).
Другими словами CLI на вход принимает текстовые команды похожие на "move body forward 5m; status get distance forward_rangemeter;" на выходе выдаётся последовательность ORFA комманд.

К пониманию необходимости дополнительного уровня виртуализации меня привела разработка проекта OR-WiFiServer где для того чтобы подвигать сервами из какой либо web формы мне потребовалось сформировать поток команд ORFA.
При подходе "в лоб" изменении в аппаратной конфигурации (переставили сервы местами или подвинули) автоматически несут в себе необходимость изменения кода web управляющей программы - это не удобно.

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

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

Основное требование - CLI должен быть кросс платформенным в части исходного кода, вполне вероятно его выполнение как на разных ОС (win, linux, Mac OC X) так и на разных процессорах (x86 AVR ARM MIPS)

Для реализации грамотного подхода в программировании предлагаю стандартизовать такие вещи как синтаксис комманд и граф переходов состояний системы.
Синтаксис лучше всего описывать в стандарте [url=http://en.wikipedia.org/wiki/Backus–Naur_Form]BNF[/url]
Графы - пока не знаю

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

Чуть позже я начну писать исходный файл синтаксиса BNF
P.S. Прелесть BNF в том что из рего в автоматическом режиме можно строить документацию этот синтаксис описывающий для применения и так же автоматически строить парсеры-обработчики на С

==========================
обновляемый синтаксис BNF

Код:

<command> ::= move <bodyobj> <lenobj> | get <sensobj> | set <exobj> | user <userobj>
<bodyobj> ::= body | leg[_l|_r]{<digit>} | arm[_l|_r]{<digit>} 
<exobj> ::= motor[_l,_r]{<digit>} 
<sensobj> ::= irsens[_l,_r]{<digit>}
<lenobj> ::= {<digit>}[mm|sm|m]
<userobj> ::= add <username> | del <username> | passwd <username> | auth <username> <password>
<username> ::= {<letter>|<digit>|_}
<password> ::= {<letter>|<digit>|_}
<digit> ::= 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0
<letter> ::= a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r | s | t | u | v | w | x | y | z

=DeaD=

1. Не понял, а зачем на входе текстовые команды, а не просто формат функций библиотек?
2. Надо тогда говорить о наличии файла конфигурации который надо будет менять при перестыковке сервы на другой контроллер и т.п.

setar

1. при вызове из web формы я хочу отобразить состояние заряда батареи, для этого я делаю системный вызов exec "cli battary status"
о каких функциях речь может идти , если я вызываю внешний обработчик на другом языке.
2. безусловно файл конфигурации будет, но может мы решим что это не файл а некая мини БД по типу регистров NVRAM

=DeaD=

А, понял, что-то я ступил про CLI

Ну тогда всё просто, предлагаю команды типа:

setMotorsPercent("base",100,100)
setServoMs("pan",1500)
setDigitalOutput("laser",1)
getAdcVoltage("sharp4")
getAdcVoltage("sharp3")
getDigitalInput("front-bumper")

каждый девайс определяется строкой, в файле конфигурации ему соответствует номер COM-порта, I2C-адрес и номер внутри контроллера.

Michael_K

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

Angel71

я тоже не хо со скобками и запятыми, неудобно для командной строки :oops:

кстати еще неплохоб было заложить систему безопасности (я про доступ), хотяб простенькую. :oops:

а то по вебки отсутствие её рано или поздно аукнется

setar

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

orcli {объект} {команда} [{значение/парамерт}]

Romer

что-то получается похоже на драйвер? драйвер орфы?

Angel71

с кавычками для текста это понятно. Romer, не, это интерфейс для удалённого взаимодействия.

ну как обычная командная строка в линухе и винде, только удалённая (с компа там команды отослать или по веб интерфейсу).

setar

в первый пост добавил начальный пример bnf синтаксиса
для тех кому лень читать стандарт там просто
[] - необязательный параметр
{} - много повторений
<> - оъект (правило)

Добавлено спустя 2 минуты 56 секунд:
вот примеры команд по нему:
>user auth test mypass;
0 - ok
>user auth badtest;
1 - wrong syntax
>move leg_r2 10sm;
0 - ok

Romer

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

setar

CLI находится не важно где главное что он имеет последовательный доступ для подачи команд ORFA
он может находиться как на ноуте который катается вместе с роботом получая команды от локального или удаленного web сервера
так и на сервере имеющем последовательный доступ прямо к контроллеру с ORFA

совсем забыл - будет ещё стандартный код возврата
типа
0 - ok
1 - wrong syntax

blindman

Надо предусмотреть запуск в режиме демона. Команды читаем через стандартный ввод, ответы выдаем в стандартный вывод.

=DeaD=

=DeaD= писал(а):

setMotorsPercent("base",100,100)
setServoMs("pan",1500)
setDigitalOutput("laser",1)
getAdcVoltage("sharp4")
getAdcVoltage("sharp3")
getDigitalInput("front-bumper")

Смысл был не в формате

в формате CLI setServoMs("pan",1500) будет выглядеть например, так:

cli setServoMs:pan:1500

если надо много команд, тогда можно пользовать что-то типа

cli setServoMs:pan:1500 setServoMs:tilt:1700

А как оно будет возвращать значение?

Добавлено спустя 1 минуту 20 секунд:
Может объекты сразу задавать по типам? Будет удобно иметь с одним именем серву и АЦП с неё же.

Vooon

Я думаю нужно изначально делать клиент-сервер.

Т.е. orfad <-> orfactl, где
orfad — демон, держит соединение с одной стороны с ORFA а с другой unix/tcp сокеты, аутентификация, думаю очень хорошо если использовать ssh для шифрации потока;
orfactl — cli интерфейс пользователя, формирует поток ORFA команд для демона.

Добавлено спустя 4 минуты 9 секунд:
А orfad может находиться например на плате OR с сетевым интерфейсом на арме.

roboforum.ru

Правила форума

Разработка Open Robotics: Command Line Interface

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