Hogyan csinálnátok jó szabályozót?

Fejlesztés

A kérdés nem költői, valós. Ha a rendszer nonlineáris, a mérés a beavatkozáshoz képest holtidős, akkor nagyjából ki is dobhatjuk mindazt, amit a PID-szabályozókról tudunk. Az egyedüli öröm benne, hogy viszonylag lassú a folyamat, fűtésről van szó. Kevésbé nagy öröm, hogy eléggé korlátos a futásidő, nem lehet eszetlenül szorozni, osztani, mintha nem lenne holnap. Most azon gondolkodom, hogy exponenciális átlagolással megtanulná, az utóbbi időben mekkora volt a fűtés teljesítményigénye egy normális PI-szabályozás során, s ezen értékhez képest felfelé és lefelé lenne mozgástere az integrátornak adott margón belül. Ha vannak még tippek, írjátok!

( meditor | 2020. 05. 02., szo – 18:06 )

Én egy neuronhálóval oldottam meg. Van 8 input és ebből az output jövőbeli értékét jósolom meg. Az érdekesség az, hogy nemcsak, hogy jól jósol, de a szőröket is leszedi a jelről. Genann forrást használok, ezt egy kis módosítással forrásnyelvi szinten beemeltem a programba. Ha érdekel, bővebben is szólok erről.

> Sol omnibus lucet.

Érdekel, bár mikrokontrolleren assembly-ben, kevés futásidővel, kevés memóriával kell ezt megoldanom. A holtidő miatt én is jósolok. Egy ring bufferbe leteszem a mért értékeket 32 mérésenként, ezek között lineáris interpolációt használok. Így a ringbuffer hossznyi múlt megvan, a jelenérték és a múlt differenciája pedig a derivált. Ennek kétszeresét hozzáadom a jelenlegi mért értékemhez, így a ringbuffer hosszának kétszerese időtávra extrapolálok előre. Ezt a jóslatot tekintem mért értéknek, s az alapjelből és ebből a jóslatból képezem a hibajelet.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Egyrészt nem hobby project, másrészt készen van a célhardware, így a mikrokontroller adott. A futásidő meg azért, mert nem volna jó, ha a kommunikációban, amelyben nincs handshake, adatvesztés lenne, és ezen kívül is van dolga a kontrollernek.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ha a külső paraméterekre nem annyira érzékeny a műszer (pl valami fűtedő, szigetelt doboz) akkor az inferencia futtatható szerintem egy kvarcjátékon is, főleg hogy nem annyira fontos hogy rövid időn belül érkezzen meg a mérés után a vezérlőjel. Itt akár szét is darabolhatod a futását több időszeletre, ha a háttérfeladatoknak fontos hogy ~realtime menjen.

Miután látom hogy 8bites mikrokontrollered van, amihez képest a C64 assembly is sokat tud már, így megváltoztatom az álláspontomat.
Feltételeztem hogy legalább osztani-szorozni tudsz hardwareből.
Olvastam olyan cikket, ahol int8/int16 -kat használtak a predikcióhoz, arra gondoltam hogy az olyasmi lett volna jó neked.

Ezt azért írom le hogyha valaki a jövőben erre téved, lássa hogy milyen megfontolás mellett lehet/nem lehet ezt csinálni.

( dap | 2020. 05. 02., szo – 18:48 )

Szerkesztve: 2020. 05. 02., szo – 19:01

A PID miért nem használható itt miközben amúgy teljesen alap fűtés-szabályzásra?

Ugyan nem vettem fel egységugrás gerjesztésre a válaszfüggvényt - pedig ezzel kellett volna kezdenem, sokkal okosabb lennék, ha ismerném kvantitatívan is az átviteli függvényt -, nagyon úgy tűnik, hogy elég nagyok az időállandók, a holtidő, így aztán a D-tag felejtős. Marad a PI. Ha azt szeretném, hogy ne fogyjon el a fázistartaléka, akkor végtelenül lassú lenne, ráadásul a legkisebb légmozgás is elviszi a fenébe a hőt. Ha elfogadható a sebesség, elfogy a fázistartalék és lényegében oszcillál. Fűteni tudok, hűteni nem, mert nem Peltier-elem.

Ha az integrátort hagyom szédelegni, elmegy nagyon messzire telítésbe. A hibajel előjelváltásakor onnan elkezd visszajönni, de addig is rossz irányba szabályoz, legfeljebb csökkenő mértékben. Ha meg limitálom az integrátort, nem lesz elég tartaléka az áram alapjel képzéséhez, azaz sohasem érem el a kívánt hőmérsékletet. Erre találtam ki, hogy bánom én, lengjen az elején, de átlagolja az addig betolt teljesítményt, és azt kvázi vezérlésként használja. Ehhez a középértékhez képest az integrátort egy viszonylag kis margóval engedném el, így nem tud nagyon elkovályogni majd.

Persze értem én, hogy ez valójában két egymásba ágyazott integráló szabályozó, ahol a belső hurokban van egy gyors, a külsőben egy lassú integrátor, de egyelőre hiszek benne, hogy jó lesz. Vagy nem. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Jellemzően nem előemésztett, kész dolgokat használok. Egyrészt, az ki tudja, hogyan működik, másrészt egy idegen kód sajátba történő integrálása favágó munka és undorító. Jobb szeretem töviről hegyire ismerni, tudni, mi történik, s akkor az egészet kézben tudom tartani.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az éppen, hogy csak működő valahogy nem hangzik jól. A kész könyvtárakat nem ember alkotta meg? Ha igen, akkor annak miért kell törvényszerűen jobbnak lennie annál, mint amit csinálok? Most nem arról van szó, hogy semmit sem tudok a szakmáról, csak láttam YouTube-on, hogy a piros drótot a pirossal, a feketét a feketével kell összekötni és csinálok mondjuk egy drónt. Hardware-fejlesztő vagyok, és ebbe néha beletartozik a programozás is természetesen.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Úgy érzem neked predikciós szabályzó kell. Elsőként prediktálni kell a jövő egy adott tartományában a kimenő jel várható alakulását. A jövőbeni alapjel ismeretlen; egy négyzetes 'költségfüggvényt' kell meghatározni, amely a jövőbeni kimenő és alapjel négyzetes eltérését veszi figyelembe. A függvényt minimalizálva kapunk egy beavatkozójel sorozatot, amelyet a modell bemenetére adunk, majd új mintavétel után az eljárást megismételjük. Azt hogy milyen model használata optimális, az adott körülményektől függ. Nemlineáris esetben konvulóciós modelt érdemes választani. A modelek kutatása bőven tudományos téma, és a végén úgyis egy meglévő modelt fogsz felhasználni. Hallgattál automatizálást, esetleg használtad már a gyakorlatban is? HW fejlesztőként nem hinném hogy nagyon ott vagy a témában, ha már a PID szabályzókat kilőtted a nonlineáris folyamatokra alapból.

Jók ezek az 'előre elkészített eszközök', mert nem kevés kutatási munka van már bennük, és mérnöki gyakorlatban elegendő pontosággal működnek. Matlab is a barátod lesz!

Nagyon szépen leírtad, hogyan helyezzünk regressziós egyenest mérési pontokra. Akkor nézzük a lehetőségeket. A legbonyolultabb művelet assembly-ben az összeadás 8 bites számok között carry-vel. Nincs lebegőpontos co-processzor. Van 4  MIPS utasítás végrehajtási sebesség, továbbá a feladat ezen részére van 4 ms-onként kb. 200 µs, azaz 800 gépi utasítás. Különféle okok miatt úgy tűnik, 24 bites számábrázolás az, amellyel a feladat megoldható. Természetesen, ha signed számok összeadásánál túlcsordulás van, nekem kell kibogarászni, hogy az operandusok azonos előjeléhez képest, az összeg ellenkező előjele túlcsordulás. Még ezek a kis finomságok is ebből a 800 utasításból oldandók meg.

Tehát viszonylag komoly ötleteket vártam, de nem arra az esetre, amikor ott dohog a háttérben a feladathoz korlátlan erőforrású gép korlátlan memóriával, futásidővel, számítási kapacitással.

Lehet, nem jól fogalmaztam. A PID-et azért dobtam, mert ott vannak feltételezések. Az egész Bode-diagramos story többé-kevésbé mégis csak arra épül, hogy a rendszerünk lineáris. Itt semmi sem az. Eleve, ha a hibajelem még pozitív, de a beavatkozó egységem már betelített, miközben az integrátoromat hagyom a pozitív hibajel meredekségével tovább menni az égbe, akkor megszívom, mert az integrátor magasabb értéke a beavatkozó egység telítése miatt nagyobb hatást nem vált ki, viszont a hibajel előjelének megváltozásakor az égboltról kell leimádkozni az integrátort, de addig ez a szerkezet tovább tolja a hőt a hőkapacitásba. Nyilván kezelhető, mert lehet szabály az is, hogy ha telített a beavatkozó szerv, akkor az integrátor maradjon a legutóbbi értékén. De látszik, hogy innentől ez nem egy sima PID-szabályozó, hanem egy valami, ami tele van egy rakás különleges eset kezelésével, és még mindig legfeljebb 800 gépi RISC utasításból kell megoldanom.

Viszont az ötletem beválni látszik, ami jó hír, csak még finomítanom kell rajta. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az éppen, hogy csak működő valahogy nem hangzik jól. A kész könyvtárakat nem ember alkotta meg? Ha igen, akkor annak miért kell törvényszerűen jobbnak lennie annál, mint amit csinálok?

Erre az a szokásos válasz, hogy ha te egyedül raksz össze valamit, amit csak te egyedül használsz, akkor jóval kisebb annak az esélye, hogy megtaláld az összes programozási hibát és tervezési hibát (tipikusan olyan ritka eseteket, amire nem gondoltál).

Ezzel szemben ha van egy könyvtár amit többen összeraktak, a forráskód elérhető, használják legalább több százan különféle célokra különféle környezetekben évek óta, akkor feltételezhető, hogy egy csomó korai bugot már valaki megtalált, szólt, kijavították. A ritka esetek egy részét a sok felhasználóból páran élesben használják évek óta (és ha nem jól kezelte a rendszer, szóltak és azóta jól kezeli).

Ugye nem lehet, tudni, hogy te milyen minőségű kódot készítesz. Lehet, hogy mindenre gondoltál és nem vétesz soha semmi hibát, a hardvert is tökéletesen ismered és a hw sem hibázik. Lehet, de a rendszered még nem bizonyított.
A másikat százak, ezrek használják évek óta = bizonyítottan jó. (Elég jó, nem feltétlenül hibátlan).

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

A félreértés ott van, hogy a HUP-ra olyan emberek járnak, akik némileg nagyobb erőforrásokkal találkoznak, mint ami egy 8 bites MCU. Az itt felbukkanó embereknek már egy Raspberry Pi is valami gyenge, kicsi játékszer. Kész függvénykönyvtárakban, operációs rendszerben, GB, de minimum MB nagyságrendű RAM-ban és sok 100 MHz-ben gondolkodtok.

Ezzel szemben a valóság az, hogy néhány tíz, de legfeljebb néhány száz byte - nem kilo, nem mega, nem giga - RAM-om van, 4 MIPS sebességem, nincs hardware-es szorzásom, osztásom, még egész típusú sem, lebegőpontos meg végképp nincs, a programtár is alig néhány ezer utasításnyi. Assembly-ben írom, a puszta szövegszerkesztőn kívül szinte semmim sincs, illetve de, egy include file, ami a processzor regisztereinek és azok bitjeinek neveit a címükkel define-olja.

Az aritmetika úgy néz ki, hogy nekem kell az overflow-t, underflow-t kezelnem, meg minden vackot. Szóval ebbe egy általánosan megírt lib nem fog belemenni úgy, hogy lefusson 200 µs-on belül. Itt az marad, hogy ki kell találni egy algoritmust, a tapasztalatok alapján egy lehető legjobbat, és azt kell megvalósítani. Csak azért, hogy gyors maradjon, gyakran kell kettő egész kitevőjű hatványait használom. 16-tal osztani még nem olyan fájdalmas, mert jobbra shiftelek és rotálok négyszer, de egy általános számmal inkább nem osztok, mert annyi időm nincs. Mármint nem nekem, a kontrollernek.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A módszerek működnek ezen a minimikró mikrókontrolleren is, csak úgy kell megírni. Nem kell ide nagy számítási kapacitás, pár változó van összesen, amik azért az MCU-hoz képest lassan mozognak.

A sima mechanikus szobatermosztátok úgy működnek, hogy amikor fűt a kazán, akkor az áramkörben egy ellenállás fűti a hőmérőt is. Ez egy nagyon egyszerű predikció megvalósítása. Egy ilyet szoftverben simán meg tudsz csinálni - még ASM-ben is -, és simán lehet, hogy elegendő is.

Az a baj, hogy ha nincs megadva a modell, akkor arra nem lehet szabályzót ajánlani. Szóval nem is tudom mit vársz itt a nagyérdeműtől?

Általános ötletekre gondoltam, hátha. Nem vagyok nagyon elkeseredve, hiszen ötletem van. Amit most csinálok az az, hogy exponenciális átlagolással - az egyre régebbi eredmények szép lassan a múlt homályába vesznek, egyre kisebb súllyal szerepelnek - képezek egy bázisvonalat arról, hogy eddig mekkora árammel kellett fűteni a célhőmérséklet eléréséhez. Ezen bázishoz képest lefelé és felfelé képezek egy margót, amelyen belül kószálhat az integrátor. Az integrátor viszonylag gyors - azért nem nagyon -, az aktuális változásokra érdemben tud reagálni. Viszont a margón kívülre nem tud elszédelegni. Ebben az a jó, hogy nem fordulhat elő, hogy túl messziről kell visszajönnie, s akkor esetleg akkor is tolja be a hőt, amikor már nem kellene. Ezt persze csak akkor csinálom, ha a hibajel abszolútértéke egy adott határon belül van. Nagy hibajelnél nem finomkodik, felszabadítom a margókat, aztán tolja neki, ami a csövön kifér.

A másik gondolatom az, hogy sima PI-szabályozónál megállítom az integrátor további növelését - vagy csökkentését - akkor, ha a beavatkozó szerv elérte a telítést, a korlátait. Azért, mert ha telített, a nagyobb integrátorból kijövő értékkel jobban már nem fog fűteni, viszont szívás, mert amikor megfordul a hibajel előjele, az integrátorban nem az a szám lesz, ami a hőntartáshoz szükséges, hanem egy őrült bagy érték, ami ekkor kezd el csökkenni. Csak amíg jön le az integrátor az égből, addig továbbra is fűtünk, holott a mért érték magasabb, mint a referenciánk. És akkor még a holtidőről nem is beszéltem.

Nagyjából ilyen szintű ötletekre vágytam. Amikor nyitottam a témát, kicsit szélmalomharcnak tűnt, de időközben sokat tisztult ez a mérések által. Szerencsére az áramot és a hőmérsékletet is tudom mérni, oszcillogrammot valós időben tudok rajzolni, így látom, mi történik.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Írtad, hogy számolni nem nagyon tudsz, mert kevés az idő és nem tud az eszközöd gyorsan szorozni meg osztani.

Az nem megy, hogy a különböző szenzorok (a fentebb írt dolgok miatt gondolom méred a fémtömböd hőmérsékletét, a levegő hőmérsékletét és a légmozgást) adatait szépen táblázatba teszed, aztán akár kiszámolod egy rendes erős számítógéppel a mátrix különféle pontjaihoz tartozó értékeket, akár valami becsült értékekkel elindítod és később a valós működés visszajelzése alapján az értékeket finomítod?

Akkor ha megvannak az inputok, komplex számítás helyett csak egy lookupot kell elvégezned.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Ha nincs processzorido futas kozben, de van elegendo memoria, ez a legjobb megoldas.

Sok dimenzios terek eseten (itt sok szenzor) eleg sok memoria kellhet. De egy belso, egy kulso homerseklet fuggvenyeben ez a legjobb megoldas.

De ugye elegge fontos az is, hogy mire probalunk optimalizalni. Egyenletes homersekletre, minimalis homersekletre, elfogyasztott energiara stb.

Nekem is egy hasonló problémára kellett megoldást találnom, ott a cefre hőmérsékletét kellett a beállított hőfokon tartani. Hűteni ott sem lehetett, és sajnos én is azt tapasztaltam, hogy mire elérjük a kívánt hőmérsékletet, addig az I szabályzó összegyűjtötte az összes hibát. Én egy "PI" szerű szabályzót fejlesztettem: a lényege az, hogy az "I" tag csak akkor lép működésbe, ha a "P" tag megrekedt, azaz a korábbi mérésekkel összevetve nem változik már a hőmérséklet. Ekkor az I tag nagyságát próbálom addig növelni apránként, amíg el nem érjük a kívánt értéket, ha túllövés van, akkor pedig csökkenti az I értékét. Így elméletileg ahogy az idő telik, megtanulja, hogy mekkora teljesítményre van szüksége a rendszer szinten tartásához. Én egyébként még emellett limitáltam ennek az "I" tagnak az értékét.

( asch v | 2020. 05. 02., szo – 20:50 )

Mitől annyira fura ez a fűtés szabályozás? Ha ahogy fentebb írtad van benne véletlen elem: nem lehet megoldani a problémát. Ha nem tudod előre, hogy huzat van-e, vagy bezárták-e az ajtót, akkor nem tudod szabályozni a folyosó hőmérsékletét és kész.

Ha előre ismert esetek vannak, amiket fel lehet ismerni (szellőztetés, főzés), akkor elvben lehetne okosabbnak lenni. Ezeket egy öntanuló "intelligens" rendszer elvben meg is tanulhatná akár. De ahhoz, hogy ez normálisan működjön lehet, hogy több szenzor kellene, több helyen és nemcsak hőmérsékletet kellene mérni. Egyetlen hőmérővel nem tudod eldönteni, hogy azért esett-e a hőmérséklet, mert felmostak, vagy azért mert szellőztettek. Kivéve ha mondjuk periódikusan mindig ugyanaz történik mint egy iskolában. (A koronavírus idejére viszont kapcsold ki a tanuló algoritmusokat, mert hetekbe fog telleni mire visszaáll a rend miután visszaállt a rend.)

Hurrá! Akkor nem az univerzum egy definiálatlan részét kell szabályozni.

Van a fémtömbnek tömege, fajhője hőellenállása statikus állapotban és ventilláció mellett.

Bizonyára a fütésnek is van teljesítménye.

Az adatokból lehet időállandót számolni és elvégezni az alapvető PID hangolást.

Ha nem szeretnél sokat számolni, akkor az eredményt táblázatba foglalhatod és csak kapcsolgatni kell az egyes elmek között. Ha túl nagy a táblázat, akkor lehet interpolálni is.

Forrasztópáka állomás lesz? :)

Én csináltam, és hatalmasat szívtam vele, míg rá nem jöttem, hogy a gyári weller állomás is hazudik (messze nem tartja annyira stabilan a hőfokot, mint írja) :D

Ott kb. 2-3 mp a holtidő a mérés és a fűtés között, és ezt baromira nehéz kezelni sima PID-el, de elvileg nem lehetetlen a holdidő kompenzáció. A holtidő közelíthető sima tárolós tagokkal, azokat pedig lehet kompenzálni.

Ennek ellenére hiába próbáltam mindent, megmérni az időállandókat, az egészet szimulálni, holtidőkompenzálni, de jól soha nem működött. Részben amiatt, amit írtál is, hogy csak fűteni tudtam.

Aztán meguntam, és írtam egy sokkal egyszerűbb algoritmust, ami nagy hőfokkülönbség esetén fűt 100%-on, közeledve a beállítotthoz pedig azt hiszem PI-re kapcsolt át. Azóta használható.

Tehát ha a rendszer viselkedéséről van jó fizikai modell, akkor nem biztos, hogy a PID a célszerű.

Ugyanezt használtam egy reaktor fűtésnél: meg lehetett adni egy tőréspontot, hogy meddig menjen 100 %-kal a fűtés és a töréspont után szépen lekeverte a teljesítményt. Néhány ezrelékes szinuszos lengéssel tartotta a 200-400 fokot.

Egy kis tömegű cucc fűtésénél már a környezet hőmérséklete is befolyásoló lehet, egy jó szabályozóhoz a környezet hőmérsékletét is mérni kéne.

> Sol omnibus lucet.

( tygryss | 2020. 05. 03., v – 02:06 )

Sima VS/SM-et néznék meg, abból sok irodalmat találsz, de ha gondolod tudok is segíteni kicsit. mivel kb a négy alapművelet kell hozzá, esetleg ha van hatványozás a modellban akor az, kézzel kell csinálni egy deriválást azt hiszem, de ennyi, az alapot kb 5perc alatt össze lehet dobni. Mennyire hobbi a történet? Esetleg kisérletezgetés, játszás belefér kevésbé közismert szabályzókkal, vagy ipari project ahol azt kell mutatni, hogy már régi jól kipróbált, akkor a VS/SM. 

Pedig a C64 assembly szerintem nagyobb utasításkészletet takar, mint ami most nekem van. :) Olyat én is tudok, hogy felírom a Laplace-transzformált átviteli függvényét ennek, de vedd úgy, hogy matematikai eszközeid, lehetőségeid nincsenek. Nem azért, mert nem tudok egy osztást megírni, hanem azért, mert nagyjából egy darab szorzás és egy darab osztás el is viszi a teljes rendelkezésre álló futásidőmet.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( tygryss | 2020. 05. 03., v – 14:43 )

azért a 4 alapműveletre szükség van, annál egyszerűbbet nem nagyon tudok, van benne egy sigmoid függvény is, mondjuk azt lehet közelíteni lineárisan. De a nemlineáris irányításelmélet az sokkal nagyobb matematikai aparátust mozgat mint a sima lineáris, mint amit általában tanítanak. Itt ott kezdődik a beugró, hogy Metrikus terek, és annak egzotikusabb változatai, mint a Banach tér. 

Lyapunov esetében szépen csinálsz egy transpose(x)Px quadratikus függvényt és arról látod be, hogy minden frankó, használati konstrukció az már könnyű. Ugyanezt csinálhatod a Kappa osztályú függvényekkel. 

Van az ebből az elvből indulva a csúszómód controller, ez a Slotine-ék irányáből jövő módszer, ezt viszonylag könnyű használni, de ebben is van 4 alapművelet, valamint egy tanh(). Ez a VS/SM.

Valamint vannak még FixPont iteráción alapuló módszerek ennek kicsit más az alapja, de eszközkészletében hasonló mint a csúszómód. Ha nagyon nagy az áthidalni kívánt idő, akkor lehet frakcionális deriváltakkal szütyögni, de sok esetben erre nincs szükség. Ennek a módszernak az előnye, hogy elég neki egy nagyon közelítő affine modell is. Valamint itt a sigmoid függvényt lehet közelíteni lineárisan is, de azért számítási kapacitás akkor is, ha nem is nagyon nagy, mondjuk Arduino már elviszi. Szép kihívás ez alatt is implementálni, de símán lehet, hogy nem is lehet nemlineárisat annyira gyenge hardwaren futtatni. Szívesen eltársalgok ezekről a dolgokról, ami tuti kell, valami float számok, ebből kell kettő, Ezek szabályzó paraméterek, az egyik olyan 1e7 és 1e-7 nagyságrendben, kell egy egy integer, +-1, kell az q, dot(q),... stb . ezek szintén float jellegűek, kell a viszacsatolás változói, ebből is van kettő float, valamint egy sigmoid függvény, ezek vannak összekombinálva, szorzással, összeadással. (a sigmoid-ban van osztás, vagy az lehet lineárisan kicselezni). Kell egy előfeldolgozó, abban csak összeadás és szorzás van, a hiba alapján, valamint kell a közelítő modell, és az integrátor (ami Euler szokott lenni, ami összeadás és szorzás), ebből annyi kell ahányad rendű a szabályzás. 

Szóval elvileg nem sok, de azért nem minden hardwaren fut el. 

Egyébként ez szokott lenni a tipikus hiba, amit sokat láttam, hogy lelkesen megcsinálják a hardware-t és nem tudják, hogy mi kell hozzá. Kell, hogy legyen előtte egy design fázis, ahol szimulációban megnézed a problémát, megnézed mekkora pontosság kell, és mikor ezzel megvagy, akkor tudod eldönteni milyen hardware kell hozzá. 

Vannak ilyen matematikailag szép, tiszta megoldások, de lehet ezt intuitív módon is csinálni. Persze értem, hogy ez utóbbi esetben nem tudunk semmit mondani arról, hogy adott zavarjelre mennyire optimálisan reagál a szabályozó. De azért az is túlzás, amikor erre operációs rendszert, matematikai apparátust használunk. Arra gondolj, ezt analóg elektronikával is meg lehetne csinálni, s nem terepasztal méretű áramkörrel. Csak azért lett firmware, mert a paraméterezhetősége kényelmesebb, mint kondenzátorokat forrasztgatni, valamint az algoritmust adott határokon belül lehet színezni.

Amit itt többen - te is - javasolnak, az a vegytiszta elmélet gyakorlati implementálása, de ahhoz valóban komoly hardware kell. Eleve nincsenek erre a célra 100 mA-eim, szeretném, ha az elektronika 10 mA alatti fogyasztású maradhatna. Elég baj az, hogy a fűtéshez kell a villany.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Azért a kettő között van átmenet, mondjuk itt nagyságrendileg kell 10float változó, 50 szorzás 50 összeadás meg egy osztás. azért ez még nem az RPI alatt Windows alatt pythonnal vezérlünk valamit. 

Egy erősen nemlineáris rendszert akarsz irányítani, valami minimum azért kell, sok dolgot te papíron fogsz megoldani ezeket bontotd le a 4 alapműveletre meg pár érték számontartása. Azért ennél kevesebből kihozni egy adaptív nemlineáris szabályzót nem lehet.

És amit írtam az SISO eset, MIMO esetben kicsit nő a szám, de nem vészesen. Egy elektromotor nemlineáris vezérlésére elég volt az arduino, aminek mint tudjuk nagyon nagy az overheadje. Ha olyan kell hogy csinálsz valmi if-then játékot, ha az az érték ennyi, az az érték annyi, akkor adj hozzá x-et, vagy vonjál le y-t elvileg lehet, nem lesz tökéletes, de akkor az meg nem gyenge matekozás és töménytelen szimuláció kell hozzá és valami fuzzy set-et össze lehet belőle kalapálni. Akkor jön a bűvészkedés, hogy neurális háló, és annak viszafejtése... stb. viszont az sem triviális feladat.  

Én a lineáris esetből indulok ki. Mivel holtidős, javarészt integráló szabályozóra van szükség, a másik ok az, hogy ne legyen statikus hibánk, ha úgy tetszik, nulla hibajel esetén is emlékezzen a szükséges beavatkozó jelre. A holtidő miatt a mért érték deriváltjából teszek jóslást  a jövőre. Már a mért érték jövőjére, ami a beavatkozó egység jelene lényegében. És akkor van ez a jaj, túltoltuk, Béláim típusú probléma, amit úgy próbálok kordában tartani, hogy egy várható érték körül hagyom kóricálni az integrátoromat. A várható érték pedig nem egyéb, mint a rendszer eddigi tapasztalata, tanulása. Az lényegében egy lassú integrálásként is felfogható, egy exponenciális átlagolás. A gond ezzel inkább az, hogy az élet elején nincs múlt, amit megtanult, így itt egy gyors tanításra van szükség, utána már jó lesz ez várhatóan. Ma már nem foglalkozom vele, csak holnap.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

" Én a lineáris esetből indulok ki. "

Az szerepelt a fórumnyitó hozzászólásodban, hogy a rendszer nemlineáris épp ezért nem lineáris szabályozásokkal akarsz kiindulni.

" Ha a rendszer nonlineáris, a mérés a beavatkozáshoz képest holtidős, akkor nagyjából ki is dobhatjuk mindazt, amit a PID-szabályozókról tudunk. " ezt írtad.

Aztán mégis a PID-szabályzók egyik esetével, a PI szabályzóval akarod megvalósítani a dolgot. Nem értelek.

Most akkor mi van?

Pedig jól látod, csak légy gyakorlatiasabb! A rendszer nonlineáris, ámbátor valahonnan mégis csak meg kellene ezt közelíteni, s onnan kényelmes, hogy azt képzelem róla, hogy lineáris. Amiről persze tudom, hogy nem igaz. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az analóg szabályzó - ha ugyanúgy rosszul van megcsinálva - épp ugyanúgy fog lengeni, mint a digitális. Legfeljebb akkor előnyösebb, ha olyan gyenge az A/D konverter, hogy ahhoz képest az analóg tud valamit hozni, vagy esetleg ha nagy dinamika tartományt kell lefedni, de egyébként épp ugyanazokkal a problémákkal kell megküzdeni.

" Arra gondolj, ezt analóg elektronikával is meg lehetne csinálni "

Igen, és ott a nemlineáris számítást, a matekot a fizikai valóság elvégzi.

Viszont te nem ezt szeretnéd, viszont ha tényleg jó nemlineáris szabályozást akarsz csinálni, akkor annak tényleg kell a matematikai háttér. Elméleti elemzés nélkül nehéz bármit is mondani bármelyik kitalált eljárás jóságáról, vagy éppen a megvalósított szabályozó tulajdonságairól.

( roleez | 2020. 05. 04., h – 16:59 )

Szerkesztve: 2020. 05. 04., h – 17:33

PIC16F84 mikrón csináltam csúszó-mód szabályozót - 20 éve, és a mai napig megy... Pár összeadás és összehasonlítás.

Tipikusan nem lineáris rendszerre. Lassú, kompresszoros rendszerre.

Kb. ilyesmi a vágyam. Azért a PIC16F84-nél picit jobb, de ez is 16-os sorozatú PIC. Tapasztalatok alapján elég sok furcsaságot írtam a kódba, s most már elég jó. Van még egy implementálási hibám valahol, mert azt csinálom, hogy egy adott értéknél nagyobb hibajel abszolútérték esetén P szabályozok is, az I mellett, ha viszont közel vagyok a célhoz, dobom a P szabályozást, marad a szimplán I. Csak valahol ez a P még nem jut érvényre, de ez csak implementációs bug, mindjárt megkeresem, hol rontottam el.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Általában az szokott lenni a trükk, hogy ezekben a módszerekben benne van egy PID jellegű dolog, ami kinematikai alapon számolsz. ezek után van még a nemlineáris rész, az egyensúlyi pont környékén használod a PID-et, messzebb meg a nemlineáris rész is bekapcsol. Ennek az szokott lenni az értelme, hogy az erősen nemlineáris rendszerekben a PID az egyensúlyi pontól távolabb használhatatlan, mivel mikor megcsinálod a Taylor sorba fejtést és kidobod a magasabb rendű tagokat, sokszor azokban a tagokban lényegi dolog volt, viszont az egyensúlyi pont körüli Taylor sor, ott elfogadható. Valamint vannak olyan módserek ahol ott lesznek problémásak, vagy csak egyszerűen a PID kevesebb erőforrást eszik és amikor elég az, akkor csak azt használod. Ezeknek a programozása sem nagy művészet nem sokkal esznek többet, csak az elején kicsit több matekot kívánnak papíron. Adott esetben akár Globálisan Stabil szabályzót is csináhasz Lyapunov direkt módszerével, kérdés persze az értelme az annyira túlbiztosított megoldásnak. 

Mindig azt kell használni amit a feladat megkíván. Van amikor mindent túl kell biztosítani, akkor nincs mese, elő kell venni Lyapunov-ot (gondolom most nem erről van szó,  azonk kevés dologból amit tudunk, ezen nem múlnak ember életek), Vannak egyszerűbb esetek, akkor jó a csúszó mód, meg vannak olyan extrém esetek, amikor nagyon sok dolgot nem tudsz az állapotokról, nem tudod mérni, meg ilyenek, akkor kell valami adaptív szabályzót elővenni, ami nem követeli meg a teljes állapottér ismeretét. Mindegyiket könnyű megérteni, a nehézség egyedül Lyapunov candidate bizonyításánál szokott lenni, de sok esetere ott is vannak receptek. 

( roleez | 2020. 05. 04., h – 19:11 )

Ismerős. Én is hasonló "bonyolulttal" kezdtem. És maradt az 5 összeadás (as fixpoint) és hasonlítás. Pont ilyen szabályozás elv van

a dr. Gyeviki János (SZE) doktorijában, igaz SM...

( locsemege v | 2020. 05. 04., h – 20:46 )

Eddig úgy néz ki, elég jól működik az elképzelésem. Jelenleg 0.1 °C peak to peak a hőmérsékleti ingadozása spontán, enyhe légmozgás mellett.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Egyszerűen csak kicsi volt az arányos tag. Ha kétszer akkora, már jó ez. Most annyi trükk van benne, hogy ha messze vagyok a célhőmérséklettől, akkor nagyobb az arányos tagom, ha néhány tized fokon belül, akkor fele akkora. Az integrátorom fixen nulla bázisú - erre még visszatérek -, s van egy alsó és felső limit, ami viszonylag szűk, itt telít, ezen a margón nem mehet túl. Van továbbá egy exponenciális átlagoló, ami az eddigi áramok átlagát képezi úgy, hogy a régebbi mérési eredmények súlya exponenciálisan, aszimptotikusan tűnik el a semmibe, de összességében hiába az új eredmény súlya a legnagyobb, az mégis nagyon kicsi. Ez adja a az integrátor offszetjét, a kószálásának középvonalát. Valami ilyesmire gondolj, bár nem ezekkel a számokkal:

középvonal = 4095 / 4096 * középvonal + 1 / 4096 * új_érték

Itt az új érték az, amiben minden benne van. A középvonallal offszetelt I szabályozás, és az arányos P is. Természetesen a különféle alul- és túlcsordulásokat, telítéseket gondosan kezelem. Azt is könnyű belátni, hogy ha kettő egész kitevőjű hatványaival dolgozom, megúszom a szorzást, osztást. A fenti összefüggésben csak shiftelés, összeadás, kivonás van. Csinálok benne olyat is, hogy ha az integrátor nagyon a margón kívülre kíván menni - akkor a hibajel adott korlátnál nagyobb értéke esetén néhány másodpercenként egyszer ezt megteheti úgy, hogy a középvonalat arrébb teszem egy integrátor margónyi értékkel abba az irányba, amerre menni akar. Viszont kis hibajel esetén csak lassan hagyom „tanulni” a középvonalat. Az aktuális gyors, mégis szerény beavatkozásra ott van a viszonylag kis erősítésű P tag és a korlátok között mocorgó I tag.

Ezeken felül a holtidő kompenzálására van egy jövőbe látó algoritmusa. Egy ring bufferbe minden n-edik mért hőmérsékleti értéket letárolom. Mivel nincs elég memóriám, nem az összeset, de két pont között lineáris interpolációval álmodom meg, mi lenne ott, ha azt is letároltam volna. A jelenérték és a múlt interpolált értékének különbségeként van egy deriváltam, egy meredekségem. Ezen egyenes mentén a jövőbe extrapolálok. Tehát, ha a jelenleg mért értékem ugyanolyan sebességgel változna, mint eddig, egy becsült holtidő múlva hány fok lesz a hőmérséklet. Ebből a jövőbeli hőmérsékletből és az alapjelből képezem a hibajelet. Ugye ez a jövőbeli hőmérséklet van jelenleg a beavatkozó szervnél nagyjából, csak a holtidő miatt még nem érkezett meg a hőmérőhöz.

Van még benne olyan is, hogy az integrátor kétszer gyorsabban jön lefelé, mint megy felfelé, mert hűteni nem tudunk. Ennek az értelméről nem vagyok meggyőződve.

Ez egy intuitív szabályozó így. Nem vettem fel a szabályozott tag paramétereit, nem tudom sem az időállandóját, sem a holtidejét. Tudom, hogy ezzel ősbűnt követtem el, de szeretem az intuitív, empirikus megoldásokat. :) Annál is inkább, mert ezen paraméterek változhatnak.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Én a ringbe úgy tárolnám az adatokat, hogy minden adatot tárolnék úgy, hogy a tárolt értékhez hozzáadnám a pillanatnyi értéket és a pointert 4-8-16 adatonként léptetném. Amikor számolok velük, akkor meg ROR annyival, amennyivel kell. Tapasztalatom szerint növeli a pontosságot.

 

Nem tudom érthetően írtam-e le.

> Sol omnibus lucet.

A jobbra rotálást értem, mert nyilván 2^n-szeres lesz az összeg, ha egyhelyben topog a pointer, és ráhalmozol 2^n darab adatot. Tehát akkor n-szer jobbra kell shiftelni. Egyébként ezt teszem, csak kicsit másképp. Minden 2^n adat alkalmával kiveszem a ringbufferből a régi értéket, leteszem egy változóba. A bufferben így felszabadult helyre beteszem az új értéket, a frissen mértet. Léptetem a pointert, ahol a legrégebbi értéknél eggyel frisseb adat van. Ebből kivonom azt a legrégebbit, amit az imént kivettem a ringből. Ezt jobbra shiftelem n-szer, így meglesz a növekményem, s minden alkalommal ezt a növekményt hozzáadom a kivett legrégebbi értékhez, azaz lineárisan interpolálok.

A jobbra shifteléssel nem veszítek pontosságot, mert lefelé kiterjesztem az aritmetikámat byte-okkal, azok a bitek nem vésznek el, így nem megy a pontosság rovására. Ha úgy tetszik, fixpontos tört aritmetikát használok, ha beleképzeljük a kettedespontot. Vagy más szavakkal azt is mondhatnám, hogy a számaimnak a 65536-szorosával dolgozok mindvégig. Értelmezés kérdése.

Amúgy, ha jól értem, a te javaslatod is lényegében ilyesmi volt.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE