Hallo zusammen, ich hänge aktuell an dem Problem ein Ausganssignal zu linearisieren. Die gemessene Ausgangssignalkurve (blaue Kurve im angehängten Bild) habe ich mir mit Excel mit einem Least Square Fit berechnen lassen. Die Funktion dieser Kurve lautet (dünne schwarte Kurve). U = 5,9602*x^2 - 1,1242*x+0,099 Die Werte für x liegen zwischen 0 und 1 bzw. 0 und 100%. Mein Ziel wäre es jetzt diesen Zusammenhang zu linearisieren. Mein Ansatz wäre jetzt, die Funktion die ich in Excel mit dem Least Square Fit errechnet habe an der Geraden zu spiegeln, welche ich nachher haben will (orange Gerade im angehängten Bild). Wenn man nun die Funktion umkehrt, sodass die Spannung des Ausgangssignals vom Prozentwert x (im Bild als Winkel in % beschrieben) abhängt, also eine Funktion x(U). Diese will ich dann in den Mikrocontroller implementieren. Dazu erstmal die Frage, ob das so funktionieren kann? Die zweite Frage wäre wie man das konkret berechnet Ich hätte die Tools Matlab und Geogebra zur Verfügung, vlt kann mir da ein Profi kurz weiterhelfen. Ich bin auch gerne für komplett andere Vorschläge offen, also andere Konzepte wie man eine solche Linearisierung durchführen kann. (am Besten ohne einen Lookup-Table implementieren zu müssen) Vielen Dank schon mal im Voraus!
Angehängte Dateien:
-
Linearisierung.PNG
35 KB
Matlab curve fitting toolbox ist dein Freund.
Die Kurve ist ja schon gefittet, mir gehts jetzt eher darum,ob mein Ansatz überhaupt funktioniert und und wie man die Spiegelung an der Geraden (f(x)=5x) berechnet.
Fritz B. schrieb: > ich hänge aktuell an dem Problem ein Ausganssignal zu linearisieren. Die > gemessene Ausgangssignalkurve (blaue Kurve im angehängten Bild) habe ich > mir mit Excel mit einem Least Square Fit berechnen lassen. Die Funktion > dieser Kurve lautet (dünne schwarte Kurve). > U = 5,9602*x^2 - 1,1242*x+0,099 Unbedenkliche Anwendung von Regression ist gefährlich. Man muss den physikalischen Zusammenhang kennen, um erstmal die Funktion festlegen zu können, auf die gefittet werden muss. Im konkreten Fall: mir sieht das nicht wirklich nach einer quadratischen Funktion aus. Wäre es wirklich eine eine, sähe der Fit viel besser aus. Also: Ich würde mal damit anfangen, mir Gedanken darüber zu machen, wie die Spannung sich tatsächlich zum Winkel verhält. Das ist mit sehr hoher Wahrscheinlichkeit kein quadratischer Zusammenhang.
Look-Up Table mit Referenzwerten für diskrete, lineare Werte. Setzt halt vorraus, dass du weißt was für Werte du erwartest. Läuft dann aber deutlich effizienter als wenn du deinen µC jedes mal neu rechnen lässt.
Der tatsächliche physikalische Zusammenhang ist eine sehr unhandliche Formel, es handelt sich nämlich um einen Hall-Sensor der sich relativ zu einem Zylindermagneten bewegt. Vorerst ist das nur mal ein Konzept, also die Genauigkeit des Fits wäre vorerst mal ausreichend.
Fritz B. schrieb: > Die Kurve ist ja schon gefittet Naja, gefittet schon. Zu gebrauchen: Nein ;) Dein "Spiegeln an der Diagonale" ist ja nichts anderes als die Umkehrfunktion zu bestimmen. Da hast Du schon eine richtige Idee gehabt. Leider kann man zu DEINEM Fit keine Umkehrfunktion bestimmen. Zum Thema Tools: Geogebra kenn ich nicht. MatLab wäre da das Tool der Wahl, im Zweifelsfall auch ohne Toolbox. Octave sollte es auch hinbekommen. /regards P.S: Magst Du mal die Werte der gemessenen Kurve zeigen? Also einfach als Zip/Txt anhängen? Dann kann man Dir schneller Sachen zeigen.
Lookup Table wollte ich eigentlich vermeiden, da ich damit noch nie gearbeitet habe und es sich um keine zeitkritische Anwendung handelt.
Fritz B. schrieb: > Mein Ansatz wäre jetzt, > die Funktion die ich in Excel mit dem Least Square Fit errechnet habe an > der Geraden zu spiegeln, welche ich nachher haben will (orange Gerade im > angehängten Bild). So richtig passend sieht die Excel-Funktion nun wahrlich nicht aus. Nach der Umkehrfunktion dazu zu suchen, ist da ziemlich witzlos. Wenn du dir mal die Differenz zur Ausgangssignalkurve plottest, wirst du feststellen, dass diese Fehlerkurve fast kein Rauschen, aber kräftig systematische Anteile enthält. Ein Polynom 2. Grades ist ziemlich ungeeignet, um deine Ausgangssignalkurve zu beschreiben. > Mein Ansatz wäre jetzt, die Funktion die ich in Excel mit dem > Least Square Fit errechnet habe an der Geraden zu spiegeln, welche > ich nachher haben will (orange Gerade im angehängten Bild). Warum vertauscht du nicht x,y und lässt dir gleich den Fit für eine Korrekturfunktion ausgeben?
Angehängte Dateien:
-
Linearisierung.PNG
34 KB
Wolfgang schrieb: > Warum vertauscht du nicht x,y und lässt dir gleich den Fit für eine > Korrekturfunktion ausgeben? Aber dann spiegle ich nicht an der Gerade die ich später haben will, nämlich y=5x. Das Polynom dritten Grades gibt eine deutlich bessere Kurve aus.
Fritz B. schrieb: > Lookup Table wollte ich eigentlich vermeiden, da ich damit noch nie > gearbeitet habe und es sich um keine zeitkritische Anwendung handelt. Es ist ja nicht nur die Zeit sondern auch der immense Flashverbrauch, den Du Dir mit den reinziehen der Mathelibrarys einhandelst. Wenn Dir 8 Bit Genauigkeit reichen, dann auf jeden Fall eine Tabelle. Rechnen lohnt sich eigentlich nur wenn Du wirklch die Genauigkeit von float benötigst.
Alles klar, so wie es scheint werde ich mich dann näher mit den Lookup Tables beschäftigen müssen. Danke für die vielen Antworten.
Fritz B. schrieb: > da ich damit noch nie > gearbeitet habe und es sich um keine zeitkritische Anwendung handelt. Lookup ist vermutlich das schnellste überhaupt und der erste Punkt ein Argument dafür.
Fritz B. schrieb: > Das Polynom dritten Grades gibt eine deutlich bessere Kurve aus. Ja, die hat mir MatLab, anhand Deiner Daten, eben auch genau so rausgeworfen. Und DIESER Fit ist jetzt auch (mehr oder weniger) invertierbar. /regards
Fritz B. schrieb: > Alles klar, so wie es scheint werde ich mich dann näher mit den Lookup > Tables beschäftigen müssen. Ich bin stillschweigend davon ausgegangen, daß Du das auf einem 8-Bit System machen willst, stelle aber gerade fest, daß davon keine Rede war. Falls Du also auf einem 32-bitter entwickelst, sieht das wieder anders aus. Dann nehme ich meine Aussage zurück. Dann ist eine Lookuptabelle nur noch ein Zeitvorteil. Davon abgesehen, schadet es aber trotzdem nicht, sich mit Lookuptabellen einmal zu befassen. Das nächste zeitkritische Problem kommt bestimmt. ;-)
Zuerst mußt Du mal festlegen, welche Genauigkeit Du überhaupt brauchst und wie genau es der Sensor, der ADC, der DAC usw. überhaupt schaffen. Eine Tabelle kannst Du ganz bequem in Excel als Komma separierte Liste erzeugen, in eine Datei exportieren und in das C-File includieren. Wenige Stützwerte kann man aber auch einfach abtippen und dazwischen interpolieren (ax+b).
Andreas B. schrieb: > Ich bin stillschweigend davon ausgegangen, daß Du das auf einem 8-Bit > System machen willst, stelle aber gerade fest, daß davon keine Rede war. Das ist auch nicht wirklich relevant. Relevant wäre, mit welcher Auflösung dieser Winkel eigentlich überhaupt gemessen werden kann und mit welcher Auflösung die Ausgangsspannung sich überhaupt einstellen läßt. Beides sind mit an Sicherheit grenzender Wahrscheinlichkeit keine 32 Bit, sondern eher was im Bereich von 8..12 Bit. DAS sind die wirklich relevanten Größen bei so einem Problem und nicht die Breite irgendwelcher Register oder Rechenwerke!
Hab ich so in einem Regler benutzt, um das Stellglied zu linearisieren. Lässt sich sehr einfach auf eine andere Anzahl von Stützstellen umbauen. Anzahl der Stützstellen sollte allerdings 2^n+1 sein. Zeile 27-30 dient Debugzwecken. Eigentlich können die Zeilen raus, dafür wird dann Zeile 25 enabled.
1 | // Die PWM Tabelle umfasst 17 Stützpunkte: |
2 | int PWM_table[17] = {
|
3 | 0, 94, 116, 133, 147, 160, 171, 182, 192, |
4 | 201, 210, 218, 226, 234, 242, 249, 255 |
5 | }; |
6 | |
7 | // Konvertiert das 10-bit Regler-Ergebnis in einen 8 bit PWM-Steuerwert |
8 | // |
9 | // Mit p1 und p2 wird der Stützpunkt direkt vor und nach dem |
10 | // Tabellen-Wert ermittelt. Zwischen beiden Stützpunkten wird linear |
11 | // interpoliert. Der Code ist sehr klein und schnell. |
12 | // Es wird lediglich eine Ganzzahl-Multiplikation verwendet. |
13 | // Die Division kann vom Compiler durch eine Schiebeoperation |
14 | // ersetzt werden. |
15 | |
16 | |
17 | int PWM2MosFET(unsigned int value){
|
18 | |
19 | int p1,p2; |
20 | // Stützpunkt vor und nach dem Steuer-Wert ermitteln. |
21 | p1 = PWM_table[(value >> 6)]; |
22 | p2 = PWM_table[(value >> 6)+1]; |
23 | |
24 | // Zwischen beiden Punkten linear interpolieren. |
25 | //return p1 - ( (p1-p2) * (value & 0x003F) ) / 64; |
26 | |
27 | int reminder = (p2-p1) * (value & 0x003F); |
28 | int result = p1 + reminder/64; |
29 | S_printf("in:%d p1:%d p2:%d rem:%d out:%d\n", value, p1, p2, reminder, result);
|
30 | return result; |
31 | } |
Fritz B. schrieb: > Der tatsächliche physikalische Zusammenhang ist eine sehr unhandliche > Formel, es handelt sich nämlich um einen Hall-Sensor der sich relativ zu > einem Zylindermagneten bewegt. Unhandlich oder nicht ist irgendwie nicht das Kriterium, das ist vielmehr: ist sie stetig differenzierbar?
c-hater schrieb: > DAS sind die wirklich relevanten Größen bei so einem Problem und nicht > die Breite irgendwelcher Register oder Rechenwerke! Es ging mir nicht um die Breite irgendwelcher Rechenwerke, sondern um die Tatsache daß 8 Bitter i.A. weniger Resourcen haben. Da macht es einen Unterschied ob ich eine Float Library in einem Tiny reinziehe oder in einem 32-Bitter, der wesentlich mehr Flash hat. Für nicht benutzen Flash gibt es kein Geld zurück. Davon abgesehen ist auch die Wahrscheinlichkeit höher, daß ich für ein Projekt, das einen 32-Bitter benötigt, Float auch an einer anderen Stelle gebrauchen könnte.
Andreas B. schrieb: > Es ging mir nicht um die Breite irgendwelcher Rechenwerke, sondern um > die Tatsache daß 8 Bitter i.A. weniger Resourcen haben. Das ist sicher so. Aber genau darum geht es auch: Die Abwägung, was nun mehr Flash verbraucht. Die Einbindung der Mathematik oder eine Tabelle. Dazu muss man aber wissen, wie groß die Tabelle eigentlich ausfallen müsste. Und dazu sind halt allein die von mir genannten Größen relevant. Allerdings auch nur für den worst case. Praktisch ist es meist noch viel entspannter, weil man nur ein paar Stützpunkte in die Tabelle packen muß und die Zwischenwerte linear interpolieren kann, was bei intelligenter Optimierung(*) auf eine Subtraktion und und eine Multiplikation hinausläuft. (*) Hat nix mit dem Kram zu tun, den Compiler als Feature haben...
c-hater schrieb: > Dazu muss man aber wissen, wie groß die Tabelle eigentlich ausfallen > müsste. Und dazu sind halt allein die von mir genannten Größen relevant. > Allerdings auch nur für den worst case. Eben, eine 1024 er Tabelle für 10 Bit wird man selten wirklich brauchen. Und wenn es wirklich genauer sein muß, dann kommt man eben wieder mehr in die Richtung daß man es berechnen wird. Aber es geht ja auch um Bequemlichkeit. Und da der TO offensichtlich Probleme mit Lookup Tabellen hat, spricht nichts dagegen es zu berechnen wenn er genug Ressourcen hat. Mit anderen Worten: Bei einem 32-bitter ist es meist egal. ;-)
Fritz B. schrieb: > Aber dann spiegle ich nicht an der Gerade die ich später haben will, > nämlich y=5x. Also, das spiegeln liefert Dir nicht die Möglichkeit aus der Spannung wieder den Winkel zu erraten. Wolfgang schrieb: > Warum vertauscht du nicht x,y und lässt dir gleich den Fit für eine > Korrekturfunktion ausgeben? Ist zumindest eine "einfache" Lösung. Kurz mal durch MatLab gejagt und für ein 3rd Order Poly einen mittleren, relativen Fehler von 5% erhalten. c-hater schrieb: > Ich würde mal damit anfangen, mir Gedanken darüber zu machen, wie > die Spannung sich tatsächlich zum Winkel verhält. Wäre auch mein Ansatz. /regards
Beitrag #6717919 wurde vom Autor gelöscht.
Fritz B. schrieb: > Alles klar, so wie es scheint werde ich mich dann näher mit den Lookup > Tables beschäftigen müssen. Danke für die vielen Antworten. Nein, keine lookup table. Das geht super mit Mathe. Du hattest eine Funktion die wunderbar Deine Messwerte fittet: a=2.4867 b=2.2302 c=0.2824 d=0.0174; y=a*x.^3+b*x.^2+c*x+d; Der fit der Umkehrfunktion funzt nicht gut, das habe ich probiert. Zweite Möglichkeit: Du suchst die Lösungen x der Funktion y=a*x.^3+b*x.^2+c*x+d; alles ausser x bekannt. Onkel Wolfram Alpha antwortet auf Reduce[y==a*x^3+b*x^2+c*x+d,x] mit den drei Lösungen der Funktion. Die beiden konjugiert komplexen werfen wir weg und nehmen nur die reele. Die lautet: xs = -b/(3*a) - (2^(1/3)*(-b^2 + 3*a*c))/(3*a*(-2*b^3 + 9*a*b*c - 27*a^2*d + 27*a^2*ys + sqrt(4*(-b^2 + 3*a*c)^3 + (-2*b^3 + 9*a*b*c - 27*a^2*d + 27*a^2*ys)^2))^(1/3)) + (-2*b^3 + 9*a*b*c - 27*a^2*d + 27*a^2*ys + sqrt(4*(-b^2 + 3*a*c)^3 + (-2*b^3 + 9*a*b*c - 27*a^2*d + 27*a^2*ys)^2))^(1/3)/(3*2^(1/3)*a) ; Zwei Quadratwurzeln, zwei kubische Wurzeln, nicht schön aber geht. a,b,c,d Konstanten, ys dein Meßwert, xs der gesuchte zugehörige Winkel. Manchmal werden die Argumente der Wurzel wegen Rechenungenauigkeiten leicht negativ, das ersetzt Du durch 0. so jeht dette. math rulez viel Spaß gehabt, thx Cheers Detlef clear x=linspace(0,1,10000); x=x(:); a=2.4867 b=2.2302 c=0.2824 d=0.0174; y=a*x.^3+b*x.^2+c*x+d; plot(x,y); xs=zeros(size(x)); n=length(y) for(k=1:n) ys=y(k); xs(k) = -b/(3*a) - (2^(1/3)*(-b^2 + 3*a*c))/(3*a*(-2*b^3 + 9*a*b*c - 27*a^2*d + 27*a^2*ys + sqrt(4*(-b^2 + 3*a*c)^3 + (-2*b^3 + 9*a*b*c - 27*a^2*d + 27*a^2*ys)^2))^(1/3)) + (-2*b^3 + 9*a*b*c - 27*a^2*d + 27*a^2*ys + sqrt(4*(-b^2 + 3*a*c)^3 + (-2*b^3 + 9*a*b*c - 27*a^2*d + 27*a^2*ys)^2))^(1/3)/(3*2^(1/3)*a) ; end; xs=real(xs); plot(x,y,'b.-',xs,y,'r.-'); return
Detlef _. schrieb: > xs = -b/(3*a) - (2^(1/3)*(-b^2 + 3*a*c))/(3*a*(-2*b^3 + 9*a*b*c - > 27*a^2*d + 27*a^2*ys + > sqrt(4*(-b^2 + 3*a*c)^3 + (-2*b^3 + 9*a*b*c - 27*a^2*d + > 27*a^2*ys)^2))^(1/3)) + (-2*b^3 + 9*a*b*c - 27*a^2*d + 27*a^2*ys + > sqrt(4*(-b^2 + 3*a*c)^3 + (-2*b^3 + 9*a*b*c - 27*a^2*d + > 27*a^2*ys)^2))^(1/3)/(3*2^(1/3)*a) ; > Zwei Quadratwurzeln, zwei kubische Wurzeln, nicht schön aber geht. > a,b,c,d Konstanten, ys dein Meßwert, xs der gesuchte zugehörige Winkel. > Manchmal werden die Argumente der Wurzel wegen Rechenungenauigkeiten > leicht negativ, das ersetzt Du durch 0. OMG Völlig schwachsinniger Rechenaufwand zur Umsetzung eines Zusammenhangs, der nichtmal als wirklich zutreffend bekannt ist (bzw. von dem sogar nach der Beschreibung der Funktionsweise des Sensors mit einiger Wahrscheinlichkeit angenommen werden kann, dass er nicht zutreffend ist). Ja, so löst der heutige Ingenineursnachwuchs Probleme. Hauptsache, es passt in matlab. Keinesfalls mal selber ernsthaft nachdenken. Das nervt doch nur.
Andreas H. schrieb: > Ist zumindest eine "einfache" Lösung. Kurz mal durch MatLab gejagt und > für ein 3rd Order Poly einen mittleren, relativen Fehler von 5% > erhalten. Durch ein Polynom 3.Ordnung lässt sich die Umkehrfunktion nun wirklich nicht beschreiben, wenn das ein bisschen passen soll. Nimm mal einen Term x^a mit passend gefittetem a<1 dazu ;-)
Wolfgang schrieb: > Andreas H. schrieb: >> Ist zumindest eine "einfache" Lösung. Kurz mal durch MatLab gejagt und >> für ein 3rd Order Poly einen mittleren, relativen Fehler von 5% >> erhalten. > > Durch ein Polynom 3.Ordnung lässt sich die Umkehrfunktion nun wirklich > nicht beschreiben, wenn das ein bisschen passen soll. Nimm mal einen > Term x^a mit passend gefittetem a<1 dazu ;-) ja, die Umkehrfunktion fittet sich nur sehr schlecht, nicht mal 5.Ordnung passt gut. >>>> OMG Nicht alles, was Du nicht verstehst, ist schwachsinnig. Ob das Modell des TO paßt oder nicht ist mir herzlich egal, ging mir um den fit. >>>> ernsthaft nachdenken Yo Cheers Detlef
Ich nutzte vor Jahren ein Tool namens TableCurve, das automatisch 3000 Funktionen über Datensätze fittet. Tatsächlich haben wir dadurch erkannt, welche zwei Funktionen sich überlagerten. Hab das mal per Python nachgebaut (ohne 3000 Funktionen… wenn mir mal langweilig ist… 🙂) Die Funktion "f(x)=ax^b+c" fitted für die Umkehrfunktion ordentlich: a,b,c=[ 0.60151694 0.38307022 -0.11127517] R² = 0.99957 Die Frage bleibt aber: welche Genauigkeit wird denn benötigt?
:
Bearbeitet durch User
Klaus H. schrieb: > > Die Funktion "f(x)=ax^b+c" fitted für die Umkehrfunktion ordentlich: > > a,b,c=[ 0.60151694 0.38307022 -0.11127517] > > R² = 0.99957 > > Die Frage bleibt aber: welche Genauigkeit wird denn benötigt? Für x=0 ist 11% zu klein, für x=1 2% zu klein. Ordentlicher fit ist für mich was anderes, aber da kann es ja verschiedene Meinungen geben. Showstopper für Deinen Ansatz ist x^b, da kannst Du Echtzeit vergessen. Cheers Detlef
Detlef _. schrieb: > Für x=0 ist 11% zu klein, für x=1 2% zu klein. Ordentlicher fit ist für > mich was anderes, aber da kann es ja verschiedene Meinungen geben. Womit wir wieder bei der Messgenauigkeit sind. Wir wissen nicht wie reproduzierbar die 10 Messwerte des TO sind. Funktionen zu fitten hilft nur eine Mathematische Funktion zu finden die mit wenigen Parametern ggf. eine tatsächliche Funktion ausreichend genau beschreibt. (Wenn dir die 10 Messwerte wichtig sind, nimm ein Polynom 10. Grades. Dann passen sie. Der Rest ist dann halt Müll. - Bitte nicht als Angriff verstehen, vermutlich weist Du das - ich wollte es für FIT- Neulinge nur anmerken). >Showstopper für Deinen Ansatz ist x^b, da kannst Du Echtzeit vergessen. Echtzeit wurde nicht angegeben. Nur dass es nicht "zeitkritisch" ist. (Performance beachte ich immer erst wenn klar ist, dass selbige nicht reicht. Dann sagt mir ein Profiler wo es klemmt.) Und einfach eine Excel Tabelle zu nehmen und zu interpolieren, macht das Messergebnis auch nicht besser. Alternativ kann man ja auch beides verbinden und ax^b+c bei der Initialisierung berechnen und in eine LUT speichern. Hab ich auch schon gemacht und hat das messtechnische System verbessert. Vor allem wenn es größere Streuungen gibt.
Klaus H. schrieb: >>Showstopper für Deinen Ansatz ist x^b, da kannst Du Echtzeit vergessen. > > Echtzeit wurde nicht angegeben. Nur dass es nicht "zeitkritisch" ist. > (Performance beachte ich immer erst wenn klar ist, dass selbige nicht > reicht. Dann sagt mir ein Profiler wo es klemmt.) Achso. Hatte ich falsch gelesen, 'eine' statt 'keine' zeitkritische Anwendung. 'exp' war ich letztens nochmal reingefallen, da benötigt ein STM32 sehr lange, 20k/s Berechnungen schaffte der nicht. Und wenn Du das Polynom 10 Ordnung auf dem 8Bitter 20k Mal /s ausrechnen willst benötigt Du auch keinen Profiler um zu sehen, dass das nicht funzt. Mit den Fahrrad zum Mond. Cheers Detlef
Experte schrieb: > Andreas H. schrieb: >> Leider kann man zu DEINEM Fit keine Umkehrfunktion bestimmen. > > Ach? > x=596020000⋅U−27410339−−−−−−−−−−−−−−−−−−−−√+562159602x={{\sqrt{596020000 > \cdot U-27410339}+5621}\over{59602}} Jo, da hab ich wohl in's Klo gegriffen und hätte besser lesen sollen... ROFL Ja, sein (erster) FIT kann man natürlich nicht umkehren. Stimmt.
Detlef _. schrieb: > Achso. Hatte ich falsch gelesen, 'eine' statt 'keine' zeitkritische Anwendung. > exp war ich letztens nochmal reingefallen, da benötigt ein STM32 sehr lange, > 20k/s Berechnungen schaffte der nicht. > Und wenn Du das Polynom 10 Ordnung auf dem 8Bitter 20k Mal /s ausrechnen willst > benötigt Du auch keinen Profiler um zu sehen, dass das nicht funzt. Die Leistungsfähigkeit von 8 Bitter wird oft unterschätzt. (Und zum Klarstellen: Ich bevorzuge 32Bit ARM Architekturen und keine 30Jahr alten 8 Bit Schiebekisten). Ich habe das ganze mal für verschiedene float Berechnungen getestet. Plattform: Arduino Nano Clone mit ATmega328, 16MHz (lag hier rum). Beispiel: Code wurde 5000mal über den Wertebereich U ausgeführt und die mittlere Zeit bestimmt.
1 | float U2W(float x) |
2 | {
|
3 | const float a = 0.60151694; const float b = 0.38307022; const float c = -0.11127517; |
4 | return a*pow(x,b)+c; |
5 | }
|
Ausführungszeiten:
1 | | Funktion | Code | tMean (ms) | max. Samples/s | |
2 | |----------------------|-------------------|------------|----------------|
|
3 | | Potenzfunktion | a*pow(x,b)+c | 0,34 | 2941 | |
4 | | Wurzel von Experte | (sqrt(a*x+b)+c)/d | 0,10 | 10000 | |
5 | | Polynom 2. Grades | a*x*x + b*x + c | 0,05 | 20000 | |
6 | | Polynom 10. Grades | …. | 0,27 | 3704 | |
Die RAM Belegung lag bei 10% (von 2048 Byte). Die ROM Belegung bei
10%...15% (von 30720 Byte)
(Ausgabe der Zeitwerte per Serial war noch drin. Alles in float. Keine
Optimierungen.)
Das Polynom 10 Grades schafft immerhin mehr als 3000 Samples.
Und meine Potenzfunktion ist auch nicht weit davon weg.
Und wenn der Sensor seine Daten mit 100Hz ausgeben soll, ist noch genug
Zeit für ADC, Filterung, Kommunikation, Steuerung.
Mein Fazit:
Für Prototypen sind gefittete float-Funktionen wunderbar auch auf
8Bitter nutzbar (wenn die Ausgaberate reicht). So kann man schnell
Messkurven linearisieren oder gleich die physikalische Funktion
implementieren.
Wenn ich ein Seriengerät baue und ggf. einiges mehr machen muss oder ich
muss auf Stromverbrauch achten, dann machen Lookup Tabellen mehr Sinn.
> Mit den Fahrrad zum Mond
Ich finde der Vergleich hinkt.
Nur das Kriterium Schnelligkeit-in-Ausführung als alleiniges Ziel zu
betrachten, halte ich für unflexibel. Es geht auch um Entwicklerzeit,
Testaufwand, Verständlichkeit, Numerische Stabilität u.v.m.
Während Villarriba noch Lookup Tabellen implementiert, feiert Villabajo
schon das Ergebnis.
:
Bearbeitet durch User
Klaus H. schrieb: > Das Polynom 10 Grades schafft immerhin mehr als 3000 Samples. Ein Polynom 10 Grades macht vor allen Dingen Unfug zwischen den Stützstellen.
Wolfgang schrieb: > Ein Polynom 10 Grades macht vor allen Dingen Unfug zwischen den > Stützstellen. So sieht's aus. Insbesondere dann, wenn es sich um ein willkürlich gewähltes Polynom handelt...
Fritz B. schrieb: > Lookup Table wollte ich eigentlich vermeiden, da ich damit noch nie > gearbeitet habe und es sich um keine zeitkritische Anwendung handelt. Das ist bei solchen Anwendungen aber durchaus Mittel der Wahl. So stellt man z.B. sicher, dass die Linearisierung durch den Nullpunkt geht, eine maximale Steigung nicht übersschreitet (regelungsfreundlicher) und partiell stetig ist. Dazwischen kubiusche splines oder akima-interpolation.
Wolfgang schrieb: > Ein Polynom 10 Grades macht vor allen Dingen Unfug zwischen den > Stützstellen. Jupp, hatte ich ja oben auch genauso geschrieben! Es ging in der Tabelle nur darum dass es rein nach Rechenzeit geht. Lookup ist oft sinnvoller, weil auch numerisch stabiler. Aber IMHO hat Linearisierung mittels float auch seine Berechtigung.
Am besten mit 128 Bit rechnen, sicher ist sicher. Auch wenn der ADC und DAC nur 8 Bit kann. Ohne eine Genauigkeitsabschätzung ist alle weitere Diskussion Mumpitz.
Peter D. schrieb: > Am besten mit 128 Bit rechnen, sicher ist sicher. Auch wenn der ADC und > DAC nur 8 Bit kann. Ironie klappt nie. Cheers Detlef
:
Bearbeitet durch User
Klaus H. schrieb: > Die Leistungsfähigkeit von 8 Bitter wird oft unterschätzt. (Und zum > Klarstellen: Ich bevorzuge 32Bit ARM Architekturen und keine 30Jahr > alten 8 Bit Schiebekisten). > Saubere Evaluation, stimmige Ergebnisse, THX. > Während Villarriba noch Lookup Tabellen implementiert, feiert Villabajo > schon das Ergebnis. Super, oder besser ultra. Kannte ich nicht, bau ich in meinen aktiven Wortschatz ein, obwohl ich ne Spülmaschine habe. Cheers Detlef
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.