roboforum.ru

против эксперимента я ничего не имею ))) но садизм над советскими движками - нехорошо

Садизма не больше чем заставлять 16Мг-цовый контроллер моргать лампочкой с частотой 1Гц

В любом случае это полезный опыт, думаю будет ещё много людей которые захотят пойти этим же путём, а тут уже есть реализация и отзывы.
К тому же это простой - готовый алгоритм передвижения по данным от энкодера. Я дома подключил два двигателя игрушечной машинки, с двумя энкодерами, чтобы посмотреть насколько будут расхождения между программным движением и реальным (проскальзывания, помехи и т.п.). Только застрял на драйвере двигателя после модернизации, левая сторона работает хорошо, а правая глючит, причину нашёл но никак не доберусь исправить.

ну не соглашусь, мыргать 1Гц мона даж не трогая ядро )

вы длительно так двигатель гоняли ? имхо перегрев вылезет со временем..

при наличии ОС можно на 100% повторить результаты.. на то она и ОС, если конечно софт/регулятор не кривой..

ПС ща еще почитаю что вы там соорудили )
ППС не, вапще я то за всякие извращения подобного плана _) а самодельные - тем более )

прогнал тему еще раз.. не во все детали влез, впечатления теже и еще докучи новые )))

новые: применение ШД в самодельных станках как думаете откуда идет ? ) правильно, грубо говоря, - от бедности..

самому интересно каким образом в нормальных ЧПУ организуется синхронизация разных осей.. в случае аналогового задания - наверно никак.. хотя при разной нагрузке по идее может и не до конца правильно отработаться задание..

но в случае самоделки, а тем более в случае управления по ЛПТ, ессно проще делать все дискретно, и качество обработки останется тоже "дискретным" ессно, но мы тут не ракеты тачаем.. нам позволительно..

вы же мутите норм сервопривод чтобы изуродовать его до шагового в итоге... эххх

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

"нормальный" сервопривод в вашем понимании это проект http://openservo.org

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

Нагрев, точность позиционирования и т.п. Это уже детали реализации. Главное что оно работает, и "шагает", несмотря на то что это не шаговый двигатель.
Отсюда при определённых условиях (двигатель+редуктор+тип нагрузки) можно использовать такой тип управления.

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

В общем, повторюсь, главное мы не знаем заранее на какой угол нужно повернуться в итоге, а тупо поворачиваем по чуть чуть пока идут импульсы step.
При таком подходе можно, например, управлять двигателем с роутера ( например dlink dir-320) не через rs-232 а через gpio (светодиоды портов)
Таким образом можно очень точно передвигаться, на малых и средних скоростях, и за одно "чувствовать" пройденный путь, т.к. мы его определили сами.

>применение ШД в самодельных станках как думаете откуда идет ? ) правильно, грубо говоря, - от бедности..
если так рассуждать, то люди ездят на машинах а не летают тоже от бедности
Каждая задача может быть решена несколькими способами, использовать самолёт/вертолёт чтобы переместиться из одного квартала в другой не имеет смысла, проще по земле (но иногда хочется и полететь).

нормальный сервопривод

нет, нету у ДПТ никаких режимов шагового.. ДПТ он и в африке ДПТ.. вы эмулируете более простое устройство более сложным...

ПИДы вам пока не нужны - потому что крутите не нагрузку, а бумажки/колеса.. как только вы посадите "аналог шаговика" на тот же винт ШВП или хуже того - начнете резать что либо ЧПУшкой с такими приводами сразу полезут пропуски, неравномерности и прочая борода.. я бы еще понял если б вы нагружали его на сверхточную механику.. в самодельщине же нет такого в принципе.. будет трение, неравномерное трение.. и прочие невкусности...

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

т.е. вам пофигу что у вас ось Х повернется на положенные 3 градуса, а ось У на 2 ? врете блин.. у вас же там степ сайз определен.. хотя вы видимо говорите о угле поворота общем.. например при резании ЧПУшкой по линии..

да, вы сделаете привод со входом step\dir на постояннике.. я обеими руками за получение вами этого опыта, в частности прикручивание ПИДов в будущем..

удачи, что сказать )) но странно все это

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

Я постоянно указываю на то что это может работать при "определённых условиях".

В частности нужно как можно сильнее снизить влияние нагрузки на двигатель, т.е. Редуктор с передаточным числом с "запасом".
Ну и второе, это то что ДПТ дешевле и доступнее. "Кулибины" чпу из ДСП собирают, и не сильно переживают по этому поводу.

Да я пока только в воздухе крутил колесо, и рукой создавал нагрузку, посмотрим как будет ездить, но что то мне кажется что ничего сильно не изменится, в моей задаче микронная точность не нужна. За то такой интерфейс заметно упрощает управление, естественно без дополнительных датчиков, рассчитывать что робот приедет в нужную точку можно только при отсутствии внешних помех и более менее однородной поверхности.
И да, на моём видео шаг увеличен в 10ть раз. Просто чтобы было заметно что колесо крутится, так что точности там выше крыши для езды по полу.
Мне нужно не по квадратам ездить а по сложным кривым, пока я не видел на форуме хорошей реализации программного движения по заданной траектории,
а такой подход позволяет легко задавать траектории любой кривизны, возможно со скоростями проблемы будут, но это вторично для меня.


Что касается нагрузки ШВП - то тоже зависит от сочетания мощность двигателя+редуктор+возмущения.
На самом деле импульсы step, по меркам контроллера, идут довольно редко (30кгц максимум), отсюда,теоретически, между шагами довольно много времени на доводку положения. К тому же с увеличением передаточного числа, уменьшается погрешность (до определённого предела),
т.е., при переходном процессе меньшем чем период импульсов step, если и будет неравномерность то она будет на очень маленьком расстоянии. А конечные положения должны остаться прежними (как у шаговика), т.е. Фреза будет "гулять" но в очень малых пределах.

В общем, никто вас не заставляет делать ЧПУ станок на этом приводе, хотите промышленные сервы - юзайте.

я ни в коем случае не сравнивал промышленные сервоприводы и самодельные творения... ваши, мои или чьи-либо еще..

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

Только сложные кривые через скорости сложно реализовать на слабеньком 16мгц 8бит контроллере.

Будем считать, что координаты платформы робота определяются, как скорость+время на каждый двигатель (трёх колёсная платформа, два ведущих колеса)
т.е. Четыре переменные на одну новую координату робота.
скоростью каждого двигателя управляет свой пид регулятор.
+ не забываем про внешние прерывания от энкодеров.
Всё это уместить в одном контроллере сложно, поэтому считаем что у нас два контроллера на каждый двигатель.

Тогда:
либо не хватит скорости на передачу данных, с этим столкнулись ребята из openservo (у них управление по i2c).
+ проблемы с синхронизацией двух двигателей

либо если повысить скорости передачи например через какой нибудь переходник USB - SPI то не будет хватать ресурсов на вычисление в пид регуляторе
и опять же синхронизация двигателей

т.е. Требуется производительный контроллер, и упихать управление обоими двигателями в него, а синхронизировать двигатели по пройденному расстоянию.
Т.к. Даже при небольшом пере регулировании по скорости окончательное положение у нас будет не там где мы хотели.
Поэтому управление по скоростям здесь не удобно, лучше задавать конечные координаты платформы (можно в относительных координатах) + время, отсюда считать скорости для каждого двигателя. Но и это достаточно трудоёмкая задача.


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

Либо проще одно ведущее оно же поворотное и не парить мозг.

linvinus писал(а):Только сложные кривые через скорости сложно реализовать на слабеньком 16мгц 8бит контроллере.

какие таки СЛОЖНЫЕ кривые ? какой из график из четырех вам больше по нраву ?

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

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

а вот дальше ИМХО пошел бред..

linvinus писал(а):Будем считать, что координаты платформы робота определяются, как скорость+время на каждый двигатель (трёх колёсная платформа, два ведущих колеса)

либо я тормоз, либо как вы решили определять координаты по скоростям и времени - я хз .. и вообще вы идете с другого конца.. у вас должна быть задача переместить робота из точки А в точку Б по некоторой траектории... она либо отрезок прямой, либо кусок окружности, либо совокупность N+M последних..

linvinus писал(а):т.е. Четыре переменные на одну новую координату робота.
скоростью каждого двигателя управляет свой пид регулятор.
+ не забываем про внешние прерывания от энкодеров.
Всё это уместить в одном контроллере сложно, поэтому считаем что у нас два контроллера на каждый двигатель.

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

linvinus писал(а):Тогда:
либо не хватит скорости на передачу данных, с этим столкнулись ребята из openservo (у них управление по i2c).
+ проблемы с синхронизацией двух двигателей

я не знаю деталей проблем ребят с ОпенСервы, но на И2Ц в 400кГц мне кажется сложно не успеть что-либо передать..
команда установки скорости на ДД адрес + номер ДД + задание + начала и концы посылок.. байт ну 10-15 с извращениями.. не больше.. на скорости и 115200 можно мнооого раз в секунду послать.. нафига ребятам ИдваСИ я не в курсе.. но даже там можно все успеть..

linvinus писал(а):либо если повысить скорости передачи например через какой нибудь переходник USB - SPI то не будет хватать ресурсов на вычисление в пид регуляторе
и опять же синхронизация двигателей

что значит не хватит ресурсов на ПИД ?! вы там что считать собрались ?
у мк вообще нет задач кроме как считать ПИДы.. опрос энкодера - прерывание или вообще хардвар, получение задания - прерывание...

linvinus писал(а):т.е. Требуется производительный контроллер, и упихать управление обоими двигателями в него, а синхронизировать двигатели по пройденному расстоянию.

1 - это реально
2 - синхронизовать можно как угодно..

linvinus писал(а):Т.к. Даже при небольшом пере регулировании по скорости окончательное положение у нас будет не там где мы хотели.
Поэтому управление по скоростям здесь не удобно, лучше задавать конечные координаты платформы (можно в относительных координатах) + время, отсюда считать скорости для каждого двигателя. Но и это достаточно трудоёмкая задача.

трудоемкая для чего? вы ее на чем собрались решать ? на драйвере движка который ПИД считает ?

linvinus писал(а):А с таким примитивным управлением как шаг/направление очень просто получить сложные кривые на слабеньком контроллере двигателей.
И ничего страшного в том что это дискретное движение нет, хотя... Может шум задолбает поживём увидим.

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

linvinus писал(а):Либо проще одно ведущее оно же поворотное и не парить мозг.

а это:
1 - смена условия задачи
2 - удачи в простоте..

1. вы начали упрощать задачу.
если вам так угодно то можете считать что путь от А до Б сложен и тернист со множеством препятствий, как прокладывать маршрут сейчас не обсуждается.
задача переместиться из точки А в Б которую нам задали, т.е. со всеми "выступами и впадинами" (считаем что программист суммашедший но путь проложен с учётом наших габаритов, если проедем точно, то никуда не свалимся)
В контроллер поступают короткие отрезки, да для него А и Б это путь по прямой или окружности.
Да хочу получить максимально точное заданное программное движение тележки (считайте перемещать фрезу)
Траектория есть, разбита на отрезки двигаемся строго по заданному пути.
Координаты А и Б задаются в абсолютной системе координат связанной с поверхностью "земли/комнаты"

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

Или вам известен другой алгоритм как посчитать куда мы попали?

3. Давайте договоримся ссылаться на реальные примеры, в частности я проект openservo изучил достаточно хорошо и запускал его на контроллере, а также мерил максимальную скорость передачи по uart в плоть до 2 000 000 бод и i2c (400kHz) вот мои тесты производительности forum40/topic10112.html
Эти данные для "пустого" контроллера, т.е. он ничего не делает, только занимается обменом, т.е. реальная скорость занчительно ниже.
Почему такие данные можем обсудить в той ветке.

вот и не получается успевать считать, получать данные, и выдавать координаты в ноут, т.к. ноут тоже должен знать куда мы переместились, и какая сейчас скорость.
Поэтому я рассматривал вариант "сендвича" если делать управление по скорости, два контроллера двигателей + управляющий контроллер.

4. ничего не дёргается! я же сказал что это шаг в 10ть раз ускоренный. А дёргается по тому что практически максимальная мощность сразу прикладывается к колесу на большой промежуток времени, при малом шаге и большой частоте вы не отличите движение от нормального.

5. Про синхронизацию возможно вышло недопонимание, я имел ввиду управление вторым колесом с учётом сколько проехало соседнее, т.к. колёса не срезу выходят на заданную постоянную скорость, да и постоянной её сложно поддерживать, т.к. есть погрешности в измерении и в управлении + разные силы трения.
Отсюда видно, что если не учитывать расхождение между заданной и реальной скоростью мы уйдём в право (относительно заданной точки) если правое колесо выйдет на заданный режим позже левого.

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

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

1. Сложен и тернист, потому и траектория рваная.. это да...

много буков будет дискуссии, думаю пора завязывать )

2. если что не так - извините, обычно говорю прямо как считаю

3. если можете уточнить параметры теста (формат пакета и что вы имеете ввиду под не полезными данными и командами.. по мне все байты в канале это либо обертка пакета либо полезные данные)

4. ок поглядим видио со временем )

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

3. Лучше в той ветке.

5. Тут либо у меня либо у вас недопонимание, и видимо без разбора алгоритма конкретной реализации спорить не о чем

Здравствуйте.
Подскажите схему магнитного энкодера AS5040, и где вы его приобретали? ни семпл ли это с сайта производителя?

rasel, схема и правки её в начале темы. покупал с рук в Киеве.
пс: приятно видеть, что тема ещё живая

http://youtu.be/XMBOGJ3MV7I

У меня получился вот такой энкодер правда в инкременте он выдаёт всего 256 импульсов на оборот, что конечно мало для нормального сервопривода, хотя для швп с шагом 5мм шаг составит 5/256=0,01953125