Optimale Steuerung mit fmincon

WICHTIG: Der Betrieb von goMatlab.de wird privat finanziert fortgesetzt. - Mehr Infos...

Partner:

Forum

Option

[Erweitert]

• Diese Seite per Mail weiterempfehlen

Gehe zu:

bronsco

Forum-Anfänger


	Beiträge: 35

	Anmeldedatum: 06.07.10

	Wohnort: ---

	Version: ---

Verfasst am: 28.05.2011, 16:53 Titel: Optimale Steuerung mit fmincon

Hallo zusammen!

Ich habe folgendes Problem:

Gegeben ist ein nichtlineares dynamisches zeitinvariantes System mit den Zuständen x und einem Eingang u, welcher jedoch von einem bestimmten Zustand abhängt und in diesem zeitveränderlichen Zustand verschiedene Werte innerhalb einer bestimmten Grenze annehmen kann (siehe Bild im Anhang). Der jeweilige Wert von u soll durch eine optimale Steuerung bestimmt werden.

Mittels fmincon soll nun eine optimale Steuerung entworfen werden, die eine bestimmte Zielfunktion minimiert. Optimierungsparameter sind also die Einträge des Vektors u, dessen Größe von der fixed-step-Integrationsschrittweite abhängt.

Mein Problem bezieht sich nun auf die dafür benötigte Rechenzeit! Dies resultiert vermutlich aus der Definition der nichtlinearen Constraints (c = [c1; c2; c3] <=0), welche ich folgendermaßen angegeben habe:

1) Definition des I. und III. Quadranten:

Code:

c1 = - u .* x; %(-> also u*x ist immer >= 0)

Funktion ohne Link?

2) Mit der Bedingnung 1) habe ich die Grenzen so definiert:

Code:

c2 = abs(u) - abs(umax);
c3 = abs(umin) - abs(u);

Funktion ohne Link?

Die benötigte Rechenzeit ist aber unglaublich lang (sogar wenn man nur unter c1 minimiert)! Kann man das Problem auch noch irgendwie anders formulieren? Rechenzeiteinsparung werde ich wohl noch mit der Angabe von Gradienten und Hesse-Matrix erreichen können, bloß wird das nicht zufriedenstellend sein...

Vielen Dank schonmal für eure Hilfe!

Viele Grüße

u(x).jpg

Beschreibung:

Download

Dateiname:

u(x).jpg

Dateigröße:

22.88 KB

Heruntergeladen:

1053 mal

Harald

Forum-Meister


	Beiträge: 24.495

	Anmeldedatum: 26.03.09

	Wohnort: Nähe München

	Version: ab 2017b

Verfasst am: 28.05.2011, 17:10 Titel:

Hallo,

ohne eine konkretere Schilderung des Problems wird man dir kaum helfen können. Zumindest solltest du sagen, wie du dein System simulierst. Mit Simulink oder MATLAB direkt?
Was ist denn für dich eine "unglaublich lange Rechenzeit"?

Grüße,
Harald

bronsco

Themenstarter

Forum-Anfänger


	Beiträge: 35

	Anmeldedatum: 06.07.10

	Wohnort: ---

	Version: ---

Verfasst am: 28.05.2011, 18:53 Titel:

okay, sorry, war vielleicht alles doch etwas zu "qualitativ"...

Zu den Rahmenbedingungen: Matlab R2009b 64-bit, 3.2 GHz (4 Kerne), 8 Gb RAM

Die Rechenzeiten betragen nur mit c1 ca. 3 Minuten und mit allen Constraints mehrere Stunden (wie lang weiß ich nicht genau, da es nach ca. 60000 Iterationen immer noch kein Ergebnis gibt). Das Problem an den Rechenzeiten ist, dass für jede Anfangsbedingung in einem diskretiserten Zustandsraum die optimale Steuerung berechnet werden soll, damit man schließlich zu einer Regelung übergehen kann.

Die Simulation läuft derzeit in Matlab mit einem diskreten linearen Modell ab. Ich denke mal, dass die Simulation eines nichtlinearen kontinuierlichen Systems durch die Funktionsaufrufe des Fixed-Step-Integrators noch länger dauern werden.

Würde man den Eingang nur mit einer oberen/unteren Schranke (lower/upper bound ub/lb) begrenzen, dann gäbe es nicht das geringste Problem. Leider besteht aber diese Verknüpfung mit einem aktuellen Zustand...

Kann es durch die Verwendung der "abs"-Befehle in den Constraints zu Problemen kommen?

Harald

Forum-Meister


	Beiträge: 24.495

	Anmeldedatum: 26.03.09

	Wohnort: Nähe München

	Version: ab 2017b

Verfasst am: 28.05.2011, 19:42 Titel:

Hallo,

wenn du mit linearen Nebenbedingungen auskommst, wird das sicher schneller sein als mit nichtlinearen.
Was immer hilft, sind möglichst gute Startwerte. Wenn du also über ähnliche Punkte iterierst, hilft es wahrscheinlich, wenn du den vorherigen Endwert als Startwert für die neue Optimierung nimmst.

Grüße,
Harald

bronsco

Themenstarter

Forum-Anfänger


	Beiträge: 35

	Anmeldedatum: 06.07.10

	Wohnort: ---

	Version: ---

Verfasst am: 29.05.2011, 11:01 Titel:

Harald hat Folgendes geschrieben:

Was immer hilft, sind möglichst gute Startwerte. Wenn du also über ähnliche Punkte iterierst, hilft es wahrscheinlich, wenn du den vorherigen Endwert als Startwert für die neue Optimierung nimmst.

Ja, das ist eine gute Idee, danke! Bloß muss dafür erstmal die Lösung für eine Anfangsbedingung der Zustände schneller werden.

Das blöde ist halt hierbei, dass meine Optimierungsparameter (Einträge von u) sich nach einem Zustand "richten" müssen...

Harald

Forum-Meister


	Beiträge: 24.495

	Anmeldedatum: 26.03.09

	Wohnort: Nähe München

	Version: ab 2017b

Verfasst am: 29.05.2011, 17:48 Titel:

Hallo,

ich sehe offen gesagt nur zwei Möglichkeiten:
a) du versuchst selbst, mit dem Profiler die langsamen Stellen des Codes zu identifizieren und zu beheben.
b) anstatt Beschreibung dessen, was du machst, wirklich Code zur Verfügung stellen. Du kannst ja das eigentliche Modell durch ein Dummy-Modell ersetzen, wenn du das nicht zur Verfügung stellen kannst / darfst.

Grüße,
Harald

bronsco

Themenstarter

Forum-Anfänger


	Beiträge: 35

	Anmeldedatum: 06.07.10

	Wohnort: ---

	Version: ---

Verfasst am: 30.05.2011, 08:52 Titel:

Hab jetzt mal deinen Vorschlag b) umgesetzt und ein Dummy erstellt...

-> Auszuführen ist die start_bsp.m

Ich hab auch mal das Ergebnis eines ersten Laufs (ustart.txt - man kann leider kein .mat hochladen) mit dazu gepackt.

Was mir mittlerweile aufgefallen ist bzw. was ich mich frage:

1) Könnte die diskrete Schrittweite zu groß sein? (0,01s)

2) Es bilden sich sehr viele Lösungspunkte für den Eingang nahe der Null. Da u von x2 abhängt und dieses in der Simulation nur sehr klein und nicht Null wird kommt es hier zu keiner Konvergenz bzgl. eines minimalen Gütemaßes?

3) Für die Gradientenbildung der Constraints sind Absolutbeträge wahrscheinlich nicht sonderlich vorteilhaft? Wäre sqrt((...).^2) besser? Wird dann wohl aber problematisch bei der Ableitung durch die Wurzel im Nenner....

4) Würde die Simulation des kontinuierlichen Systems sinnvoller sein? Also über odeX-Solver...

5) Gibt es zusätzliche Options, die ich sinnvollerweise angeben sollte?

Besten Dank schonmal für deine bisherigen Antworten Harald!

Viele Grüße

ustart.txt

Beschreibung:

Download

Dateiname:

ustart.txt

Dateigröße:

1.85 KB

Heruntergeladen:

671 mal

constraints.m

Beschreibung:

Download

Dateiname:

constraints.m

Dateigröße:

516 Bytes

Heruntergeladen:

686 mal

functional.m

Beschreibung:

Download

Dateiname:

functional.m

Dateigröße:

483 Bytes

Heruntergeladen:

649 mal

start_bsp.m

Beschreibung:

Download

Dateiname:

start_bsp.m

Dateigröße:

1.27 KB

Heruntergeladen:

654 mal

Harald

Forum-Meister


	Beiträge: 24.495

	Anmeldedatum: 26.03.09

	Wohnort: Nähe München

	Version: ab 2017b

Verfasst am: 30.05.2011, 20:22 Titel:

Hallo,

1) Ja. Wenn du willst, dass deine Optimierung konvergiert, musst du auch eine entsprechende Simulationsgenauigkeit liefern.

3) Das ist egal. Es würde nur eine Rolle spielen, wenn du die Ableitung analytisch berechnen könntest. Das ist hier aussichtslos.

4) Ich würde stark davon ausgehen. odexy diskretisiert ja auch; nur nimmt es die für die entsprechende Genauigkeit benötigte Schrittweite.

Was mir im Code auffällt:
- zu viele globale Variablen. Wie willst du da den Überblick behalten?
- Variablen wachsen dynamisch in for-Schleifen (immer schlecht)
- warum spaltest du die Simulation auf?? x' = Ax + b, y = Cx + d ist doch wunderbar, um mit Matrizen und Vektoren zu rechnen.

Grüße,
Harald

bronsco

Themenstarter

Forum-Anfänger


	Beiträge: 35

	Anmeldedatum: 06.07.10

	Wohnort: ---

	Version: ---

Verfasst am: 31.05.2011, 10:30 Titel:

3) Könntest du mir kurz sagen, wieso die Gradientenberechnung der Constraints aussichtslos ist bzw. woran du das festmachst? Dann spar ich mir gleich den Versuch...

- bzgl. globaler Variablen:
ich hatte mir davon eine einfachere/kürzere Darstellung in den functions erhofft (und evtl. einen Zeitvorteil wg. den wegfallenden Zuweisungen) und eine einfachere Eingabe, da man alles im start_bsp.m ändern kann. (Kommentare fehlen da noch...)

- bzgl. dyn. Wachsen der Variablen:
Matlab "empfiehlt" eine preallocation der Variablen aus Rechendauergründen. Hast du deswegen gemeint, dass das schlecht ist?

- bzgl. Simulation aufspalten:
Könntest du mir kurz sagen, was du da anders machen würdest bzw. wie das dann aussieht?

Harald

Forum-Meister


	Beiträge: 24.495

	Anmeldedatum: 26.03.09

	Wohnort: Nähe München

	Version: ab 2017b

Verfasst am: 01.06.2011, 19:49 Titel:

Hallo,

zu 3): um die Gradienten zu berechnen, müsstest du so etwas wie eine geschlossene Form haben. Und das sehe ich zumindest hier nicht.

zu globale Variablen: wenn Variablen übergeben, aber nicht verändert werden, passieren keine Zuweisungen. Übersichtlicher könnte es auch durch die Verwendung von Strukturen werden.

zu Vorbelegung: ja.

zu Sim. aufspalten: wie gesagt - A*x + b kann man ja direkt so hinschreiben und braucht es nicht elementweise aufspalten. Bist du dir davon abgesehen überhaupt sicher, dass die Diskretisierung so korrekt ist?
Ich würde in jedem Fall das kontinuierliche System simulieren und die Aufspaltung ode45 überlassen. Die einzelne Simulation mag dadurch vielleicht etwas langsamer sein, aber dafür (selbst wenn die Diskretisierung korrekt ist) erheblich genauer - und ich vermute, dass sich dadurch die Anzahl der benötigten Iterationen von fmincon drastisch reduzieren wird.

Grüße,
Harald

bronsco

Themenstarter

Forum-Anfänger


	Beiträge: 35

	Anmeldedatum: 06.07.10

	Wohnort: ---

	Version: ---

Verfasst am: 03.06.2011, 11:06 Titel:

Hallo,

ich hab jetzt nochmal Rücksprache mit meinem Diplomarbeitsbetreuer gehalten. Aufgrund von physikalischen Effekten könnte man die Grenzen von u auch anders angeben. Im Dummy-Modell würde das dann z.B. zwei parallele (schräge) Geraden ergeben, die nicht durch den Ursprung gehen. Also würden sich die Constraints nun in Form von u <= obere Schranke und u >= untere Schranke angeben lassen, was das ganze denke ich schon vereinfacht (weniger Ungleichungsnebenbedingungen, die jetzt auch - denke ich - die Gradientenbildung ermöglichen).

Zur Diskretisierung: Da bin ich mir eigentlich schon sicher, dass das stimmt. Aus dem linearen Zustandsraummodell wird mittels c2d und der Methode 'foh' ein diskretes Modell erstellt. Die "Simulation" kommt ja dann durch Auswerten von x[n+1] = A*x[n] + b*u[n] in der for-Schleife zu Stande.

Für die Simulation des kontinuierlichen Systems kommt nur ein fixed-step-solver in Frage, da ich ja die Länge von u (also die Anzahl der Optimierungsparameter) vorher festlegen muss, welche ich ja bei einem variable-step-solver nicht kenne. Ich werde es aber mal mit einem z.B. ode4 oder ode5 versuchen.

Mit structures würde es in der Tat wohl wesentlich übersichtlicher werden. Auch die Vorbelegung werde ich einfügen. Vielen Dank für deine Tipps!

Grüße

Harald

Forum-Meister


	Beiträge: 24.495

	Anmeldedatum: 26.03.09

	Wohnort: Nähe München

	Version: ab 2017b

Verfasst am: 03.06.2011, 18:41 Titel:

Hallo,

wichtig ist, dass du die Schrankenbedingungen auch als solche implementierst, also die Argument lb und ub statt der nichtlin. NB verwendest.

Wenn du u als stückweise konstant oder linear annimmst, dann kannst du ohne Probleme auch einen Löser mit variabler Schrittweite verwenden. Wenn du einen Löser mit fester Schrittweite verwendest, solltest du auf jeden Fall überprüfen, ob die Simulationsgenauigkeit zumindest für über die ganze Laufzeit konstantes u ausreicht. Bei fester Schrittweite ist immer die Gefahr, dass mit etwas Pech totaler Mist herauskommt - weil man eben keine Fehlerkontrolle hat.

Grüße,
Harald

bronsco

Themenstarter

Forum-Anfänger


	Beiträge: 35

	Anmeldedatum: 06.07.10

	Wohnort: ---

	Version: ---

Verfasst am: 04.06.2011, 17:18 Titel:

Habs vielleicht etwas missverständlich geschrieben: Schranken in Form von lb und ub kann ich nicht angeben, da für den Eingang u in dem Dummy gilt:

1) u <= m*x + t
2) u >= m*x - t

mit einem bestimmten Zustand x. lb und ub geben mir ja "bloß" obere und untere Schranken an, z.B. Kraft nicht über/unter 100/-100 N.

Der Eingang ist leider nicht konstant oder linear, weswegen ein fixed-step-solver unumgänglich wird (eben auch deswegen, da ich ja einen Initialisierungsvektor für u angeben muss beim fmincon-Aufruf, dessen Länge feststehen muss).

Ist es dann nicht eigentlich egal, ob ich mit einem diskreten oder kontinuierlichen System simuliere, da ja beides quasi die gleiche "Abtastzeit" haben kann?

Ich habe jetzt deine Vorschläge umgesetzt und den Code auch noch weiter vereinfacht (z.B. die for-Schleife für die "Simulation", zeitverschwendene Zeilen mittels Profiler umgeschrieben). Zudem habe ich jetzt noch die Gradienten von Zielfunktion und Constraints sowie die Hesse-Matrix analytisch berechnet ("abgesichert" mit der Option DerivativeCheck). Die Optimierungszeit hat sich damit (und mit der neuen Beschränkung für u) drastisch verkürzt!

Werde aber noch eine quantitative Aussage über den Zeitvorteil liefern... Very Happy


Einstellungen und Berechtigungen
Beiträge der letzten Zeit anzeigen:	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.