Як реалізувати самонастроюваний PID-подібний контролер

Я намагаюся написати програму мікроконтролера для контролю температури в системі з такими характеристиками:

• вихід може бути увімкнено або вимкнено, з фіксованою частотою циклу (~ 2-10 на годину)
• Рослина повільно реагує (вимірювані зміни температури займають тривалий час> 10 хвилин).
• Рослина втрачає температуру, виходячи з умов навколишнього середовища.
• Задана величина може змінюватися великими кроками залежно від потреби користувача.

Я пишу контролер, який має на меті мінімізувати помилки, а також дотримуватися частоти циклу, наданої як вхід.

Це можна легко зробити за допомогою контролера PI, і його вихід перетворюється на робочий цикл. Проблема полягає в тому, що програмі потрібно автоматично налаштувати та вибрати правильні константи Kp, Ki та адаптуватися до різних умов навколишнього середовища та змін теплової потужності. Тому заздалегідь налаштування ПІ-контролера не надто корисна.

Використання фактичного PI або PID не є обов'язковою умовою. Я готовий використовувати Fuzzy-Logic, якщо це допомагає, також є алгоритм машинного навчання на мікросхемі, який моделює системну реакцію та втрати тепла (лінійний прибл.), Який підказує інформацію про виміряну ступінь відгуку . Просто не знаю, що робити з цією інформацією.

Кілька публікацій припускають, що я можу використати дані моделювання для налаштування PI в режимі он-лайн, а також посібник з перегляду лабораторії, який підказує, що я можу використовувати Fuzzy-Logic для налаштування PI.

Моє запитання полягає в тому, який найкращий підхід для подібного сценарію (наприклад, PID, нечіткий під, згортання тощо) і як би я міг реально реалізувати його в програмному забезпеченні / практиці.

Я не EE, тому будь-який внесок буде дуже вдячний.

Я б не пішов так далеко, щоб назвати PID застарілим. Але, безумовно, є місце для вдосконалення. Один із способів автоматичного налаштування циклів управління PID - це використання методу Nelder-Mead, який є формою алгоритму симплексного сходження на гірку . Це має вигоду від можливості конвергенції та повторної конвергенції за цільовим параметром, який рухається з часом.

З цієї статті :

Наприклад, у нашому випадку налаштування параметрів PID {K _P , K _I , K _D } симплекс - тетраедр. Nelder – Mead генерує нове положення тесту симплексу шляхом екстраполяції поведінки цільової функції, виміряної у кожній тестовій точці, розташованій як симплекс. Потім алгоритм вибирає замінити одну з цих тестових точок новою тестовою точкою і таким чином техніка прогресує.

Моя особлива заява була для управління двигуном. У нас було дві петлі, петля керування струмом PID та петля управління швидкістю PI. Ми встановили наші вершини на P, I і D відповідно і провели статистику на виході циклу. Потім ми здійснювали відбиття, розширення, стиснення і зменшення знову і знову, поки створені цілі регулювання швидкості або швидкості не були в межах декількох стандартних відхилень.

З нашим продуктом ВП дуже переймався тим, як мотор "звучав". І як виявилося, це «звучало» краще, коли поточна ціль відскакувала трохи більше, ніж була математично оптимальною. Таким чином, наша настройка була виконана "в прямому ефірі", тому що ми дозволяли алгоритму шукати, поки двигун працює, щоб сприйняття користувачем звуку двигуна також враховувалося. Після того, як ми знайшли параметри, які нам сподобалися, вони були жорстко закодовані і не змінювалися.

Це, мабуть, не було б ідеальним для вас, оскільки ви заявляєте, "введення системи в коливання навіть як частина автоматичної настройки не прийнятна для користувачів". Наша система, безумовно, коливалась і робила інші жахливі речі, поки вона працювала автоматично.

Однак ви можете запустити дві копії PID-контролера. Той, який був "живим" і фактично контролював процес. І секунда, яку постійно налаштовували автоматично, подаючи ті ж входи, що й "живий" контролер. Коли вихід автоматично налаштованого контролера став «кращим» або стабільнішим, ви можете поміняти коефіцієнти на «живий» контролер. Потім контролер буде виконувати корективи процесу, поки не буде досягнуто бажаної продуктивності. Це дозволить уникнути коливань, які користувач може сприймати під час автоматичної настройки. Але якщо входи різко змінюються і PID-контролер вже не є оптимальним, автоматична настройка може змінювати нові коефіцієнти, коли вони стануть доступними.

PID-контролер корисний у ситуаціях, коли поведінку керованої системи можна обґрунтовано оцінити як суму керуючого стимулу, інтегралу керуючого стимулу та інтегралу першого інтегралу. Деякі системи контролю температури можуть задовольняти такому критерію, якщо є предмет, який нагрівається подразником рівномірно, і якщо цей об'єкт передає тепло рівномірно якомусь іншому об'єкту зі швидкістю, пропорційною різниці температур між ними. Наприклад, перший об'єкт може бути нагрівальним елементом, а другим об'єктом може бути повітря, яке циркулює в приміщенні, якщо циркуляція повітря є достатньою для того, щоб повітря вважалося таким, що має єдину рівномірну температуру. Для теплових моделей, складніших за них (наприклад, тих, які можуть включати теплові градієнти в твердому середовищі),

Я б припустив, що хорошим підходом може бути те, щоб контролер, коли нагрівач увімкнено, постійно оцінював, наскільки гарячим буде пристрій, який регулюється, якби вихід був негайно вимкнений, і температуру, до якої він закінчився б охолодження, якщо нагрівач було включено, як тільки допустимо після цього. Також оцініть, якими були б ці значення, якби нагрівач був увімкнений ще на секунду, дві секунди, три секунди тощо. Вимкніть нагрівач, коли ці значення настільки ж хороші, як і вони. Після того, як нагрівач вимкнеться, починайте виконувати подібні розрахунки, але змінюючи ролі вмикання / вимкнення, гарячого / холодного тощо, щоб вирішити, коли повернути його знову. Залежно від теплової поведінки системи, можливо, буде потрібно використовувати стратегію випередження «min / max», щоб переглянути крок або два вперед.

Можливість змінити стан управління (увімкнено або вимкнено) 2-10 разів на годину не піддається контролю робочого циклу. Вихід циклу PI буде керуючим сигналом, який змінюється за величиною залежно від помилки, і ваша установка може (реально) приймати лише двійковий вхід (вимкнено або увімкнено), оскільки "частота" управління робочий цикл, який можна прийняти, є часткою герца.

Можливо, ви захочете спростити речі та перейти до гістерезичного контролю:

• система включається, коли температура переходить нижню межу
• система відключається, коли температура переходить верхню межу
• існує достатня відстань між верхньою та нижньою межами, щоб запобігти відскакуванню керуючого виходу

Типовий (хоча загальновизнаний спрощений спосіб зробити це) називається плануванням посилення. Це класичний підхід до нелінійного управління, коли у вас є помітна змінна (або змінні), з якою ваша система змінюється (параметр планування). У вашій системі ця змінна, швидше за все, буде температурою. Ідея полягає в тому, що ви створюєте список посилень контролера при різних значеннях параметра планування (температури), а при зміні параметра планування ви використовуєте ці посилення у контролері (будь то PI, PID, зворотній зв'язок стану чи будь-що інше). Якщо це звучить дуже просто, це тому, що це так. Однак це працює і використовується в деяких дуже складних системах.

Якщо ви хочете пофантазувати, ви можете реалізувати алгоритм машинного навчання для створення матриці посилення. Це призведе до того, що контролер, що розвивається та навчається, ви, схоже, описуєте. Однак це може бути непосильним, якщо система може бути повністю охарактеризована.

Редагувати: Вибачте, я неправильно прочитав. Ви намагаєтесь контролювати температуру, щоб "умови навколишнього середовища", про які ви говорили, були вашим параметром планування.

Ви можете пройти повний контролер рекурсивних найменших квадратів, див. Astrom і Wittenmark , адаптивний контроль, але я не знаю, чи буде у мікроконтролера достатньо oomph для цього.