roboforum.ru

вопрос безотносительно к бутлоадеру (не знаю где обсуждение) - протокол не поразумевает инициативу робота при общении. То есть если сработал бампер или другой сенсор - ПК не узнает об этом, если сам не спросит?

Именно, в этой системе не реализована возможность подписки на сервисы, как это сделано в концепции MSRS. В дальнейшем может быть пересмотрим подход для совместимости со студией.

Добавлено спустя 44 секунды:
Но всё равно подход может быть максимум поменян на уровне UART до ПК, на шине I2C так уж повелось, что мастер всех опрашивать должен.

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

подумал, может я что-то упустил. Продолжаю потихоньку свой проект, подумал, что в [[MiniBot-SerControl]] протокол уже в некоторой степени реализован, так что его взял. Но обнаружил, что сенсоры не инициируют события.
А вообще обсуждение этой темы где-то есть - чтобы из темы про бутлоадер вынести? И есть ли вариант такой прошивки под стандартную конфигурацию Минибота? Думаю, что не все готовы припаивать другой кварц и переустанавливать под него фьюзы (хотя под бутлоадер все равно придется), а проект интересный.

Как же i2c сонар или ИК-дальномер может инициировать события? так что всё это будет реально опрос, я не вижу пока критичной разницы через что опрашивать, особенно если у нас пока не 100 сенсоров.

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

Отделил в отдельную тему.

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

Кварц можно и не запаивать, но тогда нужно поправить настройку USART'а и таймеров.
Бутлоадер есть и под стандартного минибота, смотри лог ревизий: http://hg.vehq.ru/minibot-bootloader/

_________________
Linux user | Firefox user

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

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


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

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

а не согласен
с ПК мы можем указать - какой сенсор интересен и на каких значениях о нем сообщать. А в роботе все равно нужно некоторую логику держать типа BIOS-а, для работы с "низкоуровневыми" устройствами. Как в DOS-е - можно было комфортно так через 21-е прерывание работать, а можно аккуратненько через 10-е - из BIOSа

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

_________________
Linux user | Firefox user

А понимаю, но это всё равно почти DSS надо на МК тогда городить, чтобы полноценно и концептуально было, а нам пока не до этого. Да ресурсы там не те...

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

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

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

ну ты это загнул, кажись ничего, что я снова на ты
опрашивать запрошенные с ПК датчики или обработать затребованное прерывание разве просто в цикле не достаточно?

Да ничего конечно

Это на словах всё так просто, но ведь в DSS нагорожено не просто так всё. А частота опроса разных датчиков совпадать должна? Так это менее эффективно и управляемо тогда, чем у меня в шлюзе. А механизм подписки на какие-то датчики, и запрос на остановку подписки? Дальше продолжать?

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

не, не продолжай - я наверное понял. Имеется ввиду довольно простое устройство - пока еще не манипулятор с N-степенями свободы и защитой от коллизий. Если рассматривать робот в смысле мультиплексора, обеспечивающего раздачу и сбор данных с сенсоров и исполнительных механизмов, то его мозгов для этого должно как раз хватить. А вот что делать с этими данными - это как раз задача DSS на ПК.

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

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

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