Возможно я не совсем правильно донес то что хотел сказать.
Рассмотрим, в качестве примера, именно эту статью.
По факту реализации (в программном коде):
1. На входе модели два параметра: позиция каретки и угол маятника.
3. Все параметры модели полностью заданы заранее как результат расчета по конкретным физ. параметрам (масса, длинна и пр.)
3. На выходе скорость (хотя на самом деле — это напряжение/скважность ШИМ).
Т.е. подразумевается, что скорость физическая однозначна будет соответствовать «напряжению» на двигателе (вычисленной скорости).
Но:
1. Столь упрощенная модель двигателя в реальной жизни будет работать с большой погрешностью.
2. Любое существенное изменение параметров (чашка кофе на маятнике, как на одном из видео в примера реализации обратного маятника) и в данной концепции мат. модель перестанет соответствовать.
п1. можно компенсировать двумя способами:
1. Адаптивно менять коэффициенты расчета ШИМ для заданной скорости.
2. Поддерживать скорость с PID (с существенно более высокой частотой).
п2. в данном способе решения (мат модель процесса) не решается в лоб вообще.
— Как решаются такие задачи на практике (промышленные решения) — я давал ссылку на очень полезную статью. https://geektimes.ru/company/npf_vektor/blog/274096/
Если бы я все это не пробовал сам на практике, то и не говорил был.
Мне нужно было (для системы типа polargraph) держать на определенных участках постоянную скорость и позиционироваться в определенную точку с обычным коллекторным мотором с редуктором (да еще червячным)
Я неделю (вечера) потратил на эксперименты с идеей: «Не хочу подбирать коэф. PID, у меня же есть гениальная идея. Щаз сделаю модель, по которой буду выставлять ШИМ исходя из скорости». Ровно так как автору. И даже такие же графики рисовал.
Все замечательно работает на участках начиная от 3-5 мм/сек.
Но вот для меньших скоростей нет. Да еще вешаешь на каретку другой груз — вообще все меняется.
Позиционирование с заданной точностью вообще не получилось (как раз по этой причине).
Плюнул на все и вернулся к классике (PID двух звенный). Все заработало.
А после того как по совету автора статьи (https://geektimes.ru/company/npf_vektor/blog/274096/) дискретизацию увеличил, так вообще все плавно и точно стало.
Самое главное, что и по первому варианту худо бедно работало. Но вот именно, что «худо бедно».
Впрочем, свои грабли, тщательно выструганные и отполированные всегда любимые же?
Ну к примеру ДПТ с энкодером (двигатель постоянного тока же имели в виду?) и мат. модель реализованная программно с неизменными коэффициентами.
Допустим, мы нашли экспериментальным или теоретическим путем график зависимости скорости от напряжения и коф. уровнения задали в константами. (Как автор)
Но эти константы получены для конкретных условий! Но при других условиях (другой массе каретки, трение покоя при старте) нужны чуть (или ничуть) другие коэфициенты. А они не меняются.
Если коэф. мат модели будут корректироваться динамически, то модель будет в процессе работы адаптироваться под физ. объект.
PID они будут корректироваться или вообще другим алгоритмом… это уже на выбор.
У автора есть фиксированная мат. модель на вход которой подается информационный сигнал (позиция), а она выдает управляющий сигнал (напряжение).
Ладно что сигнал только один (по хорошему бы еще и ток двигателя мерить, потому что правильней управлять током мотора).
Но параметры мат. модели то фиксированные. Под фактический реальный мир она не подстраивается.
Т.е. один раз создали модель с каким то приближением. Проверили что в определенных (довольно узких условия эксперимента) она более менее близка к «железке» с конкретными параметрами (масса/длина и пр.).
И сказали: «Это реальность». Все. модель (программа) полностью детерминирована (конкретному параметру на входе соответствует значение на выходе).
Но обычно делают так, что бы мат модель подстраивалась динамически под реальный мир. Самый простой и классический способ — PID (из самых простых, но можно и посложней придумать исходя из модели)
Позвольте не согласиться, несколько разные задачи. В задаче удержания сервопривода сила чаще всего (локально) постоянная и не меняет знака
Вы серьезно? Ну хотя бы видео в той статье посмотрите, где автор именно демонстрирует то что вал двигателя остается неподвижным при знакопеременных нагрузках.
А про ЧПУ, где нужно удерживать позицию при знакопеременных нагрузках я и не говорю уж.
Поскольку в выбранной вами конструкции требуется не удержать маятник строго вертикально (гироскопа/акслерометра же нет), а удержать позицию энкодера — то это ну один в один типичная задача позиционирования вала двигателя по экодеру. И все равно, для классического алгоритма (со звеньями PID, которые вам так не нравятся), сколько промежуточных механических передач присутствует между двигателем и датчиком (энкодером).
Никто не строит мат. модели ЧПУ станка. Все гораздо проще… Не нужно усложнять.
Дальше, то, что вы утверждаете, что люфт не мешает, указывает на то, что вы даже не пытались решить задачу, пусть и умозрительно. Люфт вносит лаг в систему. Чтобы это прочувствовать, давайте его увеличим: если люфт эквивалентен метру положения тележки, то маятник давно упадёт, когда тележка соизволит сдвинуться с места.
Не надо утрировать и передергивать. Люфт редуктора. О другом люфте я и не говорил. Люфт обычного редуктора с эвольвентным профилем. Сомневаюсь что люфт у Вас больше 1-2 градусов на выходном валу (ну для самых убогих и дешевых мотор/редукторов). Это вызовет в худшем случае мелкую вибрацию около 0 удержания. Не более.
Это голословное утверждение. С моей стороны я даже привёл выкладки, с вашей только пока пустой воздух.
Вы построили мат. модель и рассчитали коэф. для ускорения/скорости и напряжения в конкретных условиях наблюдения. И почему то считаете что «посчитать именно модель для гладких кривых, приближающих реальность».
Т.е. мат модель ближе к реальности чем реальная система?!
Да изменятся в параметры (да хоть смазка загустеет, другое положение маятника даже..) и…
А в самом начале графика реальное поведение весьма непредсказуемо (трение покоя, например или на какой обмотке щетка стоит или… да все мат. моделью в принципе не предусмотреть) и будет весьма далеко от «гладкой кривой мат. модели».
А как раз именно это место (начало движения) важно для того что бы «маятник стоял как влитой».
В результате на Вашем видео я и вижу раскачку туда сюда маятника в режиме «почти упал — подхватили».
Или у Вас еще одно видео? где «ловя отклонения маятника очень маленькими движениями»
Подход автора:
1. Создаем математическую модель системы и считаем что она совпадает с реальной в некотором приближении.
2. Все константы вычисляем и частично подбираем вручную (что бы наблюдаемый процесс приближался к реальному). Константы фиксированные.
3. То что выходит за рамки модели в реальном наблюдении называем «шумом» и отбрасываем.
В принципе стандартный вариант создание математической модели процесса. А что что его (этот подход) изучают не только в ТАУ — вполне нормально.
Но только в ТАУ еще и про другие вещи говорятся…
В рамках предложенной мат. модели автором, без обратной связи, оно так и будет болтаться как на видео.
Более того, автор упорно игнорирует данные мной ссылки на виде, где на ходу меняются параметры системы (чашка кофе или пару консервных банок на маятник прямо во время работы) и маятник продолжает оставаться рабочим.
При этом утверждает:
Опять же, умозрительно меняем параметры для того, чтобы понять моё утверждение: любой из предложенных вами маятников не сможет удержать центнер веса маятника.
У меня нет слов… я привожу примеры (видео!) что это возможно, а мне говорят «не сможет»…
Да. В концепции автора (математическая модель с фиксированными коэф. по конкретным массам и длинам) это не может работать.
Почему она не стоит как вкопанная на нулевой позиции, ловя отклонения маятника очень маленькими движениями?
Мелкими движениями!? Ну я же вижу это видео в статье!
Это мелкие движения? Да это скорее ближе к автоколебаниям.
Интересно, сколько у автора заняло времени подобрать параметры мат. модели (и что будет если на маятник навестить грамм 10 груза, не меняя коэффициенты?
В данном случае использовался ПИ-регулятор для токов, П-регулятор для скорости и ПИД-регулятор для положения. Никакой магии типа фаззи-логики, линейно-квадратичных регуляторов и прочего.
Цитата из приведенной мной ссылке. https://geektimes.ru/company/npf_vektor/blog/274096/
Профессионала в этой области. Это он конечно ехидно сказал. Но имеет право.
Кстати, из чего делаю вывод что по приведенной ссылке вы даже не ходили. Иначе поняли бы о чем я.
К слову, задача управления перевернутым маятником (в данной конструкции!) — это в чистом виде задача удержания позиции (по энкодеру).
И люфт в редукторе особо на это не влияет. Двигатель с редуктором в качестве сервопривода станка с ЧПУ — это типично и не особо мешает.
К слову сказать, на всех ваших ссылках оборудование стоит минимум на порядок, а то и на два больше моего. И мёртвого хода, например, в их приводах нет.
Похоже приведенные ссылки Вы просто не смотрели… Я специально подобрал варианты, наиболее близки по оборудованию. Но есть и примеры где народ делает и на энкодерах от мышки. И ничего… подергиваясь но выходит в 0 быстро.
То есть, имея текущую скорость (состояние системы), мы легко можем посчитать напряжение, которое нужно приложить, чтобы получить необходимое ускорение.
Концептуальная ошибка вот в этом постулате. И с этой концептуальной ошибкой Вы лучше результата, чем показанный на вашем ролике елозящую туда сюда каретку, не получите. Как раз Ваш ролик и демонстрируют эту ошибку.
И не надо пенять на люфты в редукторе и пр.
Давайте приведём полный список необходимых для этого физических величин:
•m: масса маятника
•2l: длина маятника (l — это расстояние от петли до центра масс маятника)
Вас не настораживает момент на всех видео (pendulum inverted), когда сверху накладывают дополнительный вес, меняя и центр масс и массу маятника, специально демонстрируя, что управление продолжает поддерживать маятник?
Нет? А зря…
Это вторая ошибка в выбранном Вами способе.
Ясно-понятно, ещё один персонаж, текст не читавший.
Читавший… все читавший.
Итак, как я и говорил в своей прошлой статье, у меня есть студенты, которые панически боятся математики,
Пришли ко мне за советом. А я ни бум-бум вообще в теории управления, никогда и близко не подходил.
Это цитаты из ваших же статей.
Общаться дальше просто не интересно. Советовать преподавателю почитать учебник, как то не комильфо.
Какое счастье, что у меня преподаватели были другие.
Наверное я предвзят, но использовать тег «учебник» для своих личных альтернативных рассуждений и подходов к решению классической задачи считаю несколько некорректно.
Почему альтернативным, потому что управление обратным маятником — это задача решаемая в рамках теории управления.
А ее курс стандартно изучают в тех. вузах.
Вот если бы я увидел результат похожий на то что видел у других (youtube)…
Простите, но я правильно понял, что вы только что предположили, что я написал много формул, но показал видео работающего маятника, в котором использовал что-то другое, нежели изложенную теорию? Ух, интересное предположение. Зачем мне это делать???
Извините. Но Вы действительно считаете, что эта система на вашем видео с незатухающими колебаниями такого размаха — это реализация задачи маятника?! (pendulum inverted)
Я подумал, что это просто демонстрация какого то промежуточного этапа работы, не более.
С Вашим оборудованием (высокого класса) маятник должен приходить в равновесие за сек и стоять мертво!
к примеру:
https://www.youtube.com/watch?v=a4c7AwHFkT8
https://www.youtube.com/watch?v=MWJHcI7UcuE
https://www.youtube.com/watch?v=XWhGjxdug0o
Такие заявления неплохо бы подкреплять ссылками.
https://geektimes.ru/company/npf_vektor/blog/274096/
Никакой магии. Классическая теория управления (3 курс).
Один только вопрос.
Просмотрев Ваши многочисленные статьи по тегом tutorial (!!!) я хотел бы получит ответ.
У Вас маятник работает (фактически) на основе изложенных в статье рассуждений и формул?
Вопрос не праздный. Все же излагать свеже придуманную теорию не подтверждая ее результатом под тегом tutorial, мне кажется, не совсем корректно.
Я могу оспорить некоторые ваши рассуждения и указать на места где потенциально может накапливаться ошибка, которая приведет автоколебаниям (в случае реализации маятника) и пр. недостатки (ручной подбор коэф. при изменении..).
Но, считаю это бессмысленным, если у вас есть только рассуждения и нет работающего результата.
Вот если бы статьи были оформлены так:
1. Вот работающий маятник. с такими то и такими то параметрами и результатами. с графиками прихода в уравновешенное состояние при внешнем воздействии.
2. А вот теперь математика и моя теория, которую я использовал… (не по классике «теория правления»)
Во было бы все корректно и правильно.
Недавно проскакивал очень полезный цикл статей про двигатели и управление позицией, написанный профессионалом в этой области. Всем заинтересованным, рекомендую прочитать эти статьи. И литературу по теории управления.
Ну а если интересно и денег нет, то можно потратить кучу времени на сборку самому «мозга» с драйверами + написание G-code процессора...: D
Вы путаете "интересно" и "денег нет". Я вполне могу сразу купить готовый станок и лицензионную Math3. Не так оно и дорого стоит. Но зачем мне это?
Разработка — это для души… Кто то спичечные коробки собирает или машины коллекционирует, а мне вот программированием и электроникой интересно заниматься (на работе типа не хватает).
Ну еще дайвинг… но это уже другая тема.
Сам факт наличия в результате ЧПУ фрезера, как результат, это то же для души.
Если уж на то пошло, то, что иногда на нем делаю (опять же для хоббийных целей) горазда дешевле было изготовить на стороне (если учесть всю стоимость).
Когда покупал контроллер ВВООБЩЕ про тему ЧПУ ничего не знал. Ну а потом менять одну готовую железку, на другую показалось не интересно. Почему — я объяснял. Работает и ладно.
OS целиком написанная и развиваемая одним человеком — сомневаюсь в практическом результате.
Да просто по объему кода физически невозможно (я не про ядро и не про «микро» OS дипломных проектов).
В том, что этим можно заниматься — даже не сомневаюсь. Возможно даже идеи заложенные концепциях гениальные.
Но кто этим будет заниматься и проверять/развивать?
Типичный диплом (тема) в НГТУ на соответствующем факультете был (сейчас не знаю): RTOS под какой ни будь контроллер/процессор или разработка ядра процессора с микрокодом.
Естественно учебная и только для демонстрации работы.
В рассуждения о…
Intel закрывает разработку в России. Может быть появившаяся статья с этим связана… или нет…
Как то хотел сделать нечто то подобное. Но останавливает практически 0-я ценность результата и вторичность (не интересно повторять).
А пока только наблюдаю за тем как цена за 2 года плавно снизилась с 60$ до 35$ (на e-bay).
Измеряемую температуру отображает почти мгновенно. Реально достаточно 1-2 периодов измерений для получения точного результата (0.3-0.5 секунд).
Мда… тогда и понятно откуда 3 минуты взялось. Это для разового измерения в интерактивном режиме 300ms "почти мгновенно". Для режима сканирования это слезы.
Придется ждать падения цен на MLX90614 или появления дешевых матриц типа MLX90620.
Есть датчик с «родной» линзой — около 5°, вероятно даже более острый угол.
В документации то диаграмма весьма красивая нарисована. Ну раз никто не нашел время проверить по факту, то наверное нужно считать, что так оно и есть.
Было бы интересно, если бы со штатной "линзой" в этом ценовом диапазоне, хотя бы на 50 метрах ловился контраст между 20 и 30 градусами (человек/животное). Для FOV=5 это не реально.
Но по факту, никто из похвалившихся разработкой, на открытой местности тестов не делает. Все в помещении на 5 метрах максимум картинки тестов.
Нормальные контроллеры в другой ценовой категории.
А так, используя (пусть и немного доделанный и частично перепаянный) китайский контроллер, я редко обрабатываю на максимальных для моего станка скоростях 1200..1300 mm/min. И что не могу на 2000..2500, например, меня не сильно напрягает.
Ну подумаешь рельеф будет на час дольше на картинке 250x160mm выполнятся. Да и ладно. Не для заработка это делаю.
Ну пусть свистят и шипят движки с этой платой. Пусть выше 1500 mm/min скорость не тянут (теряют шаги). Пусть пришлось шаговикам радиаторы на термопасту прикрутить.
Да и ладно, если станок раз, в месяц в лучшем случае, пользую. Да и то по акрилу, текстолиту и пр. с типичными скоростями 400-600mm/min.
На производство (если бы этим занимался), такую гадость как TB6… серию конечно не взял бы.
Для домашнего хоббийного употребление с доработкой "напильником"… вполне можно.
Хотя заранее сочувствую тем, кто из купленной на aliexpress/ebay китайской электронике в нижней ценовой категории сразу хочет получить работающую вещь.
Инженерные решения китайских электронщиков просто поражают иногда. Все ради копеечной экономии! Да еще и неграмотно.
Угол, если не ошибаюсь, 5 градусов(по документации).
По документации, то я и сам знаю.
Я надеялся что кто ни будь фактическую диаграмму направленности построит.
Весь скан, с учетом передвижения, занимает примерно 3 минуты
Я вот и хотел спросить, а на основе чего именно такая скорость сканирования была выбрана.
Из соображений "если больше, то больше ошибка определения температуры"? Или еще каких?
А можно подробности (если конечно такие измерения проводили) из практической эксплуатации этого датчика:
Минимальное время для измерения одной точки? Т.е. для более менее точного измерения температуры при переходе от пятна с 20 градусами, до 100 градусами, на сколько нужно зафиксировать позицию, что бы получить результат ну скажем с 20% точностью.
В статье должна быть ссылка на исходники прошивки для фрезера.
Код прошивки на фрезер с тех пор не менял. Работает и работает..
Подвариант (#ifdef...) прошивки для принтера я так и не доделал (управление экструдером). Да и принтер недоделанный стоит на подоконнике уже давно.
Все что мне надо на фрезере получается гораздо быстрее чем могло быть на принтере. Да еще из нужных материалов (пластик, текстолит, дерево и пр.).
Так что принтер как то оказался и не нужен.
Было такое (местный локальный банк + "фактура"). Пользовался именно как физ. лицо. Сейчас не особо нужно и не особо интересовался — остался ли такой сервис.
Ну а будет сильно нужно — буду искать. В конце концов доплатить руб. 500 (розница) за OTP токен или 1000руб PKI карту+(ридер) это не большая цена за безопасность.
Рассмотрим, в качестве примера, именно эту статью.
По факту реализации (в программном коде):
1. На входе модели два параметра: позиция каретки и угол маятника.
3. Все параметры модели полностью заданы заранее как результат расчета по конкретным физ. параметрам (масса, длинна и пр.)
3. На выходе скорость (хотя на самом деле — это напряжение/скважность ШИМ).
Т.е. подразумевается, что скорость физическая однозначна будет соответствовать «напряжению» на двигателе (вычисленной скорости).
Но:
1. Столь упрощенная модель двигателя в реальной жизни будет работать с большой погрешностью.
2. Любое существенное изменение параметров (чашка кофе на маятнике, как на одном из видео в примера реализации обратного маятника) и в данной концепции мат. модель перестанет соответствовать.
п1. можно компенсировать двумя способами:
1. Адаптивно менять коэффициенты расчета ШИМ для заданной скорости.
2. Поддерживать скорость с PID (с существенно более высокой частотой).
п2. в данном способе решения (мат модель процесса) не решается в лоб вообще.
— Как решаются такие задачи на практике (промышленные решения) — я давал ссылку на очень полезную статью. https://geektimes.ru/company/npf_vektor/blog/274096/
Если бы я все это не пробовал сам на практике, то и не говорил был.
Мне нужно было (для системы типа polargraph) держать на определенных участках постоянную скорость и позиционироваться в определенную точку с обычным коллекторным мотором с редуктором (да еще червячным)
Я неделю (вечера) потратил на эксперименты с идеей: «Не хочу подбирать коэф. PID, у меня же есть гениальная идея. Щаз сделаю модель, по которой буду выставлять ШИМ исходя из скорости». Ровно так как автору. И даже такие же графики рисовал.
Все замечательно работает на участках начиная от 3-5 мм/сек.
Но вот для меньших скоростей нет. Да еще вешаешь на каретку другой груз — вообще все меняется.
Позиционирование с заданной точностью вообще не получилось (как раз по этой причине).
Плюнул на все и вернулся к классике (PID двух звенный). Все заработало.
А после того как по совету автора статьи (https://geektimes.ru/company/npf_vektor/blog/274096/) дискретизацию увеличил, так вообще все плавно и точно стало.
Самое главное, что и по первому варианту худо бедно работало. Но вот именно, что «худо бедно».
Впрочем, свои грабли, тщательно выструганные и отполированные всегда любимые же?
Допустим, мы нашли экспериментальным или теоретическим путем график зависимости скорости от напряжения и коф. уровнения задали в константами. (Как автор)
Но эти константы получены для конкретных условий! Но при других условиях (другой массе каретки, трение покоя при старте) нужны чуть (или ничуть) другие коэфициенты. А они не меняются.
Если коэф. мат модели будут корректироваться динамически, то модель будет в процессе работы адаптироваться под физ. объект.
PID они будут корректироваться или вообще другим алгоритмом… это уже на выбор.
Ладно что сигнал только один (по хорошему бы еще и ток двигателя мерить, потому что правильней управлять током мотора).
Но параметры мат. модели то фиксированные. Под фактический реальный мир она не подстраивается.
Т.е. один раз создали модель с каким то приближением. Проверили что в определенных (довольно узких условия эксперимента) она более менее близка к «железке» с конкретными параметрами (масса/длина и пр.).
И сказали: «Это реальность». Все. модель (программа) полностью детерминирована (конкретному параметру на входе соответствует значение на выходе).
Но обычно делают так, что бы мат модель подстраивалась динамически под реальный мир. Самый простой и классический способ — PID (из самых простых, но можно и посложней придумать исходя из модели)
Автор почему то не любит PID…
Вы серьезно? Ну хотя бы видео в той статье посмотрите, где автор именно демонстрирует то что вал двигателя остается неподвижным при знакопеременных нагрузках.
А про ЧПУ, где нужно удерживать позицию при знакопеременных нагрузках я и не говорю уж.
Поскольку в выбранной вами конструкции требуется не удержать маятник строго вертикально (гироскопа/акслерометра же нет), а удержать позицию энкодера — то это ну один в один типичная задача позиционирования вала двигателя по экодеру. И все равно, для классического алгоритма (со звеньями PID, которые вам так не нравятся), сколько промежуточных механических передач присутствует между двигателем и датчиком (энкодером).
Никто не строит мат. модели ЧПУ станка. Все гораздо проще… Не нужно усложнять.
Не надо утрировать и передергивать. Люфт редуктора. О другом люфте я и не говорил. Люфт обычного редуктора с эвольвентным профилем. Сомневаюсь что люфт у Вас больше 1-2 градусов на выходном валу (ну для самых убогих и дешевых мотор/редукторов). Это вызовет в худшем случае мелкую вибрацию около 0 удержания. Не более.
Вы построили мат. модель и рассчитали коэф. для ускорения/скорости и напряжения в конкретных условиях наблюдения. И почему то считаете что «посчитать именно модель для гладких кривых, приближающих реальность».
Т.е. мат модель ближе к реальности чем реальная система?!
Да изменятся в параметры (да хоть смазка загустеет, другое положение маятника даже..) и…
А в самом начале графика реальное поведение весьма непредсказуемо (трение покоя, например или на какой обмотке щетка стоит или… да все мат. моделью в принципе не предусмотреть) и будет весьма далеко от «гладкой кривой мат. модели».
А как раз именно это место (начало движения) важно для того что бы «маятник стоял как влитой».
В результате на Вашем видео я и вижу раскачку туда сюда маятника в режиме «почти упал — подхватили».
Или у Вас еще одно видео? где «ловя отклонения маятника очень маленькими движениями»
1. Создаем математическую модель системы и считаем что она совпадает с реальной в некотором приближении.
2. Все константы вычисляем и частично подбираем вручную (что бы наблюдаемый процесс приближался к реальному). Константы фиксированные.
3. То что выходит за рамки модели в реальном наблюдении называем «шумом» и отбрасываем.
В принципе стандартный вариант создание математической модели процесса. А что что его (этот подход) изучают не только в ТАУ — вполне нормально.
Но только в ТАУ еще и про другие вещи говорятся…
В рамках предложенной мат. модели автором, без обратной связи, оно так и будет болтаться как на видео.
Более того, автор упорно игнорирует данные мной ссылки на виде, где на ходу меняются параметры системы (чашка кофе или пару консервных банок на маятник прямо во время работы) и маятник продолжает оставаться рабочим.
При этом утверждает:
У меня нет слов… я привожу примеры (видео!) что это возможно, а мне говорят «не сможет»…
Да. В концепции автора (математическая модель с фиксированными коэф. по конкретным массам и длинам) это не может работать.
Мелкими движениями!? Ну я же вижу это видео в статье!
Это мелкие движения? Да это скорее ближе к автоколебаниям.
Интересно, сколько у автора заняло времени подобрать параметры мат. модели (и что будет если на маятник навестить грамм 10 груза, не меняя коэффициенты?
Цитата из приведенной мной ссылке. https://geektimes.ru/company/npf_vektor/blog/274096/
Профессионала в этой области. Это он конечно ехидно сказал. Но имеет право.
Кстати, из чего делаю вывод что по приведенной ссылке вы даже не ходили. Иначе поняли бы о чем я.
К слову, задача управления перевернутым маятником (в данной конструкции!) — это в чистом виде задача удержания позиции (по энкодеру).
И люфт в редукторе особо на это не влияет. Двигатель с редуктором в качестве сервопривода станка с ЧПУ — это типично и не особо мешает.
Похоже приведенные ссылки Вы просто не смотрели… Я специально подобрал варианты, наиболее близки по оборудованию. Но есть и примеры где народ делает и на энкодерах от мышки. И ничего… подергиваясь но выходит в 0 быстро.
Концептуальная ошибка вот в этом постулате. И с этой концептуальной ошибкой Вы лучше результата, чем показанный на вашем ролике елозящую туда сюда каретку, не получите. Как раз Ваш ролик и демонстрируют эту ошибку.
И не надо пенять на люфты в редукторе и пр.
Вас не настораживает момент на всех видео (pendulum inverted), когда сверху накладывают дополнительный вес, меняя и центр масс и массу маятника, специально демонстрируя, что управление продолжает поддерживать маятник?
Нет? А зря…
Это вторая ошибка в выбранном Вами способе.
Читавший… все читавший.
Это цитаты из ваших же статей.
Общаться дальше просто не интересно. Советовать преподавателю почитать учебник, как то не комильфо.
Какое счастье, что у меня преподаватели были другие.
Наверное я предвзят, но использовать тег «учебник» для своих личных альтернативных рассуждений и подходов к решению классической задачи считаю несколько некорректно.
Почему альтернативным, потому что управление обратным маятником — это задача решаемая в рамках теории управления.
А ее курс стандартно изучают в тех. вузах.
Вот если бы я увидел результат похожий на то что видел у других (youtube)…
Извините. Но Вы действительно считаете, что эта система на вашем видео с незатухающими колебаниями такого размаха — это реализация задачи маятника?! (pendulum inverted)
Я подумал, что это просто демонстрация какого то промежуточного этапа работы, не более.
С Вашим оборудованием (высокого класса) маятник должен приходить в равновесие за сек и стоять мертво!
к примеру:
https://www.youtube.com/watch?v=a4c7AwHFkT8
https://www.youtube.com/watch?v=MWJHcI7UcuE
https://www.youtube.com/watch?v=XWhGjxdug0o
https://geektimes.ru/company/npf_vektor/blog/274096/
Никакой магии. Классическая теория управления (3 курс).
Просмотрев Ваши многочисленные статьи по тегом tutorial (!!!) я хотел бы получит ответ.
У Вас маятник работает (фактически) на основе изложенных в статье рассуждений и формул?
Вопрос не праздный. Все же излагать свеже придуманную теорию не подтверждая ее результатом под тегом tutorial, мне кажется, не совсем корректно.
Я могу оспорить некоторые ваши рассуждения и указать на места где потенциально может накапливаться ошибка, которая приведет автоколебаниям (в случае реализации маятника) и пр. недостатки (ручной подбор коэф. при изменении..).
Но, считаю это бессмысленным, если у вас есть только рассуждения и нет работающего результата.
Вот если бы статьи были оформлены так:
1. Вот работающий маятник. с такими то и такими то параметрами и результатами. с графиками прихода в уравновешенное состояние при внешнем воздействии.
2. А вот теперь математика и моя теория, которую я использовал… (не по классике «теория правления»)
Во было бы все корректно и правильно.
Недавно проскакивал очень полезный цикл статей про двигатели и управление позицией, написанный профессионалом в этой области. Всем заинтересованным, рекомендую прочитать эти статьи. И литературу по теории управления.
Вы путаете "интересно" и "денег нет". Я вполне могу сразу купить готовый станок и лицензионную Math3. Не так оно и дорого стоит. Но зачем мне это?
Разработка — это для души… Кто то спичечные коробки собирает или машины коллекционирует, а мне вот программированием и электроникой интересно заниматься (на работе типа не хватает).
Ну еще дайвинг… но это уже другая тема.
Сам факт наличия в результате ЧПУ фрезера, как результат, это то же для души.
Если уж на то пошло, то, что иногда на нем делаю (опять же для хоббийных целей) горазда дешевле было изготовить на стороне (если учесть всю стоимость).
Когда покупал контроллер ВВООБЩЕ про тему ЧПУ ничего не знал. Ну а потом менять одну готовую железку, на другую показалось не интересно. Почему — я объяснял. Работает и ладно.
Да просто по объему кода физически невозможно (я не про ядро и не про «микро» OS дипломных проектов).
В том, что этим можно заниматься — даже не сомневаюсь. Возможно даже идеи заложенные концепциях гениальные.
Но кто этим будет заниматься и проверять/развивать?
Типичный диплом (тема) в НГТУ на соответствующем факультете был (сейчас не знаю): RTOS под какой ни будь контроллер/процессор или разработка ядра процессора с микрокодом.
Естественно учебная и только для демонстрации работы.
В рассуждения о…
Intel закрывает разработку в России. Может быть появившаяся статья с этим связана… или нет…
Спасибо за информацию.
Как то хотел сделать нечто то подобное. Но останавливает практически 0-я ценность результата и вторичность (не интересно повторять).
А пока только наблюдаю за тем как цена за 2 года плавно снизилась с 60$ до 35$ (на e-bay).
Мда… тогда и понятно откуда 3 минуты взялось. Это для разового измерения в интерактивном режиме 300ms "почти мгновенно". Для режима сканирования это слезы.
Придется ждать падения цен на MLX90614 или появления дешевых матриц типа MLX90620.
В документации то диаграмма весьма красивая нарисована. Ну раз никто не нашел время проверить по факту, то наверное нужно считать, что так оно и есть.
Было бы интересно, если бы со штатной "линзой" в этом ценовом диапазоне, хотя бы на 50 метрах ловился контраст между 20 и 30 градусами (человек/животное). Для FOV=5 это не реально.
Но по факту, никто из похвалившихся разработкой, на открытой местности тестов не делает. Все в помещении на 5 метрах максимум картинки тестов.
Нормальные контроллеры в другой ценовой категории.
А так, используя (пусть и немного доделанный и частично перепаянный) китайский контроллер, я редко обрабатываю на максимальных для моего станка скоростях 1200..1300 mm/min. И что не могу на 2000..2500, например, меня не сильно напрягает.
Ну подумаешь рельеф будет на час дольше на картинке 250x160mm выполнятся. Да и ладно. Не для заработка это делаю.
Ну пусть свистят и шипят движки с этой платой. Пусть выше 1500 mm/min скорость не тянут (теряют шаги). Пусть пришлось шаговикам радиаторы на термопасту прикрутить.
Да и ладно, если станок раз, в месяц в лучшем случае, пользую. Да и то по акрилу, текстолиту и пр. с типичными скоростями 400-600mm/min.
На производство (если бы этим занимался), такую гадость как TB6… серию конечно не взял бы.
Для домашнего хоббийного употребление с доработкой "напильником"… вполне можно.
Хотя заранее сочувствую тем, кто из купленной на aliexpress/ebay китайской электронике в нижней ценовой категории сразу хочет получить работающую вещь.
Инженерные решения китайских электронщиков просто поражают иногда. Все ради копеечной экономии! Да еще и неграмотно.
По документации, то я и сам знаю.
Я надеялся что кто ни будь фактическую диаграмму направленности построит.
Я вот и хотел спросить, а на основе чего именно такая скорость сканирования была выбрана.
Из соображений "если больше, то больше ошибка определения температуры"? Или еще каких?
Т.е. можно ли существенно быстрее?
Я же правильно понимаю, что это сделано под "влиянием" https://geektimes.ru/post/257850/ ?
А можно подробности (если конечно такие измерения проводили) из практической эксплуатации этого датчика:
спасибо заранее..
не сильно.
Приложение, обрабатывающее SMS — это не сложно под Android.
В статье должна быть ссылка на исходники прошивки для фрезера.
Код прошивки на фрезер с тех пор не менял. Работает и работает..
Подвариант (#ifdef...) прошивки для принтера я так и не доделал (управление экструдером). Да и принтер недоделанный стоит на подоконнике уже давно.
Все что мне надо на фрезере получается гораздо быстрее чем могло быть на принтере. Да еще из нужных материалов (пластик, текстолит, дерево и пр.).
Так что принтер как то оказался и не нужен.
Было такое (местный локальный банк + "фактура"). Пользовался именно как физ. лицо. Сейчас не особо нужно и не особо интересовался — остался ли такой сервис.
Ну а будет сильно нужно — буду искать. В конце концов доплатить руб. 500 (розница) за OTP токен или 1000руб PKI карту+(ридер) это не большая цена за безопасность.
ну так я жж про STM32F3 писал.
Подумал, что Вы опечатались…
Да ну?! Как сказали то безапелляционно.
А я и не знал то что с выхода STM32 нельзя светодиод зажечь..
И как же это у меня станок уже который год работает?
https://habrahabr.ru/post/250677/