Turbomodus beim Raspberry Pi

Die Echtzeitberechnungen für DGPS beanspruchen das Raspberry Pi bis an die Grenzen seiner Leistungsfähigkeit. Insbesondere wenn der Receiver über USB oder gar BT connected ist, liegt das Load Average gerne dauerhaft über eins. Glücklicherweise kann der CPU-Takt per Software höher getaktet werden. Ein stabiler Betrieb ist so auch bis 900MHz möglich (bei unserem war mehr nicht ohne drop outs auf den seriellen Ports zu haben). Im alltäglichen Einsatz grade bei rechenintensiven Prozessen bedeutet das aber immerhin eine Steigerung von fast 20%.

Man kann die Übertaktung mit Hilfe einer kompletten Neuinstallation durchführen. Allerdings bedeutet das, dass sämtliche Pakete und gegenebenfalls auch selbst compilierte Programme neu installiert werden müssen. Grade bei der Verwendung für die RTKLib ist das ein nicht hinzunehmender Aufwand. Stefan Rauth hat in seinem Blog Funkenstrahlen beschrieben, wie es ohne Neuinstallation geht.

GPS-related Community Projekte

Es gibt verschiedenste Projekte, die sich Aufgaben gestellt haben und mit Themen beschäftigen die direkt oder indirekt mit OpenDGPS zu tun haben. Hier eine kurze, unvollständige Liste:

goGPS

Aus Forschungsarbeiten an den Universitäten von Osaka und Mailand hat Eugenio Realini ein OSS-Paket gestartet, dass die Ortung auf der Basis von DGPS-Informationen in Echtzeit berechnet. Ursprünglich wurde es 2009 für Mathlab entwickelt und ist inzwischen auf Java portiert worden. Der Initiator hat in seiner langfristigen Planung ebenfalls den Betrieb eigener Referenzstationen vorgesehen.

Die Genauigkeit, die mit goGPS erreichbar sind, liegt je nach Qualität der Referenzdaten bei unter einem Meter.

OSGeo

Als Metaorganisation und Inkubator hat sich OSGeo zum Ziel gesetzt, freie Projekte die sich mit dem Thema Locationservice und GPS-Software beschäftigen zu unterstützen und zu koordinieren. Mit an Board sind beispielsweise GeoServer, ein OSS Tilemap Server und GeoMOOSE ein JavaScript-Framework für verteilte Kartendaten.

OpenLayers

Als JavaScript-Bibliothek bietet OpenLayers jeder WebSite die Möglichkeit, Kartenmaterial wie die von OpenStreetMaps zu verwenden.

ZOO Project

Bei ZOO handelt es sich um ein Projekt, das als Web Processing Service fungiert. Dabei werden öffentlich zur Verfügung stehende georeferenzierte Daten als Basis für Berechnungen und Ansichten verwendet. Den ZOO Kernel gibt es für alle Betriebssysteme so, dass einem Einsatz im heimischen Environment nichts entgegenspricht.

GPSTk

Von der Uni Austin kommt diese Sammlung verschiedenster Tools gebündelt als Bibliothek. Das Ganze ist in C++ geschrieben und lässt sich Unixen und unter Windows kompilieren und in eigenen Programmen verwenden. Neben Objektstrukturen für Geo-Daten enthält es zum Beispiel auch eine Bibliothek für die mathematischen Grundlagen und sogar ein atmosphärisches Modell um Laufzeitveränderungen berechnen zu können. Die Sammlung ist unter LGPL lizensiert.

Navilock NL-507TTL u-blox TTL Modul

So sieht das Navilock NL-507 TTL mit dem u-blox LEA-4 aus:

Vorder- und Rückseite der Platine. Etwas über 2 cm und relativ schwer. Aber mit dem u-blox den man überzeugen kann, die Rohdaten rauszugeben. (Nach wie vor zu kaufen … bei Klick.)

Wie man aus dem Chip die Rohdaten rausbekommt obwohl es nur ein LEA-4 (ohne ‘T’) ist und damit eigentlich die Daten nicht freiwillig hergibt wird in einem Openmoko-Forum und in einem Thread des wichtigsten GNSS-Forums Deutschlands beschrieben.

Open Source: GNSS Software Defined Receiver

Im Frühjahr starteten etliche Entwickler die Arbeit an einem Projekt, das zukünftig die GNSS-Branche durcheinander würfeln dürfte. Auf der Basis der RTKLIB hatte Michele Bavaro herkömmliche USB-Fernsehempfänger zu GPS-Receivern modifiziert. Bei bestimmten Geräten war es möglich, die Signale von GPS-Satelliten zu extrahieren und daraus die Position zu berechnen.

Auf der Basis seiner Grundlagenforschung hat sich ein Projekt gegründet, dass die dafür notwendige Software für verschiedene Plattformen und Receiver verfügbar machen möchte. Interessant daran sind die auf etlichen Sticks verbauten FPGAs. Das eigentliche Signalprozessing kann damit direkt auf den Receivern stattfinden.

 

Eichung einer festen DGPS-Station

Das OpenDGPS-Projekt hat eigentlich ein Henne-Ei-Problem: Wie können die Fixstationen ohne Hardware wie ein Leica GRX1200+ (Richtpreis: € 14.000) möglichst exakt geeicht werden? Die Genauigkeit die die mobilen Stationen ermitteln können hängt wesentlich von der Genauigkeit der festen Stationen ab. Jede Abweichung um wenige Zentimeter führt zwangsläufig zu mindestens dieser Abweichung bei den mobilen Einheiten.

Die Berliner Mitte liegt in Kreuzberg. (Quelle: siehe Link)

Glücklicherweise gibt es Vermessungspunkte. Diese existieren überall im Land und sind je nach Typ zwischen unter zehn Zentimeter bis hin zu Millimeter genau. Mit Hilfe dieser Vermessungspunkte kann jede mobile Station temporär zu einer fixen Station umgewandelt werden. Einfach einen Punkt in der Nähe der zu eichenden Station suchen und mit einem mobilen Gerät dorthin fahren. Allerdings muss man darauf achten, dass es sich um Punkte handelt, die eine freie Sicht auf den Himmel gestatten. (Der auch sonst sehr GPS-umtriebige Ronald J. van der Kamp aus Holland hat übrigens ausführlich beschrieben, wie man so einen Punkt vermessen kann.)

Da man die Korrekturen mit der RTKLIB auch nachträglich berechnen kann, bedarf es nicht mal einer bestehenden Online-Verbindung. Eine Online-Verbindung hätte allerdings den Vorteil, dass das Signal für mehrere Fixstationen als weiteres Korrektursignal verwendet werden könnte und mehrere Stationen gleichzeitig geeicht werden könnten.

Raspberry Pi oder Goosberry oder welche Beere?

Das Raspberry Pi hat gezeigt, dass das Interesse an billigen kompakten ARM-basierten Boards groß ist. So groß, dass die Briten lange nicht liefern konnten. Dieser Bedarf hat Konkurrenten auf den Plan gerufen. Ein sehr interessantes Angebot ist das Gooseberry-Board. Mit rund 60€ ist es zwar teurer als das Original aber dafür auch in manchen Punkten wesentlich besser ausgestattet.

Es wird betrieben von einem A10 ARM-Prozessor mit 1GHz und ist damit wesentlich schneller als das Raspberry Pi. Von Hause aus ist es bereits mit einem WLAN-Chip für b/g/n ausgestattet. Da der Ethernet-Port fehlt ist es damit leider nicht wirklich für den Ausseneinsatz geeignet. Allzu häufig dürfte die automatische WLAN-Connection nicht so ohne weiteres funktionieren und wer dann keinen HDMI-fähigen Bildschirm dabei hat ist aufgeschmissen, denn einen RGB-Anschluss hat das Googberry ebenfalls nicht. Es fehlt tut leider auch ein IO-Port. Es handelt sich also eigentlich nur um ein typisches Android-Design ohne Display, Touch und Gehäuse. So verwundert es auch nicht, dass es bereits mit einem installierten Android daherkommt.

Die Hardware des Samsung Galaxy S3 als eigenes Board. (Quelle: siehe Link)

Eine weitere Alternative ist das ODROID-X. Als offene Plattform ist es besonders gut dokumentiert. Allerdings kommt es mit kanpp 100€ schon langsam in die Region des älteren aber ebenfalls gut dokumentierten Beagleboard. Als Prozessor kommt der gleiche zum Einsatz, der im Galaxy S3 steckt und der hat immerhin 4 Cores und läuft mit 1.4GHz und hat 1GByte DDR2 RAM. Es bringt also genug Power, um beispielsweise Filme gleich in Echtzeit zu kodieren oder bereits ein neuronales Netz zu betreiben, das die Route eines Robots steuert.

[Update] Über Golem kam die Nachricht über ein weiteres Boad. Diesmal noch mit erheblich mehr Power ausgestattet. Auf der Basis von zwei ARMs Cortex-A15 mit 1,7 GHz getaktet und 2 GByte bestückt. Das Board wird entgegen dem Artikel für $130 verkauft. Spannend an dem Board ist vor allem das optional erhältliche 7″-Touchdisplay für ca. $250. [/Update]

Node.js und GPS

Node.js ist momentan das dynamischte Projekt im Programmiereruniversum. Da es jedoch von Grund auf neu entwickelt wurde gibt es selbstverständlich noch nicht so viele Bibiotheken wie etwa bei Python oder Perl. Allerdings gibt es seit kurzem eine GPS-Bibliothek. Sie liefert die Koordinaten wenn es Zugriff auf einen gpsd hat. Dadurch kann es sich sowohl um die Daten eines echten GPS-Receivers handeln oder aber um Daten die von anderen Diensteanbietern im Netz.

Zusammen mit dem interessanten Projekt Hardware Control Suite für node.js (das sich jedoch noch in einem sehr frühen Stadium befindet *hüstel*) hat man übrigens alles, was man braucht um einen Roboter zu steuern ;)

Die spinnen doch! (die bei der Bahn)

OpenPlanB ist sicher eines der spannendsten Projekte im Bereich Open Data. Die Fahrplandaten der Deutschen Bahn wurden extrahiert und als lesbares Format öffentlich gemacht. Umso überraschter muss man von der Reaktion der Bahn darauf sein. Diese hat den Initiator heute in einem offenen Brief der Straftat bezichtigt und behauptet er würde der Open-Data-Bewegung einen Bärendienst erweisen.

Es ist immer wieder erstaunlich, dass es als Verbrechen gilt Daten aus ihren Gefängnissen zu befreien. Dabei dürfte inzwischen auch dem letzten Bürokraten klar sein, dass es ein Recht des Bürgers ist auf Daten zuzugreifen, die mit seinen Mitteln gesammelt wurden.

Differential GPS

Es gibt viele gute Quellen, die Differential GPS erklären. Eine DGPS-Station empfängt die Signale von verschiedenen GPS-Satelliten und errechnet für jeden einzelnen das Delta, das zum Beispiel durch die Ionosphäre bewirkt wird. Dieses Signal wird dann die mobilen Stationen in der Nähe gesendet. (Das bedeutet übrigens auch, dass Signalverzerrungen die durch die direkte lokale Umgebung entstehen – Gebäude – nicht mit DGPS rausgerechnet werden können.)

Der Übertragungsweg ist im Prinzip egal. Wichtig ist, dass die mobile Station über einen GPS-Receiver verfügt, der seinerseits Zugriff auf die Rohdaten der Satelliten-Signale bietet. Das ist leider nur bei den wenigsten gegeben. Die mobile Station benötigt natürlich nur die Daten von den Satelliten, die es selbst grade sieht.

Der einfachste Weg, um die Daten an die mobilen Stationen zu bekommen, ist NTRIP (Networked Transport of RTCM via Internet Protocol). Es basiert auf http und kann relativ leicht als REST-Service mit XML/JSON umgesetzt werden. Falls auf der mobilen Station kein IP zur Verfügung steht kann man aber auch auf Funktechnik wie den NTX2 zurückgreifen.

Interessant ist, dass ein DGPS in bestimmten Situationen keine geeichte Basisstation benötigt. Entweder kann man die Daten – beispielsweise bei der Erfassung für OpenStreetMap oder der Vermessung eines Grundstücks – nachträglich korrigieren. Oder, man hat eine Situation – beispielsweise für einen lokalen Drohnenflug – in der es genügt, exakte Angaben lediglich in Bezug auf die Basisstation.

Einsatzzwecke für OpenDGPS

Mit einem funktionieren und dichten OpenDGPS-Netz könnten mobile Stationen (sogenannte Rover) ihre eigene Position in Echtzeit bis auf wenige Zentimeter genau bestimmen. Aber wofür könnte man dies konkret einsetzen?

OpenStreetMap

Der wohl wichtigste Einsatzzweck dürfte natürlich die Erfassung von OpenStreetMap-Daten sein. Dieses unglaubliche Projekt zeigt die Power der Community. Während die meisten dieser Daten schon lange in mehr oder weniger guter Qualität in Amtsstuben vor sich hin schimmeln und nur gegen harte Währungen und nur unter unzumutbaren Lizenzen verwendet werden können hat die Crowd innerhalb weniger Jahre die Infrastrukur und die Daten für den freien Gebrauch geschaffen.

Mit Hilfe von OpenDGPS könnte die Datenqualität bereits bei der Erfassung erheblich verbessert werden. Fusswege, Eingänge oder Hydranten würden zukünftig fast blind zu finden sein. Wahrscheinlich könnte OpenStreetMap damit wesentlich bessere Daten haben als alle kommerziellen Dienste.

Autonome Copter und Rover

Eine begeisterte Community hat sich der Programmierung autonomer Copter oder Rover verschrieben. So findet beispielsweise am 5. Oktober in Berlin ein Workshop zum programmieren der AR Drone 2.0 unter node.js statt.

Bisher sind autonome Copter nur eingeschränkt einsetzbar weil die exakte Positionierung mit hohen Kosten für kommerzielle DGPS-Dienste verbunden sind. Auf der Basis von OpenDGPS könnten sich solche Geräte wesentlich besser orten. Insbesondere die Höhenangaben würden hilfreich sein. Interessant dabei ist, dass der Einsatz auch dann möglich ist, wenn in der Region kein verlässliches DGPS-Signal existiert. Mit Hilfe einer festen Station könnte der Copter oder Rover die relative Position ermitteln. Mit nachträglichem Prozessing der Daten liesse sich die genaue Flugbahn später ermitteln.

Übrigens würden autonome Drohnen mit exakter Positionierung sogar einen Fotoservice für OpenStreetMap ermöglichen.

Self-Monitoring

Eines der Buzzwords in Businessplänen der StartUp-Szene ist der Begriff des Self-Monitoring. Gemeint ist der Wunsch vieler Leute, Daten über das eigene Leben zu erheben. Egal ob das Gewicht, die gelaufenen Kilometer oder die aktuellen Nagellackkreationen, there is an app for that!

Grade für Sportler im Outdoor-Bereich ist die Speicherung der exakten Strecken interessant. Bergsteiger, die später in Google-Earth die Tour nachspielen können oder Segelflieger, die Kameraaufzeichnungen mit zentimetergenauen Angaben versehen können dürften sich über einen offenen DGPS-Dienst freuen.

Es dürfte noch viele weitere Möglichkeiten geben, OpenDGPS sinnvoll oder weniger sinnvoll einzusetzen. Egal ob Geocaching oder die Unterstützung von Hilfseinsätzen in Notfällen, letztlich entscheidet die Community was man daraus machen kann.