roboforum.ru

ну а какая система где используется ПИД будет не следящей ?

Система стабилизации.

=DeaD= писал(а):А почему (в каком смысле) "следящяя" то? Какие еще бывают? Во всех примерах [[Перевод статьи "Просто о ПИД-алгоритмах"]] она используется как управляющая, или все системы с обратной связью называются отныне "следящие"?

Это общепринятая терминология в ТАУ.

Чё-то я опять поленился погуглить короче система управления не "следящая" - это когда мы знаем полную матмодель управляемого объекта что ли?

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

=DeaD= писал(а):

RoboTok писал(а):Короче для управления скоростью ПИД не шибко подходит...
А для плавного старта и нету в ПИД регуляторе функции...

А ты не меняй резко команду и всё передавай в пид команду', и пресэмплинг:

если команда-команда'>епсилон, тогда команда'=команда'+епсилон
иначеесли команда-команда'<-епсилон, тогда команда'=команда'-епсилон
иначе команда'=команда

Вот эта штука обычно и зовется acceleration/deceleration ramp generator или rate limiter. Выполнять через регулярные интервалы времени, обычно вместе с регулятором, но можно реже. Для плавности требует большей разрядности числа для команда', чем для самой команды. Мы его звали генератор темпа. Просто ограничитель темпа нарастания/спадания скорости. Причем скокрости - именно команды на скорость. А после этой штуки - ПИД или ПИ. Тогда коэффициентами ПИ/ПИД достигаем оптимального регулирования скорости, а генератором темпа - нужного темпа. Вот код для примера - 16-разрядный ПИ для АВРки, правда работало это на довольно медленной системе и ШИМ-выходы авр шли на ПЧ типа Lenze, который управлял мотором. Там 2 канала было, но это не важно. ПИ-регулятор обеспечивал ОС по скорости, сигналом ОС были метки с вращаемой системы. Несмотря на 16 разрядов использовались реально 8.

Да. Задачи оптимизации по времени выполнения или размеру не стояло, так что написано максимально прозрачно.

Функции регулятора и рампы (числа отфонарные, совпадение с реальными изделиями случайно )

Код: Выделить всё • Развернуть

#define PI_KOEFF_P 50
#define PI_KOEFF_I  100

typedef struct
{
   long ival;
   short min;
   short max;
   short err;
   short out;
} TPIReg;

typedef struct
{
   long ival;
   long rate;
} TRate;

short StepRate(TRate *rate, short inval)
{
   long delta;
   
   delta = ((long)inval << 16) - rate->ival;
   if (delta < -rate->rate) delta = -rate->rate;
   else if (delta > rate->rate) delta = rate->rate;
   
   rate->ival += delta;
   
   return rate->ival >> 16;
}

short StepPIReg(TPIReg *reg, short err)
{
   short res;
   
   reg->err = err;
   
   reg->ival += ((long)err)*PI_KOEFF_I;
   res = reg->ival >> 16;
   
   if (res<reg->min) {
      res = reg->min;
      reg->ival = ((long)res)<<16;
   }
   else if (res>reg->max)
   {
      res = reg->max;
      reg->ival = ((long)res)<<16;
   }
   
   res += ((long)err*PI_KOEFF_P)>>8;

   if (res<reg->min) {
      res = reg->min;
   }
   else if (res>reg->max)
   {
      res = reg->max;
   }
   
   reg->out = res;
   
   return res;
}

Как применять (инициализация)

Код: Выделить всё • Развернуть

 TPIReg MyReg;
 TRate MyRate;

 PIReg1.ival = 0x50000;
 PIReg1.min  = 5;
 PIReg1.max  = 254;

 RateIn.rate = 0x800; //0x400;
 RateIn.ival = 0x2000;    

и само тело цикла регулирования:

Код: Выделить всё • Развернуть

 OCR1A = StepPIReg(&MyReg, StepRate(&MyRate, command) - feedback);

ну тут command - это команда скорости, feedback - измеренная скорость откуда-нибудь из другой части проги - из считалки импульсов.

Поле err в структуре ПИ - чисто отладочное, для расчета не нужно, а вот по уарту его выплевывать и смотреть в виде графика - полезно. Вообще для настройки регулятора жутко полезно иметь возможность смотреть на графики как минимум команды и реальной скорости, наложенных на друга.

Почему min и max - переменные, а коэффициенты - константы - не спрашивайте, не помню уже

А что вы делали, если мотор крутился прямо и поступила команда реверса ?

хоть вопрос и не мне...
вариантов два.. либо максимально быстрое реагирование на команды, либо плавность хода...

RoboTok писал(а):А что вы делали, если мотор крутился прямо и поступила команда реверса ?

Вот написано выше. По английски правда или по-португальски.

boez писал(а):Просто ограничитель темпа нарастания/спадания скорости. именно команды.

Да, только код уже другой будет...

А мне пришлось ещё делать буфер команд, чтоб при реверсе не глотались команды.

RoboTok писал(а):А что вы делали, если мотор крутился прямо и поступила команда реверса ?

Конкретно в этом применении реверса не было. А так - поскольку в регуляторе знаковые числа, то он вполне способен работать и с реверсивным вращением.

Если мотор управляется H-мостом, как в миниботе например, надо выдаваемое регулятором число не сразу в OCRxx писать, а "разобрать" на модуль и знак - модуль записать в OCRxx, а по знаку выдать 1 или 0 на ножку управления направлением.

Вот только энкодер для нормального реверса нужен квадратурный (2 канала со сдвигом по фазе на 90 градусов), чтобы направление определял - потому что иначе действительно при реверсе непонятно, в какую сторону крутится мотор. Или нужно на реверсе принудительно придавливать регулятор, выдавать какой-то начальный уровень ШИМ и ждать, пока двигатель не закрутится устойчиво в другую сторону. Или ловить минимум скорости. Или еще какой-то дополнительный алгоритм применять, вот чего не делал - того не делал.

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

IR-энкодер ?
если да - то это общеизвестный затык с ик-энкодерами. с определённной частоты смены секторов они перестают чувствовать такты.

nest писал(а):IR-энкодер ?если да - то это общеизвестный затык с ик-энкодерами. с определённной частоты смены секторов они перестают чувствовать такты.

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



Это такая фича, и энкодер большего диаметра с ИК-парами лучше читает или нужно схемку сгородить для улучшения сигнала? Или мышкины энкодера криво стоят? Решил пока переделать энкодер.

SMT, можно попробовать увеличить ток через светодиод.
попробовать поиграть с настройками фотоприёмника (включить доп. ОУ?).
но лучше всё таки сменить тип энкодера.

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

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

В случае с SMT надо глянуть схему включения.
Возможно, скорость подъёма или спада "плохие" из за большого номинала резисторов и/или, как сказал nest
слабого излучения светодиода.

Я обычно 10 кОм ставлю "под" мышиные фотоприемники при 5 вольтовом питании и сигнал с них на 74hс14 подаю для "оцифровки" в четкие "0" - "1".

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

Ещё я заметил, что вы поставили диск энкодера на вал колеса.
Самый простой вариант - это если у вас есть промежуточная шестерня, то поставить на неё диск энкодера.
Но всё равно поменять датчик на приличный.

Добавлено спустя 1 минуту 26 секунд:
АВР я уже понял, что вы поклонник апноутов от Микрочипа