Pull to refresh

Comments 78

Ну вот, как всегда самое интересное в следующем эпизоде =) А как вы планируете считывать угол наклона маятника?
Вторым инкрементальным энкодером, стоящим на каретке.
Различие теории и эксперимента может быть обусловленно тем, что вы дискретизировали задачу, а не решали дифференциальное уравнение. Т.е. используя формулу V(t+dt)=V(t)+С кривые будут немного отличаться при различных dt.
Конечно они будут разными, но у меня-то dt один и он известен.
Я имел ввиду, что, при постоянном напряжении, решением уравнения "u(t) — const1 v'(t) — const2 v(t) = 0" будет экспонента, которая лучше ложится на экспериментальные данные.
http://i.imgur.com/nLC7KqO.png
Тем более, при наличии силы трения, измеренная конечная скорость должна была бы быть меньше, чем теоретическая. А значит, на графике измерения должны быть ниже, чем теория.
Но, даже, при наличии силы трения(скольжения), в уравнение "u(t) — const1 v'(t) — const2 v(t)+const3 = 0" она входит как константа "const3" и, при постоянном u(t), решение для v(t) будет снова экспонента.
Мне кажется, что вы не очень хорошо поняли причину непопадания моих кривых в экспериментальные данные. Причина кроется вовсе не в фиттинге дискретного диффура или его непрерывного решения. Поправьте меня, но глядя на вашу картинку, я думаю, что вы взяли мои данные (красные точки) и моё приближение (синие кривые), и сделали четыре разных независимих фиттинга (чёрные кривые).
Да, признаю свою ошибку. На предидущем графике действительно 4 независимых фитинга.
Исправляюсь:
http://i.imgur.com/RHlyS94.png
Функция:V= (1 — Exp[-t0.021])(42*u — 55)
Как видно, при напряжении 6.02 В, не очень то и хорошо получаеться, но я подозреваю, что это — из-за особенностей драйвера L6201: в технических характеристиках на графике 4 видно, что сопротивление транзисторов при 6В заметно отличается от сопротивления при 12В.
Ага, спасибо! Теперь тут проблема в том, что эту функцию напрямую в ЛКР не запихнуть, нужны будут костыли, и над этим я пока что думаю.
Слушайте, отдельное вам спасибо за указание лимитов l6201, я что-то совсем прошляпил, что у него минимальное выходное напряжение 6В...
Не за что.
Я сам не подумал об этом, но когда пытался понять результаты, то пришлось разбираться глубже.
так, стоп, vref — это не выходное питание мотора, это входное питание микросхемы… Оно постоянно и у меня равно 24в.
Но всёравно сопротивление транзисторов, через которые проходит ток, зависит от напряжения Сток-Исток (прим. https://www.fairchildsemi.com/datasheets/2N/2N7000.pdf с. 4 первый график, где ток стока не линейно зависит от напряжения).

В любом случае, сила трения, для вращающегося мотора, не должна меняться от напряжения или скорости мотора, и я её включил в расчёты (коэффициент -55), она уменьшает конечное значение скорости.
Получается, что на поведение кривых должна влиять какая-то характеристика связанная с напряжением. И входит она в коэффициент при t в экспоненте.
Единственное что я могу сейчас придумать — индуктивность «L», магнитное поле в моторе «B» длина провода катушки мотора «l», радиус катушки мотора «r», сопротивление «R». Но если первые три характеристики врядли зависят от напряжения, то с R ещё можно что-то придумать (например померять ток, идущий через мотор, при максимальной скорости).

Я тут чуть лучше подтянул ремень, фиттинг заметно улучшился ;)
На днях выложу новые результаты.
Да, мне кажется, что вы нашли четыре разных модели двигателя, а не применили одну модель к четырём разным напряжениям.
Вы забываете о том, что ардуино это не RTOS с фиксированным временем выполнения. У вас фиксированный delay, но все вычисления тоже требуют время, причем в общем случае не постоянное. Отсюда и будет расхождение между теоретическим dt и реальным.
Побороть можно попробовать с помощью замера времени на вычисление и делать задержку такого вида
delay(dt — calcTime);
Спасибо, я об этом не забываю, я измерял постоянность задержки и нашёл её удовлетворительной.
Кстати у меня есть вопрос терминологии (я не специалист ни разу), но разве RTOS гарантирует фиксированное время выполнения?
У Вас просто в приведенном коде 2мс период, возможно из-за этого и возникли расхождения. Хотя и на нелинейность объекта очень похоже. Тут в принципе устоявшейся ошибки быть не должно без мертвых зон. Попробуйте учесть мертвые зоны двигателя и диапазон напряжений взять не от нуля а от минимального для двигателя.
Да, гарантирует, что задача будет выполнена (или не выполнена и прервана) за определенный промежуток времени. Причем внутри этого промежутка она м.б. по длительности любая, но это не особо принципиально, если значения датчиков брать в начале периода.
Причем внутри этого промежутка она м.б. по длительности любая,

я к тому и веду, что даже для RTOS по-хорошему нужно измерять время между итерациями цикла
У вас отличные статьи, спасибо. То, что положение не совпадает с требуемым вызванно тем, что присутствует возмущение с ненулевым распределением ( трение, потери и т.д.). Можно попытаться его скомпенисровать, но все равно будет оставаться ошибка, так как не возможно учесть все. Я бы для начала добавил дополнительную переменную состояния, которая бы накапливала ошибку положения и влияла на напряжение двигателя. Вообще ЛКР — это тот же ПИД только в профиль. Другие методы настройки но суть та же, взгляните на формулу, которая у вас получилась. Сейчас это дискретный ПД регулятор, если добавить дополнительну переменную будет ПИД. П.С. Не могли бы добавить видео эксперемента с регулятором?
Интеграл по ошибке положения — штука хорошая, но я пока его специально избегаю, так как в нём скрыто слишком много магии (в него запихиваются вообще все возмущения), а магия мне на данном этапе противопоказана. Я для начала попробую честно смоделировать физику, а когда упрусь уже в вещи, которые мне не по зубам, тогда и пойдут в ход интегральные коррекции.
Про ПИД и ЛКР лично я ещё не дорос спорить, но почитайте что говорилось в комментариях.
Прямо сейчас видео не могу, т.к. железяка не под рукой, разве что на неделе. Только неясно, а зачем видео-то? График же есть, ровно так и движется :)
Позвольте мне немного позанудствовать, очень хочется в воскресенье.
  • Закон Гаусса для магнитного поля говорит только о том, что в природе нет магнитных зарядов, то есть силовые линии поля не имеют начала и конца. Откуда вы сделали вывод о сохранении поля?
  • С каких пор в систему уравнений Максвелла входит закон Ампера, он же Био-Савара-Лапласа? Он участвует при выводе одного из уравнений, если следовать "историческому" (читай, не из вариации функционала действия) выводу, но только как кирпичик, наравне с теоремой Остроградского-Гаусса.

У вас замечательные статьи, но не стоит пытаться лезть в электродинамику "седьмым-восьмым классом школы", можно нахватать кучу глупых ляпов.
A) Я не знаю, что такое силовые линии, я знаю, что законы Гаусса говорят о нулевой дивергенции полей. Нулевая дивергенция и есть закон сохранения.
Б) Я не возьмусь датировать факт вхождения, но энциклопедия говорит следующее:
  1. Gauss's law
  2. Gauss's law for magnetism
  3. Faraday's law of induction
  4. Ampère's circuital law

За похвалу спасибо, но не советуйте мне, пожалуйста, ничего не трогать руками. Если вы видите фактические ошибки, поправьте их, я за это только поблагодарю.
Прошу вас, трогайте руками все, что не под напряжением. Но сначала читайте мануалы и учебники.
  • Вывод о сохранении поля вы можете взять, например, из уравнения непрерывности, которое получается из уравнений Максвелла. Сама же запись div H = 0 говорит только об отсутствии магнитных зарядов и ни о чем больше. Вообще.
  • Мы все-таки в России живем, в нашей терминологии четвертое уравнение принято звать теоремой о циркуляции магнитного поля. В таком случае указывайте в тексте, какой системой имен вы пользуетесь, грубо нашей/не нашей: теорема Остроградского-Гаусса за рубежом — просто теорема Гаусса; закон Бугера-Ламберта-Бера — там частенько просто закон Бера (хотя правильно различать их несколько в зависимости от записи и входящих переменных) и это отнюдь не единственные примеры, навскидку больше просто не вспомню.

Не обижайтесь, но рассуждать на тему уравнений Максвелла и при этом "не знаю, что такое силовые линии", как минимум странно.
Вы ошибаетесь, я не живу в России, и доступа к русским учебникам у меня нет. Если у вас есть поправки (к терминологии или по факту ошибок), не стесняйтесь, поправляйте, только пожалуйста, чуть меньше апломба. Именно про ваше поведение я написал длинный комментарий в самом начале статьи. Если вы не хотите себя вести по этим простым правилам — я просто не буду с вами общаться. Спасибо, я в курсе того, что такое интегральные линии векторного поля. Только вот говорить про их начало и конец — это тот же самый разговор на пальцах, что и про закон сохранения. Вы предпочитаете эту терминологию — да пожалуйста. А Гаусс сказал про поток векторного полня, что сколько вошло в небольшой объём, столько и вышло. Что это, если не закон сохранения?
Б) Прошу прощения. Резонный вопрос, образование у вас тоже не российское? И учебники наши в глаза не видели? Тогда да, названия разные
А) Не припомню этого комментария, когда впервые прочел статью. Я не могу мешать вам интерпретировать физику по-своему. Прошу прощения. Да и какой апломб, откуда? Вы — математик, я — физик. Поправки в тексте моих комментариев выше, но их найти так же сложно, как отличить теоремы Гаусса и Стокса. Извините, обещаю больше не мешать наслаждаться воскресеньем
И что? В чем у вас сохраняется поле? В баночке? Говоря о сохранении поля, точнее его энергии, мы говорим о сохранении ее во времени. Где время в законе Гаусса?
Я просмотрел вводные к другим вашим статьям. Вы — математик, учились в СПБГУ (интересно, какая же это страна), программист и не способны проследить за цепочкой уравнений. Я жалею, что ввязался в спор, хотя несколько часов назад он казался мне безобидным. Желаю вам приятного вечера.
Конкретно Гаусс говорил про сохранение потока на входе в объём и на выходе из него. Баночка для этого ни к чему.
и не способны проследить за цепочкой уравнений

Точно говорю, я ясновидящий: в комментариях моментально появился кто-то, кто начал мне объяснять, какой я идиот.
Сказать что закон Гаусса про сохранение потока это как сказать, что холодильник для нагрева комнаты. Важна свзязь между зарядом и потоком, и как следствие при отсутствии заряда поток не меняется.
"я знаю, что законы Гаусса говорят о нулевой дивергенции полей" вот эта фраза противоречит закону Гаусса. Собственно четвертое уравнение скорее эмперическое, так как не было найдено магнитных монополей.
Подождите, я ничего не понимаю. Закон Гаусса гласит: «Поток вектора напряжённости электрического поля через любую произвольно выбранную замкнутую поверхность пропорционален заключённому внутри этой поверхности электрическому заряду.»
Если в выбранном нами объёме, границей которого является та самая замкнутая поверхность, нет заряда, то эта фраза означает равенство входящего и исходящего потока. При чём тут холодильник?
Холодильник передает тепло из камеру в комнату, то есть он нагревает, но его задача именно охладить содержимое (довольно грубый пример, но надеюсь Вы поняли). Относительно закона Вы правы, но смысл именно в зависимости потока от заряда. Отсутствие заряда равносильно заряду равному нулю. Частный случай, здаже если заряд квантуется, нуль — довольно малая часть от всей области определения.
А, ну так мы об одном и том же говорим, на самом деле. Просто о терминах не сумели договориться. Согласен с вами.
При чем тут вообще Россия, не Россия? Я живу в России, пишу здесь магистерскую диссертацию, русских учебников не читал уже больше 3 лет. Сегодня английский, как когда-то латинский, де факто язык для научных работ.
Тем не менее наши учебники по фундаментальным наукам не уступают западным, и я не думаю что использование учебников на английском предпочтительнее.
Не имеет смысла сравнивать учебники по языку написания. Имеет смысл сравнивать по качеству содержания. Зачем вы их делите на западные и не западные?
Разная терминология — достаточно основание. На западе если упоминуть терему Котельникова вряд ли кто-то поймет о чем идет речь. И про Попова вряд ли многие знают. В некоторых ситуация это увы может привести к недопонимаю
Ну вот прямо сейчас я был вынужден смотреть, о чём вы. И да, про Nyquist rate я знаю, а "теорема Котельникова" у меня не вызывала вообще никаких ассоциаций. Но вся эта терминологическая путаница не должна нас отвлекать от сути вещей. Хоть горшком назови, только в печь не ставь.
Увы даже не слишком сложные обсуждения могут перейти в ссору из-за неопонимания, несмотря на то, что люди на самом деле согласны. Всегда в споре с друзьями пытаюсь выяснить что именно подразумевает собеседник, а они назыавют меня занудой=(
Оставив в стороне содержание этих учебников, хочу только отметить, что читая книги на английском, гипотетический студент параллельно тренируется читать научную литературу на английском, что тоже полезно.
Интересно! В продакшене для управления ДПТ, как правило, используется подчиненое регулирование. Регулятор положения -> регулятор скорости -> регулятор тока (или регулятор напряжения). Интегральная компонента уберет ошибку по положению. И добавить точный останов (переключение на корень квадратный от рассогласования по положению в РП).
1) Использованные в статье LQR можно при желании трактовать как подчинёнку с двумя П-регуляторами. :) Вообще, согласитесь, с точки зрения структуры все эти линейные регуляторы сводятся к сумме передаточных функций по измеряемым сигналам и заданию. В частности, в системах с одним только датчиком угла мы всегда получим управление по выходу.
2) Про интегральную составляющую автор уже писал, что не хочет её пока использовать. Ремарка: кстати, а при использовании подчинёнки И-составляющую можно вводить только в контуре скорости, используя в контуре угла П-регулятор.
3) А вот про "точный останов" это интересно. Я так понимаю, речь идет про инструментарий finite-/fixed-time сходимости, правильно? Сам подход известен, но я не видел, чтобы его реально использовали для управления системой с линейной моделью, в связке с подчинённым регулятором, и в форме переключения. Расскажите, интересно. Есть реально заметный выигрыш по качеству?
1) Да, конечно, аналитически можно свести цепочку линейных регуляторов к одной передаточной функции. И зачем?
Подчиненое регулирование позволяет независимо налаживать каждый из регуляторов. Если говорить о коллекторном двигателе с управлением от тиристорного преобразователя, то методика наладки:
а) снимаем возбуждение и/или фиксируем вал электродвигателя; подаем меандр на вход регулятора тока якоря, подбираем k и T, чтобы получить технический оптимум.
б) повторяем п.А для цепи возбуждения.
в) расфиксируем вал, включаем возбуждение, подаем меандр на вход регулятора скорости, подбираем k и T.
г) подбираем k и T для регулятора ЭДС, если двузонное регулирование.
д) настраиваем регулятор положения. Профит!
Между регулятором положения и регулятором скорости нужен задатчик интенсивности (ЗИ). За привод без ЗИ механики руки оторвут:)
2) И-составляющая без блокировки от ограничителя выхода не имеет смысла. А это нелинейность. Аналитический расчет LQR регулятора в этом случае некорректен. Очевидно это и является препятствием для введения столь полезной штуки:)
3) Под точным остановом подразумевалось работа регулятора положения от корня квадратного рассоглосования по положению. Теоретические основы у Клюева в "Теория электропривода".
На практике это дает линейно падающие ускорение (замедление :)). Что дает?
Если тормозить с постоянным ускорением: большое ускорение — большие перергулирования, колбасит у точки останова; маленькое ускорение — большой тормозной путь.
Оптимально — линейное изменение ускорения или корень квадратный от разницы по положению. Вначале тормозить интесивно, ближе к точке останова менее интесивно.
Делал так на летучих ножницах (ограничение на тормозной путь) и рольгангах(груз, держится за счет силы трения и при торможении, вначале допустимо проскальзывание, к концу -нет).
С finite-/fixed-time не сталкивался, что это в двух словах?
1) Знать, что это можно сделать и как это сделать, это не лишнее. В какой-то момент оно может пригодиться, когда захочется уйти от типовых подчинённых настроек и получить лучшее качество при той же аппаратной базе.
2) Почему автор не использует И-составляющую, это дела автора. :) Аналитический расчет остаётся корректным локально.
3) Finite-time это такие системы, в которых сходимость в ноль не экспоненциальная (или ассимптотическая при t->бесконечность), а за конечное время. Fixed-time — сходимость в область за фиксированное время независимо от начальных условий. У Вас, судя по описанию, некоторая вариация на тему finite-time.
В качестве ремарки: в моём опыте регулятор положения решает задачу слежения за траекторией, компенсации малых ошибок и парирования возмущений. Формированием же траекторий с желаемым профилем ускорения, скоростей и чего бы то ни было занимается задатчик таектории.
PS: По поводу "подбираем k и T". Я надеюсь, что Вы их, всё же, рассчитываете. :)
1) Если говорить о качестве, то основная проблема в нелинейности. К примеру, по току якоря на тиристорном приводе до 20% от номинала — зона прерывистых токов, закон Ома не работает:)
Парируют это через предуправление, которое берет на себя функцию выдачи напряжения в зависимости от задания тока, ЭДС и параметров цепи, а регулятор только сглаживает переходный процесс.
Пространство состояний бессильно в этом случае:)
2) "Корректно локально" работающий электропривод — это просто страшно:)
3) Очень интересный подход!!!
4) Начальные значения k и T современные тиристорные привода сами определяют через автонастройку(качают ток и скорости также как и при ручной). В сложных случаях — в ручную.
Аналитический расчет малоэффективен:
а) разные передаточные функции по управлению и возмущению;
б) нелинейность: прерывистые токи, трение, переменный момент инерции, двухзонное регулирование с ослаблением поля…
в) нет аналитической зависимости для момента нагрузки.
Ну это у Вас основная проблема в нелинейности усилителя, у других проблемы могут быть в неравномерности трения, в ветровых нагрузках, в ударных нагрузках, мало ли прикладных задач. :) Дело тут не в пространстве состояний, можно передаточные функции писать, можно матрицы, кому как удобнее. Но в какой-то момент для повышения качества приходится уходить от просоленных временем подчиненных контуров, даже оставаясь в рамках линейных регуляторов. Или не приходится, если конкретно Ваша задача удовлетворительно решается и без этого.
Грубо говоря, я хочу написать написать управление для сервомотора: у меня есть текущее положение оси привода и текущая скорость её вращения, я хочу её остановить в заданном положении.

Как мне кажется это задача очень похожа на классическую подзадачу управления сервомоторами для ЧПУ станка.
И она классически решается разбиением на две части:
  1. Расчета траектории с разбиением на дискретные участки (чаще всего..) с постоянной скоростью.
  2. Поддержка постоянной скорости в пределах заданного участка.

Первой задачей занимается ПО управляющее станком (автономные контроллеры или ПО типа: Mach3, Linux CNC, управляющее ПО для 3D принтеров).
В промежуточных расчетах, как результат: скорость на участках траектории. На выходе могут быть как step/dir сигналов для шаговых двигателей, так и управляющие сигналы для контроллеров сервоприводов (управляющее напряжение).
Если используются шаговые двигатели, то обычно выдачей степ сигналов для них все и заканчивается.
Для сервоприводов, контроль за скоростью возлагается на привод (контроллер двигателя).
Сделав, в свое время автономный контроллер ЧПУ на STM32f103, второй частью задачи не заморачивался, поскольку станок собрал на шаговых двигателях.
Но именно сейчас не торопясь занимаюсь похожей задачей только для коллекторных двигателей. Первое что пришло в голову "ну интересно же попробовать сделать не типично, не так как классически все делают".
Решил сделать "попроще"… и начал именно так, как описано в статье (включая съем графиков и пр. анализ)
Таким образом, реальное положение каретки слегка отличается от теоретического, я полагаю, что это из-за неучтённого трения: чем ближе к нулю, тем меньше подаваемое напряжение, и однажды оно уже не может бороться с трением. Борьба с этим феноменом будет темой одной из следующих статей. Stay tuned!

Ну… ну…
Не получится. Я на это потратил довольно много времени. Используя исключительно предложенный в статье метод, добиться точного позиционирования невозможно в принципе.
Но если хотите наступать на те же грабли, то будет повод написать еще несколько статей.
Вернулся к классике (дискретный расчет участков скорости и поддержка скорости на участке разновидностью PID) — и все работает плавно и в пределах заказанных ускорений.
В распоряжении имеется оптический энкодер (1000 пульсов на оборот), электродвигатель (750 rpm при 12В без нагрузки), драйвер L6201 и atmega 328 (arduino nano).

Оптически энкодер 1000/оборот и ATMega не имеющая аппаратной схемы работы с энкодером (как у серий STM32, например) — это тупик.
"Дребезг" энкодера программными методами не давится.
Даже с использованием 72-х МГц проца софтверная обработка (на прерываниях) не справляется (проверял ради эксперимента для энкодера 512/оборот), не говоря уж о древней atmega.
Ну… ну… Не получится. Я на это потратил довольно много времени. Используя исключительно предложенный в статье метод, добиться точного позиционирования невозможно в принципе.

Я использую "бороться" как "уменьшить влияние", а не как "полностью избавиться".
Оптически энкодер 1000/оборот и ATMega не имеющая аппаратной схемы работы с энкодером (как у серий STM32, например) — это тупик. «Дребезг» энкодера программными методами не давится. Даже с использованием 72-х МГц проца софтверная обработка (на прерываниях) не справляется (проверял ради эксперимента для энкодера 512/оборот), не говоря уж о древней atmega.

А вот тут мне стало очень интересно, так как в моём уже есть борьба с дребезгом, поняли ли вы, как я считываю значение энкодера? Если нет, то, видимо, мне нужно отдельный текст про это написать. Если поняли, то очень хочу примеры того, где оно не сработает.
У меня на энкодере есть третий канал, который выдаёт один пульс на оборот, по нему контролирусь. Никакого уплывания нет вообще, считанное rock solid для всех скоростей, от 1 оборот в секунду до 20 оборотов в секунду.
Я использую «бороться» как «уменьшить влияние», а не как «полностью избавиться».

Ну если результирующая ошибка вполне в рамках заданной величины, то почему бы и нет.
Мне нужна была более высокая точность и предсказуемый результат чем дает этот метод. Коллекторный двигатель с типичным количеством щеток/обмоток при малой скорости (мощности/заполнения ШИМ) ведет себя весьма нелинейно. Не уверен, что в заявленной задаче будет достигнут результат. Балансировка — это "мелкое" и точное управление.
А вот тут мне стало очень интересно, так как в моём уже есть борьба с дребезгом, поняли ли вы, как я считываю значение энкодера?

Не важно какой программный способ Вы применяете для фиксировании импульсов с каналов энкодера высокого разрешения на ATMega.
И… джитер энкодера практически НЕ проявляется при его вращении.

Эффект дребезга энкодера с большим разрешением отлично видно на близких к 0 или "практически" 0 скоростях.
Проявляется это так, что вычисленная программными методами координата "плывет" при 0-й скорости.

Теории и практики в Интернете полно (jitter quadrature encoder)… только ищите без слов aduino.
Слова arduino и "воинствующее невежество" для меня, как то ассоциировалось. Не на 100% но с большой вероятностью. Без обид. Я в общем имею в виду… статистически…

Впрочем, не буду Вас ни в чем убеждать и доказывать. Но стоит, наверное, задуматься зачем в контроллерах существует специальная аппаратная поддержка (обычно режим работы счетчиков) работы с энкодерами и сенсорами, где возможен данный эффект дребезга:
Supports incremental (quadrature) encoder and hall-sensor cicuitry for positioning purposes.
Поглядим, но именно что нужно отталкиваться от постановки задачи. По моим прикидкам, мне вполне должно хватить меги и инкрементальных энкодеров. ЧПУ станок я бы на таком строить не стал.
Совсем не понимаю, почему вы упираете на железную поддержку, железо или софт -принципиальной разницы нету, железо не восстановит магически потерянные данные.
Ну и напоследок про общение: вашу статистику с ардуинами мне тоже неясно, зачем вы привели, либо вы говорите, что я воинствующий невежда, либо фраза просто не по теме разговора, разве нет?
Совсем не понимаю, почему вы упираете на железную поддержку, железо или софт -принципиальной разницы нету, железо не восстановит магически потерянные данные.

Фраза про "принципиальной разницы нету" и "магически потерянные данные" говорит мне о том, что смотреть что такое quadrature encoder jitter и способы компенсации, Вы просто не стали.

А я разжевывать тему не собираюсь. Хотя еще раз замечу, что задача "балансировки" связана с очень точными и мелкими перемещениями. Не удивляйтесь, потом, автоколебаниям и невозможностью "поймать" баланс.

Фразу про воинствующих невежд, в изначальном комментарии употребил, что бы поиск не ограничился тематическими конференциями по arduino, где очень много совершенно невежественных постов и в основном тусуются школьники и студенты первых курсов.
Типичные алгоритмы и примеры работы с энкодерами на arduino (программный опрос каналов), кочующие по этим форумам применимы для других целей. Да и редко кто там сталкивается с энкодерами высокого разрешения (от $30 за штуку на e-bay).
Особенно умиляют на этих форумах предложения добавить схемный НЧ (R+C) фильтр на каналы, когда народ сталкивается с "магическими ситуациями" при работе с энкодерами и/или использует прерывания по фронту/спаду сигнала с канала.

Но раз не стали смотреть… и абсолютно уверены что Вы ВСЕ знаете, то это Ваше дело и Ваши проблемы.
Ваше и вашего будущего работодателя.

Сколько раз зарекался писать комментарии на статьи вида "а вот что я начал делать!"...
Фраза про «принципиальной разницы нету» и «магически потерянные данные» говорит мне о том, что смотреть что такое quadrature encoder jitter и способы компенсации, Вы просто не стали.

Подождите, не кипятитесь. Вы неправильно расставили скобки в моей фразе. Железо или софт — принципиальной разницы нету, (железо не восстановит магически) (потерянные данные). Есть зашумлённые данные, опрашивать их железом или софтом — я не понимаю, в чём разница. Вполне возможно, что я что-то упускаю.
Про дребезг я смотрел, и мой код дребезг (не весь, но почти весь) очень неплохо фильтрует, к сожалению, вы мне так и не ответили, поняли ли, как работает мой код, меня этот вопрос действительно живо интересует. Кроме того, помимо борьбы с дребезгом просто на каналах AB я уже говорил, что у меня есть канал Z, который просто отлично служит для борьбы с уплыванием (в моём текущем коде не используется, но я помню про него).
Про ардуино и невежд — прошу прощения, я вас неправильно понял. Не зарекайтесь писать комментарии, мне действительно интересно; спасибо за ключевые слова, уже они ценны. Но если бы вы могли написать самую малость больше, было бы вообще здорово.
"Зашумленные данные", "потерянные данные" — какие это знакомые фразы из этих форумов. Ну бред же несут! Особенно про фильтрацию.

Нет никаких "зашумленных" данных! Я поэтому и возмущаюсь, что вы так и не захотели прочитать что означает термин jitter и суть его проявления и повторяете совершенно неграмотные рассуждения.

Ну не принимайте всерьез эти форумы… ну или хотя бы читайте кроме форумов что то! Я даже ключевые слова сказал для поиска.

Джитер — это высокочастотный сигнал с обоих каналов в ситуации, когда "штрих" стоит на грани. Частота джитера такова, что обработка его программными средствами фактически невозможна. Для энкодеров в 1000 штрихов на/оборот это может быть несколько мегагерц.
Считывать состояние каналов по опросу — терять информацию. По прерыванию — просто не успеет.

Аппаратные схемы работы с квадратурным сигналом энкодеров (датчиков холла) в современных контроллерах заключаются в аппаратной обработке сигналов внутренними счетчиками контроллера. А программно читается фактическое значение энкодера. А квадратурная "разность" считается аппаратно. Могу порекомендовать заглянуть в доки на контроллеры, где этот режим поддерживает. Сразу станет понятно в чем суть и как это работает.

Даже зная теорию, и сразу подключив энкодер правильно (STM32) я ради любопытства пробовал и по опросу и по прерыванию (ну раз подключено, что бы не поэкспериментировать).

По прерыванию — сразу увидел, что не успевает. По опросу в бесконечно цикле с выводом результатов через DMA в RS323 (ну что бы вообще все минимизировать) — очень хорошо заметно как ползет случайным образом координата в ± сторону порядка 1-3 отчета в 5 сек.
А если щелкнуть ногтем по конструкции в 10 см от энкодера, то сразу скачек 15-30 отчетов в случайную сторону.

Программный же опрос условно можно считать как НЧ фильтр (хотя если уж игнорировать то схемная RC цепочка была бы лучше)… Задействовав его на медленной ATMega, Вы вполне можете получите иллюзию отсутствия джитера. А на самом деле будете просто терять информацию.

Вам же нужно не скорость мерять для удержания оборотов… (типичная задача регулирования оборотов двигателя для контроллера, реализуемая на ATMega).
Для контроля оборотов (энкодер крутится без остановку) отлично работает и программный опрос ибо эффекта джитера нет (лишь бы опрос был с частотой выше чем частота стробов на каналах).

Вы же собираетесь сделать "балансир"?
А там движения основания в пару мм — норма… Оно конечно будет работать "магически" и так… но именно магически и с дерганьем (полно роликов на youtube с мелко подрагивающими как эпилепсии балансиров). Но Вы же, наверное, хотите добиться какого то более идеального варианта? Если нет, то достаточно было бы энкодера от мышки например…

Просто всегда нужно понимать суть процессов. Тогда никакой "магии" не будет.

С аппаратным квадратурным энкодером, за час работы станка (ЧПУ) я не вижу отклонений от расчетного/фактического (по шагам шагового двигателя) к считанному с энкодера. В режиме с софтверным опросом — разница в метры.

Ставил на ЧПУ станок с шаговиками энкодер исключительно для экспериментов (там он особо не нужен).
Но заодно и проверил теорию.
А алгоритм опроса энкодера каков? Если отслеживать фазы состояния энкодера с учётом времени нахождения энкодера в каждой фазе с учётом максимальной скорости то джиттер на границе рисочки должен быть побоку.
Проблемы с программным опросом могут быть если есть перекрывающиеся задачи, которые могут прерывать опрос на достаточно большое время чтобы пропустить фазы и неверно интерпретировать состояние энкодера.
Проблемы с программным опросом могут быть если..

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

Если Вам так уж хочется узнавать все на своем личном опыте:
  • возьмите нормальный двухканальный цифровой осциллограф.
  • переключите его в режим… ну скажем 1us на деление для начала… (как раз что бы оценить..)
  • включите его в режим фиксации кадра по фронту/спаду одного из каналов.
  • щелкните ногтем по энкодеру.
  • на получившейся картинке (двух каналов) прикиньте количество/временный интервал стробов.

    Обработка по прерыванию… ну ну. Это и более "взрослый" контроллер не обработает.

    Заодно посмотрите что что ваша программа будет выдавать при таких условиях.

    В общем надоело мне на эту тему убеждать почитать… (нормальную серьезную литературу, а не рассуждения чайников на форумах). В основном, правда, все доки на английском..
Обратите внимание, что Alexeyslav вам написал в первый раз, поэтому про опять говорить некорректно.
Спасибо за предложенный протокол, я аккурат достал логический анализатор, повторю в том числе и ровно вашу последовательность действий. Ни в коем случае не собираюсь упираться, не сделав тестов. Я за то, чтобы использовать адекватные инструменты. Если что, то у меня десятибитный абсолютный энкодер лежит под боком, можно вообще его поставить.
Скажите, пожалуйста, почему вы начисто игнорируете (я два раза уже про это говорил) наличие третьего канала для борьбы с уплыванием?
Обратите внимание, что Alexeyslav

Потому что это было в данной ветке. Потому что вопрос опять же говорил о том, что по теме особо не читали…
А то что что ответ не понравился и его заминусовали — это ну просто верх корректности.
Желание общаться дальше пропадает.
Скажите, пожалуйста, почему вы начисто игнорируете (я два раза уже про это говорил) наличие третьего канала для борьбы с уплыванием?

Судя по видео, размеру шкива в районе 15..20мм, это дает… ну пусть 50мм линейного перемещения на
оборот. Для балансира отклонение в 50 мм — это уже не балансировка, а ловля падающего "маятника". Безнадежно падающего. Поэтому и игнорировал.
Т.е. рабочий диапазон в пределах одного оборота. Ну зачем здесь компенсация по третьему каналу?

Правильно подключенный энкодер, к "правильному" контроллеру "держит" точную координату в течении пары часов непрерывного перемещения туда сюда с переменной скоростью, включая нулевую местами и вибрациями.
простой тест:
  • написать простейшую программу, гоняющую туда сюда каретку (конструкция на видео) со случайными остановами и переменной скоростью, как эмуляцию работы балансира.
  • отметить положение каретки на столе (ну хотя бы карандашом)
  • погонять минут 20 каретку по столу.
  • подвести в отмеченный ноль руками (вращая вал)
  • посмотреть насколько 0 по энкодеру ушел.

Если 0 не ушел, то все в порядке, можно двигаться дальше и писать программу управления двигателями полагаясь на показания энкодера.
А если ушел — то… я бы дальше накладывать неопределенности друг на друга не стал бы.
я же не от балды все это пишу, а потому что все эти этапы уже прошел.

не люблю показывать незавершенные проекты (жду лета что бы завершить… не дома же краской на обоях рисовать по фото… для отладки размером 2 на 5 метров)
Но вот эта штука в течении часа таскает 2 кг по стене с шагом в 2 мм и возвратом в туже точку 0 с точностью до 1мм.
так что все это я уже проходил…
и энкодер на фото видно и коллекторный двигатель (привод стеклоподъемника)
Большое спасибо за то, что делитесь опытом, сейчас пошло совсем конструктивно. Я не согласен про бесполезность Z: у меня будет два энкодера, один для каретки, второй для маятника. Тот, что для маятника, будет иметь Z отметку ровно в точке баланса, и поэтому будет проходить её довольно часто, что даёт постоянное обновление. Тот, что для каретки, будет иметь обновление раз в 40мм, да, но меня устроит (медленное) уплывание позиционирования каретки +- 2см. А для быстрых реагирований его вполне себе хватит, это получается некий аналог датчика угловых скоростей: он точен на коротких промежутках и имеет дрифт на длинных. Только этот дрифт не уйдёт дальше +-2см, в отличие от гироскопа.
Мне очень полезно было узнать, что имеется вариант подключения, где уплывания не будет вообще, спасибо. Для борьбы с этим я уже купил абсолютных энкодеров и с большим любопытством смотрю, что можно использовать и инкрементальные.
Я уже гонял (минуту) с разными скоростями свой энкодер и контролировал его по Z сигналу, ничего не уплывало, что для моих целей уже более чем достаточно. Да, я знаю, что есть вещи, где мой фильтр дребезга не справится, но пока что не шёл до абсолютного идеала, мне уже хватает точности для текущей задачи. Но я обязательно буду смотреть и дальше, спасибо!
Про эмоции: желание общаться пропадает, я вас прекрасно понимаю. Но поймите и меня: я знаю, что вы уже изрядно устали от предыдущих (бесплодных) дискуссий с другими людьми, но это не повод разговаривать свысока, правда? Большое спасибо за ключевые слова, я по ним поискал информации. Но если вы хотите, чтобы я (и другие) с вами продолжали, прочтя что-то конкретное, дайте, пожалуйста, ссылку на это самое что-то конкретное, а то неясно, в какой момент останавливаться читать, чтобы можно было дальше с вами поговорить.
Я так полагаю, третий канал может служить защитой от уплывания только на макро-масштабе, т.е. на уровне количества оборотов, а если основные перемещения происходят в пределах одного оборота то когда будет выявлено несоответствие может быть накоплена слишком большая ошибка до половины оборота.
Абсолютный энкодер, в отличие от квадратурного не подвержен данной проблеме.
Для непосредственно маятника у меня вообще он не будет делать даже одного оборота, и риска Z будет стоять ровно в точке баланса, которая будет проходиться очень часто.
К сожалению, у меня нет такого энкодера. поэтому проверить при всём желании не смогу. По этой же причине не вижу необходимости много читать об этой проблеме — времени на всё слишком мало а всего слишком много, приходится расставлять приоритеты.
Было бы интересно взглянуть на подобную осциллограмму чтобы представить себе масштабы проблемы, на будущее. Если это не сложно. Наверняка она у вас уже есть.
Вдруг когда-нибудь придется столкнутся с такими энкодерми, хотябы буду знать что такая проблема имеет место быть.
И всё-таки непонятно, как можно реализовать алгоритм так чтобы положение энкодера поплыло из-за джиттера в пределах границы одного положения?
Документация на контроллер STM32F

14.3.16 Encoder interface mode
Figure 93. Example of counter operation in encoder interface mode.

Осциллограммы еще раз возится делать не буду (личного времени жалко). Но ширина и частота импульсов jitter была < 1us. И их количество просто не помещалось в буфер осцилографа (больше 20-30 точно).
Это точно помню.
Можете сами прикинуть возможность обработки каждого импульса по прерыванию и/или опросу и какую "магическую" помеху это вносит в результат.

Интернет просто переполнен (включая англоязычный сегмент) жалобами "ой… я перешел на другой процессор/сменил частоту опроса и у меня вдруг перестал работать энкодер правильно!" или "никак не могу запустить энкодер… показания скачут!".
И советы в ответ: "почисть кАнтакты у тебя навреное экодер испортился… навреное наводка от… НЛО… поставь RC фильтр- мне помогло".

За злобность прощу прощения.
Сочувствую преподам… но у них хоть карательная ручка для зачеток есть.
Эта ситуация возможна когда алгоритм слишком простой, но если следить за фазой состояния энкодера, то залипание одного из сигналов не должно приводить к регистрации ложного шага т.к. для регистрации необходимо перемещение на 2 фазы из 4-х. А тут уже не так важно сколько импульсов пройдёт за время обработки прерывания — лишь бы обработчик выполнялся быстрее чем происходит перемещение в соседнюю фазу при нормальном вращении т.е. примерно 1/4 от полного шага. Ведь нам не важно 3 прерывания зарегистрируем или 30 за это время.
Насколько я понял, аппаратный модуль энкодера работает по коду грея и поэтому лишён этой проблемы изначально.
Вобщем, как столкнусь с проблемой буду иметь в виду. Она ведь в том или ином виде встречается и с обычными энкодерами без фиксатора позиции, например в старых манипуляторах типа "мышь".
Я подозреваю, что речь о том, прерывание не успеет обработать все переходы. Если бы успевало, то вообще никакой проблемы не было бы. Пока что я тестировал на атмеге с сигналами в сотни килогерц, никаких проблем. С мегагерцами возникнут уже проблемы обработки.
image
Интересный кстати вопрос. Получается, что использование для счета 4-х фронтов потенциально опасно из-за влияния джиттера. И неважно как ведется обработка, программно или аппаратно, просто аппаратно быстрее и оно успевает обрабатывать фронты без пропусков.
Если обрабатывать по прерываниям, поймав переход канала В из low в hight и обрабатывая его, программа может пропустить переход обратно из hight в low. Соответственно насчитав по первому переходу +1, программа пропустит -1 по второму.
И пойдет дрейф показаний. Однако если для фиксации приращения +1 программа должна обрабатывать два перехода, то дребезг по одному из фронтов никак не будет влиять.
То есть по фронту канала В будет взводиться флаг готовности к счету, а по фронту канала А, при наличии флага будет производиться счет и сбрасываться флаг.
Тогда дребезг по любому фронту будет просто устанавливать (В) или сбрасывать (А) флаг, а счет производиться не будет. Чтобы был счет, вал должен повернуться как минимум на четверть шага.
Получается так. По прерыванию считать надо по двум фронтам из 4-х, иначе ловится дребезг.
STM32 мне сейчас не освоить за разумное время, поэтому костыли. Я ни разу вообще не специалист в электронике, подскажите, пожалуйста, а чем плоха фильтрация с триггером шмитта? Например, воткнуть что-то вроде 74HC14 и дальше просто читать прерывания, как я и делаю в моём коде.

Я просто смотрю, какие бывают варианты: кто-то использует HCTL-2032 в качестве хардверного чтения энкодеров, но крайне мало информации по опыту использования. В принципе, HCTL-2032 недорогой и втыкается совсем быстро, в отличие от осваивания STM32…
я ради эксперимента на 75МГц STM32F103 попробовал запустить программный алгоритм обработки сигналов с энкодера (1/512) на прерываниях. Контроллер местами оказался занят на 100%… да и не факт что все успевал все обраьлтать. На осциллограмме видел сигналы с расстоянием между фронтами 1us (1Мгц)… Конечно, типично Jitter — это звуковая частота. Но даже 20Кгц каждого фронта — это весьма затратно для обработки на прерываниях.

А STM32… да ничего сложного нет… Хорошая и понятная документация… много библиотек.
Цена? ну платка с STM32F103C8t6 стоит столько же сколько ардуиновская того же размера. А характеристики просто не сопоставимы.
Все же STM сделала мудрый шаг. NXP контроллеры ничуть не хуже, но…

HCTL-2032. Мне проще купить готовый модуль с контроллером, чем искать такую экзотику.

А из Atmel только Tiny и Мегу в мелких корпусах использую, когда что то нужно мелкое. Их еще можно самому впаять.

Простите, вы не ответили на вопрос, который меня интересовал: насколько эффективно поставить 74hc14 для борьбы конкретно с дребезгом, чтобы улучшить программную обработку и избавиться от уплываний?

А про остальное: я не собираюсь оспаривать внятность документации на stm32, но у меня сейчас нету нескольких месяцев на вдумчиво посидеть за документацией, я сейчас другой arm ковыряю, от texas instruments. Вы его уже освоили, потому вам и легче воткнуть его, а не тупую микросхему, которая раскуривается за десять минут. Мне пока что проще купить микросхему за десятку и воткнуть её, иначе смета на избавление от уплывания не десять евро плюс десять минут работы, а десять евро и месяц работы. Чисто для борьбы с дребезгом я не готов осваивать новый для меня процессор и всю среду разработки и отладки под него, всё крайне прагматично и без холиваров.
хм… а мне показалось, что ответил, говоря о том, что контроллер просто не справится с обработкой по прерыванию всех фронтов.

Мысль о «фильтрации» jitter с помощью тригера шмитта не стал комментировать, что бы не обидеть. Но раз вы настаиваете…
Вы просто не совсем верно понимаете термин jitter ИМЕННО в контексте «энкодер».
Это не какие то «магические» внешние(наводки)/внутренние помехи от которых надо «избавляться» фильрами. Это штатный режим работы отического энкодера.

А по поводу выходного сигнала с модуля энкодера высокого разрешения, то…
Не знаю, какой конкретно у вас энкодер, но, обычно экодеры высокого разрешения типа серий HEDS (например) это не просто фототранзисторы с ножками наружу, а содержат законченную схему со специфицированными выходными характеристиками. Никаких полу 0 полу 1 на ее выходе быть не может. И использование 74hc14 совершенно бессмысленно (именно как ее тригерного входа). Хуже не будет. Просто не смысла.
Ну разве что для сопряжения TTL выхода в каком то экзотичном энкодере с 3.3V входом контроллера. Да и то, обычно выход с таких модулей энкодеров — открытый коллектор.

Опять же… не знаю какой конкретно у вас энкодер, Но про энкодеры такого высокого разрешения, где есть только фототранзистор и всю обвязку нужно делать снаружи — даже не слышал.

А какой АРМ от TI?
Если A8, A9… то это «взрослые» ARM, не для контроллеров.
А если cortex M4, то видимо только начали изучать. Практически все контроллеры M3/M4 имеют встроенную поддержку quadrature encoder.
Сумеете найти ARM (именно контроллер общего назначения, а не DSP или что то еще более специализированное), что не умеет… пусть даже не TI, а другого производителя?

Опять же прошу прощения за некую злобность и сварливость, можно было мне сказать все мягче, но уж стиль такой у меня.
Мысль о «фильтрации» jitter с помощью тригера шмитта не стал комментировать, что бы не обидеть.


Не очень понимаю, с чего бы мне обижаться, я же специально пришёл за советом специалиста. А вот с дребезгом я действительно запутался тогда. Какова природа его появления? У меня энкодеры Omron E6B2-CWZ6C.

ARM, что я ковыряю, действительно достатночно крупный (omap l138).
jitte в оптических экодерах возникает при положении вала, когда датчик частично освещен.
Освещенность преобразуется в 1 или 0 по пороговому значениям. И результат может «плясать» между 1 и 0 даже когда вал условно (может и медленно вращаться) неподвижен по причине:
1. питание никогда не бывает стабильным.
2. механические вибрации.
jitter актуален для энкодеров высокого разрешения. Это для крупных полосок/фотодатчиков можно четко задать разнесенные уровни освещенности 0-1.
для мелких рисок все гораздо хуже. И разница между тень/свет не такая выраженная и механические колебания (постучать рядом с энкодером) вполне могут сдвинуть риску на критическу величину.

Отличить по одному каналу jitter от «полезного» сигнала просто невозможно ибо происхождение у них общее и «полезный»(идеальный сферический конь в вакуме) и «вредный»(реальный мир) сигнал это условности.
Т.е. нужно совместно обрабатывать все сигналы (с максимально доступной скоростью) и получать результат по 2-м каналам.
Сложно объяснить на словах… с картинками понятней.

— гляжу в спеку на Omron E6B2-CWZ6C…
— «открытый коллектор» — значит 74hc14 для согласования уровней не нужна.
— задана максимальная длинна фронта/спада на 2м кабеля в 1us. значит сигнал полностью цифровой и захват уровня освещенности датчиков внутрисхемно у энкодера (что не удивительно). 74hc14 не нужна.

omap l138 это для другой области применения чем АРМ контроллеры. Так же как в котроллерах не делают SATA интерфейс, то в таких не делают даже ШИМ генерацию аппаратную. Ибо для разных вещей предназначены.
Спасибо. Мой основной вопрос про фильтрацию состоит в том, что я бы хотел удалить все короткие импульсы. Вот у меня энкодер с тысячей пульсов на оборот. Положим, его максимальная скорость вращения будет 20 оборотов в секунду, это даёт сигнал в 20кГц или 50 микросекунд на пульс. Можно ли дёшево обрезать все пульсы с длительностью менее 50 микросекунд? Если нет, то я буду искать дешёвый (у меня самый ценный ресурс — это время) способ хардверно считать.

Я понимаю, что l138 — это полноценный компьютер, а не микроконтроллер, обратного и не утверждал, просто сказал, что ещё параллельно другую архитектуру мне не расковырять быстро, поэтому stm32 пока не могу применять. Слышал много жалоб на сложность старта с ней для новичков, близко пока не смотрел.
Кнопку «счастье» я вам не дам…
И я не знаю такого способа.
Лично на своем опыте и на сумме знаний которой обладаю в данной теме могу изложить только следующее:
Снимать и обрабатывать информацию по двум каналам энкодера высокого разрешения нужно всю (по фронтам или спадам) и обрабатывать синхронно. Иначе будет накапливаться ошибка.

Найдете способ и докажете его работу на практике — обязательно поделитесь!
Только pls, не теоретическими рассуждениями, а фактом что это работает в железе.
Критерий я называл… 15-20 минут хаотических перемещений каретки с разной скоростью и короткими остановами — хоть руками(для мазохистов), хоть программно и, что бы по возврату в фактический 0 (метка на столе карандашом) по энкодеру то же был бы 0.
У меня накопленная ошибка при программной реализации колебалась: 0.05-1%. Для меня это было много. При использование аппаратной обработки интерфейсом контроллера — ошибка 0 (ну 0 по и в пределах разрешения энкодера, конечно).

По поводу теорий… попытайтесь их вначале сами хотя бы теоретически проверить. Взять картинки осциллограмм с каналов энкодера и по проигрывать их в голове для очередной программно/аппаратной идеи.

Omron E6B2-CWZ6C крут… меня жаба задавила когда то похожий или такой же на e-bay покупать.
Несовпадение расчетных и фактических кривых может быть вызвано также неидеальностью драйвера и малым сечением проводов. При пуске двигатель кушает довольно много, а внутреннее сопротивление драйвера не менее 0,3 Ома, что даст при 4А уменьшение приложенного напряжения на 1,2В!
Ага, спасибо! Провода у меня не меньше 1мм2, так что, за это я не беспокоюсь, а вот драйвер в самом деле ведёт себя по-свински: на низких напряжениях .
Sign up to leave a comment.

Articles

Change theme settings