[Projekt] EFIS

[IH82W8]

Hallo zusammen,

nachdem ihr mir in diesem Forum bereits bei zwei Problemen bzgl. Shadern geholfen habt, wird es Zeit, auch einmal mein Hobby-Projekt vorzustellen, das - mit Unterbrechungen - in den langen Hotelabenden der letzten beiden Jahre herangewachsen ist.

Ziel/ Motivation
Ziel des Projekts ist die Entwicklung einer mobilen Anwendung zur Unterstützung von Flugdurchführungen. Hierfür gab es "damals" zwar bereits mobile Geräte (z.B. PDA), die in Kombination mit einem GPS Empfänger eine zweidimensionale Kartennavigation bereitstellen, allerdings konnte keines dieser Geräte wirklich überzeugen (preislich & grafisch)... Betrachtet man den Detailreichtum aktueller Flugsimulatoren, stellte sich die Frage, wieso digitale Informationen (Landschaft, Lufträume, Hindernisse, Flugplätze, etc.) nur partiell für die Unterstützung bei der Flugdurchführung genutzt werden. Nachdem sich auch noch herausstellte, dass die SRTM Höhendaten der NASA in einem 1"-3" Raster (bei einer geschätzten Abweichung von nur 10m!) sowie Flugplatzdaten im Netz frei verfügbar sind, konnte die Umsetzung beginnen.

Plattform
Das System wird auf einem Laptop mit externer GPS Maus und 6-Achsen Beschleunigungssensoren entwickelt und getestet. Die derzeitige Zielplattform ist ein Tablet-PC - bis das System letztendlich "fertig" ist, sollten hoffentlich auch transparente OLED Folien auf dem Markt sein, um das System mit einem zusätzlichen HUD abzurunden.

Sonstiges
Das Projekt wird rein aus Interesse an der Luftfahrt und geodätischer Navigation (gem. WGS84) verfolgt. Nachdem die Navigationskomponente sowie die grundlegende Sensorik nun weitestgehend implementiert ist, beschäftige ich mich derzeit mit der grafischen Repräsentation - weswegen ich auch auf euer Forum aufmerksam wurde :)
Auch wenn professionelle Anbieter mittlerweile solche Systeme unter dem Schlagwort "synthetic vision" in ihren Flaggschiffen (z.B. Garmin G1000) auf den Markt bringen, möchte ich das Projekt gerne weiterführen und so eine flexible (und kostengünstige ;) ) Lösung realisieren.

Hier ein paar Screens zum Vergleich Realität/ Simulation - leider ist die Video-Qualität nicht so berauschend:

Unter dem folgenden Link ist das Video eines ersten simulierten Flugs hinterlegt:
http://www.vimeo.com/6947447

Viele Grüße,
Jens

P.S.: Falls jemand an dem Projekt interessiert ist, würde ich mich über Hilfe jeglicher Art freuen, da ich bislang alleine daran schraube.

[jgl]

Hi, also das sieht echt beeidruckend aus. *Thumps up*

Nachdem sich auch noch herausstellte, dass die SRTM Höhendaten der NASA in einem 1"-3" Raster (bei einer geschätzten Abweichung von nur 10m!) sowie Flugplatzdaten im Netz frei verfügbar sind, konnte die Umsetzung beginnen.

Das ist lustig, ich habe mich auch mal damit beschäftigt, hatte aber nur die Daten in Ascii Format bekommen und diese waren schon vorbearbeitet.
Mich würde mal interessieren, wie du diese Daten auswertest. Da, so weit ich mich recht erinnere, diese unregelmäßig Angeordnet sind, und man die nicht 1:1 übertragen kann.

MfG J---

[Edit] Was wären denn das für Aufgabe, für die Du noch Leute benötigst? [/Edit]

[IH82W8]

Hallo, danke für die Daumen ;)

Die SRTM Daten liegen in "Kacheln" à 1° Länge * 1° Breite in einzelnen Binärdateien vor. Für Nordamerika (SRTM-1) liegen die Höhendaten (Big-Endian 16 bit ints) mit einer Auflösung von einer Bogensekunde (plus eine Sekunde Überlappung zur nächsten Kachel -> 3601*3601), für den Rest der Welt mit einer Auflösung von drei Bogensekunden (->1201*1201) vor. Das DLR (Deutsches Zentrum für Luft-und Raumfahrt) bietet hier auch noch genauere Modelle an, die allerdings kostenpflichtig sind. Für meine Zwecke reichen die 3" zunächst völlig aus.

Leider kann man die Daten, wie Du bereits festegestellt hast, nicht 1:1 auf ein gleichförmiges Raster übertragen, da Wissenschaftler kürzlich herausfanden, dass die Erde entgegen landläufiger Meinung keine Scheibe, sondern vielmehr ein Ellipsoid ist! Die Daten werden bei Bedarf dynamisch geladen (und natürlich auch freigegeben), in das WGS84 Referenzsystem überführt und für eine winkel- und flächentreue Darstellung des Terrains in ein ENU (East-North-Up) oder ECEF (Earth-centered earth- fixed) Koordinatensystem transformiert:

Laenge_Breite.PNG (11.21 KiB) 3423 mal betrachtet

Ich beschäftige mich seit ein paar Wochen mit der grafischen Darstellung dieser Daten und der Benutzeroberfläche - wie man im Video sieht, ist das noch ziemlich rudimentär. Hilfe könnte ich an allen Ecken und Enden brauchen (Sensorik: Unterstützung mehrerer GPS Empfänger zwar vorgesehen, aber noch nicht realisiert, Motorkontrollinstrumente noch nicht angebunden und noch nicht als Anzeigen visualisiert, Checklisten noch nicht implementiert, GUI bedarf einiger Arbeit, usw. usf.). Falls Du Interesse hast, können wir das gerne konkretisieren.

Viele Grüße,
Jens

[Lord Delvin]

Warum kopierst du die Daten zum Zeichnen nicht in ein regelmaßiges Gitter indem du aus den Quelldaten rausineterpolierst (kubische interpolation an den stellen an denen du zu wenig daten hast, gewichtetete Mittelwerte bei zu wenig daten)? Die höhen und Farbdaten dürftest du sowieso nicht auf der GraKa unterbringen können und wenn du schon am streamen bist, dann kannst du auch einfach was nehmen, mit dem sowieso jeder arbeitet. Du solltest dann nur vielleicht dran denken, die rundung der Erde mit reinzurechnen, sonst fehlt die und es sieht mit einfach besser aus. Es gibt neben den höhendaten im übrigen auch hochauflösende Farbdaten, die sich wesentlich besser machen als bunt angemalte landschaften;)
(ja debug ich weis)

Gruß

[IH82W8]

Hi, danke für das Feedback, da ich mich erst in die Darstellung von Terrains einarbeite, bin ich gerne für Vorschläge offen.

Warum kopierst du die Daten zum Zeichnen nicht in ein regelmaßiges Gitter indem du aus den Quelldaten rausineterpolierst (kubische interpolation an den stellen an denen du zu wenig daten hast, gewichtetete Mittelwerte bei zu wenig daten)? Die höhen und Farbdaten dürftest du sowieso nicht auf der GraKa unterbringen können und wenn du schon am streamen bist, dann kannst du auch einfach was nehmen, mit dem sowieso jeder arbeitet.

Worin liegt der Vorteil eines regelmäßigen Gitters? Um die LLH-Koordinaten (latitude, longitude, height) in ein solches Gitter zu transformieren wären dann doch zwei Transformationen notwendig (LLH -> ENU -> regelmäßiges Gitter)? Und da die Höheninfos ohnehin als Gesamt-Vertex in den VB müssen, müssten diese beim Cachen eines neuen Terrain Patches ohnehin aktualisiert werden - oder ist es möglich, ein regelmäßiges Gitter (x,z) als statischen VB konstant zu halten und nur die Höhenposition als dynamischen VB in einem separaten Stream zu realisieren?

Du solltest dann nur vielleicht dran denken, die rundung der Erde mit reinzurechnen, sonst fehlt die und es sieht mit einfach besser aus.

Bei der ENU Transformation wird die Erdkrümmung berücksichtigt.

Gruß,
Jens

[jgl]

Also ich habe das damals so gemacht:
Ich habe ein regelmäßiges Gitter (x,z) erstellt, und die Höhen der jeweiligen Gitterpunkte durch I.D.W. Approximation errechnet Link.
Ich habe damals noch jedem Gitterpunkt Normalen und Texturkoordinaten mitgegeben und anschliesend abgespeichert.
Die Approximation ist etwas rechenintensiv, aber deswegen kann das Ergebnis ja dann als "Mesh" abgespeichert werden.

Jedoch war das alles ohne Berücksichtigung der Erdkrümmung. Sollte aber keine grösseren Probleme bereiten...

[IH82W8]

Die Frage ist nur, welchen Vorteil ein regelmäßiges Gitter bietet? Bilslang sehe ich nur die zusätzlich notwendige Transformation.

[jgl]

Stimmt! Wo der Vorteil liegt, kann ich dir jetzt auch nich sagen.
Vielleicht gibt es keinen....

[Krishty]

Funktioniert das Ganze auch an den Polen zufriedenstellend? Wie ist dort eigentlich die Datenlage?

Das regelmäßige Gitter hat imo nur zwei Vorteile: dass es überall eine gleich gute Datenausbeute bietet und dass sich in Verbindung mit Displacement-Mapping viel Performance rausholen lässt. Wenn es allerdings – wie hier – direkt mit Daten gefüllt wird, die aus Polarkoordinaten stammen, geht mehr verloren, als man gewinnt. IH82W8 macht das also schon ganz richtig.

Anders ist das, wenn man es mit der Präzision nicht zu genau nimmt und die Daten gleichzeitig von Hand korrigiert – ich benutze für sowas immer Cube-Maps, bei denen ich die Pol-Artefakte im Grafikprogramm meines Vertrauens retuschiere. Dass bei Polarkoordinaten die Effizienz mit jedem Grad, mit dem man sich den Polen nähert, sinkt, geht mir gegen den Strich. Einzelne Tiles sollten sich auch einfacher bearbeiten lassen, weil sie nicht so stark verzerrt werden. Dafür ist die Berechnung der Gitterpositionen ein bisschen aufwändiger.

Gruß, Ky

[IH82W8]

Funktioniert das Ganze auch an den Polen zufriedenstellend? Wie ist dort eigentlich die Datenlage?

Laut WGS84 sind die Ergebnisse der Routenplanung auch an den Polen durchaus zufriedenstellend (ausser von Pol zu Pol...), allerdings hab ich's dort noch nicht ausprobiert ;). Die Abdeckung der Höhendaten liegt bei SRTM zwischen 54°S-60°N - südlich bzw. nördlich davon wären dann keine Höheninformationen mehr verfügbar, was die prinzipielle Funktionsweise des System aber nicht beeinträchtigt.

Anders ist das, wenn man es mit der Präzision nicht zu genau nimmt und die Daten gleichzeitig von Hand korrigiert – ich benutze für sowas immer Cube-Maps, bei denen ich die Pol-Artefakte im Grafikprogramm meines Vertrauens retuschiere.

Da dieser Anwendungsfall schon einer gewissen Genauigkeit bedarf, bleibt's dann erstmal bei dem ENU Raster, danke für die Info.

Gruß,
Jens

[IH82W8]

Hallo,
hier ein kleines Update zum EFIS: nach einer durchlöteten Nacht gibt's das erste Video eines Test-Sensorblocks unter http://www.vimeo.com/7737914. Das Bauteil ist mit Beschleunigungssensoren & Gyros bestückt, dessen Messdaten auf dem Board (per ATmega168) zu Euler-Winkeln und magnetic heading aggregiert und per USB transportiert werden.

Zusammen mit GPS Empfänger können damit nun die ersten "Live" Tests durchgeführt werden. Dabei soll sowohl die Darstellung der simulierten Umgebung, als auch die Einspeisung eines Videosignals als Umgebung dienen, über das dann jeweils die relevanten Informationen (HUD, Karte, etc.) geblendet wird. Die Anreicherung des Videosignals ist noch nicht implementiert, falls also jemand Erfahrung mit der Verarbeitung von Videosignalen hat (=>http://zfx.info/viewtopic.php?f=5&t=481&p=5516#p5516), wäre ich über Tipps dankbar.

Gruß,
IH82W8

[Cobi]

Das Video ist wirklich beeindruckend!
Kannst du etwas zu den verwandten Bauteilen sagen oder ggf. sogar den Schaltplan hochladen?

[IH82W8]

Als Evaluierungsboard wurde das Arduino Duemilanove verwendet. Je nach Anwendungszweck kannst du darauf die gewünschten Sensormodule einzeln montieren, oder auf bereits vorhandene Lösungen zurückgreifen. In dem Video kommt eine fertige IMU mit 6 Freiheitsgraden zum Einsatz. Eine ausführliche Anleitung findest Du hier.
Demnächst folgen weitere Module wie statischer Luftdruck, Staudruck, 3-Achsen Kompass, GPS (spart einen USB Anschluss ;) ).