Как стать автором
Обновить

Теория управления шаговым двигателем (или как вертеть PTZ камеру)

Время на прочтение4 мин
Количество просмотров8.3K
Всего голосов 9: ↑8 и ↓1+7
Комментарии43

Комментарии 43

Эту задачу в реальности надо решать для дискретного движения, так как в реальности имеем дело с шаговым двигателем. Там заметно усложняется решение

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

И вообще, задача "от нуля в ноль скорости" для 2D это самый тривиальный случай. Сложнее, когда траекторию рассчитать нужно по отрезкам и нужно учитывать граничные ускорения на переходах между отрезками в 3D (CNC).

Хотя в конечном итоге все сводится к целочисленным вычислениям с int64
На микроконтроллерах чаще всего нет аппаратной реализации операций с плавающей точкой. Да и округления могут принести неожиданные сюрпризы с поломкой фрезы.

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

Подобную задачу сын в 9 классе решал, когда манипулятор делал… (для серв, но принцип тот же)

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

для приблизительного расчета можно взять паспортный момент двигателя (или сервы), и посчитать (хотя бы прикинуть) момент реальной полезной нагрузки (с учетом «сложных условий» — дополнительной нагрузки или погодных условий ).

на практике я руками подбирал максимальное уcкскорение для каждой оси CNC.
Увеличиваешь пока пропуски не появятся. А потом ставишь в на 30% меньше в настройках.

Можно и так. Но так как у сына была задача учебная — я ему показывал как действовать не «методом тыка», а методом расчетов. Практика, в общем, подтвердила расчеты, хотя в частностях показала недостатки: при резком замедлении — «прекращении линейного ускорения», на точке перегиба — у сервы происходило «перерегулирование». Ну, заодно изучили возникающие явления — «колебания» и «резонанс».
Вылечили переводом ускорения-замедления в S-кривую, но уже без «расчетов», эмпирически.

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

Я пытался сделать программу для перемещения коллекторного двигателя с энкодером на заданное число оборотов (расстояние), чтобы оказаться в нужном месте. На рисунке ниже показано усредненный график (5 трем замерам) в шагах энкодера и 5 фаз двигателя по 1 секунде: стоп, вперед, стоп, назад, стоп. При этом для торможении я использовал реверс двигателя.

А вот рисунок как раз с выводом ускорений (разность предыдущего значение со следующим).

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

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

Чем банальный пид не угодил ?

Пробовал и пид.

ПИД при старте видит, что ошибка большая и начинает скачком выставлять высокую скорость.

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

Чтобы этого избежать приходится после ПИД последовательно ставить цифровой фильтр нижних частот.

А потом еще с ПИД не понятно когда он, наконец, установится в допустимую ошибку. Это время непредсказуемое.

ПИД при старте видит, что ошибка большая и начинает скачком выставлять высокую скорость

Значит настройки пида такие.

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

МБ проблемы с механикой еще ?

А потом еще с ПИД не понятно когда он, наконец, установится в допустимую ошибку. Это время непредсказуемое.

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

Что-то мне кажется, что в современных условиях это вообще не задача.

Эххх, разбередили :) Больше двадцати лет назад писал прошивку для управления синхронным приводом киношного 35 мм магнитофона ЛОМО. Трёхфазный сигнал + дополнительный пилот-тон, из которого внутренний привод решал - какое напряжение подавать на двигатель, чтобы он не вышел из синхрона. MCS-51 (ВЕ48), ассемблер, отладка методом прошивки ПЗУ и засовывания в кроватку. Плавный разгон с заданным ускорением, такое же плавное торможение и стабилизация скорости с отклонением не более 0.1% Эхххх, времена... :)

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

Мы в 2015м писали прошивки-спинеры шаговых двигателей на STM32.
У ARM Cortex-M4 как раз есть поддержка вычисления корня одной ASM командой.

НЛО прилетело и опубликовало эту надпись здесь

DECEL вообще не нужен

На валу шагового двигателя может быть огромная нагрузка (у меня было 70кг) с высоким моментов инерции.

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

НЛО прилетело и опубликовало эту надпись здесь

@aabzel Вы разработали алгоритм на языке ДРАКОН.
Можно ли дать ему такое название:

Вычисление моментов времени t1 и t2 переключения режимов работы шагового двигателя, управляющего поворотом PTZ камеры

Какое название алгоритма вы считаете более правильным?

Здравствуйте, @Parondzhanov. Да. Согласен. Исправил.
Спасибо Вам за Ваши учебники по ДРАКОН(у).
Вы придумали гениальную нотацию для схем алгоритмов.

@aabzel В вашем алгоритме 4 ветки. Можно ли им присвоить такие названия?
Расчет угла поворота шагового двигателя S1
Расчет времени t1, t2 для t1 = t2
Расчет времени t1, t2 для t1 I= t2
Вывод результатов t1, t2
Какие названия вы считаете более правильными?

Это, пожалуй, самый показательный коммент. Как о генитальном «инструменте», так и о тех, кто им пользуется, для кого он создан.
«названия веток» — это своего рода комментарий к алгоритму или к коду. за такие комментарии, какие предлагаете вы, даже стажера бьют чайником по морде. Предлагаемые вами «названия веток» ясно показывают: вся «симультантность» «дуракон-схемы» не помогла вам понять того, что на ней изображено. А автору схемы — не помогла корректно изобразить. Т.е. ровно то, о чем вам говорят уж последние лет 10 точно — оно бессмысленное. «Умным не нужно, начинающим вредно, дуракам не поможет»©

Ну сравните, например, с таким псевдокодом:

Функция РасчетМоментовПереключенияРежимовСервы(ТребуемоеПеремещение:Вещ, МаксимальнаяСкорость:Вещ, МаксимальноеУскорение:Вещ):{МоментПрекращенияРазгона:Вещ, МоментПереключенияНаТорможение:Вещ}

ВремяРазгонаДоМаксимальнойСкорости=МаксимальнаяСкорость/МаксимальноеУскорение
ВремяПеремещенияНаМаксимальнойСкорости=ТребуемоеПеремещение/МаксимальнаяСкорость

ПлановоеВремяДвиженияНаМаксимальнойСкорости=ВремяПеремещенияНаМаксимальнойСкорости-ВремяРазгонаДоМаксимальнойСкорости

Если ПлановоеВремяПеремещенияНаМаксимальнойСкорости < 0
Тогда
ФактическоеВремяРазгона=КвКорень(ТребуемоеПеремещение/МаксимальноеУскорение)
ФактическоеВремяДвиженияНаМаксимальнойСкорости=0
Иначе
ФактическоеВремяРазгона=ВремяРазгонаДоМаксимальнойСкорости
ФактическоеВремяДвиженияНаМаксимальнойСкорости=ПлановоеВремяДвиженияНаМаксимальнойСкорости
КонецЕсли

Возврат {ФактическоеВремяРазгона, (ФактическоеВремяРазгона+ФактическоеВремяДвиженияНаМаксимальнойСкорости)}

Все. Нужны ли здесь еще какие-то комментарии, какие-то «названия веток»? На мой взгляд, код совершенно самодостаточный и самодокументированный (ну можно один коммент добавить после «если» — «не успеваем разогнаться до максимальной скорости»). Хоть для угового, хоть для линейного перемещения. Его можно выразить на любом языке, начиная от ассемблера, и далее. На большинстве известных мне языков его еще можно подсократить, не ухудшая читаемость. Не нужно задумываться о смысле «квадратиков». Занимает в разы меньше места. IDE проконтролирует количество входных и выходных аргументов, проконтролирует типы. Такое способен (реально, а не теоретически) написать школьник 9 класса, без всяких ВУЗовских знаний. Без рисования блок-схем — они тут просто не нужны, все «как слышится, так и пишется».
Я вам еще в 2013 году скидывал ссылку на книжку, которую вы, видимо, за 10 лет так и не прочитали, ибо «не читатель, а писатель»©. Книжка издана на русском в 1985 году! процитирую оттуда всего лишь три строчки, применительно к «названию веток»:
  • Комментарии должны содержать дополнительную информацию, а не перефразировать программу.
  • Неправильные комментарии хуже, чем их отсутствие.
  • Используйте имена с подходящей мнемоникой.

Не надо нападать на ДРАКОН!
Если ДРАКОН нотацию использовать в меру, то это идеальный инструмент для объяснения алгоритмов микроконтроллеров.

У нас на дипломе в MSK ВУЗе один тип нарисовал схему специально педантично всё по ГОСТ 19.701-90. В итоге никто ни черта не понял, даже сотрудники совкового НИИ, что сидели на защите.

Поэтому ГОСТ 19.701-90 - отстой, а ДРАКОН - рулит

Если ДРАКОН нотацию использовать в меру, то это идеальный инструмент для объяснения алгоритмов микроконтроллеров.

повторю еще раз: «Умным не нужно, начинающим вредно, дуракам не поможет»©
Вы это доказали сами — автор дуракона не смог понять вашу же «идеальную схему».
У нас на дипломе в MSK ВУЗе один тип нарисовал схему специально педантично всё по ГОСТ 19.701-90. В итоге никто ни черта не понял
вы не представляете, сколько существует идиотов. И из того, что один изобразил блок-схему так, что никто не смог понять — никак не следует, что блок-схемы — ненформативны.
Но если за 40 лет существования дуракона на нем рисуют только то, что проще сделать без него — это уже говорит, что в нормальной работе он просто неприменим. Костыль. Причем еще и кривой. Несмотря на весь пиар.
спойлер
Знаете, есть у некоторых вещей, торговых марок есть девизы, слоганы?
ну, типа «Думай по-другому» у Эппл, «Соединяя людей» у Нокии, «Возможности бесконечны» у Фуджи, «создавай удивительное» у Хьюлета.
Так вот, у ДУРАКОНа он должен быть «дураками для дураков».

Вот как раз из-за такого отношения ко всему новому и прогрессивному РФ и остается дремучей и отсталой от всего цивилизованного мира территорией.

НЛО прилетело и опубликовало эту надпись здесь
Обратное тоже часто бывает верным. Поэтому эмбеддеру нужно хорошо знать и схемотехнику, и программирование. Нормальное программирование. потому, что дураконирование — это примерно как проектирование на фритцинге.

Если так рассуждать, что можно и утверждать, что те кто собирают сборки из CMake тоже слабоумные и занимаются дуракодированием (параллельно своим смежникам, что уже деградировали до уровня Fritzing).

Так как более низкоуровневая и гибкая технология это сборка из Make.

сборщики не называют себя программистами (ну по крайней мере процесс сборки — программированием, хотя он имеет свой язык). а CMake — гениальным инструментом. Не утверждают, несмотря на то, что сборщику пофиг исходный язык, на котором написаны модули, «CMake является гибридным языком». Авторы CMake, несмотря на то, что этим инструментом пользуются миллионы, не пишут книги об «улучшении работы ума», «почему мудрец похож на обезъяну», не призывают к «пересборке собственной жизни с помощью CMake», не суют CMake в медицину…
И главный аргумент — CMake не пихали в учебные заведения, по нему не проводили конференций с участием академиков — им просто удобно пользоваться.
upd.
Я бы даже не прикалывался над автором, если бы его опус был работоспособным и применяемым (т.е. удобным, полезным, информативным). Собственно, я тоже задумывался о применении «этого» 15 лет назад. Но по факту оказалось, что несмотря на тайную технологию улучшения работы ума, написать за 30 лет смогли поделку уровня студента третьего курса. дуракон при разработке дуракон-редактора не применяли (странно же, правда — у вас есть суперпупертехнология, позволяющая быстро и безошибочно программировать даже без программистов — а вы пишете свою реализацию этой технологии на позорном Дельфи). Ну и собственно, большинство восторженных поклонников, бравшихся за «доработку/разработку инструментария» (как и я, кстати), заканчивали тем, что «когда научился — это только мешает». Это же касается применеия для бизнес-процессов, да вообще для всего. Оно умерло при рождении. просто еще дергается, потому, что его за ниточки тянут

CMake менее удобен чем Make.

CMake держится исключительно на административном ресурсе внутри проектов.

Я часто замечал, что СMake скрипты дают осечки.

В большинстве российских электронных конторах, где пишут код для микроконтроллеров вообще кроме кода никакой документации по алгоритмам не делают. Все эти схемы алгоритмов только ВУЗовцы в основном рисуют.

Иногда даже сам код толком черт знает на чьем компе в организации хранится.

Главная документация это электрическая схема в *.png файлике, топология PCB в PCAD 2006 и чертеж корпуса в SolidWorks. И всё.

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


Подразумеваю, что в большом IT (разработка Web сайтов) ситуация с кодом лучше. Там хотя бы знают, что такое системы контроля версий исходников.


Ну так наверное, надо внедрять стандарты проектирования, описание интерфейсов — примерно то, что америкосы начинали делать в 1970-х.
Надо внедрять системы управления версиями, (что, кстати, приходящая молодежь делает, часто «вопреки» «дедам»).
хранитель схемы в png заслуживает того же, что и алгоритма в дураконе — «смерти через макумбу»© Ибо еще во время учебы я щупал PCAD schematic (а когда пошли первые ПК — у любого владельца-электронщика (хоть любителя, хоть инженера) — был либо набор дискет с пикадом, либо друг, у которго был набор дискет )
Вся остальная документация это результат работы редкостных альтруистичных сотрудников.
нет, отсутствие документации — это результат пофигизма начальства.
Кстати, «главное — это схема» — это и есть причина появления дуракона. (придется написать поподробнее)
Подразумеваю, что в большом IT (разработка Web сайтов)
называть сайтостроение «большим ИТ» — такое себе. (хтя к некоторому количеству сайтов это применимо)
Все эти схемы алгоритмов только ВУЗовцы в основном рисуют.
Именно. Потому, что схема алгоритмов нужна либо для учебной цели на начальном этапе, либо для нормоконтроля «на отъвяжись».
В нормальном случае код является самодостаточным, в сложных случаях — достаточно добавленных к нему комментариев. Опять же, в упомянутой мной книге ВанТассела это настоятельно рекомендуется делать:
Помните: программы читаются людьми.
Понимаете, не «не надо смотреть в говнокод который сгенерил дуракон-редактор», а «программы читаются людьми». Т.е. «пиши так, чтоб твой код мог прочитать любой нормальный человек» (под нормальным я в данном случае подразумеваю человека, которому этот код читать необходимо для каких-то целей, и он предпринял некоторые действия для этого — прочитал про синтаксис ЯП, например)

Код хорош тем что его хотя бы grep(ать) можно.

А в огромной картинке не найдешь место с ключевым словом. (Тольrо если это не векторный формат *.svg).

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
не надо здесь морочить беицим
— аргумент! прям убойный аргумент.
Типичная ситуация с кодерами — теоретиками
Это вы про паронджанова, и прочих «рисовальщиков программ»«визуальных программистов»?
НЛО прилетело и опубликовало эту надпись здесь
«когда вы говорите, Иван Васильевич, такое впечатление, что вы бредите»©
бейцым, тырса, в.у.математика, оценочные шарады, потеря будущего…

Мне кажется, что надо еще разработать нормальную нотацию для создания блок-схем печатных плат.
https://habr.com/ru/post/667030/

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории