Allgemeine Überlegungen zur Programmierung von Autopiloten

[Phil]

Servus!

Was mich schon längere Zeit wurmt, ist dass es eigentlich keinen Flieger mit Autopiloten, egal ob default, Free- oder Payware, gibt, der den Flieger bei etwas Wind noch gescheit fliegen kann - besonders schlecht ist meist das Anschneiden der VOR-Radiale.

Die Approach-Funktion ist eigentlich nur bei Windstille brauchbar, von den Autolands ganz zu schweigen. Fast alle Payware-Airliner brüsten sich mit funktionierendem Autoland, laut den Handbüchern ist Autoland sogar bis zu verschiedenen Crosswind-Componenten zugelassen, teilweise mehr als 10Knoten.

Doch im Flusi ist das ein Ding der Unmöglichkeit. Das das offenbar ein Problem der FS-internen Autopilotlogik ist, kann man beobachten, wenn man AI-Flieger auf einem Platz landen lässt, der nur eine Bahn hat und den Wind rechtwinklig drauf stellt -> die AIs landen fast alle neben der Bahn.

Auch die Höhenstabilität im Flusi ist meist grottig, was aber weniger an den APs als an den schlechten Airfiles (Beispiel PSS A330/340) liegt, wie die rühmlichen Ausnahmen von RealAir z.b. zeigen.

Jetzt frag ich mich: Wo liegt eigentlich das Problem??

Es folgen einige theoretische Überlegungen, die ich angestellt habe.

Wenn ich mehr Zeit hätte, würde ich diese grundlegenden Überlegungen liebend gerne praxisnah vertiefen und programmieren, da mir das aber zur Zeit unmöglich ist, möchte ich hier wenigstens Denkanstösse für andere Programmierer geben.

======================================


Betrachten wir Flugzeug und Autopilot als ein nichtautonomes dynamisches System. Eine Führungsgröße (z.B. Längsneigung) soll auf einen Sollwert gebracht werden. Die Führungsgröße wird stets von Störungen beeinflusst (Winde, Gewichtsverteilung, aerodynamische Istabilitäten).
Der Abstand zwischen Ist- und Sollwert wird gemessen und bildet die Steuergröße/Regelgröße. Diese wirkt über einen Regler (Autopilot) auf einen Effektor (Höhenruder), der die Führungsgröße beeinflusst. Diese wirkt sich wiederum auf die Regelgröße aus, usw,usw, ein rückgekoppeltes System also.

Nun kann man solche Systeme ja bekanntlicherweise mit Differenzialgleichungen beschreiben - ja für unseren Fall böte es sich sogar an das System zu diskretisieren und Rekurrenzgleichungen aufzustellen, doch dazu später mehr.

Jeder echte AP funktioniert ja nunmal nach diesem kybernetischen Prinzip und der Trick ist einzig und allein der, die Regelgröße der Trägheit des Systems so anzupassen, dass die Übersteurung möglichst klein ist.

(Es sei angemerkt, dass es den perfekten Autopiloten aus mathematischen Gründen nicht geben kann, denn würde jede Abweichung der Führungsgröße von der Sollgröße in beliebig kleiner Zeit ausgeglichen werden, so würde ja der Grund für die Änderung der Steuergröße entfallen)

Wir haben es hier also im Grunde nur mit folgendem Problem zu tun: Das Flugzeug und der AP bilden ein kybernetisches System, dass sich durch ein vermaschtes System nichlinearer Differenzialgleichungen beschreiben lässt. Auf Differenzialgleichungen können sogenannte Stabilitätsuntersuchungen oder Fixpunktuntersuchungen angewendet werden.
Der (im Rahmen des theoretisch möglichen) optimale AP testet also eine hinreichend große Menge von Lösungen für dieses System auf Stabilität und folgt dann der stabilsten Lösung.

Das sollte aus dem einfachen Grund technisch machbar sein, dass wir gegenüber den echten Autopilotenherstellern zwei immense Vorteile haben:

1. Kennen wir die Gleichungen, nach denen sich das System verhalten muss, denn diese sind dem Flugsimulator immanent (wenngleich es auch aufgrund Copyrightproblemen schwierig sein dürfte, ran zu kommen)
d.h. also wir brauchen im Gegensatz zu echten Autopilotenherstellern keine Modelle für das Verhalten des FLugzeugs durchzurechenen - der Flusi selbst ist ja schon das Modell ! (und das es berechnbar und stabil ist sehen wir daran, dass der Flusi läuft )

2. Kennen wir sogar (im Prinzip) alle Störgrößen bereits im Vorraus, denn es sollte möglich sein, z.B. via FSUIPC auszulesen, wo und in welche Richtung der nächste Windwechsel, die nächste Turbolenz auftritt, nach Stärke und Richtung, d.h. während ein echter Autopilot ohne Kenntnis der eigentlichen Störung die Regelgröße festlegt, kennen wir sogar die Störgröße und können sie in unseren Berechnungen verwenden.

Bleibt also noch das Problem, wie man möglichst effizient genügend Lösungen der DGLs auf Stabilität hin untersucht, möglichst ohne den Rechner vollkommen lahmzulegegen.

Desweiteren sollte man sich die Frage stellen, ob eine grundsätzliche Notwendigkeit besteht, hier überhaupt mit Differenzialgleichungen zu arbeiten
->der Flusi ist schließlich wie jede Simulation zeitdiskret und läuft in einer eigenen Zeiteinheit, den Ticks.
Daher sollte es möglich sein, das Flugzeug-AP-System mit Rekurrenz- (Differenzen-) Gleichungen zu beschrieben, die zeitdiskret mit der Einheit des Flusi-Ticks sind. Und auch zu Differenzengleichungen existiert mittlerweile ein beeindruckendes Instrumentarium für Stabilitätsuntersuchungen.

Literatur dazu:

http://www.amazon.de/exec/obidos/ASI...860884-1318942
http://www.amazon.de/exec/obidos/ASI...860884-1318942
http://www.amazon.de/exec/obidos/ASI...860884-1318942

[Matthias Lieberecht]

Hallo Philip,

ohne jetzt auf Deine umfangreiche Ausführung einzugehen, hier ein paar kleine Anmerkungen:

"Was mich schon längere Zeit wurmt, ist dass es eigentlich keinen Flieger mit Autopiloten, egal ob default, Free- oder Payware, gibt, der den Flieger bei etwas Wind noch gescheit fliegen kann - besonders schlecht ist meist das Anschneiden der VOR-Radiale"

Lässt sich im Airfile, bzw. der Aircraft.cfg korrigieren (s.u.)

"Die Approach-Funktion ist eigentlich nur bei Windstille brauchbar,"

Auch das lässt sich in der Aircraft.cfg korrigieren (s.u.)

"Doch im Flusi ist das ein Ding der Unmöglichkeit."

Stimmt so nicht, kommt auf das Modell an (s.u.)

"Das das offenbar ein Problem der FS-internen Autopilotlogik ist, kann man beobachten, wenn man AI- Flieger auf einem Platz landen lässt"

Prinzipiell richtig, hat aber meiner Meinung nach nichts mit den MS Autopilot Variablen oder der Logic des MS Autopiloten zu tun, sondern ist ebenfalls Sache des Airfiles. Richtig deshalb, da die dortigen Werte natürlich mit dem Verhalten des Autopiloten zu tun haben.

In der Aircraft.cfg gibt es die PID Werte

nav_proportional_control=
nav_integrator_control=
nav_derivative_control=
nav_integrator_boundary=
nav_derivative_boundary=
gs_proportional_control=
gs_integrator_control=
gs_derivative_control=
gs_integrator_boundary=
gs_derivative_boundary=

Ich bin alles andere als ein Experte auf diesem Gebiet und kann daher meine Behauptung lediglich durch eigene Versuche unterstreichen. Mit meiner ARJ hatte ich hier ebenfalls massive Probleme. Das Modell wanderte sehr lange um den LOC bevor sie ihn ohne weitere Korrekturen hielt und der GS wurde nur sehr unstabil gehalten. Eine Korektur der angegebenen PID Werte verbesserte jedoch das AP Verhalten massiv. Das Modell ist immer noch nicht perfekt und der AP hat immer noch diverse Probleme, aber jeder Eingriff auf die entsprechenden Parameter der Aircraft.cfg brachte eine Veränderung des Verhaltens. Für mich zeigt das, dass es lediglich erforderlich ist, hier die Werte sauber aufeinnder abzustimmen. Sucht man im Web nach entsprechenden Zusammenhängen, findet man unzählig viele Seiten zu diesem Thema. Recht gut, da kurz und übersichtlich, finde ich diese hier:

http://www.brewerscience.com/cee/oth...s/cee_pid.html

Eine interessante Diskussion zu diesem Thema findet sich hier:

http://groups.msn.com/OfficialFlight...62865555877763

Beides, sowie die vielen anderen via "PID" gesuchten Web Dokumente, halfen mir sehr den AP wesentlich zu verbessern. Wie gesagt, er ist noch lange nicht optimal aber hier eine saubere Abstimmung zu finden, ist nicht leicht. Dennoch bin ich mir in der Zwischenzeit absolut sicher, dass es nicht unmöglich ist.

Gruß
Matthias

[Phil]

Boah, wie geil, wusste garnicht, dass der FS-Autopilot tatsächlich ne PID-Logik simuliert.
Danke für den Hinweis!
Dann sollte das ganze ja ein viel kleineres Problem sein, als ich eigentlich dachte.

[Yves G.]

Ich habe mich auch schon mit der Autopilot-Problematik im FS beschäftigt. Leider lassen sich im FS2002/4 viele Probleme nicht über die AP-Einstellungen in der aircraft.cfg lösen (s. nächsten Post).

Die meisten Beeinflussungsmöglichkeiten hatte man damals im FS2000 (und FS98), da im AIR File in Section 1199 ca. 100 Paramater zur Einstellung der PID-Regler vorhanden waren (für jedes Flugzeug individuell). Nicht ganz alle schienen zu funktionieren, aber die restlichen erlaubten eine recht gute Steuerung.

Das Schema in Sect. 1199 sah folgendermassen aus:
16 AP-Funktionen mit je 7 Werten:

Bsp.:

Heading Proportional Gain = 1.5 ; dimensionslos
Heading Integral Gain 1 = 0.6 ; dimensionslos
Heading Integral Gain 2 = 0.2 ; dimensionslos
Heading Derivative Gain = 0.0 ; dimensionslos
Heading Integral Boundary 1 = 2 ; absolut (hier in Grad Abweichung vom Zielheading)
Heading Integral Boundary 2 = 0.5 ; absolut (")
Heading Derivative Boundary = 20 ; absolut (")


Es gab also ein P, zwei I (für äusseren und inneren Bereich) und ein D. Die Boundarys sind die Abweichungswerte vom Target (z.B. HDG oder Höhe) innerhalb deren die zugehörigen Gains wirken.

Neben Heading gab es u.a. auch Bank, NAV, Glideslope, Vertical Speed, Pitch, Pitch Rate, Autothrottle und Yaw Damper mit jeweils 7 Parametern. Dazu existierten noch ein paar hardgecodete Werte in der Sim1.dll wie den Anschneidewinkel beim NAV/ILS capturen.

[Yves G.]

Leider ist seit dem FS02 die Sect. 1199 nicht mehr aktiv (auch wenn sie selbst in den MS Flz. noch vorhanden ist). Diese Werte stehen jetzt irgendwo fix in der SIM1.dll. Das alte PID-Schema vom FS2000 wurde offenbar so nicht übernommen, sonst hätte ich die Tabellen in der sim1.dll wahrscheinlich aufgespürt.

Nur die PID Werte für NAV und GS gab uns MS im FS04 zurück, welche jetzt in der aircraft.cfg stehen. Die Derivativen Werte scheinen aber nicht zu funktionieren und einer der beiden Integral Werte wurde gestrichen. Ausserdem hängen die NAV Parameter mit den BANK und HDG Einstellungen zusammen, die hier teilweise fehlen. Ein sauberes Auflinieren wird daher bereits wieder schwierig.

Die übrigen AP-Parameter in der .cfg sind v.a. Ober- und Untergrenzen (die es im FS2000 nicht gab) und keine PID-Werte. Es ist zum Beispiel nicht möglich, das Auf-/Abschaukeln von Jets auf grosser Höhe durch diese Parameter wirklich zu eliminieren. Die entscheidenden Werte dafür stehen noch unentdeckt irgenwo in der Sim1.dll.

Dass manche Jets auf FL 350 im ALT Mode trotzdem nicht auf- und abschaukeln, liegt meistens an den stark überhöhten Pitch Stability Werten. MS selbst hat seine 737 und 747 mit ca. 10 fach zu hohen Pitch/Roll/Yaw-Stabilitätswerten ausgestattet und den AP darauf ausgerichtet. Jets mit realistischen Werten reagieren daher zu sensibel auf die AP-Inputs.

Man muss eigentlich die Parameter der Flugdynamik verfälschen, damit der interne AP zuverlässig arbeitet. Das ist leider nicht der Weisheit letzter Schluss. Ein externer AP könnte da wahrscheinlich Abhilfe schaffen (via FSUIPC?).

[AOG]

Hi!

Für einen guten Autopiloten sind einfache PID eh nicht geeignet, da braucht es schon etwas komplexere Regler Strukturen, die FSQ F70/100 bekommt ein spezielles adaptives PID Derivat.

Das Flugzeug veränder seine eigenschaften(=Regelstrecke) ganze dramatisch in Abhängigkeit von Speed/Höhe/Gewicht/temp..usw Darauf kann ein fix parametrisierter PID nicht reagieren..

Bei Autopiloten ist es vorallem wichtig die Rückführung von der Stellgrößte unabhänig zu reglen.

ZbSp Rückführung hoher D anteil und störgrößen gut ausregeln zu können(gusts.zBsp) jedoch stellgrößen nur mit PI zu regeln damit eingaben immer smooth geändert werden.

Weiters langt da nicht immer ein einzelner Regler sonder es braucht kaskadierte regler.

Einer regelt den Pitch, der nächste über Pitch die Speed usw... Damit kann man dann auch sinnvolle FD commands anzeigen

nur kurze Anregungen die ich hier nicht genauer ausführen möchte..

florian

[harry3]

Ich habe mich nun auch mal auseinandergesetzt mit dem Thema Autopilot im FS.
Im Prinzip müsste ein normaler PID Regler reichen, um den Flieger einigermaßen stabil fliegen zu lassen.
Für Top Autopiloten braucht man klarerweise mehr, da ist Florian('AOG') eh schon drauf eingegangen. Es war aber meine Absicht, einen Demonstrator für die Autopilotlogik zu bauen, und da reicht ein normaler PID Regler.



Für die das Thema AP noch Neuland ist, hier eine kurze Beschreibung: Oben sieht man einen Regelkreis, w ist der Sollwert, also der Wert, der erreicht werden soll(z.B. eine VSI von +500ft/min). x ist der Istwert, also der gemessene Wert(z.B. 200ft/min). Wenn man die beiden subtrahiert, so erhält man e, die Regeldifferenz(welche dann 300ft/min wäre). Diese gibt also an, wie weit man noch von seinem gewünschten Wert entfernt ist.
Aus dem Wert e wird nun mittels des PID Reglers eine Stellgröße y berechnet. Diese wirkt auf die Höhenrudertrimmung(Pitch Trim).
Durch die Ansteuerung der Höhenrudertrimmung ergibt sich nun eine Änderung der VS, diese wird wieder gemessen und nach vorne zur Differenzbildung mit dem Sollwert gebracht, wo in weiterer Folge die nächste Stellgröße berechnet wird. Und hiermit schließt sich der Kreis.

Nun aber zurück zum Thema.
Hier ein Screenshot meines APs:


Ich habe mir also nun einen Autopiloten programmiert, welcher die Höhe hält bzw. eine eingestellte Höhe anfliegt. Man wählt zwar die Höhe aus, welche gehalten werden soll, der Regler arbeitet allerdings mit der Vertical Speed. Zum Beispiel wenn man auf 1000ft Höhe fliegt und auf 2000ft steigen will, so steuert der AP einen Steigwert von +500ft/min an, bis 1800ft erreicht sind, danach wird nur noch mit +200ft/min gestiegen. Bei 1990ft/min wird schließlich die VS auf 0ft/min runtergeregelt.
Der AP weicht also bei idealer Einstellung max. +-10ft von der gewünschten Höhe ab.

Die 3 Werte des PID Reglers(Proportionalteil, Integralteil, Differenzialteil) kann ich während des Fluges einfach mittels Mausklick ändern.
Die Einstellung der Regelzeit ist fix einprogrammiert mit 0,5sec. Jede halbe Sekunde wird also überprüft ob eine Abweichung vorhanden ist und wenn ja dann wird die Höhenrudertrimmung betätigt.

Ich habe meine Testflüge mit der gutmütigen C172 geflogen.
Interessant ist nun wie die einzelnen Werte Einfluß auf das Regelverhalten haben.
Ein großer P Anteil bringt das Flugzeug ist extremes Auf und Abschaukeln, P sollte also möglichst klein sein(bei der C172 P=0,01).
Der I Anteil sorgt für ein vollständiges Ausregeln auf den gewünschten Sollwert. Allerdings bringt auch der I Anteil ein Schwingen ins System und sollte klein gehalten werden(bei der C172 I=0,02)
Erst der D Anteil bringt schließlich Stabilität ins System. Er wirkt nämlich dem I und P Anteil entgegen. Dieser D Anteil sollte eher groß gewählt werden(bei der C172 D=0,15)

Man kann nun natürlich Regler berechnen, in diesem Fall ist es weitaus besser sich an Einstellregeln zu halten.
Wikipedia zeigt da z.B. ein paar Tipps und Tricks, wie man den Regler einstellen kann:

Siehe: Wikipedia - Faustformelverfahren

Weiters zu empfehlen wäre dieser Link, wo ich mir auch die Regelkreisgraphik geliehen habe:
roboternetz - Regler(roboternetz)

Soviel dazu, vielleicht ist das Thema dem einen oder anderen dadurch verständlicher geworden.
Wer selber herumprobieren will dem kann ich das Gauge schicken(PN).

Grüße,
Harri

[Phil]

Original geschrieben von harry3
....
Ein großer P Anteil bringt das Flugzeug ist extremes Auf und Abschaukeln, P sollte also möglichst klein sein(bei der C172 P=0,01).
Der I Anteil sorgt für ein vollständiges Ausregeln auf den gewünschten Sollwert. Allerdings bringt auch der I Anteil ein Schwingen ins System und sollte klein gehalten werden(bei der C172 I=0,02)
Erst der D Anteil bringt schließlich Stabilität ins System. Er wirkt nämlich dem I und P Anteil entgegen. Dieser D Anteil sollte eher groß gewählt werden(bei der C172 D=0,15)....

Was ja nicht wirklich verwunderlich ist, schließlich misst der Differentialanteil ja die Änderung der Abweichung und versucht diese Kleinzuhalten - ein reiner D-Regler kann ja nie einen geänderten Sollwert erreichen, sondern versucht immer nur die Regelgröße konstant zu halten (sozusagen auf konstanter Differenz zur Sollgröße).

Daher solltest du, wie Florian schon anmerkte, mal folgendes versuchen:
Hoher P Anteil im Vergleich zum D beim Eindrehen einer neuen Vorgabe, und kleinerer P (größerer D)-Anteil im Moment wo die Vorgabe erreicht wird.

Man kann sich die drei Görßen P,I und D ja so vorstellen, dass P die Gegenwart, I die Vergangenheit und D die Zukunft der Regelgröße betrachtet.

Kann man übrigens sehr schön bei unerfahrerenen Fahrer(innen) auf der Autobahn sehen - die versuchen die Reglgröße (Fahrzeuglängsachse) auf die Sollgröße (linke und rechte Fahrbahnmarkierung) anzupassen. Wer direkt über die Motorhaube starrt und die zwischen den weißen Streifen zu halten versucht, regelt mit hohem P-Anteil und schaukelt darum (so fuhr meine Ex, argh...). Wer weiter nach vorne schaut, regelt mit hohem D-Anteil und fährt stabiler. Hoffe das konnte man nachvollziehen.

[harry3]

Hallo!

Daher solltest du, wie Florian schon anmerkte, mal folgendes versuchen:
Hoher P Anteil im Vergleich zum D beim Eindrehen einer neuen Vorgabe, und kleinerer P (größerer D)-Anteil im Moment wo die Vorgabe erreicht wird.

Programmtechnisch wäre es wohl am einfachsten das so umzusetzen, dass die Faktoren sich je nach Regeldifferenz ändern. Also z.B. wenn die VSI mit +-100ft/min eingehalten wird dann PI klein und D große, wenn die Abweichung größer ist dann umgekehrt. Damit sollte man auch das Überschwingen besser in den Griff bekommen(noch nicht ausprobiert).

Ich werde das sobald ich Zeit habe umsetzen und berichten.

Hoffe das konnte man nachvollziehen.

Das Fahrverhalten von Frauen kann ich beim besten Willen nicht nachvollziehen.
Aber wenn ich mir deinen Gedankengang mit einem männlichen Fahrer durchdenke klingt er durchaus verständlich.


Grüße,
Harri