spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Von denen, die ich brauche, liegen so etwa 10 mal die gleichen im Speicher.
Davon sind meist 2 statisch und der Rest dynamisch. War reine Glückssache, dass ich das herausgefunden habe.

Mit ArtMoney geht das aber "ganz einfach". Erstmal muss ein Wert bekannt sein. Zum Glück kann man die "Flüge aufzeichnen". Also ganz kurz das Flugzeug auf der Startposition "gefilmt" und es abheben lassen. Dabei nach ziehen und nach links rollen.
Wenn alles "auf Tape" ist, öffne ich die Datei, die den Flug enthält. Und siehe da: Position, relativer Vektor nach vorn, relativer Vektor nach oben sind da drin gespeichert.
Da hab ich die an Anfang genommen und nach einem Neustart nach fast genau diesen Werten gesucht (Wertebereich). Ein Stück bewegt, und nach Werten filtern, die größer/kleiner geworden sind. Das eine ganze Weile machen, bis am Ende ~30 Werte herauskommen. Diese anzeigen lassen und "nach Augenmaß" die falschen aussortieren.
Dann sind aber immernoch so 10 Stück übrig. Manche geben zum Beispiel die Orientierung des Fahrwerks an. Aso einfahren, filtern.
Dann mal das Flugzeug wechseln, so fallen auch noch mal einige weg.
Das Programm neustarten, sind es wieder weniger.
Bis am Ende meist noch genau 3 Stück übrig waren. Davon war bei der Position zum Beispiel einer immer etwas hinter den anderen. Also weg. Da sich bei den letzten beiden nichts mehr geändert hat, hab ich einfach einen der beiden genommen.

Dann hab ich das "Umfeld" abgesucht. Also 4 Bytes vor, bzw. 4 Bytes zurück. Irgendwo müssen die zum Vektor gehörigen Koordinaten ja liegen.
Und so hab ich das mit der absoluten Position, der Zeit seit Programmstart, der absoluten Geschwindigkeit, dem relativen Vektor nach oben und dem relativen Vektor nach vorn gemacht. Mehr benötige ich nicht.

Aus den beiden relativen Vektoren stelle ich mir die Orientierungs-Matrix auf (Kreuzprodukt berechnet den fehlenden Vektor). Damit rechne ich die absolute Geschwindigkeit in die relative um, differenziere diese mit der vergangenen Zeit und bekomme so die relative Beschleunigung. Addiert man jetzt noch die relative Gravitation, hat man die Werte, die ein 3D-Beschleunigungssensor messen würde.
Die Orientierungs-Matrix des letzten Frames und die aktuelle werden dividiert. So erhalte ich die Drehung seit dem letzten Frame. Bei rund 60 FPS sind das bei gemütlichem Flug sehr kleine Winkel, also rechne ich mir direkt die Euler-Winkel raus. Diese durch die vergangene Zeit geteilt, ergibt die Drehrate - die Werte des 3D-Gyroskops. Das 3D-Magnetometer ist am einfachsen. Ich suche mir die aktuelle magnetische Deklination und den Azimuth des Erdmagnetfeldes vor Ort -> 3D-Polarkoordination * Feldstärke. Das ganze per Orientierungs-Matrix noch in den relativen Vektor umgerechnet und schon habe ich ein 3D-Magnetometer simuliert.

Derzeit bin ich dabei, das Attitude-Heading-Reference-System auf dem ARM Cortex M3 zu implementieren, welches mit den simulierten Daten direkt versorgt wird. Später kommt da noch etwas Rauschen, Offset und Skalierung, und bei den Gyros ein leichtes driften hinzu. Damit werden dann die "Filter" getestet und eingestellt. Aber für diese Feinheiten muss ich erstmal die richtigen Sensoren zum Laufen bekommen, einen Testflug machen und dabei die Daten loggen.
Aus denen berechne ich dann die Fehler, die ich in etwa zu den simulierten Daten hinzufügen muss.
Dann kommt die PID-Regelung dran, kaskadiert: Drehrate -> Orientierung -> Position.

Und so ganz nebenbei studiere ich noch Maschinenbau 1. Semester und derzeit laufen die Prüfungen. Jippiaje.
Aber das wird schon, noch, irgendwann, vieleicht mal fertig.