Hallo, ich bin derjenige, der einen Tiefpassfilter auslegen möchte, weil
ich die Auflösung eines Gyro-Sensors (1°) ursprünglich verbessern
wollte.
Nun bin ich mir aber gar nicht mehr so sicher, ob das Problem die
Auflösung ist, ode ob evtl. eine Störung existiert. Ich würde gerne mal
Meinungen von euch dazu hören.
Kurz zusammengefasst: Der Gyro-Sensor von Lego gibt in digitaler Form
einmal den absoluten Winkelwert und dann noch die Ableitung aus. Ob der
Winkelwert dabei das Integral des Ableitungswertes ist, ist nicht ganz
bekannt. In manchen Artikeln steht, dass dort 2 Sensoren verbaut sind.
Das was man auf meinem Foto sieht, spricht meiner Meinung nach auch von
der Unabhängigkeit der beiden Werte.
Das System wird u.a mit den beiden Sensorwerten auf 0° geregelt
(inverses Pendel). Auf dem Foto links oben sieht man WÄHREND der
REGELUNG den Winkelwert (blau) und die Ableitung (rot). Dieses geregelte
System mit den reinen Sensorwerten ist sehr unruhig bzw. ruckelig, was
man auch im Spektrum vom Ableitungswert links unten sehen kann (Peak
zwischen 10 und 15 Hz)....
ich habe daher ein PT1-Glied ausgelegt auf die Eckkreisfrequenz 70 Hz
(also f ungefähr 11 Hz) und beide Sensorwerte für die Regelung
gefiltert.
Oben rechts und unten rechts sieht man die REINEN Sensorwerte und das
Spektrum bei Filterung der Werte für die Regelung. Es zeigt sich
deutlich, dass das Verhalten ruhiger ist, wobei allerdings auch der
erste Peak unter 5 Hz hier seltsamerweise geschwächt wird..
Nun versuche ich die Ursache herauszubekommen. Habe ich nun einfach nur
die Auflösung verbessert oder könnte es sein, dass der Ableitungswert
störbehaftet ist (er fängt beispielsweise am Anfang schon an zu
schwingen, obwohl der WInkel sich nicht ändert)? Das könnte gut sein,
denn die Leitungen von Sensoren und Motoren verlaufen nahe beieinander
und dadurch könnten diese Freqeunzen auftreten...
Wäre für jede Hilfe und Mienung unendlich dankbar
Ich glaube du hast dein Regelsystem "totgefiltert".
Vermutlich liegt die Verbesserung genau im umgekehrten Ansatz: deine
Regelung muss schneller werden.
Dann werden die Korrekturbewegungen kleiner und das System sieht
"ruhiger" aus.
Und dazu kann dir der Beschleunigungswert helfen, da er eine
"Vorhersage" einer Winkeländerung ermöglicht (D-Anteil beim PID Regler).
ich habe die Regelung natürlich am Anfang versucht zu verbessern, aber
die ruckartige Bewegung der Stellgröße ist geblieben.
Mir ist noch ein anderer Gedanke gekommen: Man sieht auf dem Bild links
oben ziemlich deutlich, dass der Sensorwert der Ableitung (rot)
weiterhin schwingt, obwohl sich der Winkelwert selbst nicht verändert.
Könnte es vielleicht einfach sein, dass die Schwingung vom Winkel
einfach nur innerhalb der 1° stattfinden, sodass das nicht aufgelöst
werden kann? In dem Fall würde es doch dafür sprechen die Auflösung
durch Tiefpassfilterung zu verbessern, oder?
Ich muss für meine Ausarbeitung eine gute Begründung für das Vorgehen
finden^^
rickm schrieb:> In dem Fall würde es doch dafür sprechen die Auflösung> durch Tiefpassfilterung zu verbessern, oder?
Nein, die Filterung verbessert die Auflösung ja nicht. Aber sie
verzögert die Reaktion.
Mir sieht es auch so aus, als ob der Beschleunigungssensor wesentlich
empfindlicher und hochauflösender ist.
Das spricht umso mehr dafür, diesen Sensorwert in die Regelung
einfließen zu lassen.
Bzw. die Regelung hauptsächlich auf diesen Sensorwert auszulegen, und
den Winkelsensor nur zum Absolutabgleich einfließen zu lassen.
Ex Kollege von mir hat mal mit einem Gyro probiert einem Messfehler auf
die Schliche zu kommen welches wir in Vibrationen vermuteten.
Es war interessant zu sehen, was der Gyro in den unteren Bits so ausgibt
wenn er einfach nur auf einem Tisch liegt.
Gebäude schwingen halt auch, und natürlich kann man das messen.
Vielleicht ist dein Signal also echt und keine Störung.
die Auflösung wird doch insofern verbessert, dass kleinere Stufen
entstehen. Anschaulichstes Beispiel wäre ein einfacher Mittelwertfilter.
Wenn ich den Tiefpass draufgebe, dann wird aber auch die Störausregelung
durch den Integralanteil besser! Da stimmt doch was mit dem
Ableitungssensor nicht... Wenn ich seine Frequenzen reduziere, wird die
Regelung zuverlässiger
ich habe mir auch gerade nochmal das Modell (aufgestellt nach Lagrange)
genauer angesehen. Also In der Gleichung für die zweite Ableitung des
Winkels (System ist ursprünglich eine Differentialgleichung zweiter
Ordnung) geht der absolute Winkel fast um das 20 fache stärker ein als
die Ableitung.
demnach- weil der Geschwindigkeitssensor die bessere Auflösung hat- wäre
es vielleicht sogar ganz gut, wenn man den reinen Messwert davon nehmen
würde und statt des originalen Winkelwerts das Integral aus dem
Geschwindigkeitswert berechnet, oder?
Vermutlich. Allerdings haben Gyros in der Regel einen Drift und das wird
durch Integrieren der Beschleunigungswerte nicht besser.
D.h. du bräuchtest noch irgend einen Sensor, der den Winkel auch über
längere Zeit genau und ohne Drift bestimmen kann. Sonst kippt dein
Pendel irgendwann.
ich habe mit MatLab mal die Geschwindigkeitswete genommen und sie nach
Trapezregel unter Berücksichtigung der Abtastzeit diskret integriert.
Dabei fällt auf, dass die maximalen Auslenkungen der berechneten Winkel
WESENTLICH kleiner sind als die der gemessenen Winkel... Ich werde
morgen mal prüfen, wie das Verhalten des Pendels in dem Fall ist.
Ich trete derzeit auf der Stelle und komme einfach nicht weiter. Durch
Veränderung der Pole des Regelkreises kann ich jedenfalls das Ruckeln
nicht wegbekommen. Ich muss nun eine anständige Begründung für die
Ausarbeitung finden.
Wenn ich sage, dass ich beide Sensoren für die Regelung auf "eine
Auflösung/ ein Niveau" bringen möchte und dass die Schwingungen der
Geschwindigkeit offenbar zu groß sind (weil die Integrale zu klein
sind), wäre das dann nicht vielleicht schon eine ordentliche Begründung
für die Tiefpassfilterung?
wenn das abtastinterval immer gleich ist erleichtert das das integrieren
(einfach aufsummieren).
vermutlich musst du dein integral eben noch mit einem faktor skalieren,
damit der winkel stimmt.
wie gross und schwer ist denn dein pendel in etwa?
Hugo H. schrieb:> Welchen hast Du denn?
Die genaue Bezeichnung ist ja nur für die Kalibrierung relevant. Ich
hatte damals die selbe Seite aufgerufen und geschaut. Ich meinte, es war
einer der neueren (N5 wenn mich nicht alles täuscht, habe ihn aber
gerade nicht vor mir liegen)... Er definiert seinen Nullpunkt immer neu
zum Programmstart, daher ist die Kalibrierung nicht notwendig
Joe F. schrieb:> vermutlich musst du dein integral eben noch mit einem faktor skalieren,> damit der winkel stimmt.
Nun ja, die Geschwindigkeitswerteerte sind in rad/s und die Teitachse
ist in s aufgetragen.
Wenn ich also das Integral diskret berechne mit:
Integral[neu]=Integral[alt]+ 0.01*
(winkelgeschwindigkeit[neu]+winkelgeschwindigkeit[alt])/2 müsste doch
die Skalierung eigentlich korrekt sein, oder nicht?
Joe F. schrieb:> wie gross und schwer ist denn dein pendel in etwa?
Gesamt 0.83 kg und Abstand Radachse- Schwerpunkt etwa 14 cm. Gesamthöhe
kommt etwa auf 22 cm.
okay, ich hatte noch einen kleinen Fehler drin. Also gemessener Winkel
(rot) und aus blau berechnete Integrale (orange) sehen im Vergleich so
aus (Foto)
Um trotzdem noch beide Sensorwerte zur Absicherung zu benutzen, könnte
ich ja auch vielleicht sagen:
Die Differenz "gemessener Winkelwert" und "berechneter Winkelwert" darf
zu keinem Zeitpunkt größer als ein definierter Wert sein. Wenn die
Differenz zu groß wird, verwendet man stattdessen den gemessenen Wert...
wäre das eine Möglichkeit? In jedem Fall schaffe ich es ja so, die
Winkelauflösung zu verbessern
rickm schrieb:> okay, ich hatte noch einen kleinen Fehler drin. Also gemessener Winkel> (rot) und aus blau berechnete Integrale (orange) sehen im Vergleich so> aus (Foto)
Aha, das sieht doch sehr gut aus.
Wie man sehen kann reagiert deine aus den Beschleunigungen integrierte
Winkelinformation sehr viel früher und hat eine höhere Auflösung.
Die 15 Hz sind aber in der Tat seltsam, denn wenn man das Pendel
umdrehen würde, käme eine Pendel-Frequenz von etwa 1,3 Hz raus.
Sind die 15 Hz die Frequenz deiner Regel-Schleife?
Was für eine Einheit hat denn deine x-Achse in den Diagrammen?
rickm schrieb:> Wenn die> Differenz zu groß wird, verwendet man stattdessen den gemessenen Wert...> wäre das eine Möglichkeit?
Nicht wirklich, denn dann schwenkt deine Messung irgendwann von deinem
Integral auf den anderen Messwert um.
Besser wäre es die Differenz beider Werte tiefpassgefiltert in die
Integralbildung rückzukoppeln, so dass du dein Integral immer langsam an
den anderen Sensor-Wert annäherst und so den Fehler minimierst.
Nützt natürlich nichts, wenn auch der andere Sensorwert (Winkel)
langfristig driftet.
rickm schrieb:> Kurz zusammengefasst: Der Gyro-Sensor von Lego gibt in digitaler Form> einmal den absoluten Winkelwert und dann noch die Ableitung aus. Ob der> Winkelwert dabei das Integral des Ableitungswertes ist, ist nicht ganz> bekannt.
Da der Sensor für den Winkel eine Genauigkeit von +/-3 Grad besitzen
soll, kann der Winkel nicht alleine aus der Integration der Drehrate vom
Gyro bestimmt werden. Da muss noch ein Winkelsensor drin sitzen, sonst
würde der Winkel mit der Zeit wegdriften.
Joe F. schrieb:> Sind die 15 Hz die Frequenz deiner Regel-Schleife?> Was für eine Einheit hat denn deine x-Achse in den Diagrammen?
Die 15 Hz müsstne in jedem Fall die ruckartige Bewegung sein, die
entsteht, wenn ich die Sensorwerte ungefiltert für die Regelung
verwende. Das kann ich aber durch Änderung der Pole wie gesagt nicht
beheben. Es sollte doch die unterschiedliche Auflösung der Sensorwerte
sein, oder? Zumal der Wert für den reinen Winkel wesentlich stärker
gewichtet im Modell eingeht
Die x-Achse ist die verstrichene Zeit in Sekunden
Wolfgang schrieb:> Da der Sensor für den Winkel eine Genauigkeit von +/-3 Grad besitzen> soll, kann der Winkel nicht alleine aus der Integration der Drehrate vom> Gyro bestimmt werden.
Diese Ungenauigkeit hat sich bisher nicht bestätigt. Bisher sind bei der
Beobachtung immer nur 1 Grad-Sprünge aufgetreten
Joe F. schrieb:> Besser wäre es die Differenz beider Werte tiefpassgefiltert in die> Integralbildung rückzukoppeln, so dass du dein Integral immer langsam an> den anderen Sensor-Wert annäherst und so den Fehler minimierst.
klingt nicht schlecht^^
wie würde das dann etwa aussehen und welche wissenschaftlichen
Grundlagen könnte ich dafür erwähnen? Irgendetwas aus der Messtechnik
evtl.?
rickm schrieb:> Die 15 Hz müsstne in jedem Fall die ruckartige Bewegung sein, die> entsteht, wenn ich die Sensorwerte ungefiltert für die Regelung> verwende.
Wie sieht denn dein Regler aus?
Für mich ist nicht erklärbar, warum der Motor mit 15 Hz (bzw. eher 12
Hz) hin- und her-ruckeln sollte, in Zeitabschnitten in denen sich der
blaue Sensorwert (Winkel) nicht verändert.
So sieht es aber in den Diagrammen aus (heftige
Beschleunigungsausschläge in beide Richtungen).
Joe F. schrieb:> Für mich ist nicht erklärbar, warum der Motor mit 15 Hz (bzw. eher 12> Hz) hin- und her-ruckeln sollte, wenn sich der blaue Sensorwert nicht> verändert.
Die Stellgröße reagiert aber tatsächlich sofort auf die Ableitung. Es
liegt daran, dass hier noch ein Motormodell mit integriert ist, denn die
Motoren von Lego lassen sich nicht über Drehmomente ansteuern, sondern
eine prozentuale Größe bzgl. der vollen Laufleistung. Und in diesem
Modell ist u.a. die Geschwindigkeit relevant und da spielt eben auch die
Ableitung des Winkels (neben der Ableitung des Motordrehgebers) eine
Rolle... es ist eine Zustandsrückführung
Tja, alles irgendwie recht undurchschaubar.
Jedenfalls schwingt der Regler aus irgendeinem Grund. Und das muss man
zu aller erst mal in den Griff kriegen bzw. abstellen.
Danach kann man sich an Optimierungen des Eingangssignals machen.
wieso denn Optimierung des Eingangssignals? Oder meinst du damit die
Sensorwerte? Die sind doch das Problem des Ganzen. Tatsächlich habe ich
gar nicht mehr so viel Zeit und habe das Gefühl, ich drehe mich bei dem
Thema nur im Kreis und komme überhaupt nicht voran.
In der Praxis funktioniert jedenfalls der Tiefpassfilter einwandfrei.
Ich schaue morgen, wie es aussieht, wenn ich die berechneten Integrale
draufgebe. Wenn das funktioniert, dann muss es ja an den verschiedenen
Auflösungen der Sensorwerte liegen...
...bzw eben an der geringeren Steilheit deines selbst integrierten
Signals.
Ja, sowas kann man nur am "lebenden Objekt" testen.
Evtl. hilft es ja auch, das Eingangssignal einfach etwas abzuschwächen.
rickm schrieb:> wie würde das dann etwa aussehen und welche wissenschaftlichen> Grundlagen könnte ich dafür erwähnen?
sensor fusion
Keine Ahnung, ich bin nicht so sehr der Theoretiker, mehr der Praktiker
;-)
In der Praxis würde ich das so lösen (vorausgesetzt der Winkelsensor hat
keinen Langzeit-Drift):
Winkelsensor-Information tiefpassfiltern,
Beschleunigungs-Information integrieren und dann hochpassfiltern,
beides addieren (und ggf. durch 2 teilen).
Für die Filter würde ich aus dem Bauch heraus eine Grenzfrequenz von <1
Hz (vllt. 0.1 Hz, vllt. auch noch niedriger) wählen, davon ausgehend,
dass der Drift deines Integrals gering ist.
Das hochpassfiltern eliminiert den Drift des Gyros, du hast aber
trotzdem noch ein "schnelles" Eingangssignal.
Durch das tiefpassfiltern des Winkelsensors erreichst du eine deutlich
"weichere" Signaländerung, die deinen Regler nicht so sehr zum Schwingen
anregt.
Beides zusammen könnte ein recht brauchbares Eingangssignal ergeben.
Ohne Arbeit kein Erfolg... ;-)
Das von dir vorgestellte Problem ist allerdings tatsächlich sehr
interessant, da solche Probleme in der Praxis sehr häufig vorkommen
(Luftfahrt, Automobilbranche, Navigation, Quadcopter etc.).
Du hast einen Sensor, der schnell und hochauflösend ist (Beschleunigung)
aber vermutlich drifted.
Um den Drift wegzubekommen nutzt du dann einen zweiten Sensor, der
allerdings Nachteile hat (geringe Auflösung).
Wer die Kunst beherrscht daraus jetzt ein nicht driftendes,
hochauflösendes Signal zu machen wird in Zukunft ein gefragter Mann
sein... ;-)
rickm schrieb:> oh je verdammt, wenn ich das alles mit dem theoretischen Hintergrund> noch verknüpfen muss, wird das eine verdammt aufwändige Arbeit noch -.-
Ich vermute, dass genau das von Dir erwartet wird.
Hast Du den Sensor überhaupt mal zerlegt und getestet?
Steht definitiv fest, dass der absolute Winkel von einem eigenen Sensor
gemessen wird oder ist das nur ein im Sensor aus der Drehrate
berechneter Wert? Ich denke nämlich, dass letzteres der Fall ist.
rickm schrieb:> Diese Ungenauigkeit hat sich bisher nicht bestätigt. Bisher sind bei der> Beobachtung immer nur 1 Grad-Sprünge aufgetreten
Die Höhe von irgendwelchen Sprüngen hat nichts mit der Genauigkeit zu
tun, sondern könnte der Auflösung des Sensors entsprechen, falls die
Sprünge denen von Einzelmessungen entsprechen.
p.s. Deinen Graphiken fehlt die Einheit und ich mag jetzt nicht den
ganzen Thread auf irgendeinen Hinweis absuchen.
Theor schrieb:> Steht definitiv fest, dass der absolute Winkel von einem eigenen Sensor> gemessen wird oder ist das nur ein im Sensor aus der Drehrate> berechneter Wert? Ich denke nämlich, dass letzteres der Fall ist.
Nein, leider gibt Lego darauf keine Hinweise. Suche schon sehr lange
nach einem vernünftigen internen Aufbau des Ganzen..
Aber wenn man die integrierten Werte mit den gemessenen vergleicht,
fällt auf, dass sie durchaus im Verhalten übereinstimmen und der
digitale Schwellenwert bei ziemlich genau 0,5 ° liegt..
Wolfgang schrieb:> Deinen Graphiken fehlt die Einheit und ich mag jetzt nicht den> ganzen Thread auf irgendeinen Hinweis absuchen.
Auf der x-Achse ist in den beiden oberen Bildern die Zeit [in s]
aufgetragen und auf der y-Achse der Winkel [in rad] bzw. die
Winkelgeschwindigkeit [in rad/s]
bei den Bildern unten die Frequenzen auf der x-Achse und auf der y die
FFT normiert auf die Anzahl der Daten
rickm schrieb:> Theor schrieb:>> Steht definitiv fest, dass der absolute Winkel von einem eigenen Sensor>> gemessen wird oder ist das nur ein im Sensor aus der Drehrate>> berechneter Wert? Ich denke nämlich, dass letzteres der Fall ist.>> Nein, leider gibt Lego darauf keine Hinweise. Suche schon sehr lange> nach einem vernünftigen internen Aufbau des Ganzen..> Aber wenn man die integrierten Werte mit den gemessenen vergleicht,> fällt auf, dass sie durchaus im Verhalten übereinstimmen und der> digitale Schwellenwert bei ziemlich genau 0,5 ° liegt..
Nun, möglicherweise muss man in diesem Fall detaillierter vorgehen um
aussagekräftige Informationen zu gewinnen. Man könnte das Maß der
"Übereinstimmung im Verhalten" und den Schwellwert einmal formal
ausdrücken und messen bzw. berechnen. Ebenso die Auswirkungen von
Auflösung und Genauigkeit.
Ich habe so den Eindruck - eher zwischen den Zeilen lesend, als aus
rationalen Gründen -, dass Du das Ding so einigermaßen am laufen hast
und denkst, man müsste jetzt nur noch eine Kleinigkeit drehen, damit es
läuft.
Ich vermute, Du irrst Dich darin und Dir steht noch viel Arbeit bevor,
weil Du wesentliche Analysen unterlassen hast.
Ich schlage vor, dass Du Dich entweder mit Deinen Kommilitonen oder
Deinen Tutoren/Profs/etc. besprichst oder hier eine wesentlich
umfangreichere Darstellung postest aus der auch Deine Vorgehensweise
deutlich wird.
Irgendwie bin ich hier am herumraten und soweit ich das beurteilen kann,
sind die fundierten Beiträge der Anderen hier mehr oder weniger
plausibel ausgewählte Hypothesen aber keine Lösungen, die auf
eindeutigen und vollständigen Angaben beruhen.
ich habe doch ziemlich viel Zeit verbracht, hier so viele Infomationen
wie möglich zu liefern. Ich habe für umfangreiche Analysen leider keine
Zeit mehr. Ich musste in dieser Arbeit eine Menge programmieren und
Soll-Trajektorien aufgeben. Bisher wurde alles mit einem gleitenden
Mittelwert über die Daten gelöst, wodurch es in der Praxis auch
funktionierte. Der Prof. wollte bei einem Zwischenvortrag aber diese
Filterung besser beschrieben haben, also habe ich die Auslegung mit dem
PT1-Glied gemacht.
Nun bin ich dabei eben auf diese neuen Erkentnisse gekommen und versuche
jetzt so plausibel wie möglich das Ganze zu erklären...
was willst du denn noch für Informationen?
rickm schrieb:> wodurch es in der Praxis auch funktionierte.
Es funktioniert halt irgendwie, aber eben nicht richtig gut.
Natürlich ist das jetzt sehr stressig für dich zu einem so späten
Zeitpunkt festzustellen, dass es durch Filtern des Eingangssignals nicht
wirklich "gelöst" ist, aber ich empfehle dir trotzdem, nochmal genauer
auf den Regler zu gucken.
Auch mit dem niedriger auflösenden Eingangssignal (Winkel) müsste ein
gut eingestellter Regler klarkommen, ohne sich aufzuschwingen (was er im
Moment tut).
Das Pendel würde 1-2° kippen, dann erst würde der Motor reagieren, einen
kleinen Sprung zur Seite machen und dann auch wieder still stehen.
Die Schwierigkeit ist eben, den Regler so einzustellen, dass die
Motor-Bewegung das Pendel genau wieder gerade stellt. Momentan schießt
der Motor heftig über das Ziel hinaus, fährt dann wieder zurück und so
weiter. Dadurch kommt das Zittern mit 12 Hz zustande.
Im Anhang mal in orange eingezeichnet, wie die Reaktion des Reglers
aussehen sollte, wenn er richtig eingestellt wäre:
Das Pendel fängt an zu kippen, der Winkelsensor (blau) meldet die
Kippbewegung, der Motor korrigiert (Beschleunigung wird positiv und geht
dann wieder auf 0 zurück).
Das Mysteriöse dabei ist, dass das System in der Simulation sogar
schafft jeden Sprung in der Führungsgröße (selbt ohne Integralanteil)
stationär genau auszuregeln
Tja.
Theors Satz #1: "Jedes hinreichend ungenau oder lückenhaft beschriebene
System zeigt unerklärliches Verhalten."
:-)
Ich denke Du musst da erstmal einen inneren Widerstand überwinden. Das
ist manchmal nicht einfach.
Naja. Ich will Dich nicht weiter triezen. Aber helfen kann ich dann auch
nicht. Bin dann raus. Vielleicht kriegst Du es ja doch noch hin.
rickm schrieb:> Das Mysteriöse dabei ist, dass das System in der Simulation sogar> schafft jeden Sprung in der Führungsgröße (selbt ohne Integralanteil)> stationär genau auszuregeln
...und am realen Modell eben nicht. Das zeigt nur, dass das
Simulationsmodell nicht 100% mit der Realität übereinstimmt.
Der Regler, der mit deinem simulierten Modell stabil funktioniert,
schiesst dann eben am realen Modell über bzw. fängt an zu oszillieren
und du musst jetzt den Parameter finden, der dafür verantwortlich ist.
Dabei ist sehr wahrscheinlich, dass es nicht am Eingangssignal (Winkel)
liegt... ;-)
Bei einem PID Regler führt ein zu groß gewähltes kp schnell zu
Oszillation.
rickm schrieb:> Es ist stabil
Wie kommst du darauf?
Man sieht doch, wie das Ding oszilliert und sich die Amplitude der
Schwingung solange aufbaut, bis der Winkelsensor den Motor zu einem
größeren Schritt veranlasst.
Dadurch wird die Oszillation kurz gestört, baut sich dann aber wieder
auf.
Das würde ich nicht "stabil" nennen.
Vielleicht kannst du ja mal versuchen, den Verstärkungsgrad des Reglers
ein paar Prozent zu reduzieren.
wobei das Problem wahrscheinlich damit zusammenhängt, dass der
Geschwindigkeitszustand im Model eben nur mit Faktor -4 in die Gleichung
für die zweite Ableitung vom Winkel eingeht. Der Winkel selbst
allerdings mit Faktor 75. Das würde ja durch die Integration verbessert
werden. Ich werde s mir morgen angucken
rickm schrieb:> wobei das Problem wahrscheinlich damit zusammenhängt, dass der> Geschwindigkeitszustand im Model eben nur mit Faktor -4 in die Gleichung> für die zweite Ableitung vom Winkel eingeht. Der Winkel selbst> allerdings mit Faktor 75. Das würde ja durch die Integration verbessert> werden. Ich werde s mir morgen angucken
Ja, teste mal am realen Modell.
Dein Regler ist für uns momentan eine Blackbox, die nur dir bekannt ist,
insofern kann man ja hier ja nur recht sinnlos spekulieren.
Nachdem sich ja die Winkelinformation nicht ändert, und der Motor
trotzdem oszilliert glaube ich eher dran, dass es am "Faktor -4" für die
Geschwindigkeit liegt (zu viel).
Bin auf jeden Fall gespannt, was am Ende dabei rauskommt und hoffe du
hältst uns auf dem Laufenden.
Ich zeige euch hier mal das lineare Modell zuerst ohne Motormodell mit
Drehmoment Tau und dann mit dem Motormodell, was für die Lego-Motoren
erforderlich ist...
Das ist noch ein vereinfachtes System mit einer Stellgröße, die auf
beide Motoren gleichzeitig aufgegeben wird. Im späteren System kommt
dann noch ein Gierwinkel des Pendels dazu, der aber für das Problem hier
keine Rolle spielt.
x ist dabei die Position des Rades, während es eine gerade Linie fährt
und ist unter anderem vom Neigungswinkel Alpha und dem Drehgebrwinkel
des Motors abhängig.
x bekommt dann bei mir noch einen Integralanteil (hier auf dem Bild
nicht berücksichtigt), somit entsteht dann noch ein 5. Zustand
Eine mögliche Zustandsrückführung wäre hier
K=[-28.2088 ,-284.2366 ,-337.3221 , -46.5210]
Für K aber keine Garantie, dass es so optimal ist, weil ich nur noch mit
dem erweiterten System gearbeitet habe ;)
Hoffe, ich konnte noch ein paar Infos bringen, die vielleicht relevant
sind
Das Ruckeln ist auch drauf, wenn man die Werte integriert, allerdings
etwas verbessert. Da der Sensor- auch wenn man ihn langsam mit der Hand
hin und herbewegt- unerwünschte hohe Frequenzanteile hat, müsste es in
jedem Fall Sinn machen ihn tiefpasszufiltern...
Beim Vergleich der integrierten Werte mit den gemessenen Winkelwerten
fällt allerdings auf, dass sich allmählich ein Drift bildet und sie sich
voneinander entfernen. Es ist laut einer Website so, dass der Sensor,
wenn er sich am Anfang kalibriert, automatisch seinen Drift bestimmt und
ihn für laufende WINKELmessungen als Offset draufgibt. Demnach habe ich
in meinen integrierten Geschwindigkeitswerten natürlich keinen Offset
mehr drin...
Von daher wird es nun vermutlich so laufen, dass ich die Sensorwerte
tiefpassfiltere und mit den integrierten ungefilterten ODER den
integrierten gefilterten Werten hochpassgefiltert zusammen addiere...
Also Sensorwerte tiefpassfiltern wegen Ruckeln und Integralwerte
hochpassfiltern wegen Drift. dann wäre ich bei der Sensorfusion
angekommen
Du hast doch wenn ich es richtig verstehe 2 Winkelsensoren.
Einen für's Pendel und einen für den Wagen (Radwinkel). Mir drängt sich
mehr und mehr der Verdacht auf, dass du an der falschen Stelle
rumdoktorst und die Oszillation eigentlich von der Motorregelung
herrührt und nicht vom Pendelsensor.
Du könntest ja mal versuchen, den Einfluß des Radwinkels zu reduzieren,
also statt
x = (α + γ) * r
x = α * r1 + γ * r2
zu verwenden, und r2 < r1 zu machen.
Ja, das probiere ich auch noch mal. Wobei der Integrierte Winkelsensor
vom Motor auch nur eine Auflösung von 1 Grad hat. Die sind beide auf dem
selben Niveau
Ich habe nun noch ein recht aussagekräftiges Experiment ausgewertet. Die
Vermutung, dass die Motoren die Sensorsignale beeinflussen, besteht
schon etwas länger. Die Leitungen liegen nämlich nahe beieinander.
Nun habe ich das Pendel mal in der Luft gehalten und einmal ohne
anlaufende Motoren und das andere Mal mit Motoren hin und her geschwenkt
und zwischendurch mal kurz ruhig gehalten, was hier in den Ausschnitten
zu sehen ist.
Man sieht ganz klar, dass bei laufenden Motoren die
Winkelgeschwindigkeitswerte (orange) deutlich stärker schwingen, während
der absolute WInkel (blau) in Ruhe ist. Ich würde das ganz klar als
Störeinfluss der Motoren sehen...
sensorwerte.png
(17 KB)
