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

demoontz

я еще не придумал куда прилепить. но в базовом виде секвенсер это функция независящая от времени и прошлого поожения. в нормальном варианте это уже добавляеться 4 измерение. т.е. время.
а вот зависимость положения от времени есть большое множество: ходьба. поворот. бег, ну и прочие шалости. эти шалости должен иметь возможность уже сам пользователь добавлять. ведь этой функцией может руководить допустим камера.
для его реалихации нам надо знать положение хекса во время t-1. а там дальше как вариант выпонять функцию каждый заданный промежуток времени. допустим каждые 0.1 сек.

какой формат входящих данных, это вам решать.

я надеюсь вы пойметя чо я тут написал. =)

=DeaD=

2demoontz: Ну вообще зависеть от прошлого положения система должна на каком-то уровне, иначе всё сломается.
А пока можно написать функции инверсной кинематики положения серв по целевому положению конца конечности шестинога.

А дальше просто описывать траектории концов конечностей и через вышеуказанную функцию генерить положения серв.

Я пока себе плохо представляю как это может работать - можно ли например будет шестиногу идти, при этом наклонившись корпусом назад или вбок?

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

demoontz

траектории концов конечностей и через вышеуказанную функцию это и есть зависимость от времени и прошлого положения. я могу математически это все реализовать. буду заморачивацца если нет пока альтернативы. а я так понимаю она(ссц32) не особо альтернатива, так как не внутри контролера.

щас всеравно пока думаю над математикой
например надо сделать так
http://micromagicsystems.com/#/balance- ... 4517267257

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

Не знаю, в правильную ли тему написал я. Если что-поправите.
Добрался я до ORFA.
1. Скомпилировал как в wiki/ORFA
"Сборка ORFA под AVR Studio + WinAVR
Для этого вам потребуется:
1. Скачать .zip-архив с нужной версией (последняя версия: 0.7.4)
2. Создать в этом же каталоге проект ORFA без создания каталога и нового файла (имя важно, иначе AVR Studio не увидит скомилированный файл)
4. Добавить в только что созданный проект файл «main.c»
5. Прописать в свойствах проекта внешний Makefile из скачанного проекта
6. Создать в папке проекта файл local_config.mk и в нём прописать платформу (PLATFORM = OR_AVR_M128_S или OR_AVR_M32_D) и скорость UART (B115200 или B9600), например:
PLATFORM = OR_AVR_M128_S
BAUD = B115200
7. Скомпилировать прошивку"
Почему-то там п.3 не было.
2. Залил прошивку в контроллер OR-AVR-M32-D.
3. Перевел переключатели на USB программаторе OR-PROG-USB в противоположное положение: три переключателя "Prog" в положение Off, два переключателя "Bus" в положение On.
4. А теперь дальше, какой конкретно программой-терминалом можно ORFA-команды посылать из ПК в контроллер OR-AVR-M32-D и получать от него ответы? А то я уже собрался на Делфи его писать на основе обычного компонента COM порта.

blindman

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

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

1.Я скачал Advanced Serial Port Monitor 3.5.3 build 41.
2 Настроил в ней доступ к COM 3, скорость 115200.
3. Инициализировал устройство.
Как это выглядело в логе программы:
V [len=1]
V1.0 [len=4]
<LF>
L20 [len=3]
L20 [len=3]
<LF>
C0064 [len=5]
C0066 [len=5]
<LF>
X [len=1]
X [len=1]
<LF>
S 20 00 00 S 21 01 P [len=20]
SWAASR06P [len=9]
<LF>
А так это интерпретирую согласно wiki/ORFA где "<" помечены мои сообщения, ">" - ответ по COM порту модуля OR-AVR-M32-D.
3.1. Получил версию протокола
< V [len=1]
> V1.0 [len=4]

3.2. Set local address
< L20 [len=3]
> L20 [len=3]
3.3. Set bus speed (freq)
< C0064 [len=5]
> C0066 [len=5]
3.4. Clear I2C bus
< X [len=1]
> X [len=1]
3.5. I2C request
< S 20 00 00 S 21 01 P [len=20]
> SWAASR06P [len=9]
А теперь рассказывайте все, разработчики, где что и как тут с этой ORFA, мне чайнику и всем кому это интересно.
Я хочу подключить контроллер к моей программе на C++. Чем и как можно тут управлять и что и как получать по чьей инициативе?

blindman

[[ORFA - Выданные идентификаторы UID]]
Там список драйверов, и ссылки на описание каждого из них.
S 20 00 00 S 21 01 P - это был запрос к драйверу-интроспектору, который сообщил, что имеются 6 драйверов. Для каждого можно запросить дополнительную информацию, см. [[ORFA Introspection driver]]

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

Давайте по порядку.
wiki/ORFA_Introspection_driver
Рассмотрим ваш пример:
"Определяем сколько драйверов в устройстве.

Запрос: L40
Ответ: L40
Первый запрос - L40 - установить адрес локального устройства в 0x40. Ответ - L40 - адрес установлен. (Можно не делать, если вы уже установили адрес локального устройства ранее)."
1. Что такое "адрес локального устройства" и почему его можно установить в значение 0x40.
2. Кстати, это в Hex?
3. Какой допустимый диапазон адресов устройств?
4. Какому устройству посылаются все команды ORFA? Только мастеру и он пересылает после парсинга командной строки нужные Slave-устройствам если такие есть или в них тоже как-то можно напрямую посылать команды?

"Запрос: S40 00 00 S41 01 P
Ответ: SWAASR06P
Второй запрос - S40 00 00 - отправим в устройство 0x40 номер регистра 00 и тип запроса 00 - получить количество драйверов, S41 01 - получить ответ 1 байт, P - конец запроса. Ответ: SW - начали запись в устройство, AA - подтверждения записи 2 байт в устройство, SR - начали получать ответ от устройства, 06 - получили 1 байт ответа (количество драйверов), P - конец ответа."
5. Какую роль выполняет в устройстве 0x40 регистр с номером 00?
6. Где полный список типов запросов?
7. S41 - а этот адрес устройства откуда вылез? Или за устройством 40 сразу закрепляется какая-то зона адресов - 40, 41.... ? Каков тогда стандартный список такой зоны?
8. P - конец ответа. Тогда какова максимальная длина ответа в байтах или в количестве отдельных ответов?
9. Компьютер должен обязательно дождаться получения подтверждения конца ответа прежде чем давать новый запрос?

=DeaD=

1. Согласно идеологии заложенной в ORFA - всё есть i2c-устройства, даже контроллер с которым мы напрямую общаемся через i2c.
2. да, это хекс;
3. 0-127, как в стандарте и2с;
4. Изначально только мастеру, другим оно пересылается уже по и2с шине, т.е. после парсинга строки полученной из УАРТА;
5. регистр с номером 00 не связан с адресом устройства - это регистр интроспектора ORFA, подробней указано на странице wiki/ORFA в разделе "Возможности встроенного/подчиненного I²C устройства (список драйверов)"
6. Он зависит от подключенных драйверов, в указанном в предыдущем пункте разделе есть таблица с текущими драйверами;
7. По стандарту и2с адрес 40 и адрес 41 это одно и то же устройство, последний бит - указатель направления запроса (запись=0\чтение=1);
8. Буферы сейчас выставлены вроде в порядка 100 байт внутри ОРФА;
9. Вроде можно не дожидаться, но не экспериментировал, как будут себя вести разные библиотеки СОМ-портов если не забирать информацию из входного буфера.

blindman

Цитата:

1. Что такое "адрес локального устройства" и почему его можно установить в значение 0x40.

Это адрес, на который откликается шлюз. То есть запросы по этому адресу он обрабатывает сам. Запросы по другим адресам просто транслируются на шину I2C.

Цитата:

2. Кстати, это в Hex?

Очевидно, да

Цитата:

3. Какой допустимый диапазон адресов устройств?

0x00 - 0xFF, младший бит игнорируется.

Цитата:

4. Какому устройству посылаются все команды ORFA? Только мастеру и он пересылает после парсинга командной строки нужные Slave-устройствам если такие есть или в них тоже как-то можно напрямую посылать команды?

Не понял вопроса.

Цитата:

5. Какую роль выполняет в устройстве 0x40 регистр с номером 00?

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

Цитата:

6. Где полный список типов запросов?

Что такое "тип запроса"?

Цитата:

7. S41 - а этот адрес устройства откуда вылез? Или за устройством 40 сразу закрепляется какая-то зона адресов - 40, 41.... ? Каков тогда стандартный список такой зоны?

2 адреса. Но на самом деле один, младший бит - это признак чтения/записи.

Цитата:

8. P - конец запроса. Тогда какова максимальная длина сообщения в байтах или в количестве отдельных запросов?

Длина сообщения ограничена буфером в 128 байт. В самом сообщении длина не указывается.

Цитата:

9. Компьютер должен обязательно дождаться получения подтверждения конца ответа прежде чем давать новый запрос?

Главное чтобы буфер не переполнился. Лучше дождаться.

Виктор, вы знакомы со спецификацией шины I2C? Протокол шлюз-контроллера был построен наподобие I2C, если вы в его почитаете, возможно ответ на вопросы 7,8 станет понятнее

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

Тогда еще вопросы.
1. Для ПК все контроллеры, выглядящие как набор устройств и где кол. устройств м.б. гораздо больше кол. контроллеров, - это один общий сервер с различными частями - устройствами, а сам ПК - клиент?
2. Как тогда работать с событиями, происходящими в МК? Например, сработал бампер. Какова последовательность взаимодействия МК и ПК в этом случае?

blindman

1. В настоящий момент, ПК через один порт может видеть только один контроллер. Да, это сервер, ПК - клиент.
2. Вопрос конечно интересный... Только опрашивая постоянно состояние порта. Короткие события могут быть пропущены.

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

Упсс. Это получается, что если в МК части 100 всяких событийных устройств, то их все нужно сканировать? А для облегчения задачи нельзя хотя бы в общем драйвере взводить флаг что в каком-то устройстве произошло событие? Хотя для хранения очереди векторов необработанных событий тоже придется городьбу городить

blindman

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

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

Удобно было бы, когда каждое устройство, способное вырабатывать события, могло работать в 2 режимах.
1. Асинхронное событие. Выдал куда-то, например, главному устройству обработки событий всю событийную инфу и быстренько продолжил свою работу по обнаружению след. событий. При этом есть вероятность необработки данного события по разным причинам (переполнение очереди, медленность обработки и потеря актуальности вследствие этого и т.д.)
2. Синхронное событие. Устройство останавливает свою работу до тех пор, пока не дождется ответа (возможно даже от самого ПК), что событие обработано и только тогда продолжает работать.

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

roboforum.ru

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

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

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