GpsFramework - VPDV WS07/08

Fachhochschule Wiesbaden
University of Applied Sciences
Anwendung der Prozessdatenverarbeitung
Wintersemester 2007/2008
Anzeige der GPS-Position mit
flexiblem Kartenmaterial auf einem
PocketPC
Carsten Altenhofen
∗
Nils von Brincken
29. Februar 2008
∗ eMail:
† eMail:
[email protected]
[email protected]
†
I
Inhaltsverzeichnis
1 Über das Projekt
1
2 Entwicklungsumgebung
2.1 Hardware . . . . . . . . . . . . . . . . . . .
2.1.1 Hewlett-Packard iPaq hx2400 . . . .
2.1.2 Navigon GPS-Empfänger "Triceiver"
2.2 Software . . . . . . . . . . . . . . . . . . . .
.
.
.
.
3
3
3
4
4
3 Datenstruktur
3.1 Google’s map tiles - Die Karten-Kacheln . . . . . . . . . . . . . . . . . . . . .
3.2 Relevante NMEA-Datensätze des GPS-Empfängers . . . . . . . . . . . . . . .
3.3 Berechnung des Sonnenstandes . . . . . . . . . . . . . . . . . . . . . . . . . .
6
6
6
8
4 Implementierung
4.1 Anzeige . . . . . . . . . . . . . .
4.2 Die Klassen BluetoothListener und
4.3 Komponenten-Konzepte . . . . .
4.4 Probleme bei der Entwicklung . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
13
13
17
17
5 Abschliessendes
5.1 Konzeptionelle, noch offene Probleme . . . . . . . . . . . . . . . . . . . . . . .
5.2 Fazit der Entwickler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
19
19
Literaturverzeichnis
20
A Projektplanung November 2007
20
B Projektpräsentation 24.01.2008
22
. . . . . . . .
NmeaDecoder
. . . . . . . .
. . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1 Über das Projekt
Dieses Dokument beschreibt die Entwicklung der GPS-Daten-Visualisierung, die im Lauf
der Vertiefungsveranstaltung "Anwendung der Prozessdatenverarbeitung" im Wintersemester 2007/2008 an der Fachhochschule Wiesbaden erstellt wurde. Das Projekt wurde von Herrn
Prof. Dr. K.O. Linn betreut.
In dieser Dokumentation liess es sich nicht vermeiden, Links ins WWW anzugeben – wir hoffen,
dass die Inhalte auch noch nach der Abgabe aktuell sind oder sich weitere Informationen schon
bald in Buch- oder weniger flüchtiger Form finden lassen.
Die Kommentierung zur Arbeitsweise des Codes findet direkt in den Quelldateien per XML
statt und kann darüber auch weiterverarbeitet werden.1
Ziel
Das Ziel, der aus Nils von Brincken und Carsten Altenhofen bestehenden Projektgruppe, war
die Anzeige einer GPS-Position auf einer Karte. Am Anfang des Projektes wurde dies als
ungefähres Ziel festgelegt und dann in wöchentlichen Besprechungen mit Herrn Linn genauer
ausgearbeitet. Somit ergab sich aus jedem aufgetauchten Problem auch die Möglichkeit, dieses
anzugehen und zu lösen oder einen alternativen Weg zu wählen. Beispielsweise hätte eine weniger anspruchsvolle Zielsetzung bei der Kartendarstellung Entwicklungszeit eingespart, jedoch
keinen Mehrwert gegenüber anderen Projekten sichtbar zu machen vermocht.
Einige Implementierungsdetails brachten den aufgestellten Zeitplan durcheinander, genauso
machten organisatorische Entscheidungen in der Zusammenarbeit klar, dass sich beim terminkritischen Entwickeln alle Komponenten ergänzen müssen. Dies gilt für die verwendeten
Software-Werkzeuge, die Einschätzung der eigenen Fähigkeiten und realistische, festgelegte
1
Vorgehen im VisualStudio: Im Solution Explorer die Properties des GpsFramework per Rechtsklick
anzeigen lassen. In der Registerkarte Build kann unter Output das Verzeichnis für die Dokumentationsdatei
ausgewählt werden. Detaillierte, englische Erklärung zur XML-Kommentierung im MSDN: http://msdn.
microsoft.com/msdnmag/issues/02/06/XMLC/
1 Über das Projekt
2
Meilensteine. So war die Entscheidung, die uns beiden am Anfang noch unbekannte Programmiersprache C# zu verwenden, sicher nicht die effektivste Lösung – aber so konnten wir uns
über die Fähigkeiten der Sprache ein Praxisbild machen.
Umrissen lagen folgende Aufgaben vor uns: Erstellen der Kartenanzeige, Auslesen der GPSDaten, Anzeigen von Position, Sonnenstand und UTM-Karteninformationen. Als Einsatzgebiet lag uns die Nutzung durch Privatpersonen beim Wandern vor Augen. Somit muss der
Kartenausschnitt flexibel, aber nicht auf hohe Bewegungsgeschwindigkeiten ausgerichtet sein.
Die Karten liegen auf einem Gerät vor, das eine beschränkte Speicher- und Batteriekapazität
aufweist, eine Online-Anbindung soll im Einsatz nicht verfügbar sein.
Ergebnis
Der Vorteil des iterativen Projektaufbaus lag in der steilen Lernkurve, da Herr Linn uns ermutigte, auch neue Wege zu gehen. So haben wir weitgehend auf vorhandene Bibliotheken wie
zur GPS-Dekodierung oder Zeit-Funktionen verzichtet und die dahinterstehenden Algorithmen selbst umgesetzt. Am Projektende können wir leider nicht auf eine vollständige Lösung
aller Aspekte verweisen – jedoch auf praktikable Ansätze und softwaretechnische Konzepte, die
das Entwicklungsfeld GPS-Visualisierung in der "Anwendung der Prozessdatenverarbeitung"
weiterbringen.
Implementiert ist die Darstellung des unterschiedlich detaillierten Kartenmaterials, das gleichzeitige Abfragen aller GPS-Informationen und das Anzeigen von Koordinaten, Bewegungsrichtung und -geschwindigkeit sowie des Sonnenstandes.
Carsten Altenhofen, Nils von Brincken
Anwendung der Prozessdatenverarbeitung
3
2 Entwicklungsumgebung
Die Rahmenbedingungen für unsere Arbeit wurden durch die von der FH Wiesbaden bereitgestellte Hardware, einen PocketPC und einen GPS-Empfänger festgelegt – dies wirkte sich
auf die Möglichkeiten der Softwarenutzung und Entwicklungstätigkeit aus. Um gleichzeitig
arbeiten zu können, mussten wir auf Emulatoren für die Datenbereitstellung zurückgreifen –
die jedoch nicht immer präzise Werte lieferten oder unkompliziert zu benutzen waren. Eine
weitere Hürde war auch der Einsatz von Microsoft Visual Studio 2005 auf einem virtualisierten
Windows XP (siehe 2.2).
2.1 Hardware
2.1.1 Hewlett-Packard iPaq hx2400
Der HP iPaq hx2400 verfügt über einen 520 MHz-Prozessor von Marvell1 und einen berührungssensitiven, 320x240 Pixel-Bildschirm, der mit einem Stift bedient wird. Die Anbindung
an andere Systeme funktioniert über Bluetooth, WLAN (802.11b-Standard) und durch ein
Cradle für die USB-Schnittstelle zu einem Rechner.
Schwierigkeiten: Für den Entwicklungsprozess ergaben sich keine Probleme mit dieser Hardware. Allerdings mussten bei der Konzeption der Anwendung die geringen Ressourcen beachtet
werden – Systemleistung (CPU), Speicherkapazität (RAM, CFII-Speicherkarte), Batterielaufzeit.
1
Beschreibung des eingesetzten Boards und der PXA270-CPU auf: http://www.logicpd.com/products/
som/marvell/pxa270
2 Entwicklungsumgebung
4
2.1.2 Navigon GPS-Empfänger "Triceiver"
Es handelt sich hierbei um ein Gerät der Firma Navigon2 , dessen GPS-Dekodierung durch
einen SiRFII-Chip3 erfolgt. Das Gerät sendet seine Positionsdaten per Bluetooth im NMEA0183-Standard [Bad08] weiter. In Windows XP wird die Hardware dann wie eine serielle
Schnittstelle (COM-Port) benutzt.
Schwierigkeiten: Als grundsätzliches Problem ist die Beschaffung der Datensätze vom Empfänger anzusehen. Da wir nur über ein Gerät verfügten, mussten wir uns mit Emulatoren
behelfen (siehe 2.2). Die Möglichkeit, GPS-Routen aufzuzeichnen und korrekt abzuspielen,
konnten wir erst am Projektende einsetzen und somit keinen Nutzen mehr daraus ziehen.
2.2 Software
Auf dem Windows Mobile 2003 des PocketPC wurde C# als Anwendungssprache benutzt. Die
Programmierumgebung war Visual Studio 2005 unter Windows XP, in dem eine enge Integration zwischen Debugging-Möglichkeiten, Gerätezugriffen und Virtualisierung des PocketPC
geschaffen wurde.
Um die Virtualisierungs- und Emulations-Situation zu verdeutlichen: Es wurde teilweise mit einem Apple MacBook programmiert, das in MacOS X mit Hilfe von Paralles Desktop4 ein Windows XP virtualisierte. Das darin benutzte Visual Studio stellte wiederum einen virtualisierten
PocketPC zur Verfügung. Dieser musste auf die Bluetooth-Schnittstelle (MacBook-Hardware)
zugreifen oder auf eine serielle Schnittstelle, die GPS-Daten emuliert bereitstellte.
Zusätzliche Werkzeuge
SiRF-Demo Windows-Programm, um den Chip des GPS-Empfängers auszulesen, u.a mit den
Positionsdaten. http://www.sirf.com/free_demo.html
GPS-Utility Windows-Programm, um die GPS-Daten des Empfängers auszulesen http://
www.gpsu.co.uk/
2
http://www.navigon.com/site/de/de/, der "Triceiver" ist nur noch im Webshop der Firma zu finden.
Beschreibung des Chip auf http://www.sirf.com/products/gps_chip7.html
4
Produkt-Homepage: http://www.parallels.com/en/products/desktop/
3
Carsten Altenhofen, Nils von Brincken
Anwendung der Prozessdatenverarbeitung
2 Entwicklungsumgebung
5
gpsfeed+ Ein Emulator, der an der seriellen Schnittstelle, per TCP/UDP oder als XMLAusgabe NMEA-Sätze zur Verfügung stellt, plattformunabhängig. http://gpsfeed.
sourceforge.net/
SerialClient Ein Programm, das es Parallels Desktop erlaubt, die seriellen Schnittstellen von
MacOS X zu benutzen. Dieses Vorgehen wird unter [SER07] genauer beschrieben. http:
//eudyptes.com/SerialClient.php
Applet zur Berechnung des Sonnenstandes http://www.geoastro.de/ErdeSonne/SE/erdesonne.
html
Carsten Altenhofen, Nils von Brincken
Anwendung der Prozessdatenverarbeitung
6
3 Datenstruktur
Das Projekt verknüpft zwei Bereiche: Das zu visualisierende Kartenmaterial und die Positionsdaten. Bei den Karten nutzen wir Google Maps1 als Basis, bei den Daten die Ausgaben des
Empfängers im NMEA-Standard. Dies wurde in der ersten Besprechung so festgelegt, da Herr
Linn uns über ein Web-Frontend Kartenteile zur Verfügung stellen konnte. Zusätzlich war die
Funktionsweise des Google-Dienstes bereits 2006 dokumentiert worden [PSZ06].
3.1 Google’s map tiles - Die Karten-Kacheln
Die Kartenabschnitte (Kacheln) liegen in einem bestimmten Benennungssystem als Bilddatei
(256x256 Pixel-JPEG) vor. Je nach Kartenverwendung (Satellitenfoto, Strassenkarten 2 ) unterscheidet es sich. Die anzuzeigenden Satellitenbilder liegen im TQRS-Format vor [PSZ06, S.
7], somit lassen sie sich gut strukturiert speichern und ein einfacher Zugriff ist möglich. Wir
konnten die für eine Koordinate benötigten Kacheln durch vorhandene Algorithmen [PSZ] bestimmen und brauchten keine weiteren Konfigurationsdateien. Diese Algorithmen finden sich
auch im WWW – leider nicht von Google bereitgestellt.
Im Bereich Informationen über ihre Datenstrukturen hält sich Google recht bedeckt und stellt
nur eine Programmierschnittstelle (API) für das WWW zur Verfügung. Die Kacheln jedoch
dürfen frei verwendet werden, zumindest für den privaten Bereich.3
3.2 Relevante NMEA-Datensätze des GPS-Empfängers
Für unser GPS-Projekt mussten wir uns zuerst mit dem sogenannten NMEA-0183-Standard
befassen. Dieser spezifiziert das Format in dem Datensätze übermittelt werden, die schließlich
1
http://maps.google.de/
Das Höhenprofil war während der Entwicklung nicht verfügbar.
3
http://maps.google.de/intl/de/help/terms_maps.html
2
3 Datenstruktur
7
von Empfängern ausgelesen werden. Der Standard ist sehr umfangreich und enthält zahlreiche
Sätze, die sich unter anderem mit der Autopilotsteuerung eines Flugzeugs befassen. Diese
Sätze werden natürlich von einem Standard-GPS-Empfänger nicht empfangen. Unser GPSEmpfänger mit SiRFII-Chip mit dem wir uns über Bluetooth verbinden, empfängt nur wenige
Sätze des Standards:
• GPRMC (Recommended Minimum Navigation Information)
• GPVTG (Track made good and Ground Speed)
• GPGSA (GPS DOP and active Satellites)
• GPGSV (Satellites in View)
• GPGGA (Global Positioning System Fix Data)
Um die für unser Projekt von Interesse befindlichen Informationen zu erhalten, benötigten wir
folgende Sätze:
RMC – Recommended Minimum Navigation Information
$--RMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,m,*hh<CR><LF>
Field Number:
1. UTC Time
2. Status, V = Navigation receiver warning A = Valid
3. Latitude
4. N or S
5. Longitude
6. E or W
7. Speed over ground, knots
8. Track made good, degrees true
9. Date, ddmmyy
10. Magnetic Variation, degrees
11. E or W
12. FAA mode indicator (NMEA 2.3 and later)
13. Checksum
Carsten Altenhofen, Nils von Brincken
Anwendung der Prozessdatenverarbeitung
3 Datenstruktur
8
VTG – Track made good and Ground speed
$--VTG,x.x,T,x.x,M,x.x,N,x.x,K,m,*hh<CR><LF>
Field Number:
1. Track Degrees
2. T = True
3. Track Degrees
4. M = Magnetic
5. Speed Knots
6. N = Knots
7. Speed Kilometers Per Hour
8. K = Kilometers Per Hour
9. FAA mode indicator (NMEA 2.3 and later)
10. Checksum
3.3 Berechnung des Sonnenstandes
Informationen zur Errechnung des Sonnenstands findet man unter anderem unter http://de.
wikipedia.org/wiki/Sonnenstand. Die Errechnung des Sonnenstands ist relativ komplex,
deshalb hier nur eine kurze Übersicht des Ganzen.
Nachdem ein TimeDateReceived-Ereignis im NmeaDecoder ausgelöst wird, wird wie im Abschnitt 4.2 (Die Klassen BluetoothListener und NmeaDecoder) erwähnt, die Methode decoder_TimeDateReceived(double days_since_2000, double utc_time_in_h) ausgeführt.
Der Parameter days_since_2000 enthält die Tage seit dem Standardäquinoktium am 1.1.2000,
wobei Schaltjahre zu berücksichtigen sind, und utc_time_in_h die Tageszeit in Stunden und
Bruchteilen von Stunden (Beispiel: 10.45 Uhr ⇒ 10.75 ) Diese beiden Zeitwerte sind für die
genaue Errechnung nötig, sowie die Koordinaten des Standorts, welche wir uns aus den aktuell
errechneten Klassenvariablen für Längen- und Breitengrad holen.
Carsten Altenhofen, Nils von Brincken
Anwendung der Prozessdatenverarbeitung
3 Datenstruktur
9
Als Erstes wird die Zeitvariable n errechnet, welche sich aus der Anzahl der Tage seit dem
Standardäquinoktium im Jahr 2000 und dem Tagesbruchteil zusammensetzt:
n = days_since_2000 + utc_time_in_h/24
Daraus läßt sich die Position der Sonne auf der Ekliptik bestimmen. Die Formel geht von der
Position aus, welche zum Zeitpunkt des Standardäquinoktium aktuell war:
L = 280.460 + 0.9856474 ∗ n
Mittels modulo 360,0 muss das Ganze noch in den Bereich von 0,0 bis 360,0 Grad gebracht
werden.
Um den Einfluss der Bahnelliptizität nachträglich zu berücksichtigen und die ekliptikale Länge
zu erhalten, ist hierzu als Korrektur die so genannte Mittelpunktsgleichung zu addieren. Diese
Korrektur hängt vom Winkel zwischen Sonne und Perihel ab, der sogenannten Anomalie.
Die Mittelpunktsgleichung erwartet als Eingabewert die (fiktive) gleichförmig anwachsende
mittlere Anomalie g. Diese wächst um 360 Grad in einem anomalistischen Jahr zu ca. 365,2596
Tagen:
g = 357.528 + 0.9856003 ∗ n
Mittels modulo 360,0 muss auch dies noch in den Bereich von 0,0 bis 360,0 Grad gebracht
werden. Daraus ergibt sich für die ekliptikale Länge Λ der Sonne:
Λ = L + 1.9150000 ∗ sin(g) + 0.0200000 ∗ sin(2.0000000 ∗ g)
Hierbei ist zu beachten, dass die Argumente im Sinus, welche wir zuvor errechnet haben, im
Bogenmaß anzugeben sind.
Für die so berechnete, entlang der Ekliptik gezählte, ekliptikale Länge Λ muss nun die zugehörige entlang des Himmelsäquators gezählte Rektaszension α bestimmt werden. Mit der Schiefe
der Ekliptik :
Carsten Altenhofen, Nils von Brincken
Anwendung der Prozessdatenverarbeitung
3 Datenstruktur
10
ε = 23.439 − 0.0000004 ∗ n
ergibt sich die Rektaszension α der Sonne. Falls jedoch der Nenner im Argument des Arcustangens einen Wert kleiner Null hat, sind 180◦ zum Ergebnis zu addieren, um den Winkel in
den richtigen Quadranten zu bringen (α muss im gleichen Quadranten liegen wie Λ):
α = arctan
cos(ε) ∗ sin(Λ)
cos(Λ)
Auch hierbei ist zu beachten, dass die Argumente in den Sinus- und Cosinus-Operationen,
welche wir zuvor errechnet haben, im Bogenmaß anzugeben sind. Am Ende muss jedoch alles
wieder ins Gradmass zurückgerechnet werden, da dies für den α-Wert gewünscht ist.
Die senkrecht zum Himmelsäquator gezählte Deklination δ ergibt sich als:
δ = arcsin(sin(ε) ∗ sin(Λ))
Hier gilt das Gleiche wie bei der vorherigen Rechnung. Die Argumente sind ins Bogenmass
umzurechnen, das Ergebnis des δ wird wieder ins Gradmass zurückgerechnet.
Nun werden die Variablen Azimut A (d.h. die Himmelsrichtung) und der Höhenwinkel h ausgerechnet. Dazu bestimme man die Zeitvariable T0 , dies ist eine Zeitvariable in julianischen
Jahrhunderten ab dem Standardäquinoktium im Jahr 2000.
T0 = days_since_2000/36525
Und damit die mittlere Sternzeit θ in Greenwich für den gesuchten Zeitpunkt T (Weltzeit UT,
in Stunden).
Der erste Term ist die Sternzeit von Greenwich zum Zeitpunkt des Standardäquinoktiums im
Jahr 2000, der zweite und dritte die Drift des Frühlingspunktes seit dem Standardäquinoktium:
h
θG
= (6.697376 + 2400.05134 ∗ T0 + 1.002738 ∗ utc_time_in_h)
Carsten Altenhofen, Nils von Brincken
Anwendung der Prozessdatenverarbeitung
3 Datenstruktur
11
Das Ergebnis ist mittels modulo 24,0 in einen Bereich von 24 Stunden zu bringen.
Die Sternzeit ist der Stundenwinkel des Frühlingspunktes, ausgedrückt im Zeitmaß (1 Stunde =
15◦ ). Ganzzahlige Vielfache von 24 Stunden werden vom Ergebnis abgezogen. Dafür haben wir
aber mittels der Modulo-Operation im Schritt davor schon gesorgt. Die Multiplikation mit dem
Umrechnungsfaktor 15 ◦ pro Stunde liefert den Greenwich-Stundenwinkel des Frühlingspunkts
im Gradmaß:
h
∗ 15
θG = θG
Für einen Ort auf der geographischen Länge (nach Osten positiv gezählt) ist der Stundenwinkel
des Frühlingspunkts:
θ = θG + longitude
Subtraktion der Rektaszension der Sonne α liefert den Stundenwinkel τ der Sonne für jenen
Ort:
τ =θ−α
Azimut A und Höhenwinkel h ergeben sich für einen Ort auf der geographischen Breite aus:
A = arctan
sin(τ )
cos(τ ) ∗ sin(latitude) − tan(δ) ∗ cos(latitude)
Falls der Nenner im Argument des Arcustangens einen Wert kleiner Null hat, sind wieder 180◦
zum Ergebnis zu addieren, um den Winkel in den richtigen Quadranten zu bringen. Ebenso sind
die Argumente wieder im Bogenmass anzugeben und später ins Gradmass zurückzurechnen.
Mittels modulo 360,0 läßt sich das Ganze wieder in einen Bereich von 360◦ bringen. Ausserdem
ist der Winkel so vom Süden aus gesehen angegeben. Um das Ergebnis vom Norden aus gesehen
zu erhalten sind letztendlich noch 180◦ zu addieren.
Höhenwinkel h:
h = arcsin (cos(δ) ∗ cos(τ ) ∗ cos(latitude) + sin(δ) ∗ sin(latitude))
Carsten Altenhofen, Nils von Brincken
Anwendung der Prozessdatenverarbeitung
3 Datenstruktur
12
Bezüglich der Argumente ist hier gleiches zu beachten.
Damit haben wir sowohl den gewünschten Sonnestand (Azimut) als auch den Höhenwinkel
der Sonne über dem Horizont für beliebige Orte weltweit ermittelt.
Carsten Altenhofen, Nils von Brincken
Anwendung der Prozessdatenverarbeitung
13
4 Implementierung
Wir entschlossen uns bei Projektbeginn, Zuständigkeiten zu bilden: Carsten Altenhofen befasste sich mit der Verarbeitung der GPS-Daten, während Nils von Brincken die Programmierung
der Kartenanzeige übernahm.
4.1 Anzeige
Die Anforderungen von Herrn Linn an die Kartenanzeige waren hoch: So sollte sie die verschiedenen Zoom-Stufen des Google Maps-Materials beherrschen und möglichst große Kartenabschnitte zur Verfügung stellen. Beim Implementieren der letzten Vorgabe schossen wir sogar
über die Zielsetzung hinaus. Durch ein Kachelmanagementsystem bewegen sich die einzelnen,
zueinander gehörenden Kartenabschnitte autark. Im sichtbaren Bereich der Anzeige (320x240
Pixel) sind immer Instanzen der Klasse Tile zu sehen, die sich je nach Bewegungsrichtung
wie auf einem unendlichen Band neu anordnen (Abbildung 4.1). Somit müssen nie mehr als
sechs Kacheln im Speicher gehalten werden. Eine statische Bildanzeige im C# .NET Compact
Framework 2.0 kann nur ein Bild der Größe 1024x1024 Pixel anzeigen [PSZ06, S. 15] . Diese
Limitierung wird somit umgangen.
4.2 Die Klassen BluetoothListener und NmeaDecoder
Diese Module sorgen für den Empfang von sogenannten NMEA-Sentences und deren Auswertung. Die Klasse BluetoothListener liest, in einem eigenen Tread permanent die serielle Schnittstelle, die in diesem Fall das Bluetooth-Signal eines mobilen GPS-Empfängers darstellt, aus.
Sie verfügt über die private Getter-Methoden
• get_latitude()
• get_longitude()
• get_azimut()
4 Implementierung
14
Abbildung 4.1: Darstellung des Kachelmanagements aus Abschnitt 4.1. A: 256x256 PixelKartenabschnitt, deckt in 2 ∗ 6-Anordnung immer jeden Bereich der 320x240Pixel Anzeige ab. B: Bei Bewegungen aus dem sichtbaren Bereich handelt die
Kachel selbständig und verschiebt sich mit neuem Inhalt ans andere Ende.
Carsten Altenhofen, Nils von Brincken
Anwendung der Prozessdatenverarbeitung
4 Implementierung
15
• get_hoehenwinkel()
• get_track()
• get_speed()
mit der sich eine andere Klasse, die eine Referenz auf ein Objekt der Klasse BluetoothListener
hält, die aktuellen Werte holen kann.
Sie konfiguriert zunächst den SerialPort, mittels welchem wir uns mit der Bluetooth-Schnittstelle
verbinden, wie folgt:
• Datenübertragung: 9600 bit/s
• Datenbits: 8
• Stop Bits: 1
• Kein Parity Bit
• Kein Handshake
Anschließend konstruiert sich der BluetoothListener als Hilfsklasse einen NmeaDecoder zur Signalentschlüsselung. Zwei weitere Methoden
• startReading()
• stopReading()
sorgen für das Öffnen und Schliessen des Ports.
Eingehende Daten auf dem Port lösen das Event DataReceived der SerialPort-Klasse aus. Auf
das wird mittels des passenden EventHandler SerialDataReceivedEventHandler reagiert und in
der zugehörigen Methode port_DataReceived() die Daten an die decode()-Methode der Klasse
NmeaDecoder delegiert, die die Nutzdaten schliesslich auswertet. Dies geschieht, indem die Methode NmeaDecoder.decode() von der Hauptklasse, mit eingehenden Sentences parameterisiert,
aufgerufen wird.
Die Klasse NmeaDecoder wertet die folgenden Sätze des NMEA-Standards aus:
• Recommended Minumum Navigation Information, um sowohl GPS-Koordinaten
als auch Zeitinformationen aus dem GPRMC-Satz zu erhalten.
• Track made good and Ground Speed Information, um Kurs und Geschwindigkeit
aus dem GPVTG-Satz zu erhalten.
Carsten Altenhofen, Nils von Brincken
Anwendung der Prozessdatenverarbeitung
4 Implementierung
16
Dies beinhaltet eine Verifizierung, durch den Vergleich einer übermittelten und der errechneten
Prüfsumme des Satzes. Das Errechnen der Prüfsumme erfolgt, indem die Byte-Werte eines jeden Zeichens des Satzes nacheinander mittels XOR-Operation ausgewertet werden. Der daraus
resultierende Byte-Wert wird zweistellig hexadezimal kodiert mit der übermittelten Prüfsumme verglichen und der Satz eventuell verworfen.
Nach erfolgreicher Verifizierung wird ein Satz in seine Blöcke zerlegt, die durch Komma separiert sind. Das Präfix im ersten Block entscheidet über die Art des Satzes im NMEA-Standard.
Desweiteren wird sichergestellt das die benötigten Blöcke Werte enthalten, ein Block kann trotz
korrekter Prüfsumme leer sein.
Im Falle eines GPRMC-Satzes wird überprüft, ob die Blöcke, welche Informationen zur UTCZeit und -Datum enthalten, Werte enthalten. Dann werden daraus Werte errechnet, die wiederum zur späteren Errechnung des Sonnenstands nötig sind. Diese sind:
• die UTC-Zeit in Stunden und Bruchteilen von Stunden (Beispiel: 10.45 Uhr ⇒ 10.75)
• Tage seit dem Standardäquinoktium am 1.1.2000, wobei Schaltjahre berücksichtigt werden.
Diese werden nun durch ein Auslösen des Events (TimeDateReceived(days_since_2000, utc_time_in_h)) an den BluetoothListener übergeben und dort weiterverarbeitet.
Das war jedoch nicht alles, was im Falle eines GPRMC-Satzes von Belang ist. Weiterhin
wird überprüft, ob die Blöcke, welche Informationen zum Längen- und Breitengrad erhalten,
Werte enthalten. Ist dies der Fall, dann wandeln wir diese Informationen, die noch in der
Grad-, Minuten- und Sekunden-Darstellungen vorliegen, in dezimale Grad-Darstellungen um.
Diese werden nun durch ein Auslösen des Events (CoordReceived(latitude, longitude)) an den
BluetoothListener übergeben und dort weiterverarbeitet.
Im Falle eines GPVTG-Satzes wird analog vorgegangen, indem Kurs und Geschwindigkeit
ermittelt werden und durch ein Auslösen des Events (TrackSpeedReceived(track, speed)) an
den BluetoothListener übergeben werden.
Die vom NmeaDecoder oben genannten ausgelösten Events
• CoordReceived
• TimeDateReceived
• TrackSpeedReceived
Carsten Altenhofen, Nils von Brincken
Anwendung der Prozessdatenverarbeitung
4 Implementierung
17
werden vom BluetoothListener durch die zugehörigen EventHandlern
• CoordReceivedEventHandler
• TimeDateReceivedEventHandler
• TrackSpeedReceivedEventHandler
abgefangen und die passende Methoden des BluetoothListeners
• decoder_CoordReceived(double latitude, double longitude)
• decoder_TimeDateReceived(double days_since_2000, double utc_time_in_h)
• decoder_TrackSpeedReceived(double track, double speed)
werden aufgerufen.
Diese aktualisieren entweder nur die Klassenattribute für Längen- und Breitengrad oder Kurs
und Geschwindigkeit oder führen im Fall von gültig empfangenen Zeitwerten weitere Rechnungen zur Ermittelung des Sonnenstandes (Azimut) und des Höhenwinkels (Höhe über dem
Horizont) durch. Dazu werden die aktuellen Längen- und Breitengrade hinzugezogen. (Siehe
Abschnitt 3.3).
4.3 Komponenten-Konzepte
C# auf dem PocketPC verfügt über einige nützliche Anzeigemechanismen. Dazu gehören die
Elemente für die Erzeugung der Bildschirmfenster, die problemlos miteinander arbeiten, sowie Benutzerinteraktion bereitstellen. Einfache Komponenten wie die Fortschrittsanzeige beim
Generieren neuer Kacheln sind vorhanden – während genauso selbstverständliche Dialoge wie
zum bestimmen eines Verzeichnisses fehlen.
4.4 Probleme bei der Entwicklung
Wir entwickelten das Modul zur Signalauswertung des GPS-Empfängers und zur Errechnung
der relevanten Werte zuerst als Konsolenapplikation in C# mittels Visual Studio 2005, womit
Carsten Altenhofen, Nils von Brincken
Anwendung der Prozessdatenverarbeitung
4 Implementierung
18
Abbildung 4.2: Kreislauf der Ereignisse – Abläufe in Abschnitt 4.2
sich gute Erfolge bei den Zwischenzielen erzielen liessen. Verifizieren könnte man seine Ergebnisse anhand diverser Websites und Applets im Internet. Dies war gerade bei der Errechnung
des Sonnenstands iterativ nötig, da Folgefehler nur schwer zu erkennen waren. Die Portierung
brachte letztendlich jedoch mehr Probleme mit sich. Dabei entwickelten wir mit dem C# .NET
Compact Framework 2.0 und testeten auf dem GPS-Emulator des Visual Studio 2005.
Zum einen war die Frage, wie das Threadhandling am besten zu gestalten ist, und zum anderen
gab es Probleme bei den Versuchen mittels C#-Grafikroutinen in unser Zielanwendung, welche
auf einem Windows Mobile-System läuft, zu zeichnen. Da das Compact Framework nur einen
Teil der C# Primitiven enthält, ist oft Wichtiges nicht enthalten.
Auch bei den Versuchen eine transparente Picturebox mit statischen Grafikelementen über
die verschiebbaren Pictureboxen, die das Kartenmaterial enthalten zu legen, gab es Probleme.
Das Compact Framework unterstützt keine Transparenz von Haus aus.
Carsten Altenhofen, Nils von Brincken
Anwendung der Prozessdatenverarbeitung
19
5 Abschliessendes
5.1 Konzeptionelle, noch offene Probleme
Es fehlt noch eine Möglichkeit, die Anwendung als Paket zu installieren. Zwar wird sie durch
Visual Studio auf den PocketPC ausgerollt (deploy), aber man muss sie über den DateiExplorer aufrufen. Eleganter ist eine Installation über die ActiveSync-Komponente, die dann
auch den Anwendungszugriff im Ordner Programme ermöglicht.
Für den Anwender sollte zusätzlich die Möglichkeit bestehen, die Bluetooth-Schnittstelle und
andere Einstellungen flexibeler bestimmen zu können.
5.2 Fazit der Entwickler
Als Anregung für nachfolgende Projekte: Es macht Sinn, zuerst den Rahmen der Entwicklungsumgebung zu schaffen, was auch den SVN-Zugang1 und genug Testdaten beinhaltet. Genauso
verfifizierbare Algorithmen (Sonnenstand, zugriff auf Koordinaten) vorher entwickeln und unabhängig überprüfen. Somit entdeckt man Fehler schneller.
Engere Bindung zwischen den Teilbereichen ist gefragt, also nicht von weit nach eng programmieren, sondern kleine Schritte zusammen gehen.
Ein interessantes, lehrreiches Projekt, da wir viel über die für uns neue Sprache gelernt haben.
Wir konnten innovative Ideen weiterentwickeln, auch wenn es nicht unbedingt zum Ziel führte.
Im Vergleich zu anderen Projekten [OG07] [MF07] wurde uns bewusst, was in einem Semester
alles schaffbar ist.
1
Quelltext-Versionverwaltung, an der FH Wiesbaden für alle Projekte bereitgestellt, http://svnbook.
red-bean.com/
20
Literaturverzeichnis
[Bad08] Glenn Baddeley. GPS – NMEA sentence information. http://home.mira.net/
~gnb/gps/nmea.html, 2008.
[Ell06]
Frank Eller. Visual C# 2005 Grundlagen und Programmiertechniken. AddisonWesley, München, 3 2006.
[MF07] Pascal Martin and Paul Fox. RoadMap – A Car Navigation System for Linux and
UNIX (and PocketPC too). http://roadmap.sourceforge.net/index.html, Oktober 2007. "RoadMap is an open source (GPL) program that provides a car navigation
for Linux, UNIX and now Windows CE. It displays a map of the streets, tracks the
position provided by a NMEA-compliant GPS receiver. Most of the map files used
by RoadMap are generated from the TIGER files provided by the US Census Bureau, and from the RNF files provided by Statistics Canada, and thus cover northern
North America only. There has been recent work on deriving RoadMap data from
other sources, including postgis and other shapefile-based formats, but this work is
either not on the main development branch, or very experimental.".
[OG07] J. Ostertag and Fritz Ganter. GpsDrive — Navigation Software for Linux. http:
//www.gpsdrive.de/, Oktober 2007. "GpsDrive displays your position provided
from your GPS receiver on a zoomable map. The maps are autoselected for best
resolution depending of your position and can be downloaded from the Internet.
GpsDrive is also running on New HP (Compaq) iPAQ devices (if running on Linux
with X-Server and GTK+)".
[PSZ]
Robert Pineker, Matthias Schmelzer, and Martin Zurkowski.
PHP-Funktion
um Koordinaten ins TQRS-Format zu überführen. http://www.informatik.
fh-wiesbaden.de/~linn/vpdv06/gpsNavi2/seiten/doku////__filesource/
fsource_default__bigfilestrack_conf_big.php.html#a21. Quelltext aus der
Web-Anwendungsdokumentation auf http://www.informatik.fh-wiesbaden.de/
~linn/vpdv06/gpsNavi2/index.html.
[PSZ06] Robert Pineker, Matthias Schmelzer, and Martin Zurkowski. Studienarbeit zum Thema "GPS Navigation – Pathfinder". Technical report, Fachhochschule Wiesbaden,
2006.
[SER07] Share a serial port with Windows on Parallels. http://www.macosxhints.com/
article.php?story=20070111135928615&mode=print, Januar 2007.
VPDV ws07/08 – Projektplanung
Zielsetzung: Anzeigen von vorhandenem und geeichtem Kartenmaterial auf einem PocketPC. Bestimmung der
Position durch ein GPS-Bluetooth-Adapter und Auswahl der dazugehörigen Karten. Einzeichnen von Layern über der
Karte: Sonnenstand, in vordefinierten Abständen Längen- und Breitengrade.
Unterschiedliche / trennbare Abschnitte
Aufeinanderfolgende Arbeitsschritte
Anzeigen eines Fensters
Formel für das Anzeigen
und überlagern der
Karten
Anzeige von Kartenmaterial im
Fenster, stückeln um fortlaufend
von der Speicherkarte auslesen
und darstellen zu können
Auslesen eines Verzeichnisses
mit Bildern (Größe beachten,
welche Daten sind vorhanden,
was ist alles auf den Karten) und
ini-Dateien (besser XMLVerwenden, um mehr Inhalte
speichern zu können)
Anzeigen von geeichten Karten
Verbindung zum
Bluetoothgeräten (Test
der Schnittstelle auch mit
Handy etc.)
Auslesen von Rohdaten
der BluetoothSchnittstelle
Parsen der Daten in eine
Struktur
Verschriftlichung Software-Doku, Hintergründe, Infos für
Präsentation
Bis Anfang Dezember
Layerfunktion über einem
Teil des Fensters
Layer für Sonnenbitmaps
und Zeichnen der Grade
Layer-Eichungsfunktion
für Grade und
Sonnenstand
Benutzerhandbuch
Version: 06.11.2007
Anwendung der PDV
Kartendarstellung im
GPS-Framework
Nils von BRINCKEN
[email protected]
Carsten ALTENHOFEN
[email protected]
Version: 2/27/08 18:13
Wir stellen euch vor ...
… welches
… welche
Ziel wir erreichen sollen
Entwicklungsumgebung wir benutzen
… wie
unsere Datenmodelle aussehen und
… wie
die Darstellung davon realisiert wurde
… was
das Framework jetzt kann (Demonstration)
Unser Ziel
!
GPS-Koordinaten auf einer Karte darstellen
!
Anzeige mit Erweiterungen realisieren
Sonnenstand, UTM-Angaben, Bewegungsrichtung
!
Nutzung
!
durch Privatpersonen (Kartenquellen)
!
zum Wandern (Übersicht, Unabhängigkeit)
!
auf HP iPaq hx2400 (Windows Mobile 2003)
Entwicklungsumgebung
!
Hardware
!
HP iPaq hx2400 (Marvell 520 MHzProzessor, 320x240 Pixel-Touchscreen,
Bluetooth, WLAN)
!
!
GPS-Empfänger (SiRFII-Chip, Bluetooth)
Software (Microsoft-lastig)
!
VisualStudio 2005 (C# .NET Compact Framework)
!
Pocket PC-Emulator, GPS-Feed+
Google Maps als Kartenquelle ?
! Für persönliche, nichtgewerbliche Zwecke
? Zugreifen auf 17.179.869.184 Kacheln ?
"
? Darstellen von 43 TB Bildmaterial ?
"
NMEA-Sentences
GPRMC - Recommended Minimum Navigation Information
$--RMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,
x.x,x.x,xxxx,x.x,a,m,*hh<CR><LF>
Field Number:
1) UTC Time
2) Status: V=Navigation receiver warning, A=Valid
3) Latitude
4) N or S
5) Longitude
6) E or W
7) Speed over ground, knots
8) Track made good, degrees true
9) Date, ddmmyy
10) Magnetic Variation, degrees
11) E or W
12) FAA mode indicator (NMEA 2.3 and later)
13) Checksum
NMEA-Sentences
GPVTG - Track made good and Ground speed
1
2 3
4 5
6 7
8 9 10
|
| |
| |
| |
| | |
$--VTG,x.x,T,x.x,M,x.x,N,x.x,K,m,*hh<CR><LF>
Field Number:
1) Track Degrees
2) T = True
3) Track Degrees
4) M = Magnetic
5) Speed Knots
6) N = Knots
7) Speed Kilometers Per Hour
8) K = Kilometers Per Hour
9) FAA mode indicator (NMEA 2.3 and later)
10) Checksum
Module / Klassen
für Empfang und Auswertung der
NMEA-Sentences:
!
BluetoothListener
!
NMEADecoder
Klasse BluetoothListener
!
Konfiguriert den Serial Port
!
Permanentes Lesen der serielle Schnittstelle, in
diesem Fall das Bluetooth-Signal eines mobilen
GPS-Empfängers
!
Konstruiert sich als Hilfsklasse einen NMEADecoder zur Signalentschlüsselung
Event-Handler des BluetoothListener
// Event-Handler prüft ab, ob serielle Schnittstelle neue Daten
// empfangen hat und ruft zugehörige Methode des Handlers auf
port.DataReceived += new
SerialDataReceivedEventHandler(port_DataReceived);
// Event-Handler prüft ab, ob NMEA-Decoder gültige Koordinaten
// empfangen hat und ruft zugehörige Methode des Handler auf
decoder.CoordReceived += new
NmeaDecoder.CoordReceivedEventHandler(decoder_CoordReceived);
// Event-Handler prüft ab, ob NMEA-Decoder gültige Zeitwerte empfangen
// hat und ruft zugehörige Methode des Handler auf
decoder.TimeDateReceived += new
NmeaDecoder.TimeDateReceivedEventHandler(decoder_TimeDateReceived);
// Event-Handler prüft ab, ob NMEA-Decoder gültigen Kurs und Geschwindig// keit empfangen hat und ruft zugehörige Methode des Handler auf
decoder.TrackSpeedReceived += new
NmeaDecoder.TrackSpeedReceivedEventHandler(decoder_TrackSpeedReceived);
Klasse NMEADecoder
!
Zum Entschlüsseln der NMEA-Sentences
aufgrund des NMEA 0183 Standards
!
Methode decode() zur Decodierung der
Informationen
!
Sentence wird verifiziert
!
Passende Events werden eventuell ausgelöst
Kreislauf der Ereignisse
Sequenzdiagramm am Beispiel einer
empfangenen Zeitinformation
Grafik-Thread
BluetoothListener
-Konfiguration der seriellen
Schnittstelle
startReading()
port.DataReceived-Event löst
port_dataReceived aus
-Eventuell Update()
Decoder_TimeDateReceived()
aus
-Errechnung des Sonnenstands
aus Zeitwerten
-Benachrichtigen des Grafik
Thread durch Event
NMEADecoder
decode()
-Ruft isVerificated() auf
-Verwirft Nachricht und kehrt
zum Polling zurück oder
-Extrahieren der Werte aus
NMEA-Sentence
decoder.TimeDateReceivedEvent löst
Module BluetoothListener,
NMEADecoder
!
Durch das Ereignis/Handler-Design ist das
Modul gut in ein GUI einzubinden
!
Kompakt und damit ideal für mobile
Systeme mit wenig Hauptspeicher
Testen und Debugging mittels
geeigneter Tools
www.geocities.de/ErdeSonne
GPS Utility zum Vergleichen
Schon implementiert
!
Fortlaufende Anzeige der Karten mit
Zoomfunktion
!
GPS-Daten Auslesen und Aufbereiten
(Ort, Sonnenstand, Track, Speed)
Und jetzt in die Praxis ...