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
Angehängte Dateien:
-
sensorwerte.png
17 KB
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).
:
Bearbeitet durch User
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?
*mit zu großer Schwingung meine ich, dass sie zu hochfrequent ist.. (evtl. vielleicht auch Erschütterungsanfällig)
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?
:
Bearbeitet durch User
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.
Angehängte Dateien:
-
messwerte.png
4,8 KB
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.
:
Bearbeitet durch User
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).
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
okay, ich danke euch schon mal für eure Hilfestellungen. Werde das ganze morgen mal testen und dann schauen.
Ich stoße bei der Sensorfusion der häufig auf stochastische Annäherungen mit dem Bayes-Theorem. Das wäre vermutlich nicht das Richtige, oder? ;)
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.
:
Bearbeitet durch User
oh je verdammt, wenn ich das alles mit dem theoretischen Hintergrund noch verknüpfen muss, wird das eine verdammt aufwändige Arbeit noch -.-
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... ;-)
:
Bearbeitet durch User
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?
Hallo! schrieb: > Der Prof liest hier heimlich mit! Und, wäre es verboten ein wenig darüber zu diskutieren? ;)
rickm schrieb: > [...] > was willst du denn noch für Informationen? Alle und jede. Das Wichtige sortiere ich dann aus.
Angehängte Dateien:
-
regler.png
21 KB
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).
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Es ist stabil und kann auch gegen Störungen (Stöße) ankommen. Allerdings verhalten sich die Motoren im Stand zu unruhig
Angehängte Dateien:
-
regler2.png
19 KB
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.
:
Bearbeitet durch User
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
Die Winkelgeschwindigkeit tritt nämlich nur im Motormodell auf und dient zur Modellierung der geschwindigkeitsabhängigen Reibung...
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.
:
Bearbeitet durch User
Angehängte Dateien:
-
Modell_urspruenglich.jpg
240 KB
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
mit Inetgralanteil von x meine ich den Regler für x ;)
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.
:
Bearbeitet durch User
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
Angehängte Dateien:
-
Vergleich.png
10 KB
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...
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.