Auftriebsbeiwerte für B777 in Flugsimulatoren?

Diskutiere Auftriebsbeiwerte für B777 in Flugsimulatoren? im Verkehrsflugzeuge Forum im Bereich Luftfahrzeuge; Jetzt habe ich unter Einbeziehung der Thrust-Altitude-Mach Table und mit ausgemerzten Fehlern folgendes simuliert: Startwerte: v = 82.3 m/s =...

stefanpc81

Fluglehrer
Dabei seit
22.01.2016
Beiträge
106
Zustimmungen
2
Jetzt habe ich unter Einbeziehung der Thrust-Altitude-Mach Table und mit ausgemerzten Fehlern folgendes simuliert:
Startwerte:
v = 82.3 m/s = 160 kts
Höhe = 1000 m
Widerstand FW * 1/18

Nach 10 s von (gamma)=0° schrittweise auf 5°.
Die Beschleunigung wird danach deutlich langsamer.

Ergebnis nach 60 s:
v = 113 m/s
Höhe = 1440 m

Und mit H = 0, v= 0 und Widerstand FW * 1/12 als Start vom Boden aus ergeben sich jetzt auch realistischere Werte als vorher:
Startstrecke = 2600 m bis v = ca. 83 m/s erreicht wird, dauert allerdings fast 1 Minute lang.
 
Schorsch

Schorsch

Alien
Dabei seit
22.01.2005
Beiträge
12.762
Zustimmungen
5.720
Ort
mit Elbblick
Jetzt habe ich unter Einbeziehung der Thrust-Altitude-Mach Table und mit ausgemerzten Fehlern folgendes simuliert:
Startwerte:
v = 82.3 m/s = 160 kts
Höhe = 1000 m
Widerstand FW * 1/18

Nach 10 s von (gamma)=0° schrittweise auf 5°.
Die Beschleunigung wird danach deutlich langsamer.

Ergebnis nach 60 s:
v = 113 m/s
Höhe = 1440 m

Und mit H = 0, v= 0 und Widerstand FW * 1/12 als Start vom Boden aus ergeben sich jetzt auch realistischere Werte als vorher:
Startstrecke = 2600 m bis v = ca. 83 m/s erreicht wird, dauert allerdings fast 1 Minute lang.
Ich würde den Widerstand am Start mit der Widerstands-Formel modellieren.
So lange das Flugzeug rollt setzt man CL gleich null.
Es bleibt der Nullwiderstand (CD0).
Rollwiderstand kann man in erster Näherung vernachlässigen.
Für eine Startkonfiguration kann man CD0 mit .035, CLmin mit .3 und k mit 0.06 annehmen. Fahrwerk kann man so mit CD_gear von 0.02 dazunehmen.

Wie ich schon mehrfach schrieb ist Startstreckenberechnung die Königsdisziplin.

Die Werte aus dem Test erscheinen grundsätzlich realistisch. Eine B777 sollte in 1000m schon in der Lage sein mit ~5-7° zu steigen ohne dabei langsamer zu werden.
 

stefanpc81

Fluglehrer
Dabei seit
22.01.2016
Beiträge
106
Zustimmungen
2
Als nächster Punkt kommt die Errechnung des Luftwiderstands als Funktion des Auftriebs.
CL = Gewicht/(rho/2 * v^2 * S_ref)
S_ref ist dabei immer die Flügelfläche des normalen, "sauberen" Flügels. Immer!
CL sollte zwischen ~0.2 und 0.8 sein.
Mit
CD = CD0 + k*(CL-CL0)^2
und den Werten aus:
https://en.wikipedia.org/wiki/Drag_Polar
ergibt ein brauchbares CD für den normalen Flug.
Dies dann mit
Widerstand = CD * rho/2 v^2 * S_ref
v ist dabei gleich x_pkt, der wahren Fluggeschwindigkeit.
So, das habe ich jetzt auch gemacht. S_ref = 427.8 m^2, für CL werden auch in etwa die Werte angezeigt, die du genannt hast.
Dies mal ins Modell einpflegen, speziell bei höheren Geschwindigkeiten sollte sich zeigen, dass der Flieger mehr Widerstand erzeugt.
Stimmt auch.

Die Simulation mit dem Start funktioniert irgendwie noch nicht. Ich lasse das jetzt erst mal sein. Zur "Königsdisziplin" kommen wir ja noch, oder?
Wie geht es nun weiter? Mit 6.3?
 
Schorsch

Schorsch

Alien
Dabei seit
22.01.2005
Beiträge
12.762
Zustimmungen
5.720
Ort
mit Elbblick
CD_gear habe ich ja oben gegeben. Einfach auf CD0 addieren.
Nächste Schritte wären die Öffnung des "Flight Envelope".
Dafür würde ich erst mal eine Testroutine erstellen, welche mir den Flugbereich zeigt.

Also, ich taste alle Kombinationen von Geschwindigkeit und Höhe ab (10kts-Schritte, 1000ft-Schritte), lasse mir für das gewählte Gewicht den Auftriebs- und Widerstandsbeiwert berechnen (daraus dann Gleitzahl bestimmen). Dann setze ich vollen Dauerschub an (das ist etwa 90% des maximalen Startschubs) und berechne die Differenz. Idealerweise variere ich dann so lange das Gamma nach oben, bis ich keinen Schubüberschuss mehr habe. Das kann ich in erreichbare Steigraten umrechnen. Irgendwann wird selbst bei Gamma=0 der Schub den Widerstand nicht kompensieren.
Mit so einer "Landkarte" hat man sein Modell etwas kennen gelernt. Welche Höhe kann ich erreichen, welche Geschwindigkeiten (dies ist beim Turbofan recht langweilig). Hier wird dann sichtbar, dass ich einen Machzahl-abhängigen Widerstand benötige.

Als weitere Verbesserungen des Modells sehe ich eigentlich nicht mehr viel. Die Steuerung müsste man umsetzen, das ist natürlich nicht ganz leicht so ohne flugmechanisches Basisverständnis.
 
Schorsch

Schorsch

Alien
Dabei seit
22.01.2005
Beiträge
12.762
Zustimmungen
5.720
Ort
mit Elbblick
Hab noch alten Code gefunden.
Das ist vollkommen ausreichend für Trajektorie.

% Here you could include a lateral control
d.php = 0.0; % change of phi/sec

ATS.Bank(i) = ATS.Bank(i-1) + d.php * CT.dt; % new phi
ATS.n(i) = ATS.n(i-1) + d.np * CT.dt; % new load factor

% Equations of Motion
v = ATS.TAS(i-1) * CT.KTS2MPS;
d.ga_pkt = 9.81/v * (ATS.n(i) * cosd(ATS.Bank(i)) - cosd(ATS.Gamma(i-1))); % gamma derivative
d.psi_pkt = 9.81/v * ATS.n(i) * sind(ATS.Bank(i))/cosd(ATS.Gamma(i-1)); % psi derivative
d.v_pkt = (10 * Sys.Thrust(i) - Sys.QdynS(i)*ATS.CD(i))/Sys.Weight(i-1) - 9.81 * sind(ATS.Gamma(i-1));

% new speed and flightpath angle (time-integration)
ATS.TAS(i) = ATS.TAS(i-1) + CT.MPS2KTS * d.v_pkt * CT.dt;
ATS.Gamma(i) = ATS.Gamma(i-1) + CT.R2D * d.ga_pkt * CT.dt;
ATS.Psi(i) = ATS.Psi(i-1) + CT.R2D * d.psi_pkt * CT.dt;
% distance covered and altitude gained
d.dist = (ATS.TAS(i)+ATS.TAS(i-1))/2 * CT.KTS2MPS * CT.dt;
d.x = d.dist * cosd((ATS.Psi(i)+ATS.Psi(i-1))/2);
d.y = d.dist * sind((ATS.Psi(i)+ATS.Psi(i-1))/2);
d.z = d.dist * sind((ATS.Gamma(i)+ATS.Gamma(i))/2);


Psi ist die Richtung.
Die fett markierten Variable sind die Inputs: die Rollrate (der integrierte Effekt eines Querruderausschlags) und die Veränderung des Lastvielfachen. Eigentlich sehr einfach und elegant. Die Trägheit des Flugzeugs muss man allerdings noch einbauen, sprich: die Rollrate kann sich maximal mit so und so viel °/sec² ändern.

Wahrscheinlich blickt da aber niemand mehr durch .... schade.
 

stefanpc81

Fluglehrer
Dabei seit
22.01.2016
Beiträge
106
Zustimmungen
2
Oje, bei diesen Berechnungen verstehe ich nur Bahnhof. Dann bleibe ich doch lieber bei der direkten Eingabe von 1-3° Änderung/sec durch Anwählen des Steuerknüppels. So realistisch muss das in diesem Fall dann auch nicht werden.

Nächste Schritte wären die Öffnung des "Flight Envelope".
Dafür würde ich erst mal eine Testroutine erstellen, welche mir den Flugbereich zeigt.

Also, ich taste alle Kombinationen von Geschwindigkeit und Höhe ab (10kts-Schritte, 1000ft-Schritte), lasse mir für das gewählte Gewicht den Auftriebs- und Widerstandsbeiwert berechnen (daraus dann Gleitzahl bestimmen). Dann setze ich vollen Dauerschub an (das ist etwa 90% des maximalen Startschubs) und berechne die Differenz. Idealerweise variere ich dann so lange das Gamma nach oben, bis ich keinen Schubüberschuss mehr habe. Das kann ich in erreichbare Steigraten umrechnen. Irgendwann wird selbst bei Gamma=0 der Schub den Widerstand nicht kompensieren.
Mit so einer "Landkarte" hat man sein Modell etwas kennen gelernt. Welche Höhe kann ich erreichen, welche Geschwindigkeiten (dies ist beim Turbofan recht langweilig). Hier wird dann sichtbar, dass ich einen Machzahl-abhängigen Widerstand benötige.
Das muss ich dann noch morgen austesten.

PS @Schorsch: Eine Interpolation habe ich gerade doch noch programmieren können, diesmal statt Arrays mit einer 2. langen Reihe von if/else if Bedingungen.
 
Schorsch

Schorsch

Alien
Dabei seit
22.01.2005
Beiträge
12.762
Zustimmungen
5.720
Ort
mit Elbblick
PS @Schorsch: Eine Interpolation habe ich gerade doch noch programmieren können, diesmal statt Arrays mit einer 2. langen Reihe von if/else if Bedingungen.
eine Alternative ist mittels Excel Trendfunktionen zu erstellen. Es reichen ja drei bis fünf Höhen.
Das Triebwerksmodell kann man da beliebig vereinfachen, jedoch wird man dann man sehr unrealistische Leistungswerte bekommen.
Das Problem ist, dass fast alle wichtigen Leistungsparameter eines Flugzeugs am Rande seines Flugbereichs erreicht werden.
Zum "Rumfliegen" ist das egal.
 

stefanpc81

Fluglehrer
Dabei seit
22.01.2016
Beiträge
106
Zustimmungen
2
Es ist noch sehr komisch, dass nach ein paar Minuten Horizontalflug mit einzelnen Änderungen des (gamma)-Winkels nach + oder - mir das Programm irgendwann NEGATIVE Geschwindigkeiten anzeigt und CL wird dann auch deutlich kleiner als 0.2!
Ich glaube bei meiner Berechnung mit v, a, x_erde, x_flugzeug ist irgendwas nicht richtig.
Sorry, hier nochmal meine aktuellen eingegebenen Formeln:

pos_z ist die aktuelle Höhe in m gegenüber der Erde
Der Operator != bedeutet "ungleich"

FG = gewicht * 9.81;
T = 288.15 - (0.0065 * pos_z);
p = 1 - (0.0065 * pos_z / 288.15);
druck = 9.80665 / 0.0065 / R;
p = Math.pow(p, druck);
p = p * 101325;
rho = p / R / T;

C_wert = rho * 0.5 * v_neu^2 * 427.8;
if (C_wert!=0&&pos_z==0) { CL = 0; }
else if (C_wert!=0) { CL = FG / C_wert; }
else { CL = 0; }
CL_diff = CL - CL0;
CD = CD0 + K0 * CL_diff^2;
FW = CD * C_wert;

M = v_neu / sqrt(K1 * T * R);
x_pkt_pkt = FT [Schub in N] - (sinus(gamma) * FG + FW);
x_pkt_pkt = x_pkt_pkt / gewicht;
v = x_pkt = x_pkt_pkt * dt;
a = x_pkt_pkt;
x_neu = x_alt + v * dt + 0.5 * a * dt^2;
v_neu = v_alt + a * dt;
x_erde = x_erde + v_neu * cosinus(gamma) * dt;

Wie x_neu eingebunden werden muss, ist mir unklar, wie ich heute feststellen musste.
 
Taliesin

Taliesin

Astronaut
Dabei seit
13.07.2008
Beiträge
2.583
Zustimmungen
952
Ort
Berlin
Ich bin jetzt auf die Schnelle nicht durch deine Berechnungen gestiegen, würde dir aber den Tipp geben bei Berechnungen wie "p = 1 - (0.0065 * pos_z / 288.15)" und "druck = 9.80665 / 0.0065 / R" großzügig mit Klammern umzugehen. Meiner Erfahrung nach entstehen gerade bei solchen Termen gerne Fehler, weil man dem Programm ganz genau beipulen muss, welche Terme zusammen gehören und welche Terme Priorität haben.

Außerdem macht es Sinn, wenn man sich sämtliche Werte der Berechnung ausgeben lässt und auf Plausibilität prüft. Hilft zum einen bei der Fehlersuche, vertieft aber auch das Verständnis für die Materie.
Für die Fehlersuche sollte man sich sämtliche beteiligten Variablen ausgeben lassen und konsequent zurück verfolgen, das sind ja auch nicht so wahnsinnig viele. Wenn deine Geschwindigkeit negativ wird, dann muss das irgendeinen Grund haben. Systematische Fehlersuche findet den Schuldigen ;)
 

LFeldTom

Astronaut
Dabei seit
01.08.2002
Beiträge
2.581
Zustimmungen
1.336
Ort
Niederrhein
Ich bin jetzt auf die Schnelle nicht durch deine Berechnungen gestiegen, würde dir aber den Tipp geben bei Berechnungen wie "p = 1 - (0.0065 * pos_z / 288.15)" und "druck = 9.80665 / 0.0065 / R" großzügig mit Klammern umzugehen. Meiner Erfahrung nach entstehen gerade bei solchen Termen gerne Fehler, weil man dem Programm ganz genau beipulen muss, welche Terme zusammen gehören und welche Terme Priorität haben.
Was die Lesbarkeit angeht bin ich da voll bei dir. Was die "Priorität" angeht hab ich jetzt Schwierigkeiten zu folgen. Für den Compiler / Interpreter wird das nicht gebraucht. Oder hab ich dich einfach falsch verstanden ?

Ich würde noch einen weiteren Punkt hinzufügen. Vermeide Konstanten in numerischer Form in Quelltexten. Das spielt für die Performance keine Rolle - erhöht aber die Lesbarkeit und vermeidet Tippfehler.

PHP:
const double temp_std = 288.15;
Die Codeschnipsel werden auch lesbarer, wenn man die hier mit dem PHP-Tag versieht.

T = 288.15 - (0.0065 * pos_z);
p = 1 - (0.0065 * pos_z / 288.15);
Vermeide doppelte Berechnungen:
hier besser
PHP:
pRel = T / temp_std;
p = Math.pow(p, druck);
p = p * 101325;
Sowas ist ganz schwer zu debuggen. Wenn du zu einem bestimmten Zeitpunkt pausierst musst du ständig im Hinterkopf haben was p denn jetzt gerade sein soll. Wenn du mehrere Schritte brauchst, dann nimm auch mehr (temporäre) Variablen. Eine Variable sollte niemals die Einheit wechseln. Später, wenn dir der Code nicht mehr so parat ist, dann hilft das auch ungemein, wenn du bereits bei der Deklaration von Variablen einen Kommentar dabei schreibst in welcher Einheit die Werte der Variablen gültig sind.

PHP:
const double p0 = 101325;
...
p = p0 * Math.pow(pRel, druck);


x_pkt_pkt = FT [Schub in N] - (sinus(gamma) * FG + FW);
x_pkt_pkt = x_pkt_pkt / gewicht;
v = x_pkt = x_pkt_pkt * dt;
a = x_pkt_pkt;
x_neu = x_alt + v * dt + 0.5 * a * dt^2;
v_neu = v_alt + a * dt;
x_erde = x_erde + v_neu * cosinus(gamma) * dt;
s.o. - beim Debuggen schwer zu behandeln.

PHP:
Fx = FT [Schub in N] - (sinus(gamma) * FG + FW); // X-Achse ist hier entlang der Flugzeugachse - ist das so gewollt ?
Ax = Fx / masse;

v_neu = v_alt + a * dt;
x_neu = x_alt + v_neu * dt;
x_erde += v_neu * dt * cosinus(gamma);
Ein Problem ist in meinen Augen deine Wahl von x mit einem Koordiantensystem, dass sich auf das Flugzeug bezieht. Wenn sich gamma ändert, dann musst du das einrechnen. Das macht aber gar keinen Spass und ist in meinen Augen auch ziemlich unnötig. Wenn du erdfeste Koordinaten nimmst hast du das Problem nicht. Kräfte bezogen auf das Koordinatensystem sind unproblematisch. Raumkoordinaten damit schon.

PHP:
// spezifisch für deine Simulation
Fx = cos(gamma) * (FT [Schub in N] - FW) - sinus(gamma) * FG;
Fy = sin(gamma) * (FT [Schub in N] - FW) - cosinus(gamma) * FG;

// allgemein - unabhängig vom simulierten Objekt
A_x = Fx / masse;
A_y = Fy / masse;

V_x += A_x * dt;
V_y += A_y * dt;

pos_x += V_x * dt;
pos_Y += V_y * dt;
Das läßt sich vektoriell natürlich noch einfacher gestalten - entsprechend einfach Arrays verwenden.

Bei sich ändernden Werten von F / A / V ist diese Form der Integration natürlich ungenau. Das kann man durch eine kleine Wahl von dt natürlich deutlich verbessern. Noch besser ist aber z.B. eine Integration nach Runge Kutta (oder ähnlichem). Für die Validierung deiner Testdaten sollte das aber noch nicht relevant sein.
 
Taliesin

Taliesin

Astronaut
Dabei seit
13.07.2008
Beiträge
2.583
Zustimmungen
952
Ort
Berlin
Was die Lesbarkeit angeht bin ich da voll bei dir. Was die "Priorität" angeht hab ich jetzt Schwierigkeiten zu folgen. Für den Compiler / Interpreter wird das nicht gebraucht. Oder hab ich dich einfach falsch verstanden ?
Wenn man komplexere Formeln in Code umschreiben muss, dann muss man auf Sachen wie Doppelbrüche achten. Bruchstriche haben mathematisch auch die Funktion einer Klammer, das weiß das Programm aber nicht, wenn man einfach nur "geteilt durch" aneinander reiht. Vielleicht hängt das vom Compiler ab, ich weiß nur, dass das in Matlab z.B. nicht automatisch erkannt wird und viel schlauer als Matlab schätze ich kaum ein Programm ein :wink:
 
Schorsch

Schorsch

Alien
Dabei seit
22.01.2005
Beiträge
12.762
Zustimmungen
5.720
Ort
mit Elbblick
M = v_neu / sqrt(K1 * T * R);
x_pkt_pkt = FT [Schub in N] - (sinus(gamma) * FG + FW);
x_pkt_pkt = x_pkt_pkt / gewicht;
v = x_pkt = x_pkt_pkt * dt;
a = x_pkt_pkt;
x_neu = x_alt + v * dt + 0.5 * a * dt^2;
v_neu = v_alt + a * dt;
x_erde = x_erde + v_neu * cosinus(gamma) * dt;
Bei hinreichend kleinen Schrittweiten kann ich mir das dt^2 auch sparen. Da Flugzeuge nicht so schnell beschleunigen, wäre bei 10-20Hz das der Fall.
Mit v und x hast du teilweise Parameter, die gleich sind. Vermeide dies.

x_neu ist erstmal keine brauchbare Größe, viel wichtiger ist delta_x_neu, also die Wegstrecke, welche das Flugzeug im letzten Zeitschritt entlang seiner Längsachse zurückgelegt hat.

Ohne ein paar Grundlagen wird es wirklich schwierig, ich kann den Code leider auch nicht einfach kopieren. Das dauert zu lange.
 

LFeldTom

Astronaut
Dabei seit
01.08.2002
Beiträge
2.581
Zustimmungen
1.336
Ort
Niederrhein
@Taliesin
Dann hab ich das in der Tat falsch aufgefasst. Die Geschichte mit den Doppelbrüchen erledigt sich in der Tat mit der besseren Lesbarkeit.

Wenn man Doppelbrüche falsch auflöst rettet einen kein Compiler dieser Welt. Das ist nicht nur bei Matlab so.

Ich hatte das ursprünglich so missverstanden, dass du mit der Klammerung eine bessere Performance / genauere Werte bekommen wolltest.
 
Spartacus

Spartacus

Flieger-Ass
Dabei seit
13.10.2010
Beiträge
491
Zustimmungen
469
Ort
Braunschweig
FG = gewicht * 9.81;
T = 288.15 - (0.0065 * pos_z);
p = 1 - (0.0065 * pos_z / 288.15);
druck = 9.80665 / 0.0065 / R;
p = Math.pow(p, druck);
p = p * 101325;
rho = p / R / T;

C_wert = rho * 0.5 * v_neu^2 * 427.8;
if (C_wert!=0&&pos_z==0) { CL = 0; }
else if (C_wert!=0) { CL = FG / C_wert; }
else { CL = 0; }
CL_diff = CL - CL0;
CD = CD0 + K0 * CL_diff^2;
FW = CD * C_wert;

M = v_neu / sqrt(K1 * T * R);
x_pkt_pkt = FT [Schub in N] - (sinus(gamma) * FG + FW);
x_pkt_pkt = x_pkt_pkt / gewicht;
v = x_pkt = x_pkt_pkt * dt;
a = x_pkt_pkt;
x_neu = x_alt + v * dt + 0.5 * a * dt^2;
v_neu = v_alt + a * dt;
x_erde = x_erde + v_neu * cosinus(gamma) * dt;
Aus Sicht eines Informatikers (und Piloten, aber nicht Aerodynamikers) hat der Code an mehreren Stellen "Potential":
  • Genannt wurde schon, dass Du besser vorher Konstanten definierst und die dann im weiteren Verlauf nutzt. Beispiel: Ich sehe in Zeile 1 eine 9,81 und in Zeile 4 eine 9,80665. Entscheide Dich für eine Genauigkeit bei Deinen Konstanten
  • Auch schon genannt: In Zeile 3 errechnest Du p, in Zeile 4 machst Du was Anderes, und in Zeile 5 und 6 veränderst Du noch mal p. Wenn Du schon nicht alles in eine einzige Formel packen kannst/willst, dann halte die Zeilen wenigstens beieinander
  • GANZ wichtig: Wenn Du mit reellen Zahlen rechnest, dann wird dein Vergleich in Zeile 10 "...pos_z==0" in den seltensten Fällen zutreffen. Ist pos_z überhaupt eine reelle Zahl bei Dir? Oder eine ganze Zahl? Falls reell, solltest du eine Vergleichsfunktion mit einer gewissen "Bandbreite" schreiben und die an dieser Stelle aufrufen. Und wenn Dein "C_wert" ständig nahe bei 0 pendelt, kann das an der Stelle auch treffen
  • Warum führst Du in Zeile 21 a ein, statt in 22 und 23 direkt mit x_pkt_pkt zu rechnen? Das hat doch keinerlei Mehrwert. Merke: So viele Variablen wie nötig, aber so wenig wie möglich
  • Auch wenn viele Programmiersprachen es zulassen, so ist eine verkettete Zuweisung wie in Zeile 20 doch "schlechter Stil". Lieber zwei Zeilen. Dann ist das Ganze auch besser lesbar und der Debugger kommt auch besser klar. Es gibt zwar Wettbewerbe für den kürzestmöglichen Code, aber wenn Dein Code in der Zukunft weiterentwickelt und gepflegt werden können soll, dann musst Du an solchen Sachen nicht teilnehmen ;-)
Das war jetzt mal ein kleiner Rundumschlag zum Programmierstil. Aber glaube mir: Fehler finden sich in lesbarem Code auch besser, als in "Spaghetti-Code".
Wenn Du den Code auf lesbar umbaust, kann es auch sein, dass Du den Fehler selbst schon direkt findest.

Viel Erfolg

Spartacus
 
Schorsch

Schorsch

Alien
Dabei seit
22.01.2005
Beiträge
12.762
Zustimmungen
5.720
Ort
mit Elbblick
Leute, verschont den armen Stefan doch bitte mit sicherlich gut gemeinten Ratschlägen zum richtigen Programmieren.
Er schießt hier mit Pfeil und Bogen, und nicht mal mit besonders spitzen.

Aber das unterstütze ich:
- eindeutige Namen
- keine Doppeloperationen

Etwa würde ich konsistent
[Richtung]_[Koordinatensystem]_[Derivativ]
nehmen.
Also
x_flz_pp
für die Beschleunigung in x-Richtung Flugzeug.
 

stefanpc81

Fluglehrer
Dabei seit
22.01.2016
Beiträge
106
Zustimmungen
2
Danke @all!
Ich habe jetzt meine Programmierung den Ratschlägen nach geändert/verbessert.
Ich habe vor wie nach der Umstellung einen Testlauf gemacht und muss folgendes loswerden:
Die negativen Werte kommen dann, sobald ich das Flugzeug mit z.B. (gamma)=18° fliegen lasse. Die Geschwindigkeit v_neu geht schnell runter und springt nach ein paar weiteren Sekunden von positiv nach negativ um (z.B. auf -160 kts), erreicht dazwischen nicht einmal die v_neu um die 0.
Ich vermute mal, dass der Fehler ganz woanders liegt. Nämlich bei

FT_minus = (sinus(gamma) * FG) + FW;
a1 = FT - FT_minus;

m.E. ist die Einberechnung des sinus(gamma) von FG gar nicht richtig, da sie Teil der Gewichtskraft ist und letztere ja bereits durch die Auftriebskraft vollständig kompensiert wird. Die Schubkraft wird aufgrund der schnelleren Höhenänderung entsprechend schnell geringer, hinzu kommt ein starker Widerstand aus sinus(gamma), der die v_neu zusätzlich runter reißt.

Ich habe jetzt gerade mit a1 = FT - FW einen neuen Testlauf gemacht und siehe da, selbst mit (gamma)=30° steigt die Geschwindigkeit und es kommt kein Minus bei raus.
 

LFeldTom

Astronaut
Dabei seit
01.08.2002
Beiträge
2.581
Zustimmungen
1.336
Ort
Niederrhein
gamma = 18° ist auch ein ganz schöner Brocken. Du fliegst ja kein Kampfflugzeug.

"Springen" sollten die Werte aber nicht.

Vielleicht hast du ja Lust deinen aktuellen Source Code mal komplett weiter zu geben. Mehr Augen sehen manchmal auch mehr...
 
Schorsch

Schorsch

Alien
Dabei seit
22.01.2005
Beiträge
12.762
Zustimmungen
5.720
Ort
mit Elbblick
Danke @all!
Ich habe jetzt meine Programmierung den Ratschlägen nach geändert/verbessert.
Ich habe vor wie nach der Umstellung einen Testlauf gemacht und muss folgendes loswerden:
Die negativen Werte kommen dann, sobald ich das Flugzeug mit z.B. (gamma)=18° fliegen lasse. Die Geschwindigkeit v_neu geht schnell runter und springt nach ein paar weiteren Sekunden von positiv nach negativ um (z.B. auf -160 kts), erreicht dazwischen nicht einmal die v_neu um die 0.
Ich vermute mal, dass der Fehler ganz woanders liegt. Nämlich bei

FT_minus = (sinus(gamma) * FG) + FW;
a1 = FT - FT_minus;

m.E. ist die Einberechnung des sinus(gamma) von FG gar nicht richtig, da sie Teil der Gewichtskraft ist und letztere ja bereits durch die Auftriebskraft vollständig kompensiert wird. Die Schubkraft wird aufgrund der schnelleren Höhenänderung entsprechend schnell geringer, hinzu kommt ein starker Widerstand aus sinus(gamma), der die v_neu zusätzlich runter reißt.

Ich habe jetzt gerade mit a1 = FT - FW einen neuen Testlauf gemacht und siehe da, selbst mit (gamma)=30° steigt die Geschwindigkeit und es kommt kein Minus bei raus.
Herzlichen Glückwunsch: Du hast die Erdanziehungskraft entdeckt. Schon ne coole Sache mir zu sagen welcher meiner Formeln wohl falsch sind. Der Blinde erzählt dem Sehenden etwas von der Farbe.

Das an die Hand gegebene Formelwerkzeug gilt für Flugzustände nahe dem Horizontalflug. Sie sind auch in dessen Umgebung gültig bzw. verursachen nur kleine Fehler. 18° Flugbahnwinkel schafft ein Verkehrsflugzeug eventuell ohne jegliche Nutzlast kurz nach dem Start bei der richtigen Geschwindigkeit für kurze Zeit.
Wenn Du Schrottwerte eingibst, wundere Dich nicht, dass Schrottwerte rauskommen. Die Simulation kann dafür nichts, ein Computer macht was man schreibt, nicht was man will.

Dein "Korrekturversuch" hat mal entspannt die Gewichtskraft rausgenommen. Ist Dir schon aufgefallen, dass man beim Berg hinauffahren mehr Gas geben muss? Genau, diesen Effekt hast Du erfolgreich gestrichen und deswegen kannst Du auch bei einem Anstieg von 32% (das entspricht 18° Gamma) noch beschleunigen.

Das "Springen" kommt vermutlich von einem immer noch zu großen Zeitinkrement (wie ist das eigentlich?), weil die IE11+Java Plattform anscheinend einen Multi-Core Prozessor auf die Geschwindigkeit eines 386SX Rechners runterprügelt.
 

LFeldTom

Astronaut
Dabei seit
01.08.2002
Beiträge
2.581
Zustimmungen
1.336
Ort
Niederrhein
Das "Springen" kommt vermutlich von einem immer noch zu großen Zeitinkrement (wie ist das eigentlich?), weil die IE11+Java Plattform anscheinend einen Multi-Core Prozessor auf die Geschwindigkeit eines 386SX Rechners runterprügelt.
Um das auszuschließen kann man ja erstmal mit festen, kleinen Intervallen rechnen. Muss ja nicht zwangsläufig Echtzeit am Anfang sein.

Zur Performance: Java != Javascript. Nun ist Javascript auch nicht gerade meine Wahl wenn man sowas implementieren möchte - aber einen Einbruch auf 386SX Niveau wird es da nicht geben (auch bei Java nicht). Und selbst bei einem 386SX+387SX kann man mit einer durchdachten Implementierung da noch gescheite Frequenzen hin bekommen. Das ist immer noch deutlich mehr als den früher A320 für das FCS zur Verfügung stand (auch ohne 387SX).

Wenn Stefan Lust hat mag ich das gerne mal portieren und auch ein paar Benchmarks dazu machen.
 
Spartacus

Spartacus

Flieger-Ass
Dabei seit
13.10.2010
Beiträge
491
Zustimmungen
469
Ort
Braunschweig
weil die IE11+Java Plattform anscheinend einen Multi-Core Prozessor auf die Geschwindigkeit eines 386SX Rechners runterprügelt
Dass JavaScript nun nix mit Java zu tun hat, weißt Du aber?
In Java ließe sich das durchaus hochperformant rechnen. Die Performance-Probleme von Java aus dessen Anfangszeiten sind seit mehreren Versionen Geschichte.

Nur, um hier keine falschen Ideen aufkommen zu Lassen ;-)

Spartacus
 
Thema:

Auftriebsbeiwerte für B777 in Flugsimulatoren?

Auftriebsbeiwerte für B777 in Flugsimulatoren? - Ähnliche Themen

  • Militärgeschichtliche Sammlung Lechfeld ab 03.03.2024 wieder für die Öffentlichkeit zugänglich

    Militärgeschichtliche Sammlung Lechfeld ab 03.03.2024 wieder für die Öffentlichkeit zugänglich: Am Sonntag, den 03.03.2024, ist unsere Sammlung (MGSL) in der Lechfeldkaserne wieder für Besucher zugänglich. Zu beachten ist dabei folgendes: -...
  • Deutsche Luftwaffe plant große Asien-Pazifik-Tour für 2024

    Deutsche Luftwaffe plant große Asien-Pazifik-Tour für 2024: [Diese Nachricht ist vom November, aber ich habe selbst erst diese Woche davon erfahren, und auch eine Suche hier bringt keine Treffer, daher...
  • Transportflugzeuge für Träger

    Transportflugzeuge für Träger: Eine der wesentlichen Unterstützungen, die Flugzeugträger brauchen, sind Transporter - die schnell große Distanzen zurück legen können und daher...
  • Was ist das für ein Fluggerät?

    Was ist das für ein Fluggerät?: Moin, ich hoffe ich bin hier halbwegs richtig. Ich habe am Wochenende in der nähe von Lüneburg dies Fluggerät beobachtet. Es bewegt sich in...
  • Daten für Manning Flanders MF.1 gesucht

    Daten für Manning Flanders MF.1 gesucht: Ich suche die techn. Daten für den Monoplane Manning Flanders MF.1 aus dem Jahr 1910 Leider bietet das www nur Bilder z.B. hier In den 1970-iger...
  • Ähnliche Themen

    Sucheingaben

    content

    Oben