Дык это... Исходники открыты. Изучайте. Выдвигайте конкретные предложения. Пишите код
Добавлено спустя 58 секунд:
Реалтайм никто и не обещал
roboforum.ru
Технический форум по робототехнике.
Обсуждение реализации шлюз-контроллера [ORFA]
Правила форума
Правила раздела OpenRobotics
Правила раздела OpenRobotics
Re: Обсуждение реализации шлюз-контроллера [ORFA]
Какие-то прототипы ORFA вы исследовали?
Роботы и реалтайм - вещи несовместимые? Я думал что наоборот.
И еще. Если драйверы нереентерабельные как в той же ДОС, никакой реалтайм не грозит.
Роботы и реалтайм - вещи несовместимые? Я думал что наоборот.
И еще. Если драйверы нереентерабельные как в той же ДОС, никакой реалтайм не грозит.
Re: Обсуждение реализации шлюз-контроллера [ORFA]
Это смотря что под реалтаймом понимать. Какой у нас канал? 115200? Каких задержек следует ожидать? Это реалтайм?
Ничто не мешает поменять прошивку таким образом, чтобы события, требующие немедленной реакции, обрабатывались на самом МК.
А ORFA (даже не она сама, а реализованный на ее основе шлюз, ибо мы именно про него говорим), как и все более-менее универсальное, никогда не будет удовлетворять всех.
Ничто не мешает поменять прошивку таким образом, чтобы события, требующие немедленной реакции, обрабатывались на самом МК.
А ORFA (даже не она сама, а реализованный на ее основе шлюз, ибо мы именно про него говорим), как и все более-менее универсальное, никогда не будет удовлетворять всех.
Re: Обсуждение реализации шлюз-контроллера [ORFA]
эээ, ну вообще если известно время всех задержек - то это тоже real-time. Так что если известна скорость передачи UART, скорость обработки команды - то это real-time.
Не нужно путать real-time с "немедленной реакцией".
Не нужно путать real-time с "немедленной реакцией".
Re: Обсуждение реализации шлюз-контроллера [ORFA]
Виктор Казаринов писал(а):Удобно было бы, когда каждое устройство, способное вырабатывать события, могло работать в 2 режимах.
Предлагаю не обсуждать сферического коня в вакууме, а только конкретные задачи
есть ощущение, что нету сейчас никаких конкретных задач, в которых ORFA была бы неприемлима. Конечно не надо пытаться завязать передачу аудио или видео или другие безумные потоки информации через ORFA Виктор Казаринов писал(а):Я м.б. еще не въехал в ORFA, но мне показалось, что она напоминает собой DOS для ПК. Те же регистровые передачи параметров в API. Они хороши тем, что довольно компактны и быстры. Но и гибкость такого подхода сомнительна. Однозадачность. Пока один запрос не будет подтвержден ответом, нельзя делать следующий. А если следующий запрос к др. устройству? А первое устройство повисло или разрушилось? Ждать ответа до "посинения"?
Мне кажется, что такая конфигурация ORFA совсем не реалтаймовская и не PnP-шная.
Запрос идёт к шлюз-контроллеру, если он разрушен - на УАРТе просто никого не будет.
Если разрушен другой контроллер - будет таймаут от шлюз-контроллера возвращен и всё.
Добавлено спустя 2 минуты 22 секунды:
Виктор Казаринов писал(а):Какие-то прототипы ORFA вы исследовали?
Роботы и реалтайм - вещи несовместимые? Я думал что наоборот.
И еще. Если драйверы нереентерабельные как в той же ДОС, никакой реалтайм не грозит.
ORFA построена на принципах I2C - там по определению пока мастер не спросит - слейв ничего сказать не может. В куче роботов это всех устраивает, если у вас есть конкретные задачи в которых это не подходит - объявите их для начала, прежде чем предлагать создать мега-универсальный дорогой и громоздкий еще один какой-нибудь USB или FireWire
Re: Обсуждение реализации шлюз-контроллера [ORFA]
Конечно, нужен консенсус, как говорили политики. Однако:
1. М.б. можно в имеющуюся архитектуру ORFA добавить события? Даже такой древний протокол как MIDI и тот весь на событиях.
2. Можно ли рассмотреть подход к обмену с пом языка FIPA ACL? Его байтовую реализацию можно посмотреть: wiki/RoboBrain_Interchange_Language
Такой подход существенно повысит абстрактность взаимодействия отдельных частей робота независимо от того, где и в каком виде они находятся. Если разобраться, то на самом деле там не все сложно и в вычислительном плане не очень ресурсоемко.
- это прототип описания этого языка.
- FIPA SL Content Language. Это на основе ACL создан язык общения агентов. И то, что на нем пишется, попадает в содержательную часть сообщения на языке ACL. Язык ACL т.о. является контейнером для SL. В рамках ORFA также можно коммуникативность разделить на 2 части - ACL и ORSL - Open Robotics Semantic Language.
- это самая общая информация по архитектуре FIPA. и там есть весьма интересные картинки по взаимодействию агентов, в качестве кот. можно рассматривать отдельные устройства ORFA.
Конечно, это лишь мои предложения и вы вправе отказаться от них. Но отдельные изолированные сообщения решили бы и проблему событий.
Я вовсе не предлагаю отказываться от I2C.
1. М.б. можно в имеющуюся архитектуру ORFA добавить события? Даже такой древний протокол как MIDI и тот весь на событиях.
2. Можно ли рассмотреть подход к обмену с пом языка FIPA ACL? Его байтовую реализацию можно посмотреть: wiki/RoboBrain_Interchange_Language
Такой подход существенно повысит абстрактность взаимодействия отдельных частей робота независимо от того, где и в каком виде они находятся. Если разобраться, то на самом деле там не все сложно и в вычислительном плане не очень ресурсоемко.
- это прототип описания этого языка.
- FIPA SL Content Language. Это на основе ACL создан язык общения агентов. И то, что на нем пишется, попадает в содержательную часть сообщения на языке ACL. Язык ACL т.о. является контейнером для SL. В рамках ORFA также можно коммуникативность разделить на 2 части - ACL и ORSL - Open Robotics Semantic Language.
- это самая общая информация по архитектуре FIPA. и там есть весьма интересные картинки по взаимодействию агентов, в качестве кот. можно рассматривать отдельные устройства ORFA.
Конечно, это лишь мои предложения и вы вправе отказаться от них. Но отдельные изолированные сообщения решили бы и проблему событий.
Я вовсе не предлагаю отказываться от I2C.
Re: Обсуждение реализации шлюз-контроллера [ORFA]
Для C/C++ есть библиотека liborfa Linux/Windows.
Точнее говоря библиотека сишная, есть обертка для си++, но не законченная.
Не уверен, что задержка автоопределения под Windows будет верна, я писал под линуксовый sleep(sec), а виндовый вроде sleep(msec).
local_config.mk лучше взять из ./doc (собственно оттуда он и копируется, если сделать make без конфига сборки)
в нем есть комментарии и примеры, это должно сильно упростить понимание где-что.
На данный момент актуальная версия 0.7.5
основная фишка — автоопределение скорости УСАПП (требует в начале соединения послать 8 '\r' и сделать задержку 20 мс).
В стандарте I2C подчиненный не может инициировать передачу, т.е. мастер должен периодически опрашивать состояние. Из этого и следует невозможность сделать асинхронные запросы. Был запрос — дождись ответа.
Но можно реализовать не слишком сложную реакцию и на самом контроллере, для этого есть простой кооперативный шедулер.
Точнее говоря библиотека сишная, есть обертка для си++, но не законченная.
Не уверен, что задержка автоопределения под Windows будет верна, я писал под линуксовый sleep(sec), а виндовый вроде sleep(msec).
local_config.mk лучше взять из ./doc (собственно оттуда он и копируется, если сделать make без конфига сборки)
в нем есть комментарии и примеры, это должно сильно упростить понимание где-что.
На данный момент актуальная версия 0.7.5
основная фишка — автоопределение скорости УСАПП (требует в начале соединения послать 8 '\r' и сделать задержку 20 мс).
В стандарте I2C подчиненный не может инициировать передачу, т.е. мастер должен периодически опрашивать состояние. Из этого и следует невозможность сделать асинхронные запросы. Был запрос — дождись ответа.
Но можно реализовать не слишком сложную реакцию и на самом контроллере, для этого есть простой кооперативный шедулер.
Re: Обсуждение реализации шлюз-контроллера [ORFA]
2Виктор:
1. Нельзя, это разрушает одну из основных концепций "всё есть i2c", реально большая часть устройств не генерит события. Компас, дальномер, аксель, гиро и т.п. - пока не спросишь не узнаешь, что там что-то поменялось.
2. См. пункт 1.
Единственное что я полагаю возможно в дальнейшем, если совсем прижмёт - установить автоопрос каких-то параметров внутри главного контроллера, но пока я не вижу задач в которых это было бы нужно.
1. Нельзя, это разрушает одну из основных концепций "всё есть i2c", реально большая часть устройств не генерит события. Компас, дальномер, аксель, гиро и т.п. - пока не спросишь не узнаешь, что там что-то поменялось.
2. См. пункт 1.
Единственное что я полагаю возможно в дальнейшем, если совсем прижмёт - установить автоопрос каких-то параметров внутри главного контроллера, но пока я не вижу задач в которых это было бы нужно.
Re: Обсуждение реализации шлюз-контроллера [ORFA]
так вроде ж в i2c есть мультислейв
Re: Обсуждение реализации шлюз-контроллера [ORFA]
I2C - это базовый протокол. Но не очень хорошо, когда надстройка над ним уподобляется ему т.к. не добавляет абстрактности и др. удобств.
Re: Обсуждение реализации шлюз-контроллера [ORFA]
EdGull писал(а):так вроде ж в i2c есть мультислейв
Нету
там есть мультимастер 
Добавлено спустя 54 секунды:
Виктор Казаринов писал(а):I2C - это базовый протокол. Но не очень хорошо, когда надстройка над ним уподобляется ему т.к. не добавляет абстрактности и др. удобств.
Я повторю свой вопрос - какую реальную задачу не даёт решить ORFA в нынешней версии?
Есть такой принцип "бритва Оккама", предлагаю от него не отклоняться
Re: Обсуждение реализации шлюз-контроллера [ORFA]
Мультимастер - это м.б. и есть то, о чем я спрашиваю?
Бритва - это хорошо, лишь бы не по горлу и не следует ее превращать в серп.
Ведь догматика никогда не доводила до добра. Даже в минимализме.
Примеры? Возьмите любой язык с ООП и в тех языках, где нет событий, народ сильно мучается. Насчет роботов - подумаю над более выразительным примером. А вот в MIDI - если бы синтезатор опрашивал по хилому интерфейсу на 31 кбод все клавиатуры, то этот канал забился бы бесполезными опросами практически сразу.
Бритва - это хорошо, лишь бы не по горлу и не следует ее превращать в серп.
Ведь догматика никогда не доводила до добра. Даже в минимализме.
Примеры? Возьмите любой язык с ООП и в тех языках, где нет событий, народ сильно мучается. Насчет роботов - подумаю над более выразительным примером. А вот в MIDI - если бы синтезатор опрашивал по хилому интерфейсу на 31 кбод все клавиатуры, то этот канал забился бы бесполезными опросами практически сразу.
Последний раз редактировалось Виктор Казаринов 12 дек 2009, 20:20, всего редактировалось 1 раз.
Re: Обсуждение реализации шлюз-контроллера [ORFA]
Т.е. задачи таки нету?
А о чем мы тогда сейчас говорим?
Добавлено спустя 45 секунд:
Мультимастер это то, о чем пока не стоит говорить, там всё сложно и большая часть устройств реальных типа сонаров или компасов с акселями всё равно в этом режиме не работает.
А о чем мы тогда сейчас говорим?
Добавлено спустя 45 секунд:
Мультимастер это то, о чем пока не стоит говорить, там всё сложно и большая часть устройств реальных типа сонаров или компасов с акселями всё равно в этом режиме не работает.
Re: Обсуждение реализации шлюз-контроллера [ORFA]
Наоборот, DeaD, событийность - это архиважно для робота. А программный опрос - серьезный тупик. Вы полагаете, что событийных устройств исчезающе мало в роботе и их кол. в обозримом будущем серьезно не увеличится? Серьезное заблуждение. Всякая пипочка если она обрабатывается по прерыванию - это уже обработка событий.
Последний раз редактировалось Виктор Казаринов 12 дек 2009, 20:24, всего редактировалось 1 раз.
