roboforum.ru

Решил выложить свою версию универсального языка взаимодействия Програма <-> Устройство, но описание дать с привязкой к робототехнике.

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

Беру частный случай - есть шасси робота (корпус, тело, и т.д - "Устройство"), которое всё выполняет, есть програма, которая им управляет. Кроме того, есть програма-транслятор команд для шасси. Задача разработать язык взаимодействия Программа<->Шасси посредством програмы-транслятора.

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

Код: Выделить всё

...
{Device}:=Value      ;запись
  Value:={Device}   ;чтение
...

Где {Device} - псевдоним заданого устройства (логическое имя).
Для перемещаемости кода, положим, что 0≤Value≤1 всегда, и для любого устройства ( Value может быть дробным числом! ). Так напр.:

для концевика: 0 - отпущен, 1 - нажат (или наоборот, как удобнее);
для привода: 0 - выключен; 1 - включён (или наоборот, как удобнее);
для серва: 0 - крайнее левое положение, 1 - крайнее правое положение (или наоборот, как удобнее)
для датчика: 0 - минимум измеряемой величины, 1 - максимум измеряемой величины (или наоборот, как удобнее)
и т.д.

Очевидно, что програма "видит" шасси, как всегда конечное множество устройств (параметров).

Предположим, по направлению информации устройства бывают трёх типов (конструктивая особенность устройства):

1) Доступные непосредственно только для чтения (префикс RD_);
2) Доступные непосредственно только для записи (префикс WD_);
3) Доступные непосредственно для записи и чтения. (те-же префиксы но по контексту команды)

Примечание: префиксы нужны только для читаемости кода (аббревиатура англ. RD - Read Direct, WD - Write Direct)

Кроме того, если учитывать конструктивные особенности узлов шасси (включая шасси в целом как узел), то применяя законы физики, можно получить дополнительные (косвенные) параметры (устройства). Будем обозначать их префиксом RI_ (Read Indirect), WI_ (Write Indirect). Устройства типов RI, WI формируються програмистом на базе Direct-устройств и/или програмой-транслятором в процессе автокалибровки (то есть, самоизучения).

Теперь, как этим пользоваться.
Опишу на простенькой модели.
Предположим, есть колёсная тележка, ходовой двигатель (WD_Engine), которой управляеться пропорционально, и только в одном направлении, таким образом, что 0 - двигатель отключён, 1 - полный вперёд;

На тележке установлен сервопривод руля (WD_Direction), таким образом, что 0 - влево на максимум, 1 - вправо на максимум, 0.5 - прямо);

Также установлен двухосевой акселлерометр (RD_AccTangential, RD_AccNormal),
RD_AccTangential=0 - торможение на максимум
RD_AccNormal=0 - выполнение поворота влево с макс. ускорением.
RD_AccTangential=1 - торможение на максимум
RD_AccNormal=1 - выполнение поворота вправо с макс. ускорением.
RD_AccNormal=0.5 - прямолинейное движение
RD_AccTangential=0.5 - равномерное движение

На ведущем мосту установлен тахометр (RD_Rotation), таким образом, что 0 - оси не вращаеться, 1 - ось вращаеться на макс. оборотах;

Обладая таким набором параметров, можно сформировать несколько Indirect устройств/параметров.

Т.к. WD_Engine доступно только для записи, формируем копию поданой на мотор команды как непрямой датчик (теперь то что записали в WD_Engine, можно прочитать из RI_Engine).

Напр. Датчик достижения заданой скорости ведущим мостом (RI_WheelDone):
RI_WheelDone:=(RI_Engine=RD_Rotation)

Примечание: в результате выполнения логических операций ("<", ">", "<>","=", "<=", ">=") возвращаеться 0 - если ложь, 1 - если истина.

Это конечно хорошо, только вот я не пойму - какой смысл писать "Универсальный язык", когда на нем не реализована еще ни одна задача? Вроде бы сначала реализовать на нем с десяток проектов, а потом показывать всем?

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

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

P/S Хотелось-бы выслушать, из чего именно состоит пачка проблем? (для того и тема открывалась )

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

1. С сервоприводом общепринятый способ работы - передача параметра -угол...0..+угол;

2. Совершенно отсутствуют методы доступа к объектам типа сервопривода, для него по хорошему должны быть свойства минУголФизический, минУголЭтойКонструкции, максУгол.-тоже-самое-, текущий угол, целевой угол, время_на_достижение_целевого_угла;

3. Нет методов составления сложных объектов, типа "Нога робота", у которой есть куча разных параметров и по идее может быть куча полезных методов;

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

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

Чесно говоря я маленько не понял идеи.

На каком уровне работает описанный язык? это протокол управления от Управляющего Устройства  (УУ) к шасси, либо драйвер обеспечивающий поставленную задачу внутри шасси ??

Я продумывал концепцию взаимодействия УУ и шасси, и вижу это следующим образом:
1. Шасси предназначено в первую очередь для перемещения, поэтому оно должно получить команду и отчитаться о её отработке или невозможности отработке с причиной по коду возврата. Какие датчики используются в этом процессе для УУ не важно.
Я допускаю что УУ может получить прямой доступ к любому датчику или исполнительному устройству, но это скорее исключение из правил. Прямой доступ не нужно стандартизировать для универсальности и заменяемости шасси.
В идеале я хотел бы получить некую рабочую платформу, к которой смонтированно например гусеничное шасси, причем замена гусеницы на шагающее шасси не должно приводить к перепрограммированию УУ расположенного в платформе.

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

Немножко тема заглохла - терию прорабатывал

2 =DeaD=

1. Вообще логично, конечно, -1 ... 0 ... +1, но с целью свести воедино пороговые устройства с неприрывными, выбрана шкала именно 0 ... 0.5 ... 1.

2. В принципе, весь этот огород-то и городиться, чтобы работать с логическими величинами (соответственно, мин=0, макс=1), а перевод в абсолютные величины должна обеспечивать программа/устройство транслятор (реализация транслятора и его калибровка - отдельная история).

3. Предполагаеться, что сложные устройства наделяються некоторой "интелектуальностью", которая обеспечиваеться сервисными ф-циями транслятора (так, напр для ноги три входных сигнала-параметра, "перенести ступню в  (X,Y,Z)", а выходной напр. "Нога установлена в заданое положение" и "Нога упёрлась в землю", зависит от аппаратных возможностей).

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

Кроме того, желательно чтобы каждое исполнительное устройство имело "сигнал отчётности/готовности". Так, напр. у себя на системе автоматизации на уровне исп. устройства сигнал отчётности я градуировал так:
0.00 - Команду выполнить не удалось.
0.25 - Команда выполняеться, но скорее всего, выполнена небудет
0.50 - Команда выполняеться, исход прогнозировать невозможно
0.75 - Команда выполняеться, и скорее всего, будет выполнена согласно указаниям
1.00 - Команда выполнена полностью согласно указаниям, устройство готово к получению новой команды.
Примечание - во всей системе учитывалась динамика, по этому, 0.25 возникало, если прогнозировалось, что напр. устройство не успевало выполнить команду вовремя. В зависимости от потребностей, возможна, конечно, иная градуировка.

setar писал(а):На каком уровне работает описанный язык?

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

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

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

Есть мысль, что так ничего путного не выйдет - ввиду неясности чем же облегчит жизнь рядовому разработчику такая система - никакой "добавленной стоимости" она не приносит, но заставляет под новый формат адаптировать обе системы - исполнительную и алгоритмическую. Зачем?

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

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

PS: Нейросеть все равно должна зависеть от типичной местности, размеров шасси по отношению к препятствиям, способов движения, расположения датчиков и т.п.

=DeaD= писал(а):...Зачем?

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

Правильно! К тому и веду, чтобы предложенная концепция стала стандартом. Стаднартизация, это и есть принцип, который...

=DeaD= писал(а):...заставляет под новый формат адаптировать обе системы - исполнительную и алгоритмическую...

...дабы стереть весьма каверзную грань "аппаратура-алгоритм".

P.S. У меня в лаборатории уже где-то 7 месяцев эксплуатируеться некоторый самотельный програмно-аппаратный измерительный комплекс, на котором реализованы зачатки такой концепции (56 совершенно разношёрстых рецепторов-датчиков от кнопок-концевиков, до АЦП, 13 исполнительных механизмов, от простых реле до полуавтоматических дозаторов, всё это неким образом (многое согласно теории, остальное - эмпирически) взаимосвязано аналитически). Как показала практика эксплуатации, весь комплекс можно не просто запрограмировать на сценарий эксперимента, но и научить самокалиброваться, проверять собственную работоспособность, погрешность (включая динамическую), "оценивать" и "распознавать", что ему "подсунули". В конечном итоге, немного самообучившись, комплекс много в чём стал "самостоятельным", что значительно сняло нагрузку с меня лично.

Кстати, чтоб не выглядело совсем заоблачно, попробую продемонстрировать на простом примере:

На рис изображена схема классической рулевой машинки. В предложеной мною концепции, с точки зрения следящей системы (внутренняя схема) на логическом уровне, "подчинённое" ей хозяйство выглядит как упр.сигнал для двигателя (WD_Servo, таким образом, что 0=мотор вращяеться с макс скоростью, поворачивая вал в RD_Servo->0; 1=мотор вращяеться с макс. скоростью, поворачивая вал в RD_Servo->1; 0.5 = мотор не вращяеться), и результирующий сигнал положения вала (RD_Servo). Чёрные прямоугольники со стрелочкой - трансляторы (реализацию условно опускаем). Кроме того, есть стимулирующий сигнал - команда (на схеме отсутствует, т.к. источник сигнала непостредственно к рулевой машинке не относиться), которую назовём RI_Servo (префикс RI_ выбран, чтобы показать, что сигнал берёться не на прямую с какого либо датчика, а вычисляеться, напр в ОПУ). Далее описываем WD_Servo как ф-цию:

WD_Servo(RI_Servo, RD_Servo):=1/(1+EXP(-k*(RI_Servo-RD_Servo)))

k - характеристический коефициент, зависит от чувствительности и следящей системы.

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

Отступ к нейросетям: то, что здесь видим (формула), не что иное, как нейросеть из одного нейрона, с двумя синапсами (RI_Servo, RD_Servo), аксоном WD_Servo, сигмоидальной активационной функцией, и обратной связью (через вал привода WD_Servo меняет значение RD_Servo, что очевидно).
(продолжение следует)

Скажите, чем рядовому роботостроителю будут полезны ваши стандарты?

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

Что касается меня - думаю что для роботостроения и алгоритмов величины, измеряющиеся в интервале 0..1 - не самый лучший вариант для использования в программах. Хотя бы потому что тогда программе нужно адаптировать свои +/- 45° к конкретному сервоприводу, у которых разброс угла поворота от +/-180° до +/-60° легко может быть.

В данном случае гораздо приятней был бы вариант инкапсулирования серва в объект, который ответил бы программе, какой диапазон углов доступен с учетом конструкции робота, который бы адаптировал эти 0..1 к конкретным градусам в +/- от нейтрального положения и т.п.

Это я говорю, как писавший хоть так и не запущенную на реальной модели, но протестированную на эмуляторе, программу управления шагающим 4хногим роботом.

=DeaD= писал(а):Скажите, чем рядовому роботостроителю будут полезны ваши стандарты?

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

=DeaD= писал(а):Что касается меня - думаю что для роботостроения и алгоритмов величины, измеряющиеся в интервале 0..1 - не самый лучший вариант для использования в программах. Хотя бы потому что тогда программе нужно адаптировать свои +/- 45° к конкретному сервоприводу, у которых разброс угла поворота от +/-180° до +/-60° легко может быть.

Это задача транслятора - свести абсолютные величины в логические.

=DeaD= писал(а):В данном случае гораздо приятней был бы вариант инкапсулирования серва в объект, который ответил бы программе, какой диапазон углов доступен с учетом конструкции робота, который бы адаптировал эти 0..1 к конкретным градусам в +/- от нейтрального положения и т.п.

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

Ну и последний фактор, из-за которого я предлагаю именно беззнаковую систему: далеко не у всех устройств есть понятие нейтрального положения (ни один сустав, например, такого понятия не имеет). В принципе, и стандартная рулевая машинка такого понятия не имеет (очень редко какие имеют аппаратную реализацию нейтрали).
Нейтральное положение - рудимент с рулевых управлений (там ещё и триммером нейтраль выставляеться) в робототехнике это понятие ОЧЕНЬ условно.

P/S

=DeaD= писал(а):Это я говорю, как писавший хоть так и не запущенную на реальной модели, но протестированную на эмуляторе, программу управления шагающим 4хногим роботом.

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

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

=DeaD= писал(а):Погодите, ну в чем же тогда будет заключаться ваш стандарт? Это IMHO не стандарт тогда получится, а предлагаемые принципы обмена данными...

Ну где-то приблизительно так
Суть в следующем:
Эффективные алгоритмы управления именно роботом получаються при функциональном подходе. Контроллеры, расчитаны на пошаговый режим работы (тоесть, для них эффективнее процедурный подход). Но дело в том, что весь робот не состоит исключительно из контроллера, в нём есть много чего, что реализует функциональный подход на аппаратном уровне. Если писать программу для контроллера на функциональном языке програмирования (будь то ЛИСП, ПроЛог или Хаскель), то получиться очень много лишних преобразований (трансляция функционального подхода в процедурный, как напр. ПроЛог транслируеться в С), а много чего аппаратно функционально зависимого адаптируеться потом под процедурный подход, для связи с контроллером. Кроме того, реально эффективные программы для контроллеров пишуться вообще на ассемблере, как на языке наинизшего уровня. Так вот я и предлагаю перевести всё в русло развития функционального подхода к решению задачи, а процедурные модули скрыть внутри них самих (будь то на аппаратном или програмном уровне). То есть, надалее, никаких пошаговых алгоритмов (т.к. они скрыты внутри устройств, которые действуют пошагово), а только функциональные зависимости типа аргумент-функция-результат. А как конкретно реализуеться та или иная функция уже нюанс исполнения, и к ОПУ отношения не имеет.