математически описать итнегрирующий регулятор
Напечатано из: Форум СТА — современные технологии автоматизации
Категория: II. АСУТП и SCADA
Название форума: Теория и практика автоматизации
Описание форума:
URL: http://forum.cta.ru/forum_posts.asp?TID=2841
Дата печати: 04 Апрель 2025 01:28 Версия программного обеспечения: Web Wiz Forums 9.64 - http://www.webwizforums.com
Тема сообщения: математически описать итнегрирующий регулятор
Автор: mb508
Тема: математически описать итнегрирующий регулятор
Дата публикации: 22 Январь 2008 16:42
с проблемой регулирования столкнулся на самом деле при написании драйвера для платы оцифровки аналогового видео, и пусть это не имеет никакого отношения к промышленной автоматизации, тем не менее тут видна прямая аналогия с ПИ или ПИД регуляторами.
Описание задачи: в карте оцифровки есть буфер (некая емкость) в него поступают оцифрованные кадры (некое содержимое). Мой драйвер должен забирать оцифрованные кадры из буфера и один за одним отправлять в какую либо программу для обработки.
Проблема:
1) в буфер карты кадры сваливаются пачками (по несколько штук), а драйвер должен читать кадры и отправлять их равномерно по одному, со строго одинаковыми временными интервалами T между друг-другом.
2) скорость наполнения кадрами буфера может немного плавать (м.б. нестабильность тактового генератора)
Всю информацию которую я могу получить из карты, это заполненность ее буфера.
Каким образом можно вычислить интервал времени T между отправкой пакетов из драйвера, и постоянно оооооочень незначительно его корректировать, чтобы не получилось так что буфер будет карты будет полностью опустошен или переполнен?
|
Ответов:
Автор: Vald
Дата публикации: 22 Январь 2008 21:27
А простым планированием на бумажке надо определить средний темп поступления и выбрать скорость отдачи немного больше чем темп поступления . Чтобы не было постоянно растущей очереди необработанных кадров. А дальше прямой пропорциональной зависимостью корректировать время от числа непереотправленных кадров.
------------- При экспериментах ни один чайник не пострадал
-----------
Плохому системному интегратору всегда OPC сервер мешает.
______________
Пишу на C++ за еду
|
Автор: mb508
Дата публикации: 23 Январь 2008 01:48
можно считать что у буфера есть два критических значения его заполненности, первое - буфер почти опустошен, второе - буфер переполнен. Ни в коем разе нельзя допускать чтобы эффективная постоянная заполненность буфера достигала одной из этих границ. (поэтому выбрать темп больше - недопустимо)
В идеале хотелось бы чтобы заполненность буфера стабилизировалась на одном значении, и любое оклонение эффективно (но не резко) компенсировалось.
Я уже попробовал регулировать скорость отправки через пропорциональную зависимость от заполненности (высчитываю корректировочный коэффициент и домножаю на него) - это очень нестабильно и вызывает уход "в разнос".
Пробовал также через интегральную зависимость (поправте если я чего недопонимаю), высчитывая поправочный коэффициент не постоянно, а спустя некоторые значительные интервалы времени, таким образом не учитывая некоторые мгновенные колебания заполненности буфера. Но это тоже оказалось неэффективно, так как эффективная заполненность буфера начинает довольно значительно колебаться вокруг некоторого стабильного значения. Причем частота колебайний вполне ясна - она равна частоте корректировки поправочного коэффициента.
Возможно необходимо некое пропорционално-интегральное регулирование скорости отправки?
Как можно эффективно отрабатывать колебания скорости наполнения буфера: как кратковременные скачки, так и длительные?
|
Автор: Kanzi
Дата публикации: 23 Январь 2008 13:42
Попробуйте взять плату видеозахвата и поработать с библиотекой DirectShow. Там диспетчер памяти кадров работает автоматически. Да и оцифровка проходит сама собой.
|
Автор: mb508
Дата публикации: 23 Январь 2008 14:40
Первоначально опубликовано Kanzi
Попробуйте взять плату видеозахвата и поработать с библиотекой DirectShow. Там диспетчер памяти кадров работает автоматически. Да и оцифровка проходит сама собой. |
к сожалению нет такой возможности, проект разрабатывается под linux платформой
я думаю проблема не такая уж и большая, я уже добился некоторых успехов простым методом тыка =) но все же хотелось бы получить большую стабильнось основываясь на математических выкладках, что можете посоветовать в этой области?
|
Автор: Vald
Дата публикации: 23 Январь 2008 14:43
Да похоже вы видите классическое качание регулятора. А посмотрите : нельзя ли по простому позиционный регулятор сделать. Точнее трехпозиционный. В числе непереотправленных кадров выбирается два значения. Одно выше какого-то фиксированно заданного и второе меньше фиксированно заданного. Для отправки используется три фиксированных скорости. Они подобраны так что вторая равна среднему темпу поступления. А первая и тратяя выбираются исходя из крайних значений скорости поступления. Если число поступивших и неотправленных кадров постепенно растет и превышает верхнюю уставку, то скорость отправки скачкообразно переключается на большуу и остается там до тех пор , пока число непереотправленных кадров не будет меньше верхней уставки минус выбранный гистерезис. Тогда скорость переотправки станет равной второй. В том случае если число непереотправленных кадров уменьшается и становится меньше нижней уставки - скорость переотправки уменьшится до миниммальной величины и останется такой пока число непереотправленных кадров не станет более нижней уставки плюс гистерезис. Конечно размер очереди будет колебаться.
Если вы хотите Организовать управление по Пропорционально Интегральному закону, то сначала попределитесь что будет являться регулируемым параметром а что управляющим. Мне кажется что регулируемым параметром будет какое то число неппереотправленных кадров. Вы выбираете это число и оно будет уставкой регулятора. Регулятор будет стремиться поддержать это число неизменным. А управлять регулятор будет через время переотправки.
Регулятор надо настроить правильно иначе он будет или заметно качаться или убегать в насыщени или туду или туда.
В вашем случает можно определить коэффициент пропорциональности и коэффициент в интегральном слагаемом размышляя. На практике отключите интегральное слагаемое и проведите серию экспериментов меняя последовательно коэффициент пропрциональности и определите ту группу значений когда качание имеет не очень большую амплитуду . Вот тогда можно подключать интегральное слагаемое и тоже ставить серию экспериментов меняя киэффициент в иетегральном слагаемом. Скорее всего вам удастся снизить размах колебания размеров очереди раз в 8 по сравнению с двухпозиционным регулированием . Но это будет в установившемся режиме. При выходе на режим надо будет просто при малой очереди жестко задавать такую скорость переотправки при которой очередь растет. Вы в выгодном положении - в тепловых процессах особо не поэкспериментируешь - вседлиться часами , а у вас долями секунд так что тут экспериментами по подбору коэффициентов вы добъетесь лучших результатов чем по импирическим методикам настройки регуляторов.
------------- При экспериментах ни один чайник не пострадал
-----------
Плохому системному интегратору всегда OPC сервер мешает.
______________
Пишу на C++ за еду
|
Автор: mb508
Дата публикации: 23 Январь 2008 15:14
Vald, спасибо за консультации =)
Я действительно немного сумбурно расписал все, но вы все правильно растолковали:
- регулируемый параметр - это объем буфер (соответственно какое то количество кадров в нем)
- управлящий параметр - это интервали времени между чтением каждого кадра из буфера (соответственно это скорость чтения)
Я тоже уже склоняюсь к мнению что самый лучший вариант - это совмесить ПИ-регулирование с неким фиксированным позиционным, во всяком случае это самый стабильный вариант, и можно контроллировать степень разноса качания введением промежуточных фиксированных значений, когда будет происходить просто переключение на другой корректировочный коэффициент, более жесткий например.
С коэффициентами на самом делее не все так просто =)
методом проб и ошибок их определить достаточно сложно по нескольким причинам:
- карта может работать в различных режимах скорость/качество, и потому может заполнять буфер разными по объму кадрами, с разной скоростью, разными по объему пачками.
- помимо простой неравномерности поступления данных в буфер, возникает еще и проблема коллебания скорости их поступления вследствие нестабильности тактового генератора, это уже можно отнести к тепловым процессам, так как по большей части обусловлено нагревом карты во время работы. Соответственно это могут быть очень значительные колебания очень низкой частоты
В конце концов последняя моя модификации регулятора в драйвере довольно стабильно проработала 1 день, а на второй день начала сильно качаться с периодом около 12 часов
|
Автор: Vald
Дата публикации: 23 Январь 2008 18:38
Можно попробовать в зависимости от усредненной скорости поступления кадров переключать коэффициент в интегральном слагаемом. Это надо с гистерезисами делать. И пороги переключения подальше друг от друга сделать - а то может получиться что в рабочем режиме будем напарываться на границу переключения - вполне возможно раскачается регулятор еще сильнее. Это надо аккуратно делать - так чтобы менялась скорость списания или прибавления интеграла а в самом интеграле скачка в момент переключения не было.
Переключать коэффициент в пропорциональном слагаемом не получится - будет щелчек в выходном значении.
Тут возможно и отследим изменение объекта. А так человечество борется борется линеаризовать объект регулирования. Когда мы это делаем - появляеся соблазн его погнуть и попереключать уже по нашему.
------------- При экспериментах ни один чайник не пострадал
-----------
Плохому системному интегратору всегда OPC сервер мешает.
______________
Пишу на C++ за еду
|
Автор: mb508
Дата публикации: 24 Январь 2008 00:16
да, все точно! пришел к таким же выводам через метод проб и ошибок =) никаких резких скачков недопустимо, переход от одного коэф-та к другому сделал через постеменноую инкрементацию/декрементацию на маааленькую дельту. Стабильность повысилась на порядок, но как побороть сверхнизкочастотные колебания я так и не могу понять.
Фактически я пришел к таким выводам: чтобы нейтрализовать колебания какой либо определенной частоты F, необходимо завести интегрирующую составляющую, которая бы позволяла получить среднее значение за период T (T = 1/F).
Но не заводить же эти интегралы для каждой из возможных частот колебаний ... должны же быть нормальные человеческие методы =) Я врочем не чужд каких либо математических выкладок и с радостью почитал бы теорию по этому вопросу, я буду очень признателен если ткнете меня в соответствующий материал ... потому как сам я видимо закопаюсь надолго с моей склонностью "разобраться во всем что надо и не надо" =)
|
Автор: s_smirnov
Дата публикации: 24 Январь 2008 09:11
Типичнейший случай астатического объекта регулирования :)
Есть бочка(буфер), в которую неравномерным потоком наливается вода (поток информации). И есть регулирующий орган, изменяющий скорость переотправки этой информации (скорость величина обратная времени ;))
Если основным критерием качества работы регулятора является равномерность потока отправки (тоесть постоянство скорости), значит самым подходящим типом регулятора будет П (пропорциональный), возможно (в самом крайнем случае) с небольшой интегральной составляющей.
Об этом свидетельствует вся теория и практика регулирования уровней в бочках, начиная с самого первого регулятора уровня в паровом котле.
Обратите внимание, что физический смысл имеет не время между отправками пакетов, а скорость отправки пакетов, т.е. обратная величина. Тогда всё совпадает с бочками!
------------- Сергей
|
Автор: Kanzi
Дата публикации: 24 Январь 2008 11:15
Первоначально опубликовано mb508
как побороть сверхнизкочастотные колебания |
Два соображения. Если у вас следящая система, то это её жизнь - следить за медленными перемещениями. Считаем, что система "не знает", эти перемещения носят периодический характер или нет.
Если же вы хотите подавить какую-нибудь частоту (например, часто в электронные устройства проникает 50 ГЦ помеха от сети и её давят) или полосу частот, то применяйте цифровые фильтры.
|
Автор: Vald
Дата публикации: 24 Январь 2008 18:07
Дайте мыло- кину пару статей.
------------- При экспериментах ни один чайник не пострадал
-----------
Плохому системному интегратору всегда OPC сервер мешает.
______________
Пишу на C++ за еду
|
Автор: mb508
Дата публикации: 24 Январь 2008 18:59
Vald, буду очень благодарен! kan@pisem.net
|
|