Brainstorming: Physik beim Drohnenflug und dessen Implementierung..

Für sonstige Unterhaltungen, welche nicht direkt mit Lazarus zu tun haben
corpsman
Beiträge: 1102
Registriert: Sa 28. Feb 2009, 08:54
OS, Lazarus, FPC: Linux Mint Mate, Lazarus SVN Trunk, FPC 3.0
CPU-Target: 64Bit
Wohnort: Stuttgart
Kontaktdaten:

Brainstorming: Physik beim Drohnenflug und dessen Implementierung..

Beitrag von corpsman »

Servus miteinander,

Ich bin in des FPV-Drohnenfliegen eingestiegen und habe mir gedacht es wäre doch cool einen eigenen Simulator zu schreiben (ich weis das ist unsinnig weil es schon viele gibt, einige sogar umsonst. Aber es geht ja um das Verständnis dahinter [und den Spass]).

Aktuell habe ich bereits erfolgreich erledigt:
-Auslesen der Funkfernsteuerung
-Mathematik die Notwendig ist um alle Bewegungsvektoren zu Berechnen (Pitch, Roll, Yaw, Throttle)
-Berechnen / Darstellen von Landschaften
-Bewegung der Kamera entsprechend der Bewegungsvektoren
-Kollision zwischen Drohne und Landschaft

Wie das ganze ausschaut könnt ihr hier sehen:
Vorschau.JPG
Vorschau.JPG (212.17 KiB) 483 mal betrachtet
Offen ist noch:
-Die Flugphysik

Hierzu mal folgende Gedanken:

Meine Drohne ist ein Punkt im Raum, dieser wird durch folgende Größen beeinfluss:
-Propeller (Auftrieb in Kamera Hoch[/ Runter bei inverted props] Richtung [ohne den CAM-Nick Offset mit dem die CAM auf der Drohne Montiert ist])
-Schwerkraft (Sinken Absolut nach Unten)
-Massenträgheit
-Luftreibung ?
-???

Meine Bisherige Idee:
Die Drohne hat Position / Geschwindigkeit (alles 3D-Vektoren)

* Alle X ms versetze ich die Position um die Geschwindigkeit scalliert mit X
* Alle X ms addiere ich auf die Geschwindigkeit den "G-Vektor"scalliert mit X nach unten
* Alle x ms Scalliere ich den Geschwindigkeitsvektor mit einem Wert >0 und <1 um den Luftwiderstand zu realisieren (Irgendwie kommt mir das falsch vor steigt der Luftwiderstand nicht mit der Geschwindigkeit..)?
* Alle X ms Addiere ich auf die Geschwindigkeit den Schubkraftvektor scalliert mit X (transformiert entsprechend der Kamera Richtung)

=> Damit wäre Geschwindigkeit meine Massenträgheit

1. Würde das Funktionieren / macht das halbwegs Sinn ?
2. Ich würde ganz gerne Dinge wie das Drohnen Gewicht / Maximale Schubkraft der Propellor berücksichtigen. Im Obigen Beispiel würde meine Drohne bei Vollgas ja unendlich beschleunigen, das ist natürlich unrealistisch, oder reicht die Dämpfung des Luftwiderstand aus um das zu begrenzen ?
3. Wie realisiert man also das die Propellor die Drohne nur maximal beschleunigen können ?

Ihr seht fragen über Fragen.

Wie seht ihr das, passt mein Ansatz ist das kompletter Unsinn (und wenn ja wie macht man es besser)...
--
Just try it

Winni
Beiträge: 157
Registriert: Mo 2. Mär 2009, 16:45
OS, Lazarus, FPC: Laz2.06, fpc 3.04
CPU-Target: 64Bit
Wohnort: Fast Dänemark

Re: Brainstorming: Physik beim Drohnenflug und dessen Implementierung..

Beitrag von Winni »

Hi!

Der Luftwiderstand geht zum Quadrat der Geschwindigkeit.

Deshalb möchten die Designer immer am liebsten Karosserien ohne Außenspiegel bauen.

Und deshalb sind manche Karosserien denkbar ungeeignet für hohe Geschwindigkeiten, wie z.B. der ,VW-Bus: "Luftwiderstand wie ein Kleiderschrank" heisst es in Designerkreisen.

Winni

mschnell
Beiträge: 3404
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: Brainstorming: Physik beim Drohnenflug und dessen Implementierung..

Beitrag von mschnell »

Ivch vermute, das ist wesentlich komplexer.
Ich würde erst einmal anfangen einen freien Fall (Parabel) zu realisieren

v+= dv,
dvx=dvy= 0,
dvz += ddvz ,
ddvz = G (Erdbeschleunigung).

Dann könntest Du den Luftwiderstand / Einfluss einrechnen:
dv+= v² * L (alle Richtungen, angenommen, das Ding ist eine Kugel, bei einem Flugzeug mit Flügeln natürlich ganz anders, weil Vortrieb in Auftrieb umgewandelt wird. Bei Erreichen der Schallgeschwindigkeit ändert sich da auch noch einiges.)

Der motorische Auf- und Vortrieb hängt natürlich von der Bauart, aktueller Motor(en)-Einstellung(en) und der Lage im Raum ab.

-Michael

kupferstecher
Beiträge: 263
Registriert: Do 17. Nov 2016, 11:52

Re: Brainstorming: Physik beim Drohnenflug und dessen Implementierung..

Beitrag von kupferstecher »

Normal berechnet man das über das Kräftegleichgewicht, Summe aller Kräfte = 0;

Kräfte ergeben sich aus
- der Erdbeschleunigung
- den Antrieben* und
- der Reibung.
Die Summe dieser Kräfte ist die Beschleunigungskraft. Alles vektoriell natürlich. Die Beschleunigungskraft ergibt über das Gewicht deine Beschleunigung (F=m*a), aber das brauch ich dir nicht sagen :).

*Bei den Antrieben spielt der Kippwinkel mit rein, je nachdem bekommst du einen Vertikal- und Horizontalanteile.
corpsman hat geschrieben:
Do 30. Apr 2020, 10:37
-Mathematik die Notwendig ist um alle Bewegungsvektoren zu Berechnen (Pitch, Roll, Yaw, Throttle)
Kannst du was dazu schreiben, wie stellst du die Lage im Raum dar? Ist nämlich nicht ganz einfach, wenn man die Position in absoluten Koordinaten mitführen möchte, was in der Simulation ja nötig ist.

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 4101
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Niederösterreich
Kontaktdaten:

Re: Brainstorming: Physik beim Drohnenflug und dessen Implementierung..

Beitrag von af0815 »

Grundlegend ist die Physik ein Hund. Weil die Reibung = Luftwiderstand der Drohne je nach Vektor verschieden ist. Alleine die wirksame Fläche ändert sich.
Die Frage ist wie gut soll die Simulation sein :-)

BTW: Ich habe das bei einer blöden Simulation beim Radfahren erfahren müssen. Siehe auch http://www.kreuzotter.de/deutsch/speed.htm
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Mathias
Beiträge: 4713
Registriert: Do 2. Jan 2014, 17:21
OS, Lazarus, FPC: Linux (die neusten Trunc)
CPU-Target: 64Bit
Wohnort: Schweiz

Re: Brainstorming: Physik beim Drohnenflug und dessen Implementierung..

Beitrag von Mathias »

-Berechnen / Darstellen von Landschaften
Deine Landschaft sieht genial aus, hast du die mit OpenGL gemacht ?
Mit Lazarus sehe ich gün
Mit Java und C/C++ sehe ich rot

corpsman
Beiträge: 1102
Registriert: Sa 28. Feb 2009, 08:54
OS, Lazarus, FPC: Linux Mint Mate, Lazarus SVN Trunk, FPC 3.0
CPU-Target: 64Bit
Wohnort: Stuttgart
Kontaktdaten:

Re: Brainstorming: Physik beim Drohnenflug und dessen Implementierung..

Beitrag von corpsman »

Hallo Alle Zusammen,

Danke erst mal für eure Hinweise ich versuche diese mal auf zu arbeiten
Deine Landschaft sieht genial aus, hast du die mit OpenGL gemacht ?
Danke für die Blumen, natürlich ist das OpenGL. Das ist auch Recht unspektakulär gemacht ist einfach nur ein Trianglestrip im Wireframe Mode Ohne Wireframe sieht es noch nicht so gut aus, weil mein Textur erzeugungsalgorithmus 1:1 skalliert (das kriege ich besser hin aber vorerst reicht es)
Vorschau2.png
Vorschau2.png (101.89 KiB) 413 mal betrachtet
Die Frage ist wie gut soll die Simulation sein.
Das ist ein Spass Projekt, in der Regel fange ich irgendwie an und iteriere dann so lange bis ich entweder nicht mehr weiter weis oder es gut genug aussieht.
=> gerade bin ich noch in der Phase, das man sieht das es unrealistisch ist. Ich würde ganz gerne wenigstens soweit kommen dass es halbwegs glaubwürdig wirkt *g*.
Kannst du was dazu schreiben, wie stellst du die Lage im Raum dar? Ist nämlich nicht ganz einfach, wenn man die Position in absoluten Koordinaten mitführen möchte, was in der Simulation ja nötig ist.
Ja das war zu Anfangs etwas Kniffelig, vor allem weil ich auch noch die Richtung der Z-Achse gedreht habe (ein Rein Persöhnliches Feature hat nichts mit der Mathe zu tun).

Wenn man aber mal weis wie es geht ist es echt einfach und das will ich euch natürlich nicht vor enthalten (wie es dazu kam, kann man hier nachlesen: https://delphigl.com/forum/viewtopic.php?f=30&t=11700 )

Zur Mathematik ein paar Details:
In OpenGL gibt es keinen Unteschied zwischen Welt Koordinaten und Kamera Koordinaten (deswegen heist es auch ModelView Matrix)
=> entweder man bewegt die Welt um die Kamera oder die Kamera um die Welt, macht keinen Unterschied, außer das eben alles Negativ wird.

Ich Rendere also meine Welt in Absolut Koordinaten und Drehe vorher die Kamera:

Code: Alles auswählen

Procedure TForm1.OpenGLControl1Paint(Sender: TObject);
Var
  Delta, t: uint64;
Begin
  If Not Initialized Then Exit;
  // Render Szene
  glClearColor(0.0, 0.0, 0.0, 0.0);
  glClear(GL_COLOR_BUFFER_BIT Or GL_DEPTH_BUFFER_BIT);
  glLoadIdentity();
  t := GetTickCount64();
  delta := t - fLastTick;
  fLastTick := t;
  fDrone.Move(delta);
  fDrone.Render(); // Die Drohne besteht im Prinzip nur aus einer sich Bewegenden Kamera
  fmap.Render();
  OpenGLControl1.SwapBuffers;
End; 
Der Fürs Rendern Relevante Teil ist dann wie Folgt:

Code: Alles auswählen

Procedure TCam.CamToOpenGL();
Begin
  If fCamAngle <> 0 Then Begin
    glRotatef(-fCamAngle, 1, 0, 0);
  End;
  glMultMatrixf(@fMatrix);
End; 
Man Beachte den "CAMAngle" dieser ist unabhängig, das ist deswegen so weil ich damit eine für alle Berechnungen "unsichtbare" Rotation der Kamera machen kann (siehe CAM-Angle on Real Drone ;) ).

FMatrix ist also das Ding das das Geheimnis macht. In der Mathematik nennt man so ein Ding Basiswechselmatrix
=> Das Ding Rechnet also Weltkoordinaten in Kamerakoordinaten um.

Will ich nun die Kamera drehen kann ich das entweder von Hand Berechnen, oder lasse es OpenGL machen und das geht dann so:

Code: Alles auswählen

Procedure TCam.Roll(Angle: Single);
Begin
  glPushMatrix();
  glLoadIdentity();
  glRotatef(-Angle, 0, 0, 1);
  glMultMatrixf(@fMatrix);
  glGetFloatv(GL_MODELVIEW_MATRIX, @fMatrix);
  glPopMatrix();
End; 
Ich habe auch eine eigene Mathe Library die das genauso machen kann, nur so geht es halt "schneller"

Man kann so auch die Kamera bewegen:

Code: Alles auswählen

Procedure TCam.StrafeUpWay(delta: Single);
Begin
  glPushMatrix();
  glLoadIdentity();
  glTranslatef(0, -delta, 0);
  glMultMatrixf(@fMatrix);
  glGetFloatv(GL_MODELVIEW_MATRIX, @fMatrix);
  glPopMatrix();
End;
Der bisherige Code hat auch so funktioniert => die Kamera wird aus sicht dieser nach Oben Versetzt.
=> Dieses Verfahren hat aber 2 Nachteile
1. Ich kann die Physik nicht sauber rein Rechnen
2. Ich weis nicht wo ich bin

das 2. ist, wenn man die Eigenschaften der Matrix Kennt leicht zu erledigen, man braucht nur die Inverse Matrix und kann so Kamera Koordinaten wieder zurück Rechnen in Absolute:

Code: Alles auswählen

Function TCam.GetPosition: TVector3;
Var
  m: TMatrix4x4;
  v, p: TVector4;
Begin
  v := v4(fMatrix[3, 0], fMatrix[3, 1], fMatrix[3, 2], 0); // Die Position in Kamera-Space
  m := TransposeMatrix(fMatrix); // Da es sich um eine Ortohonalmatrix Handelt ist die Inverse die Transponierte
  p := m * v; // Rückprojektion der Kamera Position in das Absolute Koordinatensystem
  result := v3(-p.x, -p.y, -p.z); // Typconvertierung
End; 
Und damit kann man dann auch "leicht" das 1. Lösen. Denn Wenn meine Drohne Gas gibt muss ich ja wissen wie sich die Beschleunigung in Absolut Koordinaten Auswirkt und das geht ganz einfach wenn für V nicht die Werte Aus der Matrix nimmt sondern

Code: Alles auswählen

 v := v4(0,Thrust,0);
Result wird dann zu den Nach Achsen Separierten Anteilen umgerechnet ;).

So viel zur Mathematik, wem das nicht Reicht einfach noch mal Konkreter Nachfragen ;).

So nun aber zu meinen Themen:

Folgendes habe ich gemacht und es schaut schon mal deutlich besser aus (leider kann ich hier keine Filme hochladen, sonst könntet ihr es auch sehen *g*).
- Driften geht schon ;)
- Achtung wer den Code Nachvollziehen Will bei mir ist x nach Links, y nach Oben und z nach Vorne

Code: Alles auswählen

Const
  Gravity = 9.8 / 10;  // Die musste ich doch drastisch "kürzen"
  Throttle: Single = Gravity * 2; // Die Drohne muss stärker als die Gravitation sein, sonst fliegt sie nicht (Typisch ist normalerweise Faktor 4-8)

Procedure TDrone.MoveAcro();
Var
  f: Single;
Begin
  // Throttle
  f := Input.Throttle(); // [-1..1]
  If fPropMode = pmNormal Then Begin // Normal Fliegen
    f := (f + 1) / 2; //Umrechnen nach [0..1]
    fActualForce := fActualForce + fcam.ConvertCamCoordToWorldCoord(V3(0, -Throttle * f, 0));
  End
  Else Begin // Inverted Flugmodus
    fActualForce := fActualForce + fcam.ConvertCamCoordToWorldCoord(V3(0, -Throttle * f, 0));
  End;
  // Yaw
  fcam.Yaw(Turn * Input.Yaw());
  // Roll
  fcam.Roll(Turn * Input.Roll());
  // Pitch
  fcam.Pitch(Turn * Input.Pitch());
  If assigned(Map) Then Begin
    // Schwerkraft
    fActualForce := fActualForce + v3(0, -Gravity, 0);
  End;
End;

Procedure TDrone.Move(Delta_ms: Integer);
Var
  p: TVector3;
Begin
  If Not assigned(Input) Then exit;
  fActualForce := v3(0, 0, 0);
  Case fFlightMode Of
    fmAcro: MoveAcro();
    fmArcade: MoveArcade();
  End;
  fVelocity := fVelocity + fActualForce * Delta_ms / 1000;
  p := fCam.Position;
  p := p + fVelocity;
  fcam.Position := p;
  // Kollisionen ..
  If assigned(Map) Then Begin
    If fCam.CollideWithGround(map.GetHeightAtPosition(p.x, p.z)) Then Begin
      fVelocity := v3(0, 0, 0);
    End;
  End;
End;
=> Es fehlt also noch der Luftwiderstand, wie mache ich das ?
=> Es fehlt noch die Geschwindigkeitsbegrenzung (das dürfte doch dann der Luftwiderstand erledigen)?
=> Es fehlt noch die Masse der Drohne (oder macht man das in dem man einfach Throttle anpasst)?

-\
-/ So siehts schon mal deutlich besser aus, ich musste G aber um Faktor 10 Reduzieren und auch mein Throttle ist irgendwie nur geraten
--
Just try it

Warf
Beiträge: 1412
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: MacOS | Win 10 | Linux
CPU-Target: x86_64
Wohnort: Aachen

Re: Brainstorming: Physik beim Drohnenflug und dessen Implementierung..

Beitrag von Warf »

In der Schule hatten wir damals im Physik Unterricht Finite Difference Time Domain benutzt um Simulationen von kräften zu beschreiben (https://www.wikiwand.com/de/Finite_Diff ... ime_Domain)

Die idee dabei ist das man die Zeitachse diskretisiert und die änderungen zwischen den Zeitschritten als linear animmt (Wenn ich jetzt ne ahnung von Numerik hätte wüsste ich wie diese art von Integral approximation heißen würde).

So machen das übrigens auch PC spiele, daher werden Spiele Engine gerne für Simulationen benutzt, z.b. Nutzt das US militär die Cry-Engine um simulationen zu bauen.

Ich bastel mir ganz gerne mal so kleinere Physik simulationen mit dieser technik, geht ganz einfach:
Du legst dir ne Liste mit Forces an, und in jedem Zeitschritt berechnest du dann

Code: Alles auswählen

// compute forces
Forces[0] := G*m1*m2/r^2 *direction // gravity
// compute sum of forces as acceleration
Acceleration := 0;
for force in Forces do
  Acceleration += force * mass;
// apply forces
Position := Position + Velocity * delta;
Velocity := Velocity + Acceleration * delta;
Ich hab vielleicht irgendwo auf der Platte noch eine kleine Simulation rumfliegen, falls ich sie finde poste ich sie hier mal

corpsman
Beiträge: 1102
Registriert: Sa 28. Feb 2009, 08:54
OS, Lazarus, FPC: Linux Mint Mate, Lazarus SVN Trunk, FPC 3.0
CPU-Target: 64Bit
Wohnort: Stuttgart
Kontaktdaten:

Re: Brainstorming: Physik beim Drohnenflug und dessen Implementierung..

Beitrag von corpsman »

@Warf,

Was du da beschreibst ist ja genau was ich gemacht habe, nur das du in der Gravity noch eine Masse multipliziert hast.
Ich habe auch Diskrete Zeitschritte (delta), damit müsste ich genau die Beschriebene Methode haben,

Das Flugbild sieht ja auch schon echt Toll aus. Die Frage war ja wie ergänze ich meine Berechnungen um den Luftwiderstand.

mschnell hatte das mit
dv+= v² * L
beschrieben, nur hatte ich nicht verstanden wie ich das mit einbauen kann ...
--
Just try it

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 4101
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Niederösterreich
Kontaktdaten:

Re: Brainstorming: Physik beim Drohnenflug und dessen Implementierung..

Beitrag von af0815 »

mschnell schrieb aber was von einer Kugel, das hast du ja nicht.

Dumme Frage, hast du vor dein bisheriges Modell mit der Natur abzugleichen ?
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

corpsman
Beiträge: 1102
Registriert: Sa 28. Feb 2009, 08:54
OS, Lazarus, FPC: Linux Mint Mate, Lazarus SVN Trunk, FPC 3.0
CPU-Target: 64Bit
Wohnort: Stuttgart
Kontaktdaten:

Re: Brainstorming: Physik beim Drohnenflug und dessen Implementierung..

Beitrag von corpsman »

Er schrieb das der Luftwiderstand bei einer Kugel Gleichförmig ist, ich also eigentlich die Lage der Drohne bei der Berechnung des Luftwiderstands berücksichtigen müsste, dies kann ich vernachlässigen, wenn wenn ich eine Kugelform annehme (was auch mein Plan gewesen wäre, ich wills ja nicht übertreiben..)

Und nein ich habe nicht vor es gegen die Natur zu testen, ich selbst fliege aber fast Täglich mehrere Akkus mit meiner Minidrohne durchs Haus und wo es die Situation zuläst auch draußen. Daher versuche ich schon die Simulation so realistisch wie möglich zu machen.

Ich denke wenn ich den Luftwiderstand mit einberechne kriege ich ein gutes Mittel hin die Maximale Geschwindigkeit zu Begrenzen (ja ich weis ich könnte auch einfach die Beschleunigung kappen) aber ich denke das Versuche ich noch bevor ich auf diesen Letzten Weg zurückgreife.

Wenn ich das Speedlimit habe, wollte ich mich noch an einem "Propwash" genannten Effekt versuchen und dann bin ich zufrieden. Hab ja noch ein paar andere sachen mit meiner Simulation vor ;).
--
Just try it

Warf
Beiträge: 1412
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: MacOS | Win 10 | Linux
CPU-Target: x86_64
Wohnort: Aachen

Re: Brainstorming: Physik beim Drohnenflug und dessen Implementierung..

Beitrag von Warf »

Du hast mich grad ein kleines bisschen generdsniped, ich habe zwar meinen alten Code nicht mehr gefunden, aber hatte grade lust mal selbst wieder ne kleine Simulations-engine zu bauen. Hab den code mal angehängt.

Simuliert die Bahnen des Mondes um die Erde, und man kann Luftwiederstand hinzufügen. Habe an den entsprechenden Stellen die Wikipediaartikel mit den Formeln verlinkt.
Dateianhänge
Simulation.zip
(6.17 KiB) 7-mal heruntergeladen

kupferstecher
Beiträge: 263
Registriert: Do 17. Nov 2016, 11:52

Re: Brainstorming: Physik beim Drohnenflug und dessen Implementierung..

Beitrag von kupferstecher »

Danke für die ausführliche Beschreibung zur Vektorgeometrie.
corpsman hat geschrieben:
Do 30. Apr 2020, 19:03
mschnell hatte das mit
dv+= v² * L
beschrieben, nur hatte ich nicht verstanden wie ich das mit einbauen kann ...
Hattest oder hast?

dv ist ja die Geschwindigkeitsänderung, also Beschleunigung.
a = v²*L
oder
F/m = v²*L
oder
F_reib = v²*L*m
oder
F_reib = v²*L_2

Diskretisiert kommst du wieder auf die += Schreibweise.

corpsman
Beiträge: 1102
Registriert: Sa 28. Feb 2009, 08:54
OS, Lazarus, FPC: Linux Mint Mate, Lazarus SVN Trunk, FPC 3.0
CPU-Target: 64Bit
Wohnort: Stuttgart
Kontaktdaten:

Re: Brainstorming: Physik beim Drohnenflug und dessen Implementierung..

Beitrag von corpsman »

@Kupferstecher
Manchmal hat man Tomaten vor den Augen, ich habe immer noch nicht:

Aus dem Beispiel von Warf habe ich nun gesehen, dass ich alle Kräfte durch die Masse Teilen muss, wenn ich Masse Simulieren will.

Aber der Luftwiderstand äergert mich immer noch, evtl kannst du es mir ja in den unten stehenden "Zusammengefassten" Code integrieren.

Code: Alles auswählen

Procedure TDrone.Move(Delta: Integer); 
Const
  cw: Single = 0.45; // CW-Wert einer Kugel ( https://de.wikipedia.org/wiki/Str%C3%B6mungswiderstandskoeffizient )
  A: Single = 0.3 * 0.3; // Ungefähre Fläche einer 30cm*30cm großen Drohne
Var 
  d, p: TVector3; 
Begin 
  fActualForce := v3(0, 0, 0); 
  // Aufsummieren aller Kräfte die auf die Drohne wirken können
  // Steuerbefehle
  f := Input.Throttle(); // [-1..1]
  If fPropMode = pmNormal Then Begin // Normal Fliegen
    f := (f + 1) / 2; // Umrechnen nach [0..1]
    fActualForce := fActualForce + fcam.ConvertCamCoordToWorldCoord(V3(0, -Throttle * f, 0))/fmass;
  End
  Else Begin // Inverted Flugmodus
    fActualForce := fActualForce + fcam.ConvertCamCoordToWorldCoord(V3(0, -Throttle * f, 0))/fmass;
  End;
  (*
    * Code der die Drohne dreht ..
    *) 
  // Schwerkraft
  fActualForce := fActualForce + v3(0, -Gravity / fmass, 0);      
  
  fVelocity := fVelocity + fActualForce * (Delta / 1000);
  // Versuch den Luftwiderstand zu Berechnen
  //d := cw * A * 0.5 * fVelocity * fVelocity; -- Alt
  d := cw * A * 0.5 * DotV3(fVelocity, fVelocity) * fMass * fVelocity; // Warum brauche ich hier die Masse ?
  form1.caption := format('%0.2f / %0.2f / %0.2f', [d.x, d.y, d.z]); // Zum Debuggen
  fVelocity := fVelocity - d;
  p := fCam.Position;
  p := p + fVelocity;

  fcam.Position := p;  
  
end;
Mit dem hier Funktioniert die Simulation schon gar nicht schlecht, es fehlt leider immer noch
-Der Luftwiderstand (der Obige Code erzeugt einen Luftwiderstand von immer 0
-Die Korrekte Simulation/ Berechnung von Throttle (Wenn meine Drohne x Gramm wiegt, jeder Motor y-Gramm Schub erzeugen kann, ist dann Throttle tatsächlich 4*y/x und gut ?)

[Edit]
Meine Mathelibrary hat einen Bug, wenn ich V3*V3 Mache kommt da kein Scalar sondern das Kreuzprodukt raus, deswegen war das recht Strange.
Die Neue Formel macht es deutlich "intuitiver", aber warum brauche ich hier die Masse ?
--
Just try it

Warf
Beiträge: 1412
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: MacOS | Win 10 | Linux
CPU-Target: x86_64
Wohnort: Aachen

Re: Brainstorming: Physik beim Drohnenflug und dessen Implementierung..

Beitrag von Warf »

Formel für drag: https://www.wikiwand.com/en/Drag_(physi ... es_of_drag
F = 1/2 * roh * v² * koeffizient * A
Beschleunigung:
F = m *a <=> a = F / m
Also ist die Beschleunigung
a = 1/2 * roh * v² * koeffizient * A / Masse

Wobei roh die dichte von luft ist (etwa 1), A der drag-koeffizient ist (du nimmst eine kugel an, drohnen sind eher windschnittig gestaltet, also ist ein wert zwischen 0.05 und 0.1 eher angebracht https://www.wikiwand.com/en/Drag_coefficient) A ist der die Projezierte Fläche gegen den wind (https://www.wikiwand.com/en/Cross_section_(geometry)).
Also wenn man die werte einsetzt kommt da 1/2 * v² * 0.1 * A / Masse.

Du musst also durch die Masse teilen und nicht damit multiplizieren. Am ende multiplizierst du auch nochmal mit dem Vektor fVelocity, wahrscheinlich um das ganze zu nem richtungsvektor zu machen, doch da musst du 1. den negativen vektor nehmen (immerhin ist drag in die entgegengesetzte richtung) und zum anderen den vektor normalisieren, damit der nicht die stärke der kraft beinflusst.

Das gesagt berechnest du mit dem drag eine kraft, in der zeile drüber:

Code: Alles auswählen

fVelocity := fVelocity + fActualForce * (Delta / 1000);
Berechnest du die geschwindigkeitsänderung aus der kraft. Warum fügst du den wert nicht zu totalForce hinzu und bevor du totalForce für die berechnung von Velocity benutzt?

PS: TotalForce ist eine Beschleunigung, also totalAcceleration, nicht ne Kraft, da du bereits schon durch die masse geteilt hast, der Name ist verwirrend

Antworten