Comments 42
Туториалы о ТАУ, тем более в gamedev, это всегда здорово! Спасибо за статью. Я только пять копеек про некоторые неточности о ПИД добавлю, вдруг пригодится.
Недостаток пропорционального закона управления заключается в том, что регулятор никогда не стабилизируется в заданном значении
Это не так. Можно говорить, что в механических системах и при наличии трения это похоже на правду, но не в общем случае.
увеличение коэффициента пропорциональности всегда приводит к автоколебаниям
То же самое — не всегда, а для некоторых типов систем.
интегральное звено всегда вносит некоторое смещение и если система подвержена некоторыми постоянным ошибкам, то оно их компенсирует (за счет своего смещения). А вот если же этих ошибок нет или они пренебрежительно малы, то эффект будет обратным — интегральная составляющая сама будет вносить ошибку смещения.
Вот это вообще на столько не так, что я даже теряюсь, откуда это. Никакой ошибки смещения нормально сделанная интегральная составляющая вносить не будет (разве что в каком-то очень искусственном примере, но я не смог с ходу такого придумать).
Именно по этой причине её не используют, например, в задачах сверхточного позиционирования.
Это всё ещё про интегральную составляющую, и это абсолютно не так. Используют, ещё как используют. Скорее от D откажутся, чет от I.
Ключевым недостатком интегрального закона управления является эффект насыщения интегратора (Integrator windup)
Справделивости ради, для этого недостатка есть ряд достаточно простых способов обхода, anti-windup.
На самом деле есть множество других костылей, <...> или же поставить фильтры нижних частот между SP(t) и операцией SP(t)−PV(t) за счет которого будет происходить плавное нарастание ошибки
Вот это (поставить задатчик траетории) как раз самое правильное решение.
а можно совсем развернуться и впендюрить самый настоящий фильтр Калмана для сглаживания входных данных <...> В общем костылей много, и добавить наблюдателя конечно хотелось бы
Фильтр Калмана и наблюдатели в этой задаче ни при чём, они используются для оценивания недоступных измерению состояний объекта.
Собственно вся ТАУ и крутится вокруг частотных характеристик процессов
Да уже почти 50 лет как нет. :) Годов с 70-х прошлого века, наверное.
Но это не критика, а некоторые нюансы. :) Спасибо за статью!
Это не так. Можно говорить, что в механических системах и при наличии трения это похоже на правду, но не в общем случае.
Вот как раз здесь пример именно, что без трения — можете собрать такой же проект на Unity3D и сидеть ждать, когда положение корабля стабилизируется после поворота — если использовать только один П-регулятор, то это случится… никогда, ну я по крайней мере не дожадлся :-), да и в Octave тоже самое получается.
А вот при наличии углового трения, уже да, колебания корабля во время поворотов станут затухающими и он сможет стабилизироваться в заданном положении, через какое-то время, но это будет равносильно тому, что для случая без трения мы добавили еще один контур П-регулирования по скорости (как в самом конце статьи).
А вот если мы выкинем из модели всю динамику вращательного и поступательного движения, т.е., например, будем напрямую и мгновенно менять положение, то тогда да, тогда с П-законом вообще никаких проблем не будет. Но это уже будет другая динамическая система и совсем другая модель. Вот только тут не понятно что общее, а что частное: мое мнение такое, что в принципе все физические процессы инертны, да еще такие неприятные моменты, как задержки в контуре управления и т.д., т.е П-составляющая всегда будет вносить некоторую колебательность, но для некоторых частных случаев все будет хорошо.
Вот это вообще на столько не так, что я даже теряюсь, откуда это. Никакой ошибки смещения нормально сделанная интегральная составляющая вносить не будет (разве что в каком-то очень искусственном примере, но я не смог с ходу такого придумать).
Что значит «нормально сделанная»?
Это же фундаментальная особенность именно операции «интегрирования»: на всем интервале наблюдения (интегрирования) все значения [ошибок в нашем случае] будут просуммированы и накоплены.
Можно посмотреть на это по другому — звено интегратора найдет площадь криволинейной трапеции, описываемой функции ошибки, и эта площадь на всем интервале наблюдения почти всегда будет отличная от нуля.
Это разве что ли прикрутить какой-нибудь костыль, например, сбрасывать аккумулятор через определенные интервалы времени или еще чего.
Просто в реальной жизни астатичные системы встречаются редко и обычно имеют дело со статичными САУ, у которых всегда имеется некоторая установившееся ошибка после переходного процесса. И вот интегральное звено эту ошибку компенсирует и повысит степень астатизма САУ. Осталось только придумать такую динамическую систему, которую можно было бы (и имел бы смысл) использовать в игре.
Что касается примеров того, где интегральная составляющая вносит смещение, то пожалуйста: собственно сабж — сделайте Ki, отличную от нуля и всегда будете получать некоторую ошибку, вот прям здесь это хорошо видно на примере регулятора угловых скоростей youtu.be/oVL0tvluUe8?t=48 но и с регулятором угла будет такая же ситуация. А уж в совсем запущенных случаях (при большом коэффициенте) интегратор так вообще раскачает корабль и выведет его из равновесия.
А вот если если снова добавить трение, то интегратор будет уже не таким страшным — только толку от него все равно никакого не будет, только длительность переходного процесса увеличит, а корабль итак без смещения выставляется в нужный угол.
Так что тут остается только вносить в программную модельку, блин я даже так с ходу хз, например, какую-то постоянную ошибку при определении скоростей или позиции, шумы там какие-нибудь, то тогда да, тогда интегральная составляющая будет работать. Вопрос только — а надо ли это? Я вот хз, например, в том же KSP я не замечал что они там моделируют какие-то ошибки управления и шумы и т.д.
В общем все зависит исключительно от того какую динамическую систему мы пытаемся регулировать. Вот можно было бы сейчас повыдумывать разные динамические системы из игр, впихнуть их в Unity3D и расширить статью, вот в тех примерах, которые я приводил — рулят исключительно П- и ПД-регуляторы (что в случае наличия трения, что без оного).
Может если сюда заглянет какой-нибудь разработчик и расскажет где какие у него проблемы или что он использует. Просто те же повороты в Unity3D можно реализовать без этих всяких регуляторов: заморозили оси вращения и и используем Qunaternion.Lerp и все (пример я тоже тут привел), еще и контроллировать параметры игровых объектов будет проще. А вот, например, если управление осуществляется честно только за счет физики (т.е. прикладывая разные силы к объектам), тут вот у народа возникают вопросы, как реализовать повороты и круиз-контроль (вот хотел его тоже добавить, но сил не хватило, может потом расширю статью), еще и при разных параметрах физики (с трением/без трения, со всякими материалами и т.д.).
Какие еще примеры можно выдумать?
Вот в случае… эээ… наведения ракеты на маневрирующую цель с переменным ускорением, вот там как раз можно впихнуть интегратор и будет работать точнее и надежнее, но это точно уже другая статья и отдельная тема по алгоритмам навигации (а их несколько), по которой кстати тоже вопросы «как это сделать в Unity3D» постоянно задаются forum.unity.com/threads/augmented-proportional-navigation.392427 и на них не особенно охотно отвечают, зато продают ассеты :-)
Фильтр Калмана и наблюдатели в этой задаче ни при чём, они используются для оценивания недоступных измерению состояний объекта.
Ну, например, я вот не особо в курсе, что за динамическая система типа Ship у меня в итоге получилась: если массу, предположим, я задаю ручками, то вот какой момент инерции получается — я хз, потому что твердое тело сложной формы (и Unity3D это все же учитывает). А знал бы какой момент инерции, то смог бы тогда синтезировать оптимальный регулятор контроля поворота или еще чего. Тем более еще под большим вопросом, что твориться внутри физического движка Unity3D, тут вот на Хабре есть целая статья, где народ выяснял как там работает трение (с RigidBody2D проще, т.к. Unity3D использует Box2D для таких тел и в его исходном коде можно порыться, но опять таки большое хз, чего там своего авторы Unity3D могли наворотить, а их мануал вообще нихрена не раскрывает того, что твориться под капотом).
В общем, тут бы по-хорошему еще бы пройтись по идентификации динамической системы в Unity3D.
Да уже почти 50 лет как нет. :) Годов с 70-х прошлого века, наверное.
Я хз, как крутили-вертели Фурье, Лапласом, Гильбертом и Z-преобразованием, так и крутят-вертят дальше.
Большой текст получается, поэтому я разделю ответ на несколько веток, этот комментарий и два ниже.
Сразу же дисклеймер — я очень поверхностно знаком с программированием вообще и совсем не знаком с геймдевом (я долгое время думал, что раз unity это такой gui для Ubuntu, то при чём тут геймдев?). Когда вы мне пишете про кораблик в unity, то я мало что в этом понимаю, я не знаю как это устроено, какую физику и как они моделируют, так что примеры из octave для меня куда понятнее. Но так оказалось, что я несколько разбираюсь в ТАУ.
Теперь по вопросам.
Вот как раз здесь пример именно, что без трения — можете собрать такой же проект на Unity3D и сидеть ждать, когда положение корабля стабилизируется после поворота — если использовать только один П-регулятор, то это случится… никогда, ну я по крайней мере не дожадлся :-), да и в Octave тоже самое получается.
Я предполагаю, что в unity и в octave вы моделируете систему как задание момента, который делится на момент инерции, интегрируется, получается скорость, которая потом интегрируется и получается угол, так? То есть мы говорим про двойной интегратор. Действительно, в этом случае пропорциональный по ошибке угла регулятор приведёт к автоколебаниям. А если бы у вас был какой-то сервопривод, который отрабатывает заданную ему скорость, то П регулятор по ошибке угла обеспечивал бы сходимость этого угла к заданной величине. А если бы было вязкое трение, то тоже была бы сходимость. А если бы вы управляли не углом, а скоростью, то опять П-регулятор давал бы сходимость. А если бы при этом у вас было сухое трение, то была бы (прикидываю в уме) статическая ошибка. Видите сколько вариантов? Потому я и написал, что общие и категоричные утверждения
<пропорциональный> регулятор никогда не стабилизируется в заданном значении
т.е П-составляющая всегда будет вносить некоторую колебательность
неверны, так как всё сильно зависит от конкретной системы и деталей.
Второй вопрос.
Это же фундаментальная особенность именно операции «интегрирования»: на всем интервале наблюдения (интегрирования) все значения [ошибок в нашем случае] будут просуммированы и накоплены. Можно посмотреть на это по другому — звено интегратора найдет площадь криволинейной трапеции, описываемой функции ошибки, и эта площадь на всем интервале наблюдения почти всегда будет отличная от нуля.
Вы правы, что интегратор интегрирует. Но как ошибка может быть положительной или отрицательной, так и её интеграл может быть равен нулю.
А ещё мне кажется, что вы смешиваете смещение и колебания. Да, если И составляющая применена не так и не там, где она нужна, то замкнутая система может стать колебательной или неустойчивой. Но ни к какому (постоянному) смещению она приводить не должна. Упрощённо — если есть постоянное смещение (ошибка), то оно накапливается на интеграторе, что приводит к росту управления, что приводит к движению в сторону уменьшения ошибки. Как правило, добавление И составляющей к регулятору в линейных системах приводит к повышению порядка астатизма на единицу. Два интегратора последовательно добавили — повысили порядок астстизма на два. И так далее. Откуда возмётся смещение?
Что касается примеров того, где интегральная составляющая вносит смещение, то пожалуйста: собственно сабж — сделайте Ki, отличную от нуля и всегда будете получать некоторую ошибку, вот прям здесь это хорошо видно на примере регулятора угловых скоростей
По указанным выше причинам я не могу воспроизвести этот пример, а видео мне мало о чём говорит. Но если у вас добавление И составляющей приводит к появлению постоянного смещения, а система при этом остается устойчивой, то это очень странно. Попробуйте повторить в octave, было бы интересно разобраться.
Просто в реальной жизни астатичные системы встречаются редко и обычно имеют дело со статичными САУ, у которых всегда имеется некоторая установившееся ошибка после переходного процесса.
Я бы более сказал, что встречаются и такие системы, и этакие. А каких больше — специфика предметной области.
Сначала в статье описывается регулятор углового положения «кагбэ в космосе» — там отлично работает ПД-регулятор и никакого шума в систему управления тут не вносится (вообще я думал по этому месту тоже пройтись, но меня закосячило, тем более это не совсем оправданное усложнение).
А И-звено там реально бесполезное. Если его внести, то будет такая ситуация: как только корабль приблизится к нужному углу — у него все равно будет присутствовать некоторая ошибка, которая будет асимптотически стремится к 0, ну т.е. уменьшаться то она будет, но только очень-очень медленно, совсем медленно. Возможно когда-нибудь, где-нибудь в бесконечно, ошибка и установится в 0.
Можно поиграться с И-составляющей и добиться таки достаточно заметного смещения, главное не поусердствовать — при слишком большой И — корабль просто разбалтывает нафиг.
Аналогичная ситуация будет с круиз-контролем на этом же пимере (сюда я его не впилил, хотя наверное стоит), но там еще веселее — вполне себе хватает П-составляющей.
Ну а конце система управления прирастает еще одним ПИД-регулятором, который всегда компенсирует скорость поворота, т.е. его задача выдавать момент сил, противоположенный вращению и вот если там подкрутить И-составляющую, то при определенном угле смещении оба регулятора будут выдавать одинаковые по модулю, но противоположенные по знакам угловые моменты, меняя И-составляющую у второго регулятора можем добиться разных смещения :-)
В Octave кстати тоже самое получается.
Вообще все от типа динамической системы зависит — надо что ли это как-то дополнить, я хз. Хорошо было бы придумать пример именно с ПИ-регулятором: зачем добавлять Д к П — хороший пример прям на поверхности, второй пример где только П-звено я не привел (а надо бы наверное, хз только куда его вставлять — перед поворотами или после? Ну и он не совсем честный — работает так, как буд-то бы у корабля движки находятся с 4-х сторон, соосно с центром масс, так шо я хз — стоит ли).
А вот чего не хватает, так это примера с ПИ — регулятором (был бы он, можно было бы сразу все впендюрить), но я чойт так с ходу и не придумал: если контроль поворота с помощью ПД и вектора скорости с помощью П(Д) — поверхности, то куда воткнуть именно И-регулирование (шоб сразу было очевидно его преимущество) я даже хз.
И еще раз о системах. Вообще особенность всех наших алгоритмов автоматического управления в том, что они отлично работают… на Земле, когда у нас полно всяких нелинейностей, диссипативных сил и прочих неприятных вещей. Скажем так, аэродинамическое трение таки очень помогает при управлении летальными аппаратами, а попадаешь в среду где диссипативных сил нет, зато есть здоровенные консервативные силы и поведение объектов заметно изменяется. Поэтому, если пройдетесь по космическим аркадкам, то обнаружите, что они в большинстве своем используют физику «а-ля автомобиль» или как буд-то объект движется внутри идеальной жидкости/газе (тоже кстати забавный прием получается), шо собственно и меня подтолкнуло к написанию этой статьи: отличный сферовакуумный пример, на котором можно уже дальше самому поэкспериментировать.
А И-звено там реально бесполезное. Если его внести, то будет такая ситуация: как только корабль приблизится к нужному углу — у него все равно будет присутствовать некоторая ошибка, которая будет асимптотически стремится к 0, ну т.е. уменьшаться то она будет, но только очень-очень медленно, совсем медленно. Возможно когда-нибудь, где-нибудь в бесконечно, ошибка и установится в 0.
То есть если ошибка асимптотически сходится к нулю, но недостаточно быстро, то вы это называете смещением? :) Ну это как бы не совсем корректно. Когда говорят о постоянном смещении, то, как правило, имеется ввиду, что даже в асимптотике это смещение остаётся.
А вот чего не хватает, так это примера с ПИ — регулятором (был бы он, можно было бы сразу все впендюрить), но я чойт так с ходу и не придумал
Пусть корабль поворачивается (следит) за точкой, которая вращается с постоянным ускорением. Если я правильно понял используемую в вашей системе модель, то ПД регулятор даст постоянную ошибку слежения, а добавление И составляющей её уберёт. Если делать не настоящую Д составляющую по ошибке, а только по скорости, то такой же эффект будет уже при слежении за целью, которая движется с постоянной скоростью.
Третья часть
В общем, тут бы по-хорошему еще бы пройтись по идентификации динамической системы в Unity3D.
Кончено, (расширенный) фильтр Калмана можно использовать для идентификации параметров модели. Но у вас, как я понимаю, всё это крутится в виртуальной песочнице, никаких шумов измерений. Зачем тут стохастический по натуре аппарат?
Опередлить параметры системы будет несложно гораздо более простыми детерминированными методами.
Я хз, как крутили-вертели Фурье, Лапласом, Гильбертом и Z-преобразованием, так и крутят-вертят дальше.
Ну знаете… Крутят, конечно. Вот в програмировании есть алгоритмы сортировки. Их все изучают, постоянно используют, и даже кто-то, вроде, работает над их исследованием. Но мы же не говорим, что всё программирование крутится вокруг сортировки? Так же и в ТАУ. Частотные методы изучают и используют, но они давно уже не составляют центра области.
Другой пример уже реальный — мультиплеер. Вот там будут и большие задержки (пинг 100 мс — нормальное явления) и будут потерянные пакеты — некоторая информация будет теряться. Собственно каждый игрок играет в мультиплеере играет в свою игру, а уж потом их игры синхронизируются. Вот это уже реальная проблема, особенно для физики.
Вот есть такая игра — Space Engeneers, хз как сейчас, но когда я в неё играл (3-4 года назад), при игре по мультиплееру физика в игре начинала сходить с сума: решил пройтись по кораблю во время движения и оказался в стене, например :-) Вот там бы точно не помешал бы прикрученный к каждому игроку наблюдатель (хз, может они его и прикручивали — я хз). Вот в мультиплеере есть де разгуляться — там и задача оценивания при неполной информации, и предсказания.
Алгоритмы разные, в последнем видео исторически самый первый алгоритм, которым можно попадать только по прямо-летящим целям :-) Первый и второй и спользуются уже в современных ракетах (например AIM-120 и AIM-9).
Есть и другие варианты. На самом деле ничего сложного — алгоритмы простые и эффективные и записываются в пару строчек кода, только вот информации по ним нихрена нет (точнее она есть, но очень мало и писец как заумно, а уж на русском языке я вообще не знаю ни одной книги по автонавигации).
По-моему у меня даже уже специальный проект на базе стнардартного Unity3D (где там с самолетиками) уже запилен. Так что только причесать и вперед.
Вот с другими вопросами несколько сложнее, например с нейросетями, а их же можно использовать по-разному: самый простой вариант — выбор поведения в зависимости от текущей ситуации, а обучение — по специальной таблице, в которой мы описываем несколько желаемых шаблонов поведения — далее back-propogation и вперед, еще и в процессе игры можно дообучать немного. Другой вариант — использование нейроэволюции — это уже долго, т.к. процесс обучения это повторяющиеся раунды, зато можно запилить совсем прямое управление, которые иммитируют нажатие кнопок игроком:
Видео уже не мое, но сам принцип демонстрирует, собственно используемый в видео NEAT в качестве халявного Ассета для Юнити уже даже появился.
В общем там тоже технологий много, самых разных и надо бы это дело таки добить, только время нужно.
По ПИД-регуляторам: надо думать — еще больше примеров и прикинуть как бы по-проще реализовать простую автонастройку.
Вот только это надо бы до логического конца довести, когда будет время — хз.
Ждем продолжения.
Интересно было бы услышать про наиболее эффективные алгоритмы автоматической настройки ПИД-регулятора.
А так подходов несколько:
— характеристические методы по данным полученным в результате испытания в разомкнутом контуре, собственно тот же метод Циглера-Никольса
— аналитический синтез, формулы там несложные, вот только нужная точная модель объекта управления
— синтез на основе частотных характеристик, и опять таки, эти частотные характеристики САУ надо откуда-то получить
— и собственно оптимальный численный синтез, но и там нужно как-то идентифицировать наш объект управления.
В общем виде придется делать так:
1. Идентифицировать систему (допустим наш корабль), ну там хз, подавать ступенчатые воздействия или еще какие более хитрые, прям в самой игре. А на их основе построить модель: ПИД-регуляторы могут работать с моделями первого и второго рода, их форма известно, нужно только параметры как-то подобрать.
2. Ну а потом уже имея модельку, мы можем численно оптимизировать параметры ПИД-регулятора отдельно от игрового цикла Юнити.
Вот только тут тоже есть проблемка — критериев качества много: максимизировать скорость нарастания переходного процесса, минимизировать ошибку перерегулирования и автоколебания, минимизировать длительность переходного процесса. В общем куча критериев, которые еще друг другу противоречат — увеличиваем реакцию системы (например, скорость поворота) и появляются колебания, уменьшаем колебаний — увеличивается время реакции, ну и т.д.
Т.е. этих более менее оптимальных ПИД-регуляторов только на один объект управления будет не один, а дохрена и все простые и классические методы оптимизации идут лесом, тут нужно уже что-то посложнее. Хотя в принципе можно обойтись и оптимизации по критерию стабильности САУ.
Всякие хитры методы автонастройки/оптимизации ПИД-регуляторов — патентуют все кому не лень и хотят за это много денег.
В общем тут надо еще подумать, как бы получше и попроще запилить тулкит именно для ПИД-регуляторов игровых объектов в Unity3D. Либо это действительно будет метод Циглера-Никольса где как раз и используется стандартная форма ПИД-регулятора, которую я выше привел — правда в примере с космическим кораблем он не заработает — он всегда устойчиво колебается, когда нет трения (а вот когда есть — таки заработает), так что не получится найти критическое значение Kp и соответствующий ему период колебаний Tu. Либо же это будет какой-то сугубо численный метод оптимизации, шоб был простым и эффективным. Это вот предпочтительнее ИМХО, но надо думать.
Мне, увы, не удалось реализовать более менее стабильно функционирующий (на реальном объекте) алгоритм автонастройки ПИД-регулятора :(
Но я когда-то давно использовал NSGA для настройки ПИД-регулятора: на выходе получал кучу вариантов настройки с учетом всех критериев качества. Вроде даже работало, вот только у меня была достаточно точная математическая модель динамической системы, поэтому я могу гонять NSGA в онлайне и уже потом применял полученные результаты на готовом устройстве.
А вот чтоб прям в онлайне он автотюнинлся… не ну есть такое, но это все под патентами и там куча яйцеголовых, в том же Сименсе над этим трудится.
В результате был сделан вывод о том, что будущее САУ лежит в области нечеткой логики и нейросетей. :)
Подавляющее большинство специалистов в ТАУ относятся к этому скептически. Смотрите, вы даже три параметра не смогли автоматичеси настроить. Почему же несколько сотен сможете? :)
Хотя, конечно, место для нечеткой логики и нейронных сетей есть, свою нишу они займут (уже занимают), и ниша эта будет немаленькой.
Один мой хороший товарищ инспектирует системы АСУТП на ТЭЦ и, с его слов, ничего сложнее ПИ-регуляторов там не используют, а зачастую регулирование проходит в ручном режиме а-ля «Васильич, бегом до задвижки #### и поверни ее на пол-оборота».
Так было по-крайней мере лет пять назад, но не думаю, что с тех пор что-то кардинально поменялось.
Ключевой момент в том, что полным пониманием того, почему «задвижка #### » и «пол-оборота» обладает сотрудник, который давно там работает и научился понимать, КАК нужно воздействовать на объект регулирования в зависимости от цели регулирования.
Так вот, имхо, основная задача будущих САУ будет заключаться в том, чтобы тем или иным образом (с использованием нейросетей или еще чего-то) формировать т.н. экспертную систему, которая в процессе наблюдения за процессом управления и объектом регулирования сможет сформировать базу правил, с помощью которой, как минимум, можно будет повторить действия условного «Васильича». Безусловно, такая система должна обладать возможностью дообучения/самообучения.
В принципе, такой подход позволяет настраивать в том числе и ПИД-регуляторы :)))
Я понимаю вашу мысль, но должен отметить, что экспертное сообщество с ней, в своей массе, не согласно.
А теория АУ остается теорией когда для её реализации приглашают человека, который либо в ней толком не разбирается, либо не имеет ресурсов для нормальной разработки. Даже не знаю, что чаще, "Вась! У тебя же лет 10 назад был один семестр ТАУ? Забацай тут автоматизацию, ты же всё равно программист!" или "Что значит нужно время на эксперименты и новые датчики? Нам вчера надо, пусть оно пока в полуручном режиме работает!"
А нейросеть в принципе итак уже может, например, идентифицировать систему. Вообще если капнуть глубже, то, например, цифровые адаптивные фильтры уже являются однослойным линейным персептроном, а они уже давно работают где только можно.
Вот только однослойный персептрон может решать только линейно-разделимы задачи. От многослойного персептрона можно ждать большего. Ну т.е. нейросеть сама по себе может быть регулятором — прям торчать в контуре управления также как и этот ПИД-регулятор: получать на вход ошибку и выдавать на выходе сигнал управления, я правда хз используется ли это где, но в цифровой фильтрации нейросети дают лучшие результаты чем обычные адаптивные КИХ-фильтры… только ресурсов дохрена требуется
Имхо, нужна система, которая будет регистрировать действия конкретного пилота (который, желательно, лучше всех умеет управлять данным типом вертолета) в различных ситуациях и на основании этой информации сформирует базу правил для автопилота.
Ну а если к этому еще добавится обобщенная аналитика действий других пилотов (BigData и пр.), то построенная на этой основе САУ вполне годится для управления самыми сложными системами.
При таком подходе в плюсе мы имеем универсальность и существенное снижение затрат.
При этом вы, как я понимаю, неявно предполагаете, что лучше пилота летать нельзя, и метод вождения человека — оптимальный. Но это не так. Почему бы автопилоту не обучиться управлять по своему, по особенному, так, как пилот не сможет, но лучше? Взять автосимулятор, запустить на нём оптимизацию нейросети, ну и так далее.
Преимущества человека в поведении при нештатных ситуациях, а не в выполнении рутинных задачи, не в точности и не в скорости реакции.
Точная аналогия описана у Лема в «сумме технологии» — когда он рассуждает о разуме и возможности создания некой имитации в виде коробки с базой данных всех возможных вопросов и ответов на них. Так вот, возвращаясь к системам управления… Если объект достаточно сложный и имеет достаточно большую долю воздействия случайных факторов (а это все реальные объекты), то управлять им должна система с настоящим ИИ. Достаточно слабого, но база данных с набором правил — не пойдет. Она без надзора оператора (сильного ИИ) натворит дел при первом же чихе. Поэтому ответственные объекты никогда не оставляются без присмотра людей. А в деле разработки ИИ, не видно никакого прогресса. Они как были болванами, выдающими как «попка-дурак» статичные ответы на фиксированный набор запросов, так и остались.
Только не параметры объекта, а его аппроксимация. Которая может хорошая, а может нет, и для более-менее сложных систем может не подойти. А типовых настроек, в зависимости от выбранной аппроксимации, с десяток видов. Казалось бы, есть из чего выбирать, нет?
Из личного опыта — когда ПИ настраивался для более-менее простых систем, типа конутра тока тут, то там был аналитиский расчёт, он простой совсем. А для более-менее сложных систем или задач ПИ/ПИД не тянет, там приходилось другие структуры разрабатывать.
Помню, настраивал немецкий инженер нам регулятор гидроагрегата на ГЭС. Подал ступенчатое воздействие, снял отклик, а потом уже от определенных параметров объекта и исходил в настройке регулятора.
А выпускники ВУЗов по специальности ТАУ сидят и не знаю, куда пойти работать по специальности. Сходите на кафедру ТАУ или систем управления ближнего к вам приличного университета и пригласите студентов на практику или стажировку.
Если вам нужны разовые консультации по ТАУ, то и это решается.
А у остальных ТАУ если проходиться, то как-то совсем мимо. Да еще ТАУ требует хорошую математическую подготовку, а её… эээ… не все вузы могут обеспечить. На моей памяти, по крайней мере раньше, всех тауведов расхватывали еще на стадии студенческой скамьи, как щас я правда хз.
Там в профиле Моква стоит. Я думаю, что уж в Москве-то можно студентов найти. :)
Не знаю как в ваши времена, но вот лет десять назад спрос на спецов в ТАУ был, но не особо высокий, а предлагаемые зп от больших гос или бывших гос предприятий были не особо конкурентноспособны. Многи на лету переквалифицировались в электронщиков или программистов.
Я вот, например, когда учился — на нашем отделении решили сделать финт ушами: увеличили число часов по матанализу и включили в него ТФКП, соответственно саму ТФКП тоже ликвидировали, но суммарное число часов не изменилось… только забыли об этом сказать преподу, студентов тоже никто не предупредили — ну нет ТФКП и нет. Стандартный матан таким макаром очень быстро кончился и препод не зная чем себя занять принялся за углубенное изучение интеграла Лебега, интеграла Интеграл Курцвейля-Хенстока, потом когда и это кончилось — принялся за функан и дифгем. Но ТФКП в итоге не было — об этом узнали только на госниках :-)
А в Москве так вообще очень странная ситуация: конкуренция очень высокая — только не со стороны выпускников, а наоборот — со стороны работодателей и в тоже время работодатели еще и носом воротят.
В общем как мне всегда казалось специалистов мало, даже очень мало. А сейчас вон ADAS во вс щели полезла (только вот я уже желающими запилить свой автопилот для автомобиля пообщался — с разными конторами… и по-моему они вообще плохо понимают куда ввязались и кто им нужен)
Скажите, пожалуйста, есть ли особое название у класса PID регуляторов, которые удерживают целевой показатель не выше определённого значения. Например, допустимые значения PV это [0; 100], при этом "зелёная зона" это [0; 90], и процессом управлять не надо, а "красная зона" это [90; 100], и задача регулятора заключается в том, чтобы при заходе процесса в "красную зону" вытолкнуть его в "зелёную" (причем конкретные значения PV внутри зелёной зоны не важны, колебания допустимы). Есть ощущение, что они описываются какими-то своими уравнениями.
ТАУ для самых маленьких: пример реализации ПИД-регулятора в Unity3D