|
|
|
Umstellung von variable auf fixed step size |
|
| Marc! |
Forum-Anfänger
|
 |
Beiträge: 14
|
|
|
|
Anmeldedatum: 22.04.15
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
 |
|
Verfasst am: 08.07.2015, 18:56
Titel: Umstellung von variable auf fixed step size
|
 |
| |
 |
 |
Hallo zusammen,
ich arbeite momentan an einer Fahrzeugsimulation in Simulink. Dies ist mein erstes Simulink-Projekt und daher stoße ich auf viele Probleme und mache vermutlich auch viele Fehler.
Das Modell funktioniert mit variable step size sehr zuverlässig und liefert auch plausible Ergebnisse. Jedoch benötigt die Berechnung eine halbe Ewigkeit. Das Ziel der Simulation soll es aber sein, schneller als Echtzeit zu simulieren. Daher habe ich die step size auf 0.008 s festgesetzt und die Simulationszeit auf den gewünschte Geschwindigkeit reduzieren können.
Die Simulation verfügt über eine simple Antriebsschlupfregelung, welche den Schlupf auf einen Zielwert durch Beeinflussung des Motormoments regelt. Mit variable step size funktioniert das auch super, mit der erwähnten fixed step size fängt der Schlupf jedoch unglaublich stark an zu schwingen.
Mein Problem ist nun, dass ich nicht weiß, wie ich das beheben kann. Ich habe schon erfolglos verschiedene Solver ausprobiert, jedoch ohne Erfolg - und Verstand. Eine Verringerung der Schrittweite verbessert die Situation geringfügig, steht jedoch auch wieder im Konflikt mit der Simulationszeit. Theoretisch müsste ich auch mit der Schrittweite 0.008 s plausible Ergebnisse produzieren können, da gängige Simulationsprogramme, wie CarMaker und Adams teilweise mit 0.01 s simulieren.
Ich hoffe, ihr könnt mir Anregungen und Tipps geben, wie ich das Problem in den Griff bekommen kann.
|
|
|
|
|
|
| Harald |
Forum-Meister
|
|
Beiträge: 24.492
|
|
|
|
Anmeldedatum: 26.03.09
|
|
|
|
Wohnort: Nähe München
|
|
|
|
Version: ab 2017b
|
|
|
|
|
|
|
Verfasst am: 08.07.2015, 19:14
Titel:
|
|
Hallo,
ohne das Modell zu sehen, ist es schwierig, Aussagen zu treffen.
Der variable-step Solver wählt allerdings Schritte, die gerade so groß sind, dass die Fehlertoleranz eingehalten wird. Wenn ode45 lange braucht, dann liegt das häufig an der "Steifigkeit" des Systems. Ich würde also mal ode15s oder ode23s versuchen. Mehr Infos zu den Solvern hier:
Ein Umstellen auf einen fixed-step Solver halte ich nicht für sinnvoll, da diese Schrittweite entweder sehr klein sein muss oder die Simulation recht ungenau wird, wie du ja selbst festgestellt hast.
Ein Problem kann natürlich immer auch ein Modellierungsfehler sein. Dazu kann man ohne das Modell aber nun wirklich gar nichts sagen.
Grüße,
Harald
|
|
|
|
| Marc! |
Themenstarter
Forum-Anfänger
|
|
Beiträge: 14
|
|
|
|
Anmeldedatum: 22.04.15
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 09.07.2015, 21:00
Titel:
|
|
Hallo,
vielen Dank für die schnelle Antwort. Ich habe verschiedene Solver durchprobiert, wobei die ode23er Fraktion deutlich schneller läuft, jedoch auch stark in der Schlupfregelung schwingt.
Ich bin ziemlich ratlos, wie ich weiter vorgehen soll. Ich finde es momentan auch sehr unwissenschaftlich nur irgendwelche Solver und Einstellungen auzuprobieren. Es gibt doch sicher eine sinnige Herangehensweise für solch ein Problem.
Muss ich bei meiner Reglerabstimmung auch was beachten, wenn ich zwischen verschiedenen Solvern und Schrittweiten wechsel?
Könnt ihr Literatur empfehlen, die eine eventuelle Vorgehensweise und Modellierungsfehler aufdeckt?
Das Ziel meines Modells ist es eine Parameter-Simulation sehr schnell durchzuführen und auch eine einzelne Simulation soll deutlich unter Echtzeit laufen. Ich weiß, dass es mit einem solchen Modell möglich ist, deutlich schneller als in Echtzeit zu simulieren.
Grüße,
Marc
|
|
|
|
| Harald |
Forum-Meister
|
|
Beiträge: 24.492
|
|
|
|
Anmeldedatum: 26.03.09
|
|
|
|
Wohnort: Nähe München
|
|
|
|
Version: ab 2017b
|
|
|
|
|
|
|
Verfasst am: 09.07.2015, 22:01
Titel:
|
|
Hallo,
| Zitat: |
| Es gibt doch sicher eine sinnige Herangehensweise für solch ein Problem. |
Ja, und ich hatte dich ja schon auf
doc ode45
verwiesen. Dort findest du eine schöne Übersicht zur Verwendung der einzelnen Solver.
Grüße,
Harald
|
|
|
|
| Andreas Goser |
Forum-Meister
|
|
Beiträge: 3.654
|
|
|
|
Anmeldedatum: 04.12.08
|
|
|
|
Wohnort: Ismaning
|
|
|
|
Version: 1.0
|
|
|
|
|
|
|
Verfasst am: 10.07.2015, 07:57
Titel:
|
|
Eine Meta-Frage ist auch was das Ziel des Ganzen ist. Eine Aufgabenstellung aus der Industrie vermutlich nicht. Alle Auto-Hersteller haben verschiedenste, grosse Fahrzeugmodelle seit vielen Jahren. Also vermutlich eine Aufgabe im Rahmen des Studiums. Da sollte es doch für den mathematisch - numerisch - regelungstechnische Betreuung geben. Selbst wenn der vom Tool keine Ahnung hat wäre das für mich eine natürliche Anlaufstelle.
Andreas
|
|
|
|
| Epfi |
Forum-Meister
|
|
Beiträge: 1.134
|
|
|
|
Anmeldedatum: 08.01.09
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 10.07.2015, 08:31
Titel:
|
|
| Marc! hat Folgendes geschrieben: |
| wobei die ode23er Fraktion deutlich schneller läuft, jedoch auch stark in der Schlupfregelung schwingt. |
Und Du bist Dir sicher, dass das nicht tatsächlich auch so der Fall ist? Schwingende Regler sind nicht sonderlich schwer herzustellen, so dass ich da den Fehler erst mal weniger beim Solver als bei der Parametrierung/Struktur des Reglers suchen würde...
|
|
|
|
| Marc! |
Themenstarter
Forum-Anfänger
|
|
Beiträge: 14
|
|
|
|
Anmeldedatum: 22.04.15
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 10.07.2015, 18:54
Titel:
|
|
| |
|
|
Die Simulation baue ich für das Formula Student Team meiner Uni auf. Auf allzu viel Unterstützung kann ich da leider nicht hoffen.
Ich habe mal die Ergebnisse der Schlupfregelung für verschiedene Solver angehaben. - Wobei Schlupfregelung hier etwas zu hochgegriffen ist: Der Betrachtete Regler, soll nur den Gasfuß des Fahrers darstellen, der vom Gas geht, wenn er merkt, dass die Räder zu viel schlupfen. Daher ist eine gewisse Abweichung des Schlupfes hier erlaubt.
Naja, wie man sieht, funktioniert die Regelung unter ode45 mit variable Stepsize gut. Bei einem anderen Solver mit variable Step und unter fixed Stepsize mit 0.008 s Schrittweite, läuft das leider schon ganz aus dem Ruder. Was auch auffällt, ist dass der Schlupf der Vorderräder, die frei abrollen bei der fixed Stepsize ebenfalls stark anfangen zu Schwingen und diese sind nicht geregelt.
Denkt ihr weiterhin, dass es sich um ein Problem des Reglers handelt?
| Beschreibung: |
|
Download |
| Dateiname: |
variable_ode45.JPG |
| Dateigröße: |
91.39 KB |
| Heruntergeladen: |
530 mal |
| Beschreibung: |
|
Download |
| Dateiname: |
variable_ode23s.JPG |
| Dateigröße: |
148.92 KB |
| Heruntergeladen: |
537 mal |
| Beschreibung: |
|
Download |
| Dateiname: |
fixed_0,008_ode3.JPG |
| Dateigröße: |
214.17 KB |
| Heruntergeladen: |
531 mal |
|
|
|
|
| Epfi |
Forum-Meister
|
|
Beiträge: 1.134
|
|
|
|
Anmeldedatum: 08.01.09
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 10.07.2015, 19:10
Titel:
|
|
| |
|
|
Der ode23 fährt wie mein Chef... binär :)
Das ist dann wohl wirklich eher der Solver. Was passiert denn, wenn Du beim ode45 die minimale Schrittweite auf 0.008 begrenzt? Dann sollte es ja so ähnlich aussehen.
Du könntest mal versuchen, das Modell zu linearisieren und gucken, wo die Eigenwerte so liegen. Ich tippe darauf, dass da der ein oder andere jenseits der 125Hz liegt. Die müsstest Du dann eliminieren, zum Beispiel durch Massenreduktionsverfahren (findet man u.a. in den Büchern von Hans Dresig).
Was ist eigentlich die Ziel-Hardware? Oder soll Dein PC das in Echtzeit berechnen? In der Regel laufen solche Programme, wenn sie für die Echtzeit-Hardware kompiliert wurden dann nochmal deutlich schneller.
Wenn überhaupt keine Aussicht besteht, dass es schneller werden könnte: Modell diskretisieren. Und wenn es dann immer noch zu lahm ist: Den automatisch generierten C-Code lesen, da lässt sich noch ein bisschen was rausholen, wenn man bestimmte Blöcke vermeidet.
|
|
|
|
| Harald |
Forum-Meister
|
|
Beiträge: 24.492
|
|
|
|
Anmeldedatum: 26.03.09
|
|
|
|
Wohnort: Nähe München
|
|
|
|
Version: ab 2017b
|
|
|
|
|
|
|
Verfasst am: 10.07.2015, 20:27
Titel:
|
|
Hallo,
noch ein Gedanke: mal die relative Toleranz bei ode23s und ode45 verringern, z.B. auf 1e-6 bzw. bis vergleichbare Ergebnisse herauskommen.. Die Ergebnisse sehen nämlich sehr unterschiedlich aus, d.h. ich habe ziemliche Zweifel, was das tatsächliche Systemverhalten angeht.
Grüße,
Harald
|
|
|
|
| Marc! |
Themenstarter
Forum-Anfänger
|
|
Beiträge: 14
|
|
|
|
Anmeldedatum: 22.04.15
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 11.07.2015, 08:17
Titel:
|
|
Vielen Dank für eure Tipps, ich werde sie mal ausprobiern und versuchen umzusetzten.
Ja die Ziel-Hardware ist mein PC oder später auch andere PCs/Laptops von meinen Teamkameraden.
|
|
|
|
| Marc! |
Themenstarter
Forum-Anfänger
|
|
Beiträge: 14
|
|
|
|
Anmeldedatum: 22.04.15
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 11.07.2015, 11:39
Titel:
|
|
Sorry, für den Doppelpost, habe keine Bearbeitungs-Funktion gesehen.
Also ich hab zum einem die Toleranzen für die verschiedenen variable-Solver reduziert. Von den ode23ern bekomme ich einzig den ode23t mit einer relativen Toleranz von 1e-8 stabil an laufen. Er wird dann allerdings seeeehr langsam.
Das festlegen der minimalen Schrittweite auf 0.008 oder sogar kleiner führt dazu, dass sich die Simulation in einem der ersten Schritte aufhängt. Das muss ich mir mal anschaunen.
Des Weiteren habe ich mein Fahrzeugmodell nun auf die reine Längsdynamik heruntergebrochen, um das Problem erstmal in einem weniger komplexen Umfeld zu untersuchen. Das reduzierte Modell liefert zum Vollfahrzeugmodell identische Ergebnisse, sodass diese Vereinfachung zulässig erscheint.
Ich werde mihc nun mal an der erwähnten Linearisierung des Models versuchen...
|
|
|
|
| Marc! |
Themenstarter
Forum-Anfänger
|
|
Beiträge: 14
|
|
|
|
Anmeldedatum: 22.04.15
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 12.07.2015, 19:39
Titel: Zustandsraum?
|
|
Ich bins nochmal,
bei meiner weiteren Lösungssuche und Literaturrecherche bin ich immer wieder über die Darstellung von Systemen im Zustandsraum gestolpert.
Mein Modell ist nicht im Zustandsraum dargestellt. Algebraische und Differential-Gleichungen sind mehr oder weniger unverändert in Simulink eingebaut.
Beispielsweise der Drallsatz:
Ich habe ein Momentengleichgewicht in einem Additionsblock, teile die Summe durch das Massenträgheitsmoment und erhalte die Drehwinkelbeschleunigung, welche ich in nächsten Schritt integriere, um die Drehzahl zu erhalten.
In wie fern ist es sinnvoll, das Modell in den Zustandsraum zu überführen? Kann das die Ursache des Problems sein? Bringt das einen Performance-Vorteil?
Ich meine das Modell funktioniert mit variable Step ja auch so, aber die Zustandsraum-Darstellung gibt es ja nicht aus Spaß 
|
|
|
|
| Epfi |
Forum-Meister
|
|
Beiträge: 1.134
|
|
|
|
Anmeldedatum: 08.01.09
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 13.07.2015, 08:46
Titel:
|
|
Die Zustandsraumdarstellung wurde erfunden, um Menschen zu quälen... ;-)
Vor allem setzen sehr viele Theorien der Regelungstechnik auf die Zustandsraumdarstellung. Letztendlich ist das nur ein strukturiertes Aufschreiben der Differenzialgleichungen, so, dass alle Parameter in Matrizen und Vektoren stehen. Das ist dann zum Rechnen ganz handlich.
Wenn Du Dein jetziges System in die Zustandsraumdarstellung überführen kannst, ist es schon linear. Dann kannst Du mal probieren, die Eigenwerte des Systems rauszufinden. Wenn Du die Control System Toolbox hast, gibt es in Simulink unter Analysis im Untermenü Control Design den Punkt Linear Analysis..., da kannst Du Dir alle möglichen Bilder malen lassen und unter anderem auch welche, die Dir die Eigenwerte verraten.
|
|
|
|
|
|
|
Einstellungen und Berechtigungen
|
|
Du kannst Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum posten
Du kannst Dateien in diesem Forum herunterladen
|
|
Impressum
| Nutzungsbedingungen
| Datenschutz
| FAQ
|  RSS
Hosted by:
Copyright © 2007 - 2024
goMatlab.de | Dies ist keine offizielle Website der Firma The Mathworks
MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, SimBiology, SimHydraulics, SimEvents, and xPC TargetBox are registered trademarks and The MathWorks, the L-shaped membrane logo, and Embedded MATLAB are trademarks of The MathWorks, Inc.
|
|
