Svenska ElektronikForumet

Det beror helt på vad man använder för reglerstrategi, vi gjorde en hel del labbar på en inverterad pendel i en av de senare reglerkurserna på universitetet.

En av de coolare var att använda lyapunov-reglering för att på kortast tid, eller med minsta möjliga energi, få en inverterad pendel att nå den lokala stabilitetspunkten stående rakt up från den asymptotiskt stabila (hängande rakt ned)

MPC var också rätt mycket bättre än en vanlig PID eller LQ(G)

Har svårt att se en 8-bitars AVR hantera det i realtid.

.

LHelge skrev:Det beror helt på

Håller med helt

Glattnos skrev:

LHelge skrev:Det beror helt på

Håller med helt

LHelge skrev:Det beror helt på vad man använder för reglerstrategi, vi gjorde en hel del labbar på en inverterad pendel i en av de senare reglerkurserna på universitetet.

En av de coolare var att använda lyapunov-reglering för att på kortast tid, eller med minsta möjliga energi, få en inverterad pendel att nå den lokala stabilitetspunkten stående rakt up från den asymptotiskt stabila (hängande rakt ned)

MPC var också rätt mycket bättre än en vanlig PID eller LQ(G)

Har svårt att se en 8-bitars AVR hantera det i realtid.

.

Häftigt! Orsaken varför MPC är bättre har med att MPC tar hänsyn till dötider, överskjut och systembegränsningar.

Det är just denna kontrolltyper jag vill fokusera på. Lyapunov, MPC med mera. Dvs regulatorer som beräknar de återkopplade signalerna.

ToPNoTCH skrev:Jag är inne på hawkans linje.
En F4 baserad flightcontroller.

- Bra pris
- Hög klockfrekvens
- FPU
- Alla sensorer du behöver på köpet.

Exempel:
LÄNK

Ja. Här börjar vi tala om något som är bra och billigt på samma gång. Vilket språk programmerar man den i?

Glattnos skrev:En inverterad pendel är väl inga problem en 8-bitar? En AVR på 16-20 MHz måste ju vara snabb så det räcker.

Det är 16 till 20 miljoner iterationer per sekund i CPU:n. Men frågan om det räker med matrisberäkningar för en inverterad pendel?

hawkan skrev:Inverterad pendel? Jag tycker du kan testa med en Due i så fall. Min känsla, dock bara känsla, är att det krävs en del men trots allt begränsat med beräkningar för att hålla balans på en inverterad pendel. Jämför med flight-controllers för multikoptrar eller modellhelikoptrar, de har precis vuxit ur 8-bitars kontrollers och använder 32-bitars. Där utgås från diverse givare för att korrigera läget, ungefär som du vill göra.

Sen kanske du inte ska använda alltför generella fall i dina beräkningar utan kondensera ner det till exakt det du behöver. Kanske du kan göra egna, slimmade versioner av matrisberäkningarna.

Det kanske blir en 32-bit flygmikroprosessor?

Krille Krokodil skrev:Codesys Matrix Library €250.00 plus VAT https://store.codesys.com/matrix-librar ... re=default

Har du kollat Scientific Python på Pi?

Utveckla matematik i ett kompilerat språk är 100'000 omkompileringar, tandagnissel och gråt, enklare att först testa fram fungerande lösningar i Matlab, Octave, Scipy etc. och sedan översätta dem till C/C++.

2500 kr för ett bibliotek är inte fel. Men frågan om man kan använda den hela tiden och för Raspberry PI?

Varför inte skriva direkt i C++? Eller C som nu alla mikroprocessorer kräver. Jag har testat Simulink Coder som kan generera Simulink kod till PLC kod. Fungerade riktigt bra!

Varför inte skriva direkt i C++? Eller C som nu alla mikroprocessorer kräver.

Finns inga processorer som kräver något språk, vad de kräver är maskinkod, dvs en uppsättning maskininstruktioner.

Ja, men man skriver inte maskinkod. Man har alltid ett utvecklingsverktyg.

Förvisso är det så, men det är inte processorn som ställer kraven, utan de som utvecklat verktygen som ställer kraven.
Och jo man skriver i bland i maskinkod, det är rätt många här som gör det. I vissa lägen måste man det, för att alla saker går helt enkelt inte att lösa med ett högnivåspråk.

Nja, assembler iallafall. Vilket är en underskattad konst.

Assembler är ju maskinkod.

För mig är maskinkod 101010101 i praktiken. Jag menar inte att man öppnar en .txt fil och skriver in 101010101 och sparar och stänger. Sedan skickar man den filen via USB till uC:n. Klart.

Jag menar mer att man sätter vissa "logikelement" i uC:n till ON/OFF. Kommer säkert bli tillrättavisad angående detta, typ som användarna här vore Windows Update kl 23:00.

Assembler i sitt ursprung är en direkt översättning av maskinkod, man satte helt enkelt mneonics på maskininstruktionerna, då det är lättare att läsa.
Enkelt uttryckt, en assembler-mneonic motsvarar alltid en specific maskinkod.

Beklagar TomasL, du har fel. Om det beror på begränsad erfarenhet eller villfarelse har jag ingen åsikt om.

Öh, nej, jag har inte fel.
Däremot kan en del assemblatorer hantera makron och liknande, men det har egentligen inget med assembler att göra, snarare att likna med preprocessorn i C.
Men du kan alltid handassemblera ett assemblerprogram, har gjort det många många gånger, det var så vi dessutom lärde oss i skolan på 70-talet.
Vi skrev programmet i assembler, handassemblerade det (dvs översatte varje enskild assemblermneonic till dess motsvarighet i maskinkod) och matade in hexkoden i processorn (på den tiden 6800) manuellt via strömbrytare.

I en blå burk från Didact. Jo jag vet. Men assembler är fortfarande inte samma som maskinkod.

Eh, jo, om du skalar bort makrona.

I en blå burk från Didact.

Vet inte om den var blå, den hade 4+2 7-seg, ett 20 knappars tangentbord och en labb-platta på toppen.

Vi bootstrappade dessutom vår minidator med ett assemblerprogram, och där hade vi vanliga strömbrytare, 16 st för data och 32 st för adress samt något tiotal för register.
Allt åskådliggjort med enkla LEDar.

Skit samma, det finns ingen anledning att käfta om detta.
Jag har rätt och du har fel.