NLMPC Warm-up

[BystrickyK]

~~Funkce na převod implicitního MPC na explicitní je v Matlabu pouze pro lineární MPC. Procházel jsem i nějaké papery a netroufám si je pokoušet replikovat.
Našel jsem funkci, která nelineární MPC převede na libovolný počet lineárních MPC v libovolných bodech stavového prostoru. Zkusím tedy řízení pomocí gain-scheduled implicitního MPC, a to pak případně převést na explicitní, pokud bude pořád problém s rychlostí výpočtů. ~~

[BystrickyK]

V průběhu implementace mi nějak začalo docházet, že když lineárnímu MPC naladěnému okolo spodní úvratě pošlu jako referenci horní úvrať, tak z toho bude zmatené a řízení by asi nefungovalo.

Pročítal jsem si teda znova nějaké papery o optimalizaci NLMPC a v tomto jsem se dočetl o warm startu - tedy že se solveru vždy pošle řešení z minulého kroku. Už jsem o warm-upu tušení měl, protože jsem o tom četl v Mathworks nápovědě, ve které se píše, že NLMPC objekt warm-up dělá sám, tak jsem se o to dál nestaral. Problém byl v tom, že jsem to přečetl špatně a sám ten warm-up dělá Simulink blok NLMPC, ne ten matlabovský. Odkaz na nápovědu - Specify Initial Guesses.

Tak jsem tam warm-up hned implementoval. To samozřejmě hodně pomohlo - vyhladilo to špičky ve výpočetním času, které nastávaly při změně reference. Problém byl asi v tom, že když solver vždy začínal z náhodného bodu, tak např. ve spodní úvrati je mnoho způsobů, jak se vyšvihnout nahoru. Dokud tedy je okolo spodní úvrati, tak nerozhodně přepíná mezi možnými trajektoriemi, které navíc vždy počítá z náhodného počátečního odhadu - nejenže tedy nerozhodnost zhoršuje výslednou trajektorii, ale ještě je dost výpočetně náročná. Pokud si však pamatuje poslední krok, tak se drží jedné trajektorie a v každém kroku se počáteční odhad solveru moc od optimálního neliší.
Dále jsem zkoušel upravovat constrainty a omezení polohy vozíku na interval [-0.5, 0.5] výrazně prodlužuje výpočetní časy - přidává to kolem 80%. Constraint jsem teda vyhodil, pokud bude problém s tím, že vozík moc jezdí a bude mít riziko nárazu, budu ho omezovat raději zvyšováním běžné váhy.

Tady je simulace s vzorkovací periodou 0.1s. Každou desátou sekundu začne swing-up, pak po 6.5 sekundách swing-down. Pořád se občas stane, že výpočetní časy vyskočí při změně reference, ale už to není pravidlo. Ještě se pokusím při změně reference podsunout solveru předpočítaný počáteční odhad.

[BystrickyK]

Upravil jsem trochu parametry a už se špičky neobjevujou. Zkoušel jsem podsouvat i počáteční odhad při změně reference, ale z nějakého důvodu to špičky zhoršovalo. Teď už s tím ale není problém. Udělal jsem 500 sekundovou simulaci -> 50x swing-up a swing-down a ani jednou nepřekročil výpočetní čas 0.1s.

Jinak výpočty EKF probíhají s desetinovou periodou MPCčka. Měřil jsem časy jedné iterace celé smyčky (i se simulací nelin. systému ode45kou) a jsou někde okolo 0.003s, takže do 0.01s ( perioda EKF ) se vlezou.

[PajinV2]

zda se mi, ze to nlmpc v tom puvodnim demo prikladu melo warm-up