Greve Hamilton skrev:
Nja, ta bort pricken på x:et så är det rätt. Då har du samma form som jag skrev förut men med \(F(x_k,u_k) = Fx_k+Gu_k\). Varför är det fel menar du?
Glömde pricken. Jag kopierade bara.
Problemet är att jag vill inte använda en diskret matematisk modell då jag tycker det är onödigt och dåligt samt svårt. Varför ska man ha en diskret matematisk modell när man kan egentligen köra istället med mycket kort sampling t.ex. 0.0001 sekunder?
Många jag har pratat med uppmanar mig att välja diskreta modeller om jag ska implementera en regulator i en mikrokontroller, men de kan inte förklara varför jag måste ha en diskret modell. Det är som det vore en norm från 50-talet att använda diskreta modeller.
Jag kan simulera en tidskontinuerlig ODE (Ordinär Differentialekvation) med hjälp av en for-loop i C. Inga problem alls!
u = 10;
for(int i = 0; i < 100; i++)
{
dx = A*x + B*u;
y[i] = C*x;
T[i] = t;
x = x + dx*t; // Uppdatera nästa tillstånd
}
Där t är samplingstiden och y kan nu plottas över tiden T.
OK, jag tror att vi pratar förbi varandra. Jag fortsätter dock hävda att så fort ett dt är inblandat så har du att göra med ett tidsdiskret system. Oavsett hur litet det är. Ditt kodexempel implementerar på sista raden just den diskretisering jag beskrev först.
MEN, det är ju så att ju mindre dt desto mer likt blir det diskreta systemet det kontinuerliga. Så om du vill kalla din metod med litet dt för kontinuerlig så låt inte mig hindra dig.
Alltså med andra ord så skulle det fungera att implementera en tidskontinuerlig matematisk modell i en digital regulator?
Typ som att använda den tidskontinuerliga PID-regulator formeln, istället för den diskreta? \(K = P((r-y) - \frac{\delta y}{t} + \int_0^t (r-y)dt)\)
Edit: RPi klarar nog av det men pga att du har ett OS så blir det inte deterministiskt. Det blir inte deterministiskt utan OS heller om man klantar till det.
Senast redigerad av lillahuset 30 juli 2017, 19:49:07, redigerad totalt 1 gång.
Edit: RPi klarar nog av det men pga att du har ett OS så blir det inte deterministiskt. Det blir inte deterministiskt utan OS heller om man klantar till det.
Så typ en "badass" Arduino är att föredra? Typ en Due eller Zero, vilket är en Mega på 32-bit och en Uno på 32-bit?
hawkan skrev:Gör om det till state space representation och lös det med t ex lsode, ode23 eller ode45 i octave.
Garderar mej för att jag kan vara helt fel ute.
Varför så fixerad vid Arduino? Jag tvivlar på att det finns bättre än Cortex-M3 på Arduino.
Du vill ha en Cortex-M4F (eller bättre). USD14:40 ska väl inte vara något problem. Finns hos en del av de stora katalogdistributörerna i Sverige också.
Ja då får du iallafall bra beräkningskapacitet.
Hur problemet med bristande determinism påverkar en regulator vet jag inte. Däremot vet jag att determinismen i en standard Linux inte duger för att göra vibrationsmätningar. Eller duger och duger, det beror ju på kraven.
Reglerteknik intresserar mig inte alls. Jag har skrivit en PID-regulator och en hittepå-regulator åt kunder hittills i mitt liv. Och fler lär det inte bli.
Mitt intresse har länge varit och är fortfarande signalbehandling. Därmed inte sagt att jag är en stjärna på det. Som det brukar vara, bättre än de flesta, sämre än många.
Om du gillar signalbehandling så rekommenderar jag att läsa på om LQE - Linear Quadratic Estimation.
Det är alltså ett filter som gör två saker:
1. Skatta ALLA signaler i systemet igen endast en insignal. Typ om du har 1 signal från en givare, så kan du veta deplacement och förändringshastighet hos en annan elektronikkomponent någon annanstans.
2. Filtrera bort brus från alla frekvenser.
Men vad kan vi dra för slutsats i denna tråd?
* Jag kan använda en tidskontinuerlig modell i den digital mikrokontroller.
* Jag ska använda Raspberry Pi då den är bättre än Arduino
Jag antar att du brukar använda överföringsfunktioner ofta?
Greve Hamilton skrev:
OK, jag tror att vi pratar förbi varandra. Jag fortsätter dock hävda att så fort ett dt är inblandat så har du att göra med ett tidsdiskret system. Oavsett hur litet det är. Ditt kodexempel implementerar på sista raden just den diskretisering jag beskrev först.
MEN, det är ju så att ju mindre dt desto mer likt blir det diskreta systemet det kontinuerliga. Så om du vill kalla din metod med litet dt för kontinuerlig så låt inte mig hindra dig.
Alltså med andra ord så skulle det fungera att implementera en tidskontinuerlig matematisk modell i en digital regulator?
Typ som att använda den tidskontinuerliga PID-regulator formeln, istället för den diskreta? \(K = P((r-y) - \frac{\delta y}{t} + \int_0^t (r-y)dt)\)
Grejen är ju att så fort du försöker implementera den kontinuerliga formeln så kommer du landa i någon av de tidsdiskreta varianterna som finns. Man kan ju inte utföra ideal derivering/integrering numeriskt. Men vi ska inte förlora oss i semantiken kring vad som är diskret och kontinuerligt... Kör på bara!
Har du någon känsla för storleken den snabbaste tidskonstanten på systemet du försöker reglera? Detta brukar normalt sett bestämma den minsta frekvens med vilket reglerloopen skall köras, vilket också kan vara värdefullt att veta för att bestämma hur snabb processor du behöver. En tumregel är att reglera med en period < snabbaste tidskonstanten / ~15. Men sånt har du säkert koll på.
>> Har du någon känsla för storleken den snabbaste tidskonstanten på systemet du försöker reglera?
0.2 m/s är nog den snabbaste hastigheten i systemet.
Alltså när det kommer till LQ-teknik så handlar det inget om frekvens och tidskonstanter. Normalt så brukar man köra på att samplingsintervallet ska vara 0.01 sekunder. Då får man en väldigt fin kurva.
Jag tror det är dags att sluta teoritesera och dags att börja realisera, dvs skriva kod och se hur det går.
Att sampla med 100Hz tror jag går alldeles utmärkt med en RPi och även en Atmega jag men den hinner som sagt kanske inte med alla beräkningar.
Jag tror inte att avsaknaden av RT-egenskaper i Linux kommer vara ett problem. "Premature optimization is the root of all evil"