Альтернатива ПИДу. Ненужная ерунда, или давно известный велосипед?

[IVM]

Не надо много слов. Переходный процесс для своего чудо регулятора покажи.

[anthrwpos]

Не надо много слов. Переходный процесс для своего чудо регулятора покажи.

Вообще, в разных условиях переходные процессы выглядят по-разному.
Более того, оптимальные настройки регуляторов на регулирование без резких бросков и для преодоления переходных процессов будут разными.
Ну для затравки я настроил параметры моего и ПИД регуляторов на достижение минимальной среднеквадратичной отстройки методом Монте-Карло. А затем поставил их в условия резкого переходного процесса. Вот что из этого вышло. Здесь кривая моего регулятора черный цвет, ПИД регулятора - красный.
temp2.png
Затем я настроил их параметры на наилучшее прохождение переходных процессов и получил следующую картину.
temp3.png
Upd Для более чистого эксперимента отключил шумы модели вообще.

Стенд для испытаний регуляторов с жесткой моделью здесь https://github.com/anthrwpos1/RegTest
Кто владеет java - можете поразвлекаться тоже а заодно проверить, что я не жульничаю)

[kon48]

Добрый вечер!
Коллега anthrwpos.
1.О каком сравнении может идти речь если из представленной регистрации видно, что ПИД регулятор не настроен. Такой процесс свойственен П-регулятору.
2.Часто употребляете выражение опримальные настройки регулятора. О каком критерии оптимальности идет речь? Сформулируйте его.
С уважением Николай Митюхин

[anthrwpos]

Добрый вечер!
Коллега anthrwpos.
1.О каком сравнении может идти речь если из представленной регистрации видно, что ПИД регулятор не настроен. Такой процесс свойственен П-регулятору.
2.Часто употребляете выражение опримальные настройки регулятора. О каком критерии оптимальности идет речь? Сформулируйте его.
С уважением Николай Митюхин

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

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

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

[Владимир Ситников]

Затем я настроил их параметры на наилучшее прохождение переходных процессов и получил следующую картину.
temp3.png

Можете пояснить что нарисовано на этих графиках?
По оси x, очевидно, время. А что по оси Y?

О каком воздействии на систему речь?

Кто владеет java - можете поразвлекаться тоже а заодно проверить, что я не жульничаю)

Добавили бы unit-test'ы. Было бы проще на всё это смотреть.

Например, сдаётся мне, что ваш "волшебный" регулятор может выдать управляющий сигнал "больше 100%" (или меньше 0) (см https://github.com/anthrwpos1/RegTes...g.java#L48-L50 -- возвращается значение pRaw, которое, очевидно, может выходить за границы), и модель подчинится такому управлению и заставит нагреватель сгенерировать больше тепла (или вообще батарею превратит в кондиционер).

Я бы в обработку модели предложил добавить проверку на то, что регулятор не пытается возвращать управляющий сигнал за пределами 0..1

Как у вас работает датчик -- непонятно (я про dSense0/dSense1). Почему не идёте по своей концепции и не делаете в духе "теплопроводность датчика", "теплоёмкость датчика"?


PS. На "new PhysReg(50, 200, 300, 0.1, 20, 40, 300);" без боли смотреть невозможно. Что означают все эти цифры?
Тут нужно либо на Kotlin'е писать (там есть именованые параметры), либо в духе new PhysReg().setTimeStep(0.1).set... , либо ещё как. Но на 50, 200, 300 смотреть невозможно, и, очевидно, тут какое-то жульничество, которое даже проверять не хочется.

[o_nik]

...я настроил параметры моего и ПИД регуляторов

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

А что, если попробовать в вашем примере вот такие коэффициентики ПИДа:

PID_Fine pid = new PID_Fine(4.3, 60, 300, 0.1, 40, 20);  //создаем ПИД-регулятор

[Владимир Ситников]

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

Всё так!
Я сначала тоже думал это же самое написать, но остановился на мысли "как бы разговор не перешёл в плоскость Java программирования".

[o_nik]

как бы разговор не перешёл в плоскость Java программирования

Похоже, уже переходит Только я с Вами сильно дискутировать=спорить не буду, т.к. уже лет 7 на Java не писал.

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

[anthrwpos]

Можете пояснить что нарисовано на этих графиках?
По оси x, очевидно, время. А что по оси Y?

значение регулируемой величины.

Например, сдаётся мне, что ваш "волшебный" регулятор может выдать управляющий сигнал "больше 100%" (или меньше 0) (см https://github.com/anthrwpos1/RegTes...g.java#L48-L50 -- возвращается значение pRaw, которое, очевидно, может выходить за границы), и модель подчинится такому управлению и заставит нагреватель сгенерировать больше тепла (или вообще батарею превратит в кондиционер).

Я бы в обработку модели предложил добавить проверку на то, что регулятор не пытается возвращать управляющий сигнал за пределами 0..1

pHeater = limit(regulator.control(tSensor)) * pHeaterMax;

limit - это оно и есть - ограничитель выхода регулятора.
А сам регулятор должен выдавать управление и меньше 0 и больше 1 на случай, если он регулирует не процент включения нагревателя, а какую либо другую величину, которая может изменяться в других пределах.
Например у меня есть регулятор, который вычисляет температуру теплоносителя. Тут уж диапазоном 0..1 никак не обойтись.

Как у вас работает датчик -- непонятно (я про dSense0/dSense1). Почему не идёте по своей концепции и не делаете в духе "теплопроводность датчика", "теплоёмкость датчика"?

этот финт дает более глубокую задержку данных от датчика, которую невозможно компенсировать по производной. Всё как в жестокой реальности)

PS. На "new PhysReg(50, 200, 300, 0.1, 20, 40, 300);" без боли смотреть невозможно. Что означают все эти цифры?

В стандартной библиотеке java есть полно конструкторов с простым перечислением кучи параметров. Я лично уже привык смотреть в исходники либо в документацию, чтобы понять что это всё такое.
Может это конечно плохой стиль, спорить не буду.

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

У меня к сожалению очень мало опыта в программировании. Уж что вышло то вышло. Ну и плюс делал второпях, чтобы провести нужные испытания и хоть что нибудь по существу тут задаваемых вопросов ответить. Ну и самому убедиться, что регулятор работает как положено.

А что, если попробовать в вашем примере вот такие коэффициентики ПИДа:

PID_Fine pid = new PID_Fine(4.3, 60, 300, 0.1, 40, 20);  //создаем ПИД-регулятор

Я сегодня устранил баг в модели, поэтому там все параметры поменялись. Если вы рассчитывали эти параметры регулятора под старую модель, то нужно пересчитать.
А если просто так - то сейчас оно выглядит так:
temp2.png
уставка черным, график температуры красным.

[o_nik]

Я сегодня устранил баг в модели, поэтому там все параметры поменялись. Если вы рассчитывали эти параметры регулятора под старую модель, то нужно пересчитать.

Качал с гитхаба сегодня, где-то за 30 - 60 мин до своего поста.

При запуске Main я так понимаю в консоль выхлоп оценки ошибки выдавался для ПИД и вашего регулятора?
А где аналогичный график с вашим регулятором?