Обсуждение реализации шлюз-контроллера [ORFA]

blindman

Дык это... Исходники открыты. Изучайте. Выдвигайте конкретные предложения. Пишите код

Добавлено спустя 58 секунд:
Реалтайм никто и не обещал

Виктор Казаринов

Какие-то прототипы ORFA вы исследовали?
Роботы и реалтайм - вещи несовместимые? Я думал что наоборот.
И еще. Если драйверы нереентерабельные как в той же ДОС, никакой реалтайм не грозит.

blindman

Это смотря что под реалтаймом понимать. Какой у нас канал? 115200? Каких задержек следует ожидать? Это реалтайм?

Ничто не мешает поменять прошивку таким образом, чтобы события, требующие немедленной реакции, обрабатывались на самом МК.

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

Сергей

эээ, ну вообще если известно время всех задержек - то это тоже real-time. Так что если известна скорость передачи UART, скорость обработки команды - то это real-time.

Не нужно путать real-time с "немедленной реакцией".

=DeaD=

Виктор Казаринов писал(а):

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

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

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

Виктор Казаринов писал(а):

Я м.б. еще не въехал в ORFA, но мне показалось, что она напоминает собой DOS для ПК. Те же регистровые передачи параметров в API. Они хороши тем, что довольно компактны и быстры. Но и гибкость такого подхода сомнительна. Однозадачность. Пока один запрос не будет подтвержден ответом, нельзя делать следующий. А если следующий запрос к др. устройству? А первое устройство повисло или разрушилось? Ждать ответа до "посинения"?
Мне кажется, что такая конфигурация ORFA совсем не реалтаймовская и не PnP-шная.

Запрос идёт к шлюз-контроллеру, если он разрушен - на УАРТе просто никого не будет.
Если разрушен другой контроллер - будет таймаут от шлюз-контроллера возвращен и всё.

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

Виктор Казаринов писал(а):

Какие-то прототипы ORFA вы исследовали?
Роботы и реалтайм - вещи несовместимые? Я думал что наоборот.
И еще. Если драйверы нереентерабельные как в той же ДОС, никакой реалтайм не грозит.

ORFA построена на принципах I2C - там по определению пока мастер не спросит - слейв ничего сказать не может. В куче роботов это всех устраивает, если у вас есть конкретные задачи в которых это не подходит - объявите их для начала, прежде чем предлагать создать мега-универсальный дорогой и громоздкий еще один какой-нибудь USB или FireWire

Виктор Казаринов

Конечно, нужен консенсус, как говорили политики. Однако:
1. М.б. можно в имеющуюся архитектуру ORFA добавить события? Даже такой древний протокол как MIDI и тот весь на событиях.
2. Можно ли рассмотреть подход к обмену с пом языка FIPA ACL? Его байтовую реализацию можно посмотреть: wiki/RoboBrain_Interchange_Language
Такой подход существенно повысит абстрактность взаимодействия отдельных частей робота независимо от того, где и в каком виде они находятся. Если разобраться, то на самом деле там не все сложно и в вычислительном плане не очень ресурсоемко.
http://www.fipa.org/specs/fipa00061/SC00061G.html - это прототип описания этого языка.
http://www.fipa.org/specs/fipa00008/SC00008I.html - FIPA SL Content Language. Это на основе ACL создан язык общения агентов. И то, что на нем пишется, попадает в содержательную часть сообщения на языке ACL. Язык ACL т.о. является контейнером для SL. В рамках ORFA также можно коммуникативность разделить на 2 части - ACL и ORSL - Open Robotics Semantic Language.
http://www.fipa.org/specs/fipa00001/SC00001L.html - это самая общая информация по архитектуре FIPA. и там есть весьма интересные картинки по взаимодействию агентов, в качестве кот. можно рассматривать отдельные устройства ORFA.
Конечно, это лишь мои предложения и вы вправе отказаться от них. Но отдельные изолированные сообщения решили бы и проблему событий.
Я вовсе не предлагаю отказываться от I2C.

Vooon

Для C/C++ есть библиотека liborfa Linux/Windows.
Точнее говоря библиотека сишная, есть обертка для си++, но не законченная.
Не уверен, что задержка автоопределения под Windows будет верна, я писал под линуксовый sleep(sec), а виндовый вроде sleep(msec).

local_config.mk лучше взять из ./doc (собственно оттуда он и копируется, если сделать make без конфига сборки)
в нем есть комментарии и примеры, это должно сильно упростить понимание где-что.

На данный момент актуальная версия 0.7.5
основная фишка — автоопределение скорости УСАПП (требует в начале соединения послать 8 '\r' и сделать задержку 20 мс).

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

=DeaD=

2Виктор:

1. Нельзя, это разрушает одну из основных концепций "всё есть i2c", реально большая часть устройств не генерит события. Компас, дальномер, аксель, гиро и т.п. - пока не спросишь не узнаешь, что там что-то поменялось.
2. См. пункт 1.

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

EdGull

так вроде ж в i2c есть мультислейв

Виктор Казаринов

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

=DeaD=

EdGull писал(а):

так вроде ж в i2c есть мультислейв

Нету

там есть мультимастер

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

Виктор Казаринов писал(а):

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

Я повторю свой вопрос - какую реальную задачу не даёт решить ORFA в нынешней версии?
Есть такой принцип "бритва Оккама", предлагаю от него не отклоняться

Виктор Казаринов

Мультимастер - это м.б. и есть то, о чем я спрашиваю?
Бритва - это хорошо, лишь бы не по горлу и не следует ее превращать в серп.
Ведь догматика никогда не доводила до добра. Даже в минимализме.

Примеры? Возьмите любой язык с ООП и в тех языках, где нет событий, народ сильно мучается. Насчет роботов - подумаю над более выразительным примером. А вот в MIDI - если бы синтезатор опрашивал по хилому интерфейсу на 31 кбод все клавиатуры, то этот канал забился бы бесполезными опросами практически сразу.

=DeaD=

Т.е. задачи таки нету?

А о чем мы тогда сейчас говорим?

Добавлено спустя 45 секунд:
Мультимастер это то, о чем пока не стоит говорить, там всё сложно и большая часть устройств реальных типа сонаров или компасов с акселями всё равно в этом режиме не работает.

Виктор Казаринов

Наоборот, DeaD, событийность - это архиважно для робота. А программный опрос - серьезный тупик. Вы полагаете, что событийных устройств исчезающе мало в роботе и их кол. в обозримом будущем серьезно не увеличится? Серьезное заблуждение. Всякая пипочка если она обрабатывается по прерыванию - это уже обработка событий.

=DeaD=

Где задача? :cry:

roboforum.ru

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

Обсуждение реализации шлюз-контроллера [ORFA]

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