DeaD, ты раньше приводил в пример модули девантеч. Они делают драйвер 2 моторов ? наверняка да - так как это всем роботостроителям надо. Он у них как то управляется по i2c ? Наверняка же в даташите написано как. И наверняка ДОРОГОЙ модуль поддерживает множество команд и фич.
В любом случает у Parallax.com это наверняка так.
=DeaD= писал(а):поэтому если видели - укажите где
Да чтож я таИл бы чтоль ? кабы знал.
ИМХО не суть какие команды давать, главное протокол передачи и приема чтоб был. А какие команды будут реализованы зависит от драйверов уже, с версиями может наращиваться. Только Мк нужно выбрать чтоб памяти хватало.
У робоклуба в префиксе буквы используются - одна буква пусть руление по скорости вращения, другая по пути, остальные еще какие функции, да и букв может быть несколько.
Главное чтоб подчиненный отвечал мастеру если не поддерживает ту команду которую он принял.
Добавлено спустя 3 минуты 26 секунд: ===============
Вот протокол команд контроллера Робоклуба
Очевидно комбинируя буквы можно расширять до бесконечности.
Нужно лишь задаться базовыми. Возможно и исходники можно у боджи попросить. Ну или накалякать.
Новый контроллер они уже на ATmega64 ! сделали. А столько же стоит LPC2138 у которого флэша аж 512 Кб !
не сужается ровно никак количество маневров... просто задаем не скорости а обороты... даем задание по положению, а не по скорости.. но добавляем к заданию по положения время выполнения задани.. отсюда привод сам считает скорсти необходимые.. поскольку к этому же контроллеру подлючены энкодеры он с легкостью может обрабатывать обратные связи по скорости и положению ...
стандартно привод строится по схеме
де внешний контур - по положения следующий - по скорости тут должен быть по напряжению якоря движка я его выкинул лень было кучу рисовать... и самый мелкий по току якоря..
это принцип попстроения аналогового управления, но наш случай такой же ... нужна обр связь по положению чтобы адекватно выпонять команды... и ходить обратной связью через протокол связи в мозги и обратно нах не нужно.. имхо ..
У робоклуба в префиксе буквы используются - одна буква пусть руление по скорости вращения, другая по пути, остальные еще какие функции, да и букв может быть несколько.
Главное чтоб подчиненный отвечал мастеру если не поддерживает ту команду которую он принял.
avr123.nm.ru писал(а):DeaD, ты раньше приводил в пример модули девантеч. Они делают драйвер 2 моторов ? наверняка да - так как это всем роботостроителям надо. Он у них как то управляется по i2c ? Наверняка же в даташите написано как. И наверняка ДОРОГОЙ модуль поддерживает множество команд и фич. В любом случает у Parallax.com это наверняка так.
Я смотрел, что они предлагают, там той полноты манёвров и близко нету. Повороты на ходу там нереализуемы в принципе.
avr123.nm.ru писал(а):У робоклуба в префиксе буквы используются - одна буква пусть руление по скорости вращения, другая по пути, остальные еще какие функции, да и букв может быть несколько. Главное чтоб подчиненный отвечал мастеру если не поддерживает ту команду которую он принял.
Вот протокол команд контроллера Робоклуба
Очевидно комбинируя буквы можно расширять до бесконечности.
Нужно лишь задаться базовыми. Возможно и исходники можно у боджи попросить. Ну или накалякать.
Новый контроллер они уже на ATmega64 ! сделали. А столько же стоит LPC2138 у которого флэша аж 512 Кб !
Да я под протоколом имею в виду прежде всего концепцию, а не набор буковок а буковки я всё равно буду использовать стандартизованные под свой формат, и одновременно под i2c, это позволит мне прозрачно свой функционал встраивать как в шлюз-контроллер, который напрямую с UART'ом работает, так и в любой i2c-slave контроллер, не меняя практически ничего, кроме смены внутри прошивки, откуда получать команды.
А робоклубовский протокол и прошивка под их контроллер при мне разрабатывалась, я же уже говорил.
Добавлено спустя 6 минут 56 секунд:
Duhas писал(а):не сужается ровно никак количество маневров... просто задаем не скорости а обороты... даем задание по положению, а не по скорости.. но добавляем к заданию по положения время выполнения задани.. отсюда привод сам считает скорсти необходимые.. поскольку к этому же контроллеру подлючены энкодеры он с легкостью может обрабатывать обратные связи по скорости и положению ...
По поводу контроля в первую очередь по положению - согласен конечно, однако тут вопрос получается в целесообразности задавать то и другое, тем более, раз мы в целых числах всё передаём - будет противоречивость информации, если идти от положения, а вот если уже внутри МК высчитывать положение и по нему постоянно корректироваться, тогда более менее всё складывается.
Duhas писал(а):стандартно привод строится по схеме: де внешний контур - по положения, следующий - по скорости, тут должен быть по напряжению якоря движка я его выкинул лень было кучу рисовать... и самый мелкий по току якоря..
это принцип попстроения аналогового управления, но наш случай такой же ... нужна обр связь по положению чтобы адекватно выпонять команды... и ходить обратной связью через протокол связи в мозги и обратно нах не нужно.. имхо ..
Ну типа да, я в экспериментах раньше ограничивался двумя контурами по положению и по скорости.
avr123.nm.ru писал(а):Т.е. тебя интересую не команды а как надежно и адресуемо передавать данные ? Тогда wake нужно посмотреть - его хвалят.
Меня пока интересует только концепция сама команд, которыми обмениваемся, протокол у меня строго один - i2c или завернутый в мой формат для прогонки его по UART.
avr123.nm.ru писал(а):
=DeaD= писал(а):а буковки я всё равно буду использовать стандартизованные под свой формат, и одновременно под i2c.
Блин ... опять что-то свое и ни с чем не стыкуемое ? Давайте уж делать (придумывать) что-то интегрируемое в мировое роботосообщество !
Куда вам еще более стыкуемое, чем i2c, под который у меня всё заточено?
1. У меня не работает сайт параллакс, выдает ошибку, браузер у меня - лиса, и пусть сами убьют себя об стену ; 2. Что вы меня все этой MS Robotics Studio стращаете? Кто в России под ней работает реально, кто её себе поставил и освоил? 3. И вообще не связано это с робостудией - там лишь вопрос обёртку прописать для устройства и всё, а я сейчас про принципы.
ну в целых.. да .. и что? у нас все равно есть разрешение управлени.. в принципе по кол-ву кликов энкодера.. можно от етого оттолкнуться..
пакет вида [control register][time][left angle][rigth angle][check summ] control register=[sleep, reply req, left dir, right dir, full forward, full backward, full left, full rigth] в байт уложится... над размером тайи нада подумать на сколько дробить секуну.. и хватит ли байта.. я думаю да... углы тоже по байту можно ... ну и контрольную сумму на всякий пожарный...
да и зачем под кого то прогибаться? пускай мир прогнется под нас... я лично сомневаюсь что они в общем умнее )) )
Duhas писал(а):ну в целых.. да .. и что? у нас все равно есть разрешение управлени.. в принципе по кол-ву кликов энкодера.. можно от етого оттолкнуться..
Я знаю что такое количество кликов, но что вы имеете в виду под словами "от етого оттолкнуться" применительно к ним - я не догоняю пока.
Duhas писал(а):пакет вида [control register][time][left angle][rigth angle][check summ] control register=[sleep, reply req, left dir, right dir, full forward, full backward, full left, full rigth] в байт уложится... над размером тайи нада подумать на сколько дробить секуну.. и хватит ли байта.. я думаю да... углы тоже по байту можно ... ну и контрольную сумму на всякий пожарный...
Давайте пока оставим за кадром контрольную сумму и прочую шелуху, мы сейчас про принципы управления, я вообще не хочу пока обсуждать обёртку - как это и через что будет передаваться и какими средствами защиты от повреждений будет снабжено, важно что будет передаваться. И я нифига не понял, что вы имели в виду под [control register] и [left angle], [right angle].
Duhas писал(а):да и зачем под кого то прогибаться? пускай мир прогнется под нас... я лично сомневаюсь что они в общем умнее )) )
Да при чем тут умнее или нет - не реализовано у них ничего такого и точка. Хватит уже про "них".
если понятно что такое кол-во кликов на оборот, то должно быть понтно от чего можно отталкиваться.. контрол регистр, это тупо байт в поылке.. пару бит которого используем как указатели направлени вращения.. + я туда напихал всячины всякой возможно полезной ибо 6 бит еще есть..
Left\right angle - угол поворота... в кликах энкодера...к примеру 32 клика на энкодер.. имеем задание 64 клика... получается делаем 2*пи*эр расстояние... поскольку пи и эр нам известно считаем кол-во кликов и отправляем контроллеру.. например нужно пройти по квадрату, метр на метр.. делим метр на наши пиэры, получаем клики, задаем.. если делать на угол поворота лишь байт, то мона сделать в статус регистре бит повторить предыдущую... вопщем мне кажетс я все понятно описал.. о чем я говорю ...
Duhas писал(а):если понятно что такое кол-во кликов на оборот, то должно быть понтно от чего можно отталкиваться.. контрол регистр, это тупо байт в поылке.. пару бит которого используем как указатели направлени вращения.. + я туда напихал всячины всякой возможно полезной ибо 6 бит еще есть..
Left\right angle - угол поворота... в кликах энкодера...к примеру 32 клика на энкодер.. имеем задание 64 клика... получается делаем 2*пи*эр расстояние... поскольку пи и эр нам известно считаем кол-во кликов и отправляем контроллеру.. например нужно пройти по квадрату, метр на метр.. делим метр на наши пиэры, получаем клики, задаем.. если делать на угол поворота лишь байт, то мона сделать в статус регистре бит повторить предыдущую... вопщем мне кажетс я все понятно описал.. о чем я говорю ...
Что-то я не догоняю, вы хотите перевести все команды в формат (LD,RD,T) что ли? Где LD - расстояние со знаком, которое должно пройти левое колесо, RD - правое, а T - время на выполнение, так что ли? Так это неоднозначная команда получается ведь тогда? На какой скорости колёс должна завершиться команда? На нулевой? Тогда забываем про манёвры на ходу. Всё только с остановками. Иначе неопределенность...
Duhas писал(а):Left\right angle - угол поворота... в кликах энкодера...к примеру 32 клика на энкодер.. имеем задание 64 клика... получается делаем 2*пи*эр расстояние... поскольку пи и эр нам известно считаем кол-во кликов и отправляем контроллеру...
Дык тут такач штука, чтобы пройти по правильной траектории надо контроллировать И скорость, И путь. например, повернуть сначала и потом проехать это не то же самое, что сначала проехать, а потом повернуть. Или Вы количеством кликов молчаливо задаете скорость, то есть одно из колес будет вращаться в отношение путей быстрее? То есть, так сказать, естественная траектория движения- окружность ( в предельном случае с бесконечным радиусом)? P.S. Тема " о правильной одометрии" дубль два.
Считаю что для правильного управления движением НУЖНО КОНТРОЛИРОВАТЬ И СКОРОСТЬ И РАССТОЯНИЕ. Все споры о целесообразности этого предлагаю отделить от обсуждения конкретных вариантов как задавать целевую траекторию.
Пока есть вариант который я предлагал с самого начала - (Ls,Rs,Lf,Rf,T), других вариантов пока не прозвучало, по крайней мере хорошо сформулированных. Все варианты предлагаю озвучивать в виде набора параметров, не пытаясь сформулировать пока как это будет в конкретном протоколе побайтов, и уж тем более не интересуют пока методы контроля целостности пакета с командой
Я в принципе не вижу Ваших затруднений. Необходимо передать независимую информацию о движении, зависимые переменные можно пересчитать друг в друга. Если Вы выбрали равноускоренное движение, значит хватит скорости (каждого колеса), ускорения(каждого колеса) и времени движения. Если же мы зададим путь, то из ускорения и скорости найдем время. Можно в общем виде вообще передавать все параметры, а неиспользуемые помечать. По моему, тут сам алгоритм контроля и обратной связи намного важнее.
Алгоритм контроля и обратной связи если не заморачиваться про замедление другого движка, если этот тупит, простой и всем известный - ПИД-регулятор, опыт с ними у меня есть, поэтому сейчас хочу обсудить именно принципы построения команд для такого шасси.
Кстати, да, действительно важное замечание - выбрали равноускоренное движение в рамках каждой команды.
Теперь про формат команды, второй вариант, я так понимаю, наклёвывается - (Ls,Rs,Lf,Rf,DL,DR,T), где DL,DR - расстояния, которое должно пройти левое и правое колесо. Чтобы мы могли точно задать прежде всего это расстояние, а скорости уже были второстепенным параметром. Разумеется должно быть DL ~= (Ls+Lf)*T/2 и DR ~= (Rs+Rf)*T/2, и как-то ограничены разумными рамками ускорений abs(Ls-Lf)/T и abs(Rs-Rf)/T.
Я использую такой вариант, но без T. Непонятно зачем нужно время, ведь траектории задаются расстоянием, если у нас не танцы роботов конечно. Хотя в общем случае можно оставить. А еще было замечено, что в моем случае не играет роли параметр - начальная скорость, т.к. начальная скорость - всегда текущая скорость робота на момент выдачи команды.
