roboforum.ru

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

Почти полностью портировав Teacup на STM32, развернулся и пошел назад - стал встраивать свои функции сразу на обработчик очереди заданий. Все это выглядит очень убого, но позволило вкрчть еще одну проблему, которую надо решить (кроме контроля подачи и ускорения по нескольким осям одновременно) - очень сложно осуществить и, главное, отловить программно достижение целевой точки. То есть если мы приближаемся к точке и снижаем скорость, в какой-то момент серва остановится при необнуленной до конца ошибке. Не дойдет шагов пять-пятнадцать до точки назначения. Это значит, что алгоритм будет продолжать исполнять этот шаг вечно. Можно очень долго пытаться ПИД-ом вывести значение в ноль, но это долго и сложно сделать равномерно на всех осях. Можно обнулить ошибку, но тогда на каждом шаге будет накапливаться ошибка примерно в сотку миллиметра. И т.д.

Более того, это все сильно зависит от используемого железа - алгоритмы управления придется сильно перестраивать под моторы и нагрузку. Имхо овчинка все-таки не стоит выделки. (хотя на форумах народ на брушлесах делает сервоприводы - но это вполне себе такая инженерная задачка уровня нашего великого учителя).

legion писал(а):Ошибку не обнулять, а учитывать при расчете движения для следующей команды?

тоже да

Добавлено спустя 57 минут 56 секунд:
Почему когда я днем думаю об этом контроллере, мне кажется, что это самое элементарное, что можно сделать?

Почему когда я вечером добираюсь до дома мне кажется, что это неподъемный проект?

А я вот пришел к тому, что надо не по позиции работать ПИД-ом, а по скорости перемещения.

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

Можно в начале/конце перемещения сделать плавный рост/падение скорости, пока не понял как. Но это позволит избежать перелета. и неравномерности на старте (на все оси нагрузка разная, по идее и результат работы ПИДов должен быть разный)

Добавлено спустя 2 минуты 36 секунд:
почему не по позиции: как я уже писал, сложно вывести сервомотор на четкую позицию. тут мы бьем отрезок на 100, например, частей. почему на 100, почему не на 200? На каждом саб-отрезке получается погрешность в 10-20 тиков, если делать как говорит legion, ошибка будет не накапливаться, а плавать в этих же пределах, но каждый отрезок надо перечитывать. Т.е. управлять каждым подотрезком, как отрезком. Мы бьем задачу, но в результате задача не становится проще. Фрактал.

boez писал(а): А в ПИДе позиционирования просто защита - если рассогласование выше 0.01 мм (к примеру) - авария, стоп и красная лампочка. И сидим настраиваем ПИДы позиционирования чтобы такого не происходило.

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

Я тут еще чуть-чуть подумал и допер вот до чего. При управлении сервоприводом, скорее всего, нет смысла делать фиксированный тайм-бейз (т.е. вызывать ПИД каждые, скажем, 10мсек). Скорее имея требуемую точность и скорость подачи, надо звать ПИД не каждые 10мс, а каждые 0,001мм для обеспечения точности в 0,1мм. Подача нам известна, значит мы знаем время перемещения инструмента с заданной подачей. И мы можем рассчитать в соте за какое время инструмент с заданной подачей пройдет 0,001 мм. И вот через эти временные отрезки и звать ПИД. Критика?

Ок, понял, принимается. Заход был не на "давайте сэкономим времени процессорного", а на достаточно простую реализацию контроля ускорения... Ладно, продолжаем пилить фиксированный таймбейс.

в сервах вроде вообще П регуль просто..